OpenVPN iroute и маршрут ядра: чего не хватает?

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

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

Два решения, а не один маршрут

Представьте связь между площадками, где 10.77.20.0/24 находится за одним клиентом. Маршрут ядра сервера, например ip route add 10.77.20.0/24 dev tun0, отправляет подходящие пакеты на устройство туннеля. Затем OpenVPN обращается к собственной внутренней таблице, построенной из записей iroute в каталоге конфигурации клиента, чтобы решить, какое соединение пира их получит. Без маршрута ядра пакет никогда не достигает процесса, а без маршрута пира достигает процесса и никуда не идёт.

Это разделение легко забыть, потому что одна строка маршрута в профиле клиента может выглядеть так, будто делает обе работы. Это не так: проталкивание маршрута говорит клиентам, что отправлять через туннель, тогда как iroute говорит серверу, кому принадлежит диапазон адресов за клиентом. Они живут в разных файлах, читаются разными сторонами и отказывают в противоположных направлениях.

Где место iroute и что он говорит

Запись попадает в отдельный файл клиента, названный по его common_name, в client-config-dir, в виде iroute 10.77.20.0/24. Совпадение имени файла не косметическое: OpenVPN ищет аутентифицированную личность и читает файл именно с этим именем, поэтому файл site-a действует только для клиента, чьё общее имя — site-a. Добавьте ccd-exclusive, если клиентов без такого файла нужно отвергать полностью, — это правильная настройка, когда каждый клиент является шлюзом площадки. Держите один файл на шлюз и называйте его по субъекту сертификата, который вы действительно выпускаете.

Проверьте запись с сервера, прежде чем винить удалённую локальную сеть. Файл состояния перечисляет подключённых клиентов с их общими именами, а сервер с --verb 4 записывает установку iroute в момент подключения пира. Если при подключении ничего не появляется, файл лежит в неверном каталоге или называет неверную личность.

Ловушка: файл есть, личность не та

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

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

Завершите путь за пиром

Владение пиром — это середина пути, а не конец. Клиент должен пересылать пакеты из туннеля в свою локальную сеть, то есть на этом хосте включена пересылка IP и правило брандмауэра разрешает проход. Хостам в удалённой сети нужен обратный путь для адреса туннеля: либо маршрут, указывающий назад на шлюз, либо намеренно спроектированный NAT на стороне клиента. Подтвердите настройку пересылки на клиенте с помощью sysctl net.ipv4.ip_forward, а не предполагайте значение по умолчанию дистрибутива.

Если другим клиентам VPN нужно попасть в эту подсеть, схема снова растёт: серверу нужен client-to-client, а этим клиентам нужно маршрутизировать префикс через туннель. Ничего из этого не следует из собственной таблицы маршрутов сервера.

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