Вторият WAN вход на VPN не работи, докато основният продължава да работи

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

Всеки WAN се нуждае от свой договор за вход

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

Устройството и неговата версия също трябва да поддържат тази подредба. DNS запис не може да отвори услуга на друг интерфейс, а на много платформи слушателят се конфигурира за адрес, а не за устройство. IPsec на базата на интерфейс на ASA свързва криптокарти и групи тунели с външния интерфейс, затова вторият ъплинк се нуждае от политика, прикачена там, където тези пакети действително пристигат. Решенията на базата на маршрути се държат различно: слушателят може да се свързва с всеки адрес или с един именуван адрес, и този избор решава дали доставчик B може изобщо да отговори.

Проверете дали вторият WAN наистина отговаря

Тествайте отвън и двете линии, а не от машина зад шлюза, и тествайте точно името, което използва профилът на клиента. За TLS слушател бързата проверка е openssl s_client -connect ADDRESS:443 -servername vpn.example.com -showcerts изпълнена от хост извън вашата мрежа. Искате завършено ръкостискане, чиято верига съответства на името в профила, а не просто TCP порт, който приема връзка.

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

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

Следвайте отговора, не само заявката

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

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

Дайте на клиента начин да научи за втори вход

Превключването е решение от страна на клиента и всяко семейство клиенти научава за алтернативите по различен начин. На ASA списъкът с резервни сървъри се доставя чрез webvpn атрибутите на груповата политика, докато други клиенти очакват списък в профила или ръчен втори профил, който потребителят избира. Ръководството на Cisco за политики на свързване описва както информацията, конфигурирана в клиента, така и предоставената от шлюза, и тези протоколно специфични подробности не бива да се обобщават за всеки клиент или режим на тунел. Потвърдете кой механизъм прилага внедреният клиент, преди да изградите втория вход около грешния.

Какъвто и да е механизмът, клиентът трябва да може да разпознае алтернативното име, преди да загуби основния път. Именно тази зависимост хората пропускат: ако резервното име се отговаря от резолвер, достъпен само през тунела, който току-що се срина, резервният вариант дори не може да започне. Публикувайте второто име в резолвер, който отговаря локално или през интернет. Очаквайте нова автентикация и нова сесия на приложението след преместването, защото клиентското превключване не е превключване със състояние и дълготрайните сесии не го преживяват.

Един адрес при два доставчика е различен продукт

Поддържането на един публичен адрес достъпен през двете линии е услуга за маршрутизиране, а не отметка във VPN. Тя се нуждае от адресно пространство, което и двамата доставчици са готови да пренасят, обявено по начин, който техните мрежи приемат, и точно това дава многоадресното свързване с независимо от доставчика пространство и BGP. Присвояването на адреса на доставчик A на интерфейса на доставчик B не стига дотам; пакетът пристига в мрежа, която никога не е обявявала префикса, и се изхвърля по-нагоре.

Не се нуждаете от нищо от това, за да публикувате два входа. Ако клиентът може да държи две имена и да превключва между тях, два независими входа са достатъчни и избягвате AS номер, споразумение за пиъринг и префикс, който трябва да бъде приет навсякъде. Обмисляйте опцията за преносим адрес само когато наистина ви трябва една стабилна входна точка, която клиентите не могат да бъдат преконфигурирани да заменят, или когато превключването на базата на DNS с неговото закъснение от TTL е твърде бавно за прекъсването, срещу което проектирате.

Какво да проверите след това

Работете навън от отказалия вход в този ред: отговаря ли вторият адрес отвън, представя ли идентичността, която клиентът очаква, излиза ли отговорът по пътя, по който е пристигнала заявката, и може ли клиентът да научи името, преди да му потрябва. Където отговорът е „не“, поправете този слой и тествайте отново с внедрения профил, а не с тестов хост, защото ръкостискане от лабораторията доказва по-малко от завършена връзка от реалния клиент.

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