Сервер или клиент: какой модуль OpenVPN на Pi с двумя ролями

На Pi работают два процесса OpenVPN, которые одновременно принимают роуминговых пользователей и достигают вышестоящего провайдера, и они почти ничего не делят, кроме оборудования. Один слушает входящие туннели, другой звонит наружу. Каждый читает свой каталог, и у каждого свой режим отказа. Перезапуск не того — самый распространённый способ, которым исправление клиента вместо этого роняет слушателя.

Сопоставьте имя модуля с каталогом, который он загружает

Upstream 2.6 поставляет два шаблонных модуля: [email protected] и [email protected]. Шаблон сервера запускается в /etc/openvpn/server и загружает оттуда %i.conf. Шаблон клиента запускается в /etc/openvpn/client. Экземпляр с именем roaming может существовать в обоих местах одновременно — как сервер и как клиент, с двумя несвязанными конфигурациями и без какой-либо связи между ними, кроме строки.

Спрашивайте systemd, а не файловую систему, потому что сборщики пакетов добавляют дополнительные файлы, которые могут изменить рабочий каталог или аргументы, получаемые бинарником.

systemctl list-units --type=service 'openvpn-*@*'
systemctl cat [email protected]
systemctl show -p WorkingDirectory -p ExecStart [email protected]

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

Решайте по направлению пакетов, а не по имени интерфейса

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

Это различие говорит, куда относится правило. Правило, совпадающее с интерфейсом внутри цепочки пересылки, только разрешает трафик, который маршрутизация уже выбрала; оно никогда не выбирает маршрут. Когда пакеты роумингового пользователя уходят не тем путём, цепочка для проверки — forward, а не output.

Посмотрите на сокеты, прежде чем теоретизировать. Сервер, привязанный к udp/1194, показывает слушающий сокет. Клиент показывает ассоциацию с адресом провайдера и ничего, что слушает.

ss -lunp | grep openvpn
ss -unp state established '( dport = :1194 or sport = :1194 )'

Маршрут по умолчанию одного экземпляра может перехватить ответы другого

redirect-gateway, который проталкивает вышестоящий клиент, устанавливает маршрут по умолчанию, конкурирующий со всем остальным на машине, включая ответы, которые сервер отправляет роуминговым пользователям. OpenVPN делает исключение для собственного адреса партнёра, чтобы туннель оставался доступным, но это исключение ничего не говорит о телефоне в гостиничной сети.

Симптом обычно асимметричен. Рукопожатие завершается, клиент сообщает о подключении, и трафик умирает после первого пакета ответа. Маршрутизация политик на основе источника или метка пакета, заданная на экземпляре сервера с помощью --mark, держат два потока раздельно; ни одно из этого само по себе не является полным набором правил, и обоим нужны действительные маршруты в таблице, которую они выбирают.

Проверяйте локальное решение, а не состояние туннеля, потому что ядро выбирает источник и интерфейс раньше, чем OpenVPN увидит пакет.

ip route get 203.0.113.44
ip rule show

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

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

Запишите условие остановки до изменения: потеря вышестоящего туннеля блокирует роуминговых пользователей или откатывается на собственный аплинк Pi? DNS и IPv6 тоже требуют явного ответа, потому что протолкнутый резолвер часто живёт дольше маршрута, который сделал его полезным.

systemctl restart [email protected]
systemctl is-active [email protected]
journalctl -u [email protected] -n 20 --no-pager

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