Настраиваем OpenConnect middle server для доступа к закрытому контуру

В этой заметке рассмотрим работу OpenConnect сервера в роли промежуточного сервера для доступа к закрытой инфраструктуре.

Сразу обозначу важный момент: основная цель здесь не в том, чтобы ещё раз поднять обычный ocserv. Этому у меня уже посвящена отдельная инструкция. Здесь интереснее другая часть: middle server, который принимает подключения от пользователей, сам поднимает клиентское OpenConnect-подключение к закрытому контуру и дальше маршрутизирует трафик.

Предисловие

📝 Сперва разберёмся с определением:

В моём случае задача была следующая: есть закрытая инфраструктура, доступная только через защищённую точку входа. При этом мне нужно было выдать доступ пользователям не напрямую в эту точку, а через отдельный промежуточный сервер, которым я могу управлять независимо.

Для этого я собрал Docker-образ, в котором рядом с ocserv работает ещё и клиент OpenConnect. Получается такая схема:

• пользователь подключается к middle server;
• middle server держит своё подключение к private server;
• трафик пользователя уходит дальше через клиентский туннель middle server;
• при необходимости через этот туннель уходит не весь трафик, а только выбранные домены и подсети.

Чуть подробнее о том, что умеет образ:

• Поднимать обычный OpenConnect-сервер для входящих подключений пользователей;
• Поднимать исходящее OpenConnect-подключение из контейнера к private server;
• Перенаправлять весь клиентский трафик в этот upstream-туннель;
• Перенаправлять только выборочный трафик по списку доменов и подсетей;
• Обновлять списки доменов и маршрутов без перезапуска контейнера;
• Автоматически настраивать nftables, policy routing и dnsmasq;
• Работать с несколькими upstream-профилями для простого failover;
• Управляться через один файл .env.

Подготовка

Далее предполагается, что у вас есть два Linux-сервера:

• private server - сервер, через который уже доступна закрытая инфраструктура;
• middle server - промежуточный сервер, к которому будут подключаться пользователи.

Также предполагается, что на серверах:

• выполнены базовые настройки Linux;
• у пользователя есть привилегии sudo;
• установлен и запущен Docker Engine.

Я буду использовать реальные домены, чтобы можно было получить валидные TLS-сертификаты от Let’s Encrypt. Для простого теста можно обойтись и внутренними сертификатами: если сертификат не примонтирован в ./data/ssl/live/$OC_SRV_CN/, entrypoint скрипт сгенерирует внутренний CA и серверный сертификат сам.

Вводные данные примера из статьи:

Оба сервера работают под управлением Debian GNU/Linux 13-й версии.

Настройка private server

На private server нам нужен обычный ocserv, к которому middle server сможет подключиться как OpenConnect-клиент.

Подключаемся к private server по защищённому протоколу SSH и работаем от root:

ssh private.r4ven.me

sudo -i

Создаём рабочую директорию:

mkdir -vp /opt/openconnect

cd /opt/openconnect

Создаём файл описания сервисов:

vim compose.yaml

---

services:
  certbot:
    image: certbot/certbot
    container_name: certbot
    restart: no
    stop_grace_period: 5s
    cpus: 0.5
    mem_limit: 512M
    environment:
      TZ: ${TZ}
    hostname: certbot
    volumes:
      - ./data/ssl:/etc/letsencrypt
    entrypoint: >
      sh -c "
        certbot certonly --non-interactive --keep-until-expiring --standalone --preferred-challenges http --agree-tos --email ${OC_USER_EMAIL} -d ${OC_SRV_CN}; exit 0;
      "
    ports:
      - "80:80"

  openconnect:
    depends_on:
      certbot:
        condition: service_completed_successfully
    build:
      context: .
      dockerfile: Dockerfile
    image: r4venme/openconnect:v1.4-client
    container_name: openconnect
    restart: always
    stop_grace_period: 30s
    cpus: 1
    mem_limit: 512M
    cap_add:
      - NET_ADMIN
      - NET_RAW
    hostname: openconnect
    env_file:
      - .env
    volumes:
      - ./data/:/etc/ocserv
    devices:
      - /dev/net/tun:/dev/net/tun
      - /dev/vhost-net:/dev/vhost-net
    ports:
      - "${OC_SRV_PORT}:${OC_SRV_PORT}/tcp"

  certbot_renew:
    depends_on:
      certbot:
        condition: service_completed_successfully
    image: certbot/certbot
    container_name: certbot-renew
    restart: unless-stopped
    stop_grace_period: 5s
    cpus: 0.5
    mem_limit: 512M
    environment:
      TZ: ${TZ}
    hostname: certbot-renew
    volumes:
      - ./data/ssl:/etc/letsencrypt
    entrypoint: >
      sh -c "
        trap exit TERM;
        while true; do
          certbot renew --non-interactive --keep-until-expiring --standalone --preferred-challenges http --agree-tos;
          sleep 24h;
        done
      "
    ports:
      - "80:80"

Создаём .env:

vim .env

Для private server достаточно серверной части. Параметры клиента и split tunneling оставляем выключенными (хотя при необходимости он также может быть и middle сервером):

# System
TZ="Europe/Moscow"

# Certbot, если используете Let's Encrypt
OC_USER_EMAIL="kar-kar@r4ven.me"

# OpenConnect server
OC_SRV_PORT="443"
OC_SRV_CN="private.r4ven.me"
OC_SRV_CA="R4ven private CA"
OC_IPV4_NET="10.11.11.0"
OC_IPV4_MASK="255.255.255.0"
OC_DNS1="8.8.8.8"
OC_DNS2="8.8.4.4"
OC_CAMOUFLAGE_ENABLE="true"
OC_CAMOUFLAGE_SECRET="secretPrivateServerWord"
OC_CAMOUFLAGE_REALM="Private service"

Запускаем:

docker compose up -d

docker compose logs -f

Теперь создадим пользователя, которым middle server будет подключаться к private server:

docker exec -it openconnect ocuser private "Private Client"

Готовый файл появится здесь:

ls -l ./data/secrets/private.p12

Копируем его во временную директорию, чтобы затем забрать на middle server:

cp -v ./data/secrets/private.p12 /tmp/private.p12

chmod 644 /tmp/private.p12

Настройка автозапуска с помощью Systemd

Когда всё проверили, можно настроить автозапуск нашего private server через systemd:

docker compose down

cat << EOF > /etc/systemd/system/openconnect.service
[Unit]
Description=OpenConnect middle server
Requires=docker.service
After=docker.service

[Service]
Restart=always
RestartSec=5
WorkingDirectory=/opt/openconnect
ExecStart=/usr/bin/docker compose up
ExecStop=/usr/bin/docker compose down

[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload

systemctl enable --now openconnect

journalctl -fu openconnect

Настройка middle server

Теперь переходим к основной части. Именно middle server будет принимать пользовательские подключения и решать, куда отправлять их трафик.

Как говорил ранее, есть поддержка двух режимов:

• Full routing - весь трафик пользователя уходит через private server;
• Split routing - через private server уходят только выбранные домены и подсети.

Начнём с общей подготовки.

С помощью scp копируем файл .p12 на middle server, затем подключаемся к нему и также переходим на root:

scp private.r4ven.me:/tmp/private.p12 middle.r4ven.me:/tmp

ssh middle.r4ven.me

sudo -i

Теперь создаём рабочую директорию, копируем в неё файл .p12 и создаём файл описания сервисов:

mkdir -vp /opt/openconnect

cd /opt/openconnect

cp /tmp/private.p12 ./

vim compose.yaml

Наполняем:

---

services:
  certbot:
    image: certbot/certbot
    container_name: certbot
    restart: no
    stop_grace_period: 5s
    cpus: 0.5
    mem_limit: 512M
    environment:
      TZ: ${TZ}
    hostname: certbot
    volumes:
      - ./data/ssl:/etc/letsencrypt
    entrypoint: >
      sh -c "
        certbot certonly --non-interactive --keep-until-expiring --standalone --preferred-challenges http --agree-tos --email ${OC_USER_EMAIL} -d ${OC_SRV_CN}; exit 0;
      "
    ports:
      - "80:80"

  openconnect:
    depends_on:
      certbot:
        condition: service_completed_successfully
    build:
      context: .
      dockerfile: Dockerfile
    image: r4venme/openconnect:v1.4-client
    container_name: openconnect
    restart: always
    stop_grace_period: 30s
    cpus: 1
    mem_limit: 512M
    cap_add:
      - NET_ADMIN
      - NET_RAW
    hostname: openconnect
    env_file:
      - .env
    volumes:
      - ./data/:/etc/ocserv
      - ${OC_CLIENT_0_CERT_FILE}:${OC_CLIENT_0_CERT_FILE}
      # - ${OC_CLIENT_1_CERT_FILE}:${OC_CLIENT_1_CERT_FILE}
      # - /etc/iproute2/rt_tables.d:/etc/iproute2/rt_tables.d
    devices:
      - /dev/net/tun:/dev/net/tun
      - /dev/vhost-net:/dev/vhost-net
    ports:
      - "${OC_SRV_PORT}:${OC_SRV_PORT}/tcp"

  certbot_renew:
    depends_on:
      certbot:
        condition: service_completed_successfully
    image: certbot/certbot
    container_name: certbot-renew
    restart: unless-stopped
    stop_grace_period: 5s
    cpus: 0.5
    mem_limit: 512M
    environment:
      TZ: ${TZ}
    hostname: certbot-renew
    volumes:
      - ./data/ssl:/etc/letsencrypt
    entrypoint: >
      sh -c "
        trap exit TERM;
        while true; do
          certbot renew --non-interactive --keep-until-expiring --standalone --preferred-challenges http --agree-tos;
          sleep 24h;
        done
      "
    ports:
      - "80:80"

Режим Full Routing

Ниже представлена схема сетевого взаимодействия, когда весь клиентский трафик отправляется через upstream-туннель middle server:

Для такого режима включаем OC_CLIENT_ENABLE и добавляем параметры подключения к private серверу:

vim .env

# System
TZ="Europe/Moscow"

# Certbot, если используете Let's Encrypt
OC_USER_EMAIL="kar-kar@r4ven.me"

# OpenConnect server
OC_SRV_PORT="443"
OC_SRV_CN="middle.r4ven.me"
OC_SRV_CA="R4ven CA"
OC_IPV4_NET="10.10.10.0"
OC_IPV4_MASK="255.255.255.0"
OC_DNS1="8.8.8.8"
OC_DNS2="8.8.4.4"
OC_CAMOUFLAGE_ENABLE="true"
OC_CAMOUFLAGE_SECRET="secretMiddleServerWord"
OC_CAMOUFLAGE_REALM="Middle service"

# OpenConnect client
# Optional: force physical uplink interface for NAT rules. Empty means auto-detect.
# OC_MAIN_IFACE="eth0"
OC_CLIENT_ENABLE="true"
OC_CLIENT_IFACE="oc-middle"
OC_CLIENT_CHECK_INTERVAL="5"
OC_CLIENT_CHECK_THRESHOLD="3"

# Number of configured OC_CLIENT_<index> profiles.
# Set to "2" when OC_CLIENT_1_* variables are enabled, "3" for OC_CLIENT_2_*, etc.
OC_CLIENT_COUNT="1"

OC_CLIENT_0_SSL_FLAG=true
OC_CLIENT_0_SERVER="private.r4ven.me"
OC_CLIENT_0_SERVER_PORT="443/?secretPrivateServerWord"
OC_CLIENT_0_CERT_FILE="/opt/openconnect/private.p12"
OC_CLIENT_0_CERT_PASS="p12SecretInBase64encode"
OC_CLIENT_0_CHECK_HOST="10.11.11.1"

# OC_CLIENT_1_SSL_FLAG=false
# OC_CLIENT_1_SERVER="private2.example.com"
# OC_CLIENT_1_SERVER_PORT="443/?SecretUrl"
# OC_CLIENT_1_CERT_FILE="/opt/openconnect/private2.p12"
# OC_CLIENT_1_CERT_PASS="p12SecretInBase64encode"
# OC_CLIENT_1_CHECK_HOST="10.12.12.1"

Разбор параметров OC_CLIENT

Теперь подробнее разберём параметры, которые отвечают за исходящее OpenConnect-подключение из middle server в private server.

Для каждого upstream-профиля используется индекс: 0, 1, 2 и так далее.

Логика работы следующая:

• occlient.sh ждёт, пока локальный ocserv начнёт слушать порт;
• загружает профиль OC_CLIENT_0_*;
• запускает openconnect с указанным .p12;
• создаёт таблицу маршрутизации 430 oc_vpn;
• в режиме full routing добавляет для подключившегося пользователя policy rule в таблицу 430;
• регулярно проверяет OC_CLIENT_0_CHECK_HOST;
• при проблемах переподключается или переключается на следующий профиль.

printf '%s' 'password-for-private-p12' | base64

- ${OC_CLIENT_0_CERT_FILE}:${OC_CLIENT_0_CERT_FILE}

Несколько upstream-профилей

Если закрытая инфраструктура доступна через несколько точек входа, можно описать несколько профилей:

OC_CLIENT_COUNT="2"

OC_CLIENT_0_SSL_FLAG="true"
OC_CLIENT_0_SERVER="private.r4ven.me"
OC_CLIENT_0_SERVER_PORT="443/?secretPrivateServerWord"
OC_CLIENT_0_CERT_FILE="/etc/ocserv/secrets/private.p12"
OC_CLIENT_0_CERT_PASS="p12SecretInBase64encode"
OC_CLIENT_0_CHECK_HOST="10.11.11.1"

OC_CLIENT_1_SSL_FLAG="true"
OC_CLIENT_1_SERVER="private2.r4ven.me"
OC_CLIENT_1_SERVER_PORT="443/?secretPrivate2ServerWord"
OC_CLIENT_1_CERT_FILE="/opt/openconnect/private2.p12"
OC_CLIENT_1_CERT_PASS="anotherP12SecretInBase64"
OC_CLIENT_1_CHECK_HOST="10.12.12.1"

Если текущий профиль перестаёт проходить health check, скрипт сначала пытается переподключиться к нему же. Если это не помогает, он переключается на следующий профиль. И так по кругу, пока куда-нибудь не подключится и health check будет успешным.

Запуск middle server

Запускаем middle server:

docker compose up -d

docker compose logs -f

Создаём пользователя уже на middle server:

docker exec -it openconnect ocuser middleuser "Middle User"

Копируем клиентский .p12 в /tmp:

cp -v ./data/secrets/middleuser.p12 /tmp/middleuser.p12

chmod 644 /tmp/middleuser.p12

Проверка Full Routing

На клиентской машине скачиваем .p12 файл:

scp middle.r4ven.me:/tmp/middleuser.p12 ./

Подключаемся к middle server:

sudo openconnect -c ./middleuser.p12 'middle.r4ven.me/?secretMiddleServerWord'

Проверяем внешний IP:

curl ifconfig.me

В ответ должен прийти внешний IP private server, потому что весь трафик клиента ушёл через middle server, а затем через upstream-туннель на private server.

Дополнительно можно посмотреть маршрут:

mtr -wb linuxmint.com

Он должен идти через middle server (10.10.10.1) затем через private server (10.11.11.1).

Режим Split Routing

Теперь рассмотрим более интересный режим. В нём пользователь подключается к middle server, но через private server уходит только тот трафик, который мы явно указали.

Например:

• ifconfig.me и example.com отправляем через private server;
• подсеть 192.168.25.0/24 отправляем через private server;
• весь остальной интернет остаётся на стороне клиента и не заворачивается в private server.

Схема получается такая:

Для этого включаем клиентскую часть и добавляем split tunneling:

# System
TZ="Europe/Moscow"

# Certbot, если используете Let's Encrypt
OC_USER_EMAIL="kar-kar@r4ven.me"

# OpenConnect server
OC_SRV_PORT="443"
OC_SRV_CN="middle.r4ven.me"
OC_SRV_CA="R4ven CA"
OC_IPV4_NET="10.10.10.0"
OC_IPV4_MASK="255.255.255.0"
OC_DNS1="8.8.8.8"
OC_DNS2="8.8.4.4"
OC_CAMOUFLAGE_ENABLE="true"
OC_CAMOUFLAGE_SECRET="secretMiddleServerWord"
OC_CAMOUFLAGE_REALM="Middle service"

# OpenConnect client
# Optional: force physical uplink interface for NAT rules. Empty means auto-detect.
# OC_MAIN_IFACE="eth0"
OC_CLIENT_ENABLE="true"
OC_CLIENT_IFACE="oc-middle0"
OC_CLIENT_CHECK_INTERVAL="5"
OC_CLIENT_CHECK_THRESHOLD="3"

# Number of configured OC_CLIENT_<index> profiles.
# Set to "2" when OC_CLIENT_1_* variables are enabled, "3" for OC_CLIENT_2_*, etc.
OC_CLIENT_COUNT="1"

OC_CLIENT_0_SSL_FLAG=true
OC_CLIENT_0_SERVER="private.r4ven.me"
OC_CLIENT_0_SERVER_PORT="443/?secretPrivateServerWord"
OC_CLIENT_0_CERT_FILE="/opt/openconnect/private.p12"
OC_CLIENT_0_CERT_PASS="p12SecretInBase64encode"
OC_CLIENT_0_CHECK_HOST="10.11.11.1"

# Split tunneling
OC_SPLIT_ENABLE="true"
OC_SPLIT_TUNNEL_DNS="true"
OC_SPLIT_ROUTES='
192.168.25.0/24
10.1.0.0/16
1.1.1.1/32
'
OC_SPLIT_DOMAINS='
ifconfig.me
example.com
gnu.org
'

Разбор параметров OC_SPLIT

Теперь разберём split tunneling. Он включается только вместе с OC_CLIENT_ENABLE=true, потому что без upstream-туннеля разделять трафик просто некуда.

При включении split tunneling внутри контейнера происходит несколько вещей:

• создаётся таблица маршрутизации 431 oc_split;
• добавляется правило fwmark 0x1 table 431;
• для выбранных IP используется маршрут по умолчанию через OC_CLIENT_IFACE;
• dnsmasq начинает слушать DNS-адрес middle server внутри VPN-подсети;
• ocserv.conf обновляется так, чтобы VPN-клиенты получили DNS middle server;
• домены из списка превращаются в правила dnsmasq вида nftset=/domain/4#ip#oc_nat#oc_set;
• nftables помечает IP из oc_set, и только такой трафик уходит в upstream-туннель.

Попробую описать чуть понятнее:

• При запросе к домену из заранее заданного списка dnsmasq получает IP-адреса от вышестоящего DNS-сервера, возвращает их клиенту и добавляет в nftset-множество.
• Пакеты, направленные к IP-адресам из этого nftset, маркируются с помощью правил фаервола.
• Маркированный трафик перенаправляется в отдельную таблицу маршрутизации, в которой задан маршрут через OpenConnect-туннель ведущий к private server. Остальной трафик идёт через основной интерфейс middle server.

Одним из преимуществ данного способа является формирование nftset по wildcard. Другими словами, вы добавляете домен example.com в список и при обращении к доменам нижнего уровня, например test.example.com, трафик автоматически пойдет через OpenConnect туннель.

Подобную схему я уже ранее реализовывал в статье по подключению роутера на OpenWRT к OpenConnect серверу.

Домены

Домены можно указать сразу в .env:

OC_SPLIT_DOMAINS='
ifconfig.me
example.com
gnu.org
'

При первом запуске entrypoint скрипт положит их в файл:

./data/domains.txt

После запуска удобнее редактировать уже этот файл:

vim ./data/domains.txt

Формат простой:

ifconfig.me
example.com
gnu.org

Пустые строки и строки с # игнорируются.

Подсети и IP-адреса

Маршруты можно также указывать через .env:

OC_SPLIT_ROUTES='
192.168.25.0/24
10.1.0.0/16
1.1.1.1/32
'

Или после запуска редактировать файл:

vim ./data/routes.txt

Формат такой же простой:

192.168.25.0/24
10.1.0.0/16
1.1.1.1/32

Изменения в domains.txt и routes.txt подхватываются автоматически. Контейнер перезапускать не нужно. В случае обновления переменных в .env придётся перезапускать контейнер.

Запуск middle server

docker compose down

docker compose up -d

docker compose logs -f

Проверка Split Routing

Подключаемся к middle server на клиенте:

sudo openconnect -c ./middleuser.p12 'middle.r4ven.me/?secretMiddleServerWord'

Проверяем домены из списка:

curl ifconfig.me

curl eth0.me

Если ifconfig.me добавлен в OC_SPLIT_DOMAINS, он должен открываться через private сервера. Если eth0.me в список не добавляли, он должен показать внешний IP middle сервера.

Проверяем маршруты:

mtr -wb example.com

mtr -wb linuxmint.com

mtr -wb 1.1.1.1

Обратите внимание на второй hop: для адресов из списка трафик должен уходить в сторону middle/private цепочки, а для остальных адресов - идти обычным путём.

Пример обновления списков доменов и подсетей на лету

Например, добавим домен и отдельный IP:

echo 'eth0.me' >> ./data/domains.txt

echo '9.9.9.9/32' >> ./data/routes.txt

Через некоторое время на клиенте можно сбросить DNS-кеш и проверить:

resolvectl flush-caches

curl eth0.me

mtr -wb 9.9.9.9

Запуск в режиме network_mode: host

Хоть и работа сервисов в изолированной Docker среде - это преимущество, оно же имеет и недостатки. В случае работы клиентского подключения к private server внутри контейнера, скорость клиентов, подключённых к middle server может быть, в среднем, в 3 раза ниже.

Если вам критически важна скорость, то можно запустить middle server в сетевом режиме хоста. Для этого просто замените директиву ports на network_mode: host.

Пример:

---

services:
  openconnect:
    depends_on:
      certbot:
        condition: service_completed_successfully
    build:
      context: .
      dockerfile: Dockerfile
    image: r4venme/openconnect:v1.4-client
    container_name: openconnect
    restart: always
    stop_grace_period: 30s
    cpus: 1
    mem_limit: 512M
    cap_add:
      - NET_ADMIN
      - NET_RAW
    hostname: openconnect
    env_file:
      - .env
    volumes:
      - ./data/:/etc/ocserv
    devices:
      - /dev/net/tun:/dev/net/tun
    network_mode: host

Я постарался по максимуму адаптировать логику работы скриптов внутри контейнера так, чтобы они идентичным образом работали и в сетевом режиме хоста.

Настройка автозапуска с помощью systemd

Когда всё проверили, можно настроить автозапуск нашего middle server через systemd:

docker compose down

cat << EOF > /etc/systemd/system/openconnect.service
[Unit]
Description=OpenConnect **middle server**
Requires=docker.service
After=docker.service

[Service]
Restart=always
RestartSec=5
WorkingDirectory=/opt/openconnect
ExecStart=/usr/bin/docker compose up
ExecStop=/usr/bin/docker compose down

[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload

systemctl enable --now openconnect

journalctl -fu openconnect

Полезные команды для диагностики

Посмотреть логи контейнера:

docker compose logs -f openconnect

Проверить, поднялся ли upstream-интерфейс:

docker exec -it openconnect ip addr show oc-middle0

Посмотреть policy routing:

docker exec -it openconnect ip rule show
docker exec -it openconnect ip route show table 430
docker exec -it openconnect ip route show table 431

Посмотреть nftables:

docker exec -it openconnect nft list table ip oc_nat

docker exec -it openconnect nft list chain DOCKER-USER

Посмотреть текущие домены и маршруты split tunneling:

cat ./data/domains.txt
cat ./data/routes.txt

При необходимости можно вручную очистить nftables set с доменными IP:

docker exec -it openconnect nft flush set ip oc_nat oc_set

Послесловие

Во время разработки образа было выпито не мало кружек чая и потрачено сильно больше нервов, чем планировалось. Но результат того стоил, я считаю.

В итоге получился очень удобный и гибкий инструмент для управления маршрутизацией внутри приватных сетей.

Пользователи подключаются к middle server, а дальше вы сами выбираете логику: отправлять весь их трафик через private server или пропускать туда только нужные домены и подсети.

Мне такой подход нравится тем, что он не требует раздавать пользователям прямой доступ к private server. Private-контур остаётся закрытым, а middle server можно отдельно обновлять, переносить, ограничивать и использовать как управляемую точку входа.

Уверен у многих пользователей могут возникнут различные вопросы. Смело задавайте их в Вороньем чате, в issue на GitHub или пишите мне на почту: kar-kar@r4ven.me.

Спасибо, что читаете. Всех благ!

👨‍💻Ну и…

Не забывайте про нашу телегу📱и чат 💬 Всех благ✌️

That should be it. If not, check the logs 🙂