Вториот WAN VPN запис не работи, додека примарниот продолжува да работи

Примарниот тунел останува подигнат, корисниците продолжуваат да работат, а втората ISP линија стои неискористена, што и да промените. Објавивте адреса за резервната линија, упативте име кон неа, можеби додадовте резервен запис во клиентот, и клиентот или никогаш не го пробува или се автентицира и потоа умира. Во случаите што ги следев, функцијата failover обично беше во ред; она што недостасуваше беше една од петте работи што го прават записот употреблив. Името може да се резолвира до резервната адреса додека ништо не слуша на тој интерфејс, а слушателот може да прими врска додека одговорот излегува преку примарниот. Третирајте го секој WAN како посебен запис со свој договор и дефектот престанува да изгледа како грешка на клиентот.

Секој WAN бара свој договор за запис

Запишете пет полиња за секој WAN: јавното име и адреса, транспортот и портата, интерфејсот или контекстот што го завршува, идентитетот на партнерот што треба да го претстави и каде излегува одговорот. Две линии значат два целосни множества. Ако второто множество нема завршен интерфејс или повратен пат, немате резервен запис; имате DNS запис што опишува намера.

Уредот и неговата верзија исто така мора да го поддржуваат овој распоред. DNS запис не може да отвори услуга на друг интерфејс, и на многу платформи слушателот се конфигурира по адреса, а не по уред. IPsec базиран на интерфејс на ASA ги врзува крипто-мапите и тунелските групи за надворешниот интерфејс, затоа вториот uplink бара политика таму каде што тие пакети навистина пристигнуваат. Решенијата базирани на рути се однесуваат поинаку: слушателот може да се врзе за секоја адреса или за една именувана адреса, и тој избор одлучува дали ISP B воопшто може да одговори.

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

Тестирајте од надвор од двете линии, не од машина зад портата, и тестирајте го точното име што го користи профилот на клиентот. За TLS слушател брзата проверка е openssl s_client -connect ADDRESS:443 -servername vpn.example.com -showcerts , извршена од домаќин надвор од вашата мрежа. Сакате завршено ракување чиј ланец одговара на името во профилот, а не само TCP порта што прима врска.

RFC 9525 објаснува што проверува клиентот: идентитетот до кој мислел да стигне, спореден со сертификатот што го презентира услугата. Вториот запис што го враќа сертификатот на примарниот запис, или стандарден сертификат во кој не е наведено ниту едно од имињата, паѓа на овој тест, иако портата е отворена и огнениот ѕид го дозволува.

Два модели ги објаснуваат повеќето дефекти овде. Врската што виси обично значи дека нема слушател на тој интерфејс, правило за пристап што дозволува само примарните подмрежи, или уред на операторот пред втората линија што ја фрла портата. Ракувањето што завршува со погрешен идентитет обично значи друг trustpoint, стандарден виртуелен домаќин или конфигурација копирана од примарниот без прилагодување на идентитетот.

Следете го одговорот, не само барањето

Вториот WAN обично се крши на повратниот пат. Барањето доаѓа преку ISP B, уредот одговара, и одговорот излегува преку стандардната рута на ISP A со изворна адреса што клиентот никогаш не ја побарал. Преводот со состојба го влошува тоа: ако мапирањето е изградено за примарниот интерфејс, пакетот што се враќа го пропушта преводот или носи извор што огнениот ѕид на клиентот го фрла. Давателите на услуги исто така фрлаат изворни адреси што не припаѓаат на линијата што ви ја дале, затоа ова изгледа како еднонасочна црна дупка, а не како чиста протоколна грешка.

Проверете ја одлуката за рутирање за сообраќајот чиј извор е вториот запис. Одговорот треба да излезе од интерфејсот на кој пристигна барањето, или барем да носи адреса што далечната страна ја прифаќа како припаѓа на тој пат. На платформи со рутирање по политика тоа значи правило врзано за влезниот интерфејс или преведениот извор, плус изјава за превод врзана за секој надворешен интерфејс. Снимајте истовремено на двата интерфејса додека клиентот се поврзува; SYN што пристигнува на ISP B и SYN-ACK што излегува на ISP A го решаваат прашањето во едно извршување.

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

Failover е одлука на страната на клиентот, и секое семејство клиенти дознава за алтернативите на различен начин. На ASA списокот со резервни сервери се доставува преку webvpn атрибутите на групната политика, додека други клиенти очекуваат список во профилот или рачен втор профил што го избира корисникот. Водичот на Cisco за политики за поврзување опишува и информации конфигурирани во клиентот и информации обезбедени од портата, и тие протоколно специфични детали не треба да се генерализираат на секој клиент или режим на тунел. Потврдете кој механизам го имплементира распоредениот клиент пред да го изградите вториот запис околу погрешниот.

Каков и да е механизмот, клиентот мора да може да го резолвира алтернативното име пред да го загуби примарниот пат. Токму оваа зависност луѓето ја пропуштаат: ако резервното име го одговара резолвер достапен само преку тунелот што штотуку падна, резервата воопшто не може да започне. Објавете го второто име во резолвер што одговара локално или преку интернет. По преместувањето очекувајте нова автентикација и нова апликациска сесија, бидејќи клиентскиот failover не е failover со состојба и долгите сесии не го преживуваат.

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

Одржувањето на една јавна адреса достапна преку двете линии е услуга за рутирање, не е поле за штиклирање во VPN. Бара адресен простор што двајцата даватели се подготвени да го носат, објавен така што нивните мрежи го прифаќаат, и тоа го дава повеќекратното поврзување со простор независен од давателот и BGP. Доделувањето на адресата на ISP A на интерфејсот на ISP B не води таму; пакетот пристигнува во мрежа што никогаш не го објавила префиксот и се фрла погоре.

Не ви треба ништо од тоа за да објавите два записи. Ако клиентот може да држи две имиња и да префрла меѓу нив, доволни се два независни записи, и избегнувате AS број, договор за peering и префикс што мора да биде прифатен насекаде. Опцијата за пренослива адреса разгледајте ја само кога навистина ви треба една стабилна влезна точка што клиентите не можат да ја преконфигурираат, или кога failover базиран на DNS со своето TTL доцнење е премногу бавен за прекинот против кој проектирате.

Што да проверите потоа

Работете од записот што не работи кон надвор по овој редослед: дали втората адреса одговара од надвор, дали го презентира идентитетот што клиентот го очекува, дали одговорот излегува по патот по кој пристигна барањето, и дали клиентот може да го научи името пред да му затреба. Каде одговорот е не, поправете го тој слој и тестирајте повторно со распоредениот профил, а не со тест домаќин, зашто лабораториското ракување докажува помалку од завршена врска на вистинскиот клиент.

Држете краток запис за секој WAN со адреса, порта, завршен интерфејс, име на сертификатот, повратен пат и правило за превод, и проверувајте го повторно секогаш кога ќе се промени линија, NAT уред или верзија на клиентот. Неискористените резервни патишта тивко гнијат: ништо не предупредува за записот што никој не го користи сѐ до денот кога сите зависат од него.