pfSense OpenVPN: доступ к сети за другим маршрутизатором

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

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

Один пакет, три решения о маршрутизации

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

Отказ любого из них даёт один и тот же отчёт пользователя. Поэтому порядок отладки важнее инструментов.

Дайте клиенту префикс, а не догадку

На сервере pfSense SSL/TLS с сетью туннеля IPv4 больше /30 поле IPv4 Local network(s) распространяет маршруты клиентам при подключении. Добавьте нижний префикс туда, вместо того чтобы рассчитывать, что клиент придумает его сам. Затем прочитайте фактическую таблицу клиента после подключения, потому что профиль с route-nopull или фильтр маршрутов может проигнорировать то, что отправил сервер. Сервер может быть совершенно правильным, пока клиент ничего не устанавливает.

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

Направьте pfSense на внутренний маршрутизатор

Статическому маршруту в pfSense нужен определённый и достижимый шлюз, а интерфейс, выбранный для этого шлюза, должен быть тем, который действительно до него доходит, как описывает руководство Netgate по статическим маршрутам. В иллюстративной схеме транзитный канал — 192.168.77.1 на межсетевом экране и 192.168.77.2 на внутреннем маршрутизаторе, а сеть сервисов — 172.16.30.0/25 за ним. Тогда маршрут называет префикс и следующий узел, а не адрес сервиса. Использование адреса из удалённой сети в качестве шлюза — распространённый способ построить маршрут, который выглядит правильным и никуда не передаёт.

Присвоение интерфейсу имени не описывает сети за ним. Статический маршрут — это и есть описание.

Удалённая сторона должна знать пул

Нижнему маршрутизатору нужен обратный маршрут для пула, в этом примере 10.55.0.0/24 через 192.168.77.1, если маршрут по умолчанию или динамический протокол уже не даёт его. Шлюз самого хоста сервиса должен вести к этому маршрутизатору, что обычно верно, когда маршрутизатор является его шлюзом по умолчанию, и неверно, когда хост настроен вручную. Маршрутизация по политике на межсетевом экране тоже может переопределить таблицу для конкретного трафика, поэтому проверьте, не выбирает ли правило другой шлюз, прежде чем заключить, что маршрут неверен.

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

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

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