pfSense как VPN-сервер и клиент: два пути, один маршрутизатор

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

Назовите две роли, прежде чем трогать любую настройку

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

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

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

Держите ответы сервера на пути WAN

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

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

netstat -rn | head -20
pfctl -sr | grep -i vpn
ifconfig | grep -A3 ovpn

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

Не позволяйте исходящему туннелю съесть собственную конечную точку

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

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

netstat -rn | grep -F '198.51.100.10'
traceroute -n 198.51.100.10

Выберите, какие пользователи получат выход

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

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

openvpn --config user07.ovpn
curl -sS https://ifconfig.me
curl --interface 10.10.10.1 -sS https://intranet.corp.example/health

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

Решите, что происходит, когда выход отказывает

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

Отключите экземпляр клиента, посмотрите, до чего подключённый пользователь ещё добирается, затем запустите его снова. Запрос, который истекает по времени, — это запрошенный вами результат полной блокировки; тот, что отвечает адресом WAN, — это возврат, который вы не задокументировали. Повторите проверку для IPv6 и для DNS, потому что политика, написанная для IPv4, ничего не говорит о трафике AAAA, а резолвер, протолкнутый любым из туннелей, отвечает оттуда, откуда запрос действительно выходит.

pfSsh.php playback svc stop openvpn client 2
curl --max-time 6 -sS https://ifconfig.me
pfSsh.php playback svc start openvpn client 2

Рецепт Netgate для маршрутизируемого OpenVPN показывает, как сочетаются политика источника, назначение интерфейса и исходящая трансляция, и его охват «от площадки к площадке» — та часть, которую не стоит копировать целиком. Чего он вам не скажет, так это какое из трёх условий выше ваш собственный проект уже нарушил.