VPN · Проксирование · Корпоративная сеть

Двойное
туннелирование:
OpenConnect
+ VLESS

...

Как мы дали 10+ офисам единый российский IP, обошли корпоративные блокировки и сделали так, чтобы трафик был неотличим от обычного HTTPS.

TCP 443 · Не блокируется
Автор Семёнов Евгений
Март 2026
Время чтения ~12 мин
Содержание
01

Зачем это нужно

У нас несколько офисов на роутерах Keenetic — и всем нужен единый выходящий IP в России. Без этого целый класс сервисов просто отваливается. Знакомая история, да?

Банки и госпорталы
Блокируют зарубежные IP на уровне сессии. Войти в личный кабинет с немецкого VPS — невозможно.
1С онлайн · CRM · ERP
Корпоративные системы с IP-whitelist. Не знают о ваших серверах и не будут знать, пока не добавишь вручную.
Контроль и безопасность
Весь трафик офиса через подконтрольный сервер. Единая точка аудита. Защищённое соединение.

Требование жёсткое: минимум возни на стороне офиса. Никаких клиентских программ, никакого «зайди на каждый компьютер и пропиши конфиг». Только VPN-подключение на самом Keenetic — и всё.

02

Проблема с обычными VPN

Стандартные решения мы перебрали и отмели — каждое по конкретной причине:

Проблема

WireGuard (UDP 51820)

Многие российские провайдеры блокируют нестандартные UDP-порты через DPI. VPN периодически не поднимается — без какого-либо сообщения об ошибке.
Проблема

OpenVPN

Требует клиентского ПО на каждом устройстве. С Keenetic работает плохо без сторонних прошивок. Сложно в поддержке.
Проблема

Готовые VPN-сервисы

Нет контроля над выходным IP. Могут заблокировать в любой момент. IP попадает в публичные blacklist. Не подходит для корпоративного применения.
03

Наше решение: двойной туннель

В итоге мы сделали двухуровневую систему. Каждый слой — независимый, решает ровно одну задачу. Ломается один — другой продолжает работать.

Офис
Устройства + Keenetic роутер
Телефоны, компьютеры, IoT — обычная офисная сеть
OpenConnect / Cisco AnyConnect · TCP 443 · выглядит как HTTPS
Уровень 1 — Transport
Сервер-шлюз · Debian 12
ocserv + xray (TPROXY) + iptables · 155.212.159.202
VLESS + TLS · маскируется под Chrome HTTPS · fingerprint: chrome
Уровень 2 — Proxying
Выходной узел в РФ
xray VLESS сервер · sudvless.itfresh.ru · 202.148.54.236
Реальные запросы
Интернет
Российский IP · 202.148.54.236
Именно этот IP видят банки, госпорталы и корпоративные системы

Уровень 1 — Transport. Keenetic поднимает Cisco AnyConnect на порту 443. Да, обычный HTTPS-порт. Заблокировать его без отключения всего интернета невозможно физически — это мы проверяли на практике не раз.

Уровень 2 — Proxying. На шлюзе трафик от роутеров перехватывается через TPROXY прямо в ядре Linux — без каких-либо агентов на клиентах. Дальше xray прозрачно гонит всё через VLESS-туннель на выходной узел в России. VLESS при этом прикидывается обычным TLS-трафиком Chrome. Снаружи — ничем не отличается.

04

Что происходит под капотом

Покажу полный путь пакета, когда устройство в офисе открывает любой сайт:

Шаг 1Запрос с устройства (телефон, ноутбук) поступает на Keenetic роутер.
Шаг 2Keenetic отправляет трафик через OpenConnect туннель на сервер-шлюз.
Шаг 3На шлюзе iptables перехватывает пакет через механизм TPROXY и помечает его fwmark 0x1 — без изменения содержимого.
Шаг 4xray получает помеченные пакеты через TPROXY listener (порт 12345) и прозрачно проксирует через VLESS на выходной узел.
Шаг 5Выходной узел делает реальный запрос в интернет — его IP видят все сайты.
Шаг 6Ответ идёт обратно по той же цепочке.
Суть
Ни одно приложение на устройстве не знает, что работает через двойной прокси. Всё настраивается только на уровне роутера и серверов. Никаких клиентских программ, настроек браузера или ручных конфигов.
05

Компоненты системы

ocservОткрытая реализация Cisco AnyConnect сервера. Принимает подключения от Keenetic на порту 443 TCP+UDP. Keenetic имеет встроенную поддержку этого протокола — никаких доп. прошивок.
xray (TPROXY)Работает в двух режимах одновременно: TPROXY listener на порту 12345 (прозрачно принимает трафик от клиентов) и VLESS outbound (отправляет трафик на выходной узел).
iptables (OCVPN)Кастомная цепочка. Перехватывает весь трафик от OpenConnect клиентов (интерфейсы vpns+) и перенаправляет в xray через механизм TPROXY ядра Linux.
ip routing (fwmark)Специальные правила маршрутизации: fwmark 0x1 → table 100 → local route on lo. Позволяют ядру доставлять помеченные TPROXY пакеты в сокет xray. Без этих правил TPROXY физически не работает.
tproxy-routing.serviceSystemd-сервис, который восстанавливает ip rule/ip route после каждой перезагрузки сервера. Без него всё работает до первого reboot.
06

Установка шаг за шагом

Что понадобится: чистый Debian 12, отдельный VPS с xray в режиме VLESS+TLS — это выходной узел, — и root по SSH. Больше ничего.

01

Обновление системы

bash
apt update && apt upgrade -y
apt install -y curl wget iptables-persistent               netfilter-persistent ocserv openssl
02

Установка xray

bash
bash -c "$(curl -L https://github.com/XTLS/Xray-install/raw/main/install-release.sh)" @ install
03

Конфиг xray

Создайте /usr/local/etc/xray/config.json. Внутри два inbound: socks на порту 10808 — для ручной проверки, и TPROXY на 12345 — для реального трафика. Плюс VLESS outbound, смотрящий на выходной узел.

config.json
{
  "inbounds": [
    {
      "tag": "socks-in",  // для тестирования через curl
      "port": 10808, "listen": "127.0.0.1",
      "protocol": "socks"
    },
    {
      "tag": "tproxy-in",  // прозрачный прокси для офисного трафика
      "port": 12345, "listen": "0.0.0.0",
      "protocol": "dokodemo-door",
      "settings": { "network": "tcp,udp", "followRedirect": true },
      "streamSettings": { "sockopt": { "tproxy": "tproxy" } }
    }
  ],
  "outbounds": [
    {
      "tag": "vless-out",
      "protocol": "vless",
      "settings": { "vnext": [{
        "address": "ВАШ_VLESS_ДОМЕН", "port": 443,
        "users": [{ "id": "ВАШ_UUID", "encryption": "none" }]
      }]},
      "streamSettings": {
        "network": "tcp", "security": "tls",
        "tlsSettings": {
          "serverName": "ВАШ_VLESS_ДОМЕН",
          "fingerprint": "chrome"  // маскировка под браузер
        }
      }
    }
  ]
}

systemctl enable --now xray

Проверяем VLESS — в ответе должен прийти IP выходного узла, не IP шлюза:

curl -s --socks5 127.0.0.1:10808 https://api.ipify.org
04

Установка и конфиг ocserv

ssl + user
# Самоподписанный сертификат
mkdir -p /etc/ocserv/ssl && cd /etc/ocserv/ssl
openssl req -x509 -newkey rsa:2048 -keyout server-key.pem   -out server-cert.pem -days 3650 -nodes   -subj "/CN=ВАШ_IP_СЕРВЕРА"

# Создать пользователя
ocpasswd -c /etc/ocserv/ocpasswd itfresh
/etc/ocserv/ocserv.conf
auth            = "plain[passwd=/etc/ocserv/ocpasswd]"
tcp-port        = 443
udp-port        = 443
server-cert     = /etc/ocserv/ssl/server-cert.pem
server-key      = /etc/ocserv/ssl/server-key.pem
device          = vpns
ipv4-network    = 192.168.8.0/24
dns             = 8.8.8.8
route           = default
# Критично: исключить IP шлюза и VLESS-сервера из туннеля
no-route        = 155.212.159.202/255.255.255.255
no-route        = 202.148.54.236/255.255.255.255
max-clients     = 50
keepalive       = 30
dpd             = 60

systemctl enable --now ocserv
05

iptables TPROXY

bash
# Создать цепочку OCVPN
iptables -t mangle -N OCVPN
iptables -t mangle -A PREROUTING -i vpns+ -j OCVPN

# Не трогать приватные адреса
iptables -t mangle -A OCVPN -d 0.0.0.0/8     -j RETURN
iptables -t mangle -A OCVPN -d 10.0.0.0/8    -j RETURN
iptables -t mangle -A OCVPN -d 127.0.0.0/8   -j RETURN
iptables -t mangle -A OCVPN -d 172.16.0.0/12 -j RETURN
iptables -t mangle -A OCVPN -d 192.168.0.0/16 -j RETURN
iptables -t mangle -A OCVPN -d ВАШ_VLESS_IP/32 -j RETURN

# Направить в xray
iptables -t mangle -A OCVPN -p tcp -j TPROXY   --on-port 12345 --on-ip 0.0.0.0 --tproxy-mark 0x1
iptables -t mangle -A OCVPN -p udp -j TPROXY   --on-port 12345 --on-ip 0.0.0.0 --tproxy-mark 0x1

# Борьба с фрагментацией MTU
iptables -t mangle -A FORWARD -i vpns+ -p tcp   --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

netfilter-persistent save
06

IP routing для fwmark — самый важный шаг

Это правило говорит ядру Linux: помеченные TPROXY-пакеты доставить в сокет xray. Пропустите его — клиенты подключатся, но интернета не будет. Мы теряли на этом час отладки, пока не разобрались.

bash
ip rule add fwmark 0x1 table 100
ip route add local 0.0.0.0/0 dev lo table 100

# Проверка
ip rule list | grep fwmark
# 218: from all fwmark 0x1 lookup 100  ← должно быть так
Стоп
Эти правила не сохраняются после перезагрузки — в отличие от iptables. Без следующего шага после reboot сервер перестанет работать.
07

Персистентность routing rules

Теперь systemd-сервис, который поднимает ip rule при каждой загрузке — иначе после перезагрузки правило пропадёт:

/etc/systemd/system/tproxy-routing.service
[Unit]
Description=TPROXY IP routing rules for OpenConnect+VLESS
After=network.target netfilter-persistent.service xray.service
Requires=netfilter-persistent.service

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/bash -c "ip rule add fwmark 0x1 table 100 2>/dev/null || true;   ip route add local 0.0.0.0/0 dev lo table 100 2>/dev/null || true"
ExecStop=/bin/bash -c "ip rule del fwmark 0x1 table 100 2>/dev/null || true;   ip route del local 0.0.0.0/0 dev lo table 100 2>/dev/null || true"

[Install]
WantedBy=multi-user.target
bash
systemctl daemon-reload
systemctl enable --now tproxy-routing

# Финальная проверка всех сервисов
systemctl is-enabled ocserv xray tproxy-routing netfilter-persistent
# → enabled enabled enabled enabled
07

Настройка Keenetic

Вся красота архитектуры — именно здесь: настройка на стороне офиса занимает ровно 2 минуты.

Интернет → VPN → ДобавитьТип подключения: Cisco AnyConnect
Сервер155.212.159.202 · Порт: 443
Логин / ПарольУказанные при создании пользователя через ocpasswd
Проверять сертификатНЕТ — используется self-signed сертификат
Маршрутизация«Использовать как шлюз по умолчанию» — ДА. Весь трафик офиса пойдёт через VPN.
Удобство
После настройки Keenetic все устройства в офисе — телефоны, ноутбуки, принтеры — автоматически выходят в интернет через российский IP. Ничего настраивать на них не нужно.
08

Диагностика после настройки

# Все сервисы активны?
systemctl is-active ocserv xray tproxy-routing
# Keenetic'ы подключены?
ip -br addr | grep vpns
# Трафик идёт через TPROXY?
iptables -t mangle -L OCVPN -v -n | grep TPROXY
# VLESS работает (нужен IP выходного узла)
curl -s --socks5 127.0.0.1:10808 https://api.ipify.org
# Живой трафик в реальном времени
journalctl -u xray -f
# fwmark правило на месте?
ip rule list | grep fwmark

Живой трафик в логах xray выглядит так:

journalctl -u xray -f
from 192.168.8.80:56099 accepted tcp: 149.154.167.99:443 [tproxy-in >> vless-out]
from 192.168.8.201:36862 accepted tcp: 142.251.143.131:443 [tproxy-in >> vless-out]
from 192.168.8.187:49196 accepted udp: 142.251.143.142:443 [tproxy-in >> vless-out]
09

Известные грабли

Грабля 1

После перезагрузки клиенты подключаются, но интернет не работает

Причина: ip routing rules для fwmark пропали.

Проверка: ip rule list | grep fwmark — если пусто, вот причина.
Быстрое исправление: systemctl start tproxy-routing
Постоянное: убедитесь, что tproxy-routing.service enabled.
Грабля 2

Все клиенты разом отвалились и не могут залогиниться

Причина: пароль в /etc/ocserv/ocpasswd изменился.
Диагностика: journalctl -u ocserv | grep "failed authentication"
Решение: ocpasswd -c /etc/ocserv/ocpasswd itfresh, затем systemctl restart ocserv.
Keenetic'ы переподключатся автоматически в течение ~30 секунд.
Грабля 3

Петля маршрутизации: xray → VLESS → через VPN → xray → ...

Причина: в ocserv.conf нет строки no-route для IP VLESS-сервера.
Без неё Keenetic пытается отправить трафик к самому VLESS-серверу тоже через VPN-туннель — и возникает бесконечная петля.
Решение: добавить в конфиг ocserv:
no-route = ВАШ_VLESS_IP/255.255.255.255
no-route = ВАШ_ШЛЮЗ_IP/255.255.255.255
Помните
Именно поэтому мы не используем WireGuard: UDP 51820 блокируется многими российскими провайдерами через DPI. OpenConnect на TCP 443 физически невозможно заблокировать без отключения всего HTTPS-интернета.
10

Результат

10+
офисных роутеров Keenetic подключено одновременно
443
единственный порт — не отличим от HTTPS
~30с
автопереподключение Keenetic после reboot шлюза
0
дополнительных программ на устройствах сотрудников

В итоге весь офисный трафик выходит через российский IP 202.148.54.236. Соединение по 443/TCP снаружи неотличимо от обычного HTTPS — никаких характерных признаков VPN. VLESS + TLS маскируется под Chrome через fingerprint: chrome. При перезагрузке шлюза все четыре сервиса поднимаются сами, без каких-либо ручных действий.

Итог
Двойной туннель решил ровно ту задачу, для которой создавался: прозрачный для пользователей, неблокируемый по протоколу, с российским выходным IP. Настройка нового офиса занимает 2 минуты — просто добавить VPN-подключение на Keenetic.

Комментарии

Часто задаваемые вопросы

Что такое Двойноетуннелирование:OpenConnect+ VLESS?

Двойноетуннелирование:OpenConnect+ VLESS — это важный аспект системного администрирования, который позволяет настроить и оптимизировать работу IT-инфраструктуры. В данной статье подробно рассматриваются все ключевые моменты.

Как правильно настроить Двойноетуннелирование:OpenConnect+ VLESS?

Для корректной настройки Двойноетуннелирование:OpenConnect+ VLESS необходимо следовать пошаговой инструкции, представленной в статье выше. Важно учитывать особенности вашей инфраструктуры и требования безопасности.

Какие типичные ошибки возникают при работе с Двойноетуннелирование:OpenConnect+ VLESS?

Наиболее частые ошибки при работе с Двойноетуннелирование:OpenConnect+ VLESS: некорректная конфигурация, недостаточные права доступа и несовместимость версий. Рекомендуем обратиться к специалистам ITFresh для профессиональной настройки.

Официальная документация: Telegram MTProto Documentation, Debian Wiki — iptables