Antrasis WAN VPN įrašas neveikia, o pirminis tebeveikia

Pirminis tunelis lieka pakeltas, naudotojai dirba toliau, o antrasis ISP kanalas stovi nenaudojamas, kad ir ką keistumėte. Paskelbėte atsarginio kanalo adresą, nukreipėte į jį vardą, galbūt pridėjote atsarginį įrašą kliente, o klientas arba niekada jo nebando, arba autentifikuojasi ir tada miršta. Mano tirtuose atvejuose failover funkcija paprastai būdavo tvarkinga; trūko vieno iš penkių dalykų, kurie padaro įrašą naudingu. Vardas gali išsispręsti į atsarginį adresą, nors tame sąsajoje niekas neklauso, o klausytojas gali priimti ryšį, nors atsakymas išeina per pirminį. Traktuokite kiekvieną WAN kaip atskirą įrašą su savo sutartimi ir gedimas nustos atrodyti kaip kliento klaida.

Kiekvienam WAN reikia savo įrašo sutarties

Užrašykite penkis laukus kiekvienam WAN: viešą vardą ir adresą, transportą ir prievadą, sąsają ar kontekstą, kuris jį užbaigia, partnerio tapatybę, kurią jis turi pateikti, ir kur išeina atsakymas. Du kanalai reiškia du pilnus rinkinius. Jei antrasis rinkinys neturi užbaigiančios sąsajos arba grįžtamojo kelio, jūs neturite atsarginio įrašo; turite DNS įrašą, aprašantį ketinimą.

Įrenginys ir jo versija taip pat turi palaikyti tokią tvarką. DNS įrašas negali atidaryti paslaugos kitoje sąsajoje, o daugelyje platformų klausytojas konfigūruojamas pagal adresą, o ne pagal įrenginį. Sąsaja pagrįstas IPsec ASA įrenginyje susieja šifravimo žemėlapius ir tunelio grupes su išorine sąsaja, todėl antrajai aukštynkryptei reikia politikos ten, kur tie paketai iš tikrųjų atvyksta. Maršrutais pagrįsti sprendimai elgiasi kitaip: klausytojas gali prisirišti prie kiekvieno adreso arba prie vieno įvardyto adreso, ir šis pasirinkimas lemia, ar ISP B apskritai gali atsakyti.

Patikrinkite, ar antrasis WAN tikrai atsako

Testuokite iš abiejų kanalų išorės, o ne iš mašinos už tinklų sietuvos, ir testuokite būtent tą vardą, kurį naudoja kliento profilis. TLS klausytojui greita patikra yra openssl s_client -connect ADDRESS:443 -servername vpn.example.com -showcerts , paleista iš už jūsų tinklo esančio kompiuterio. Jums reikia užbaigto rankos paspaudimo, kurio grandinė atitinka profilio vardą, o ne vien TCP prievado, kuris priima ryšį.

RFC 9525 paaiškina, ką tikrina klientas: tapatybę, kurią ketino pasiekti, palygintą su sertifikatu, kurį pateikia paslauga. Antrasis įrašas, kuris grąžina pirminio įrašo sertifikatą arba numatytąjį sertifikatą, kuriame nenurodytas nė vienas vardas, šio testo nepraeina, nors prievadas atidarytas ir ugniasienė jį leidžia.

Du modeliai paaiškina daugumą gedimų čia. Kabančis ryšys paprastai reiškia, kad toje sąsajoje nėra klausytojo, prieigos taisyklė leidžia tik pirminius potinklius, arba operatoriaus įrenginys prieš antrąjį kanalą meta prievadą. Rankos paspaudimas, pasibaigiantis neteisinga tapatybe, paprastai reiškia kitą trustpoint, numatytąjį virtualųjį hostą arba konfigūraciją, nukopijuotą iš pirminio nepritaikius tapatybės.

Sekite atsakymą, o ne tik užklausą

Antrasis WAN paprastai lūžta grįžimo kelyje. Užklausa ateina per ISP B, įrenginys atsako, o atsakymas išeina numatytuoju maršrutu ISP A su šaltinio adresu, kurio klientas niekada neprašė. Būseninis vertimas tai dar labiau pablogina: jei susiejimas buvo sukurtas pirminei sąsajai, grįžtantis paketas praleidžia vertimą arba neša šaltinį, kurį kliento ugniasienė išmeta. Tiekėjai taip pat išmeta šaltinio adresus, kurie nepriklauso jų duotam kanalui, todėl tai atrodo kaip vienkryptė juodoji skylė, o ne švari protokolo klaida.

Patikrinkite maršrutizavimo sprendimą srautui, kurio šaltinis yra antrasis įrašas. Atsakymas turi išeiti per sąsają, kuria atėjo užklausa, arba bent jau nešti adresą, kurį tolimoji pusė priima kaip priklausantį tam keliui. Politika pagrįsto maršrutizavimo platformose tai reiškia taisyklę, susietą su įeinančia sąsaja arba išverstu šaltiniu, plius vertimo teiginį, susietą su kiekviena išorine sąsaja. Fiksuokite vienu metu abiejose sąsajose, kol klientas jungiasi; SYN, atėjęs per ISP B, ir SYN-ACK, išėjęs per ISP A, išsprendžia klausimą vienu paleidimu.

Duokite klientui būdą sužinoti apie antrąjį įrašą

Failover yra kliento pusės sprendimas, ir kiekviena klientų šeima apie alternatyvas sužino skirtingai. ASA atsarginių serverių sąrašas perduodamas per grupės politikos webvpn atributus, o kiti klientai tikisi sąrašo profilyje arba rankinio antrojo profilio, kurį pasirenka naudotojas. Cisco ryšio politikos vadovas aprašo ir kliente sukonfigūruotą, ir tinklų sietuvos teikiamą atsarginę informaciją, ir šios protokolui būdingos detalės neturėtų būti apibendrinamos visiems klientams ar tunelio režimams. Patvirtinkite, kokį mechanizmą įgyvendina įdiegtas klientas, prieš statydami antrąjį įrašą aplink netinkamą.

Kad ir koks būtų mechanizmas, klientas turi galėti išspręsti alternatyvų vardą prieš prarasdamas pirminį kelią. Būtent šios priklausomybės žmonės nepastebi: jei atsarginį vardą atsako sprendėjas, pasiekiamas tik per ką tik sugedusį tunelį, atsarginis variantas net negali prasidėti. Paskelbkite antrąjį vardą sprendėjuje, kuris atsako vietoje arba per internetą. Po perkėlimo tikėkitės naujos autentifikacijos ir naujos programos sesijos, nes kliento failover nėra būseninis failover ir ilgos sesijos jo nepatiria.

Vienas adresas dviejuose tiekėjuose yra kitas produktas

Vieno viešo adreso pasiekiamumą per abu kanalus palaikyti yra maršrutizavimo paslauga, o ne VPN žymės langelis. Jai reikia adresų erdvės, kurią abu tiekėjai sutinka perduoti, paskelbtos taip, kad jų tinklai ją priimtų, ir tai suteikia daugiarūšis prisijungimas su nuo tiekėjo nepriklausoma erdve ir BGP. ISP A adreso priskyrimas ISP B sąsajai ten nepriveda; paketas atvyksta į tinklą, kuris niekada neskelbė prefikso, ir yra išmetamas aukščiau.

Nieko iš to nereikia, kad paskelbtumėte du įrašus. Jei klientas gali laikyti du vardus ir perjungti tarp jų, dviejų nepriklausomų įrašų pakanka, ir jūs išvengiate AS numerio, peering susitarimo ir prefikso, kuris turi būti priimtas visur. Nešiojamo adreso variantą apsvarstykite tik tada, kai jums tikrai reikia vieno stabilaus įėjimo taško, kurio klientai negali perkonfigūruoti pakeisti, arba kai DNS pagrįstas failover su TTL delsa yra per lėtas sutrikimui, prieš kurį projektuojate.

Ką tikrinti toliau

Dirbkite iš neveikiančio įrašo į išorę šia tvarka: ar antrasis adresas atsako iš išorės, ar jis pateikia tapatybę, kurios klientas tikisi, ar atsakymas išeina keliu, kuriuo atėjo užklausa, ir ar klientas gali sužinoti vardą prieš jam prireikiant. Kur atsakymas yra ne, pataisykite tą sluoksnį ir testuokite iš naujo su įdiegtu profiliu, o ne su bandomuoju kompiuteriu, nes laboratorijos rankos paspaudimas įrodo mažiau nei užbaigtas tikro kliento ryšys.

Laikykite trumpą įrašą kiekvienam WAN su adresu, prievadu, užbaigiančia sąsaja, sertifikato vardu, grįžimo keliu ir vertimo taisykle, ir tikrinkite jį iš naujo kiekvieną kartą, kai keičiasi kanalas, NAT įrenginys ar kliento versija. Nenaudojami atsarginiai keliai tyliai pūva: niekas neįspėja apie įrašą, kurio niekas nenaudoja, iki dienos, kai visi nuo jo priklauso.