Екінші WAN VPN жазбасы істемейді, ал негізгісі жұмысын жалғастырады

Негізгі туннель көтерілген күйде қалады, пайдаланушылар жұмысын жалғастырады, ал екінші ISP желісі не өзгертсеңіз де бос тұрады. Сіз резервтік желі үшін мекенжай жарияладыңыз, оған атау бағыттадыңыз, мүмкін клиентке резервтік жазба қостыңыз, ал клиент оны ешқашан сынамайды немесе аутентификациядан өтіп, содан кейін өледі. Мен бақылаған жағдайларда failover функциясы әдетте дұрыс болатын; жетіспейтіні — жазбаны пайдалануға жарамды ететін бес нәрсенің бірі. Атау резервтік мекенжайға шешілуі мүмкін, бірақ сол интерфейсте ештеңе тыңдамайды, ал тыңдаушы қосылымды қабылдауы мүмкін, бірақ жауап негізгі арқылы шығады. Әр WAN-ды өз келісімі бар бөлек жазба ретінде қарастырыңыз, сонда ақау клиенттің қатесіндей көрінбейді.

Әр WAN-ға өзінің жазба келісімі қажет

Әр WAN үшін бес өрісті жазып алыңыз: жария атауы мен мекенжайы, тасымалдау және порт, оны аяқтайтын интерфейс немесе контекст, ұсынылуы тиіс серіктес сәйкестігі және жауап қайдан шығады. Екі желі екі толық жиынтықты білдіреді. Егер екінші жиынтықта аяқтайтын интерфейс немесе қайтару жолы болмаса, резервтік жазбаңыз жоқ; ниетті сипаттайтын DNS жазбаңыз бар.

Құрылғы мен оның нұсқасы да бұл орналасуды қолдауы керек. DNS жазбасы басқа интерфейсте қызмет аша алмайды, ал көптеген платформаларда тыңдаушы құрылғы бойынша емес, мекенжай бойынша конфигурацияланады. ASA-да интерфейске негізделген IPsec крипто-карталар мен туннель топтарын сыртқы интерфейске байланыстырады, сондықтан екінші жоғары арнаға осы пакеттер шын мәнінде келетін жерде саясат қажет. Маршрутқа негізделген жобалар басқаша әрекет етеді: тыңдаушы әр мекенжайға немесе бір аталған мекенжайға байланыса алады, және бұл таңдау ISP B жауап бере ала ма, жоқ па — соны шешеді.

Екінші WAN шынымен жауап беретінін тексеріңіз

Екі желінің сыртынан тексеріңіз, шлюздің артындағы машинадан емес, және клиент профилі қолданатын дәл атауды тексеріңіз. TLS тыңдаушысы үшін жылдам тексеру — openssl s_client -connect ADDRESS:443 -servername vpn.example.com -showcerts , оны желіңізден тыс хосттан іске қосасыз. Профильдегі атауға сәйкес келетін тізбегі бар аяқталған қол алысуды қалайсыз, қосылымды қабылдайтын TCP портын ғана емес.

RFC 9525 клиенттің нені тексеретінін түсіндіреді: жетуге ниеттенген сәйкестікті қызмет ұсынатын сертификатпен салыстырады. Негізгі жазбаның сертификатын қайтаратын немесе екі атаудың ешқайсысын тізімдемейтін әдепкі сертификат ұсынатын екінші жазба бұл сынақтан өтпейді, порт ашық және брандмауэр рұқсат етсе де.

Мұндағы ақаулардың көбін екі үлгі түсіндіреді. Ілініп қалған қосылым әдетте сол интерфейсте тыңдаушы жоқтығын, тек негізгі ішкі желілерге рұқсат беретін қатынау ережесін немесе екінші желінің алдындағы оператор құрылғысы портты тастайтынын білдіреді. Қате сәйкестікпен аяқталған қол алысу әдетте басқа trustpoint, әдепкі виртуалды хост немесе сәйкестікті түзетпей негізгіден көшірілген конфигурацияны білдіреді.

Жауапты қадағалаңыз, тек сұранысты емес

Екінші WAN әдетте қайтару жолында бұзылады. Сұраныс ISP B арқылы келеді, құрылғы жауап береді, ал жауап ISP A-дағы әдепкі маршрутпен клиент ешқашан сұрамаған бастапқы мекенжаймен шығады. Күйі бар түрлендіру оны нашарлатады: егер карта негізгі интерфейс үшін құрылған болса, қайтарылатын пакет түрлендіруді өткізіп алады немесе клиенттің брандмауэры тастайтын бастапқы мекенжайды алып жүреді. Провайдерлер де өздері берген желіге тиесілі емес бастапқы мекенжайларды тастайды, сондықтан бұл таза протокол қатесі емес, бір бағытты қара құрдым сияқты көрінеді.

Екінші жазбадан шығатын трафик үшін маршруттау шешімін тексеріңіз. Жауап сұраныс келген интерфейстен шығуы керек немесе кемінде алыс жақ сол жолға тиесілі деп қабылдайтын мекенжайды алып жүруі керек. Саясаттық маршруттау платформаларында бұл кіріс интерфейсіне немесе түрлендірілген бастапқы мекенжайға байланған ережені, сонымен қатар әр сыртқы интерфейске байланған түрлендіру мәлімдемесін білдіреді. Клиент қосылған кезде екі интерфейсте бір уақытта түсіріңіз; ISP B-ге келген SYN мен ISP A-дан шыққан SYN-ACK мәселені бір жүгірісте шешеді.

Клиентке екінші жазба туралы білу жолын беріңіз

Failover — клиент жағындағы шешім, және әр клиент отбасы баламаларды өзінше біледі. ASA-да резервтік серверлер тізімі топтық саясаттың webvpn атрибуттары арқылы беріледі, ал басқа клиенттер профиль ішіндегі тізімді немесе пайдаланушы таңдайтын қолмен жасалған екінші профильді күтеді. Cisco-ның қосылым саясаты жөніндегі нұсқаулығы клиентте конфигурацияланған және шлюз ұсынған резервтік ақпаратты да сипаттайды, және бұл протоколға тән мәліметтерді әр клиентке немесе туннель режиміне жалпылауға болмайды. Екінші жазбаны қате механизмнің айналасында құрмас бұрын орналастырылған клиенттің қай механизмді іске асыратынын растаңыз.

Механизм қандай болса да, клиент негізгі жолды жоғалтпас бұрын балама атауды шеше алуы керек. Адамдар дәл осы тәуелділікті ұмытып кетеді: егер резервтік атауға жаңа ғана істен шыққан туннель арқылы ғана қолжетімді шешуші жауап берсе, резервтік нұсқа тіпті бастай алмайды. Екінші атауды жергілікті немесе интернет арқылы жауап беретін шешушіде жариялаңыз. Ауысқаннан кейін жаңа аутентификация мен жаңа қолданба сессиясын күтіңіз, өйткені клиенттің failover-ы күйі бар failover емес және ұзақ сессиялар одан аман қалмайды.

Екі провайдердегі бір мекенжай — басқа өнім

Бір жария мекенжайды екі желі арқылы да қолжетімді ұстау — маршруттау қызметі, VPN-дегі құсбелгі емес. Оған екі провайдер де тасымалдауға дайын мекенжай кеңістігі қажет, ол олардың желілері қабылдайтындай жариялануы керек, және мұны провайдерге тәуелсіз кеңістік пен BGP бар мультихоминг береді. ISP A мекенжайын ISP B интерфейсіне тағайындау оған апармайды; пакет префиксті ешқашан жарияламаған желіге жетеді және жоғарыда тасталады.

Екі жазба жариялау үшін осының ешбірі қажет емес. Егер клиент екі атауды ұстай алып, олардың арасында ауыса алса, екі тәуелсіз жазба жеткілікті, және сіз AS нөмірінен, peering келісімінен және барлық жерде қабылдануы тиіс префикстен құтыласыз. Тасымалданатын мекенжай нұсқасын клиенттерді қайта конфигурациялау мүмкін емес бір тұрақты кіру нүктесі шынымен қажет болғанда ғана немесе TTL кідірісі бар DNS негізіндегі failover сіз жобалайтын үзіліс үшін тым баяу болғанда ғана қарастырыңыз.

Әрі қарай нені тексеру керек

Істен шыққан жазбадан сыртқа қарай осы ретпен жұмыс істеңіз: екінші мекенжай сырттан жауап бере ме, клиент күтетін сәйкестікті ұсына ма, жауап сұраныс келген жолмен шыға ма, және клиент атауды қажет болмай тұрып біле ала ма. Жауап жоқ жерде сол қабатты түзетіп, сынақ хостымен емес, орналастырылған профильмен қайта сынаңыз, өйткені зертханадағы қол алысу нақты клиенттің аяқталған қосылымынан аз дәлелдейді.

Әр WAN үшін мекенжай, порт, аяқтайтын интерфейс, сертификат атауы, қайтару жолы және түрлендіру ережесі бар қысқа жазба ұстаңыз және желі, NAT құрылғысы немесе клиент нұсқасы өзгерген сайын оны қайта тексеріңіз. Бос резервтік жолдар үнсіз шіриді: ешкім пайдаланбайтын жазба туралы бәрі оған тәуелді болған күнге дейін ештеңе ескертпейді.