Второй вход VPN через WAN не работает, а основной продолжает работать

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

Каждой WAN нужен собственный контракт входа

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

Устройство и его версия также должны поддерживать такую схему. Запись DNS не может открыть службу на другом интерфейсе, а на многих платформах слушатель настраивается на адрес, а не на устройство. IPsec на основе интерфейса в ASA привязывает криптокарты и группы туннелей к внешнему интерфейсу, поэтому второму аплинку нужна политика там, куда эти пакеты действительно приходят. Схемы на основе маршрутов ведут себя иначе: слушатель может привязываться ко всем адресам или к одному именованному адресу, и этот выбор решает, сможет ли ISP B вообще ответить.

Проверьте, что вторая WAN действительно отвечает

Проверяйте снаружи обоих каналов, а не с машины за шлюзом, и проверяйте именно то имя, которое использует профиль клиента. Для слушателя TLS быстрая проверка — это openssl s_client -connect ADDRESS:443 -servername vpn.example.com -showcerts, запущенная с хоста вне вашей сети. Вам нужно завершённое рукопожатие, цепочка которого совпадает с именем в профиле, а не просто порт TCP, принимающий соединение.

RFC 9525 объясняет, что проверяет клиент: идентичность, к которой он намеревался попасть, в сравнении с сертификатом, который предъявляет служба. Второй вход, возвращающий сертификат основного входа, или сертификат по умолчанию, где нет ни одного из имён, не проходит эту проверку, даже если порт открыт и межсетевой экран его пропускает.

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

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

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

Проверьте решение о маршрутизации для трафика, источник которого — второй вход. Ответ должен уходить через интерфейс, куда пришёл запрос, или хотя бы нести адрес, который удалённая сторона принимает как принадлежащий этому пути. На платформах с маршрутизацией по политике это означает правило, привязанное к входящему интерфейсу или транслированному источнику, плюс оператор трансляции, привязанный к каждому внешнему интерфейсу. Снимайте захват на обоих интерфейсах одновременно, пока клиент подключается; SYN, приходящий на ISP B, и SYN-ACK, уходящий на ISP A, решают вопрос за один запуск.

Дайте клиенту способ узнать о втором входе

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

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

Один адрес у двух провайдеров — это другой продукт

Держать один публичный адрес доступным через оба канала — это услуга маршрутизации, а не галочка в VPN. Для неё нужно адресное пространство, которое оба провайдера готовы передавать, анонсированное так, чтобы их сети его принимали, и именно это даёт мультихоуминг с независимым от провайдера пространством и BGP. Назначение адреса ISP A интерфейсу ISP B туда не приведёт; пакет приходит в сеть, которая никогда не анонсировала этот префикс, и отбрасывается выше по потоку.

Ничего из этого не нужно, чтобы опубликовать два входа. Если клиент может держать два имени и переключаться между ними, двух независимых входов достаточно, и вы избегаете номера AS, соглашения о пиринге и префикса, который должен приниматься везде. Рассматривайте вариант переносимого адреса только тогда, когда вам действительно нужна одна стабильная точка входа, которую клиенты не могут заменить перенастройкой, или когда переключение на основе DNS с его задержкой TTL слишком медленно для отказа, который вы проектируете.

Что проверить дальше

Двигайтесь наружу от отказавшего входа в таком порядке: отвечает ли второй адрес снаружи, предъявляет ли он идентичность, которую ожидает клиент, уходит ли ответ тем путём, которым пришёл запрос, и может ли клиент узнать имя до того, как оно понадобится. Там, где ответ «нет», исправьте этот уровень и повторите проверку с развёрнутым профилем, а не с тестовым хостом, потому что рукопожатие из лаборатории доказывает меньше, чем завершённое соединение настоящего клиента.

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