Как построить политику отказоустойчивого переключения VPN на роутере без утечек

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

Определите результат до выбора детектора

Обычно на столе три результата: отправить затронутых клиентов через резервный туннель, позволить им использовать обычный WAN или заблокировать их полностью. Запишите, какой из них относится к какой VLAN, SSID или классу устройств. Одно плоское правило «переключиться на WAN» — именно так финансовая папка выше оказалась на публичном пути.

Эти три варианта не взаимозаменяемы. Возврат на WAN позволяет службе поддержки отвечать на звонки, но раскрывает внутренние имена локальному резолверу. Резервный туннель сохраняет политику, но может оказаться на выходном адресе, который удалённая сторона не принимает. Блокировка правильна для VLAN зарплаты и неправильна для гостевой сети, которая никогда не пользовалась туннелем.

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

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

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

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

Используйте уровни, а не один плоский список участников. Основной на уровне 1, резервный туннель на уровне 2, WAN на уровне 3 только для тех VLAN, чья политика это допускает. В pfSense это находится в System > Routing > Gateway Groups: добавьте оба шлюза, задайте им разные уровни, установите Trigger Level на недоступность участника плюс потерю пакетов, сохраните, затем примените группу как шлюз по умолчанию интерфейса или в поле Gateway правил брандмауэра, которым она нужна.

Для экземпляра клиента OpenVPN в pfSense 2.5 и новее параметр Default Gateway экземпляра решает, заменяет ли туннель системный маршрут по умолчанию вообще. Маршрутизация по правилам ведёт себя так, как вы ожидаете, только когда маршрут, который вы предполагаете, действительно установлен. После изменения проверьте Status > Gateways, а не доверяйте значку состояния туннеля.

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

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

Сначала утечки DNS. Резолвер продолжает отвечать на WAN и пересылать через неё, поэтому имена продолжают разрешаться через провайдера, пока трафик привязан к туннелю. Ограничьте исходящие интерфейсы резолвера, протолкните внутренний резолвер клиентам и заблокируйте порт 53 для всего остального в VLAN только с VPN.

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

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

Проверьте падение, мигание и путь обратно

Отключите основной при безобидном трафике, затем прочитайте четыре вещи: Status > Gateways для состояний участников группы, pfctl -ss для состояний, всё ещё привязанных к старому шлюзу, traceroute с клиента для выходного пути и запрос к резолверу, чтобы увидеть, какой сервер ответил.

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

Наконец, убедитесь, что вы всё ещё можете администрировать роутер. Держите внешний путь, например консольный кабель, управляющую VLAN или сотовый модем. Тест отказоустойчивости, который запирает вас снаружи, — это тест, который вы не можете закончить, а недоступный роутер не может вернуться сам.

Прежде чем считать политику готовой, вы должны суметь ответить на четыре вопроса, не открывая терминал: какие VLAN могут использовать WAN, пока туннель недоступен, что наблюдает детектор и сколько ждёт, какие серверы имён и маршруты IPv6 перемещаются вместе с путём, и как вы вернётесь, если резерв тоже откажет. Если любой ответ — «что было по умолчанию», политика всё ещё принадлежит роутеру, а не вам.