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. VLESS + TLS маскируется под Chrome браузер через fingerprint: chrome. При перезагрузке шлюза все четыре сервиса поднимаются автоматически.

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