Три вида отработки отказа OpenVPN на pfSense, три механизма

«OpenVPN failover» на pfSense охватывает как минимум три несвязанных проекта, и каждый из них требует своего механизма. Удержание туннеля живым через резервный интернет-канал, переподключение к другому серверу и направление трафика LAN в другой уже установленный туннель — это не варианты одной функции. Выберите сбой, от которого вы защищаетесь, прежде чем строить группу шлюзов. Группа, исправляющая один из них, ничего не делает для двух других.

Назовите сбой до того, как построите группу

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

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

Локальный WAN: перенести транспорт

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

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

Правило маршрутизации на основе политики для пересылаемых пакетов LAN — не та настройка, которая переносит локально созданное транспортное соединение VPN. Это два разных поиска, и изменение одного не меняет другого.

Удалённая конечная точка: другой сервер

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

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

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

Путь туннеля: выбрать другой выход

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

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

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

Мониторы, NAT и правило fail-closed

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

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

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

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