A doua intrare VPN WAN eșuează în timp ce prima încă funcționează

Tunelul principal rămâne activ, utilizatorii lucrează mai departe, iar al doilea circuit ISP stă inactiv indiferent ce schimbi. Ai publicat o adresă pentru circuitul de rezervă, ai îndreptat un nume spre ea, poate ai adăugat o intrare de rezervă în client, iar clientul fie nu o încearcă niciodată, fie se autentifică și apoi moare. În cazurile pe care le-am urmărit, funcția de failover era de obicei în regulă; lipsea unul dintre cele cinci lucruri care fac o intrare utilizabilă. Un nume se poate rezolva la adresa de rezervă în timp ce pe acea interfață nu ascultă nimic, iar un ascultător poate accepta o conexiune în timp ce răspunsul iese prin cea principală. Tratează fiecare WAN ca o intrare separată cu propriul contract, iar defecțiunea nu mai arată ca un bug al clientului.

Fiecare WAN are nevoie de propriul contract de intrare

Notează cinci câmpuri per WAN: numele și adresa publice, transportul și portul, interfața sau contextul care o termină, identitatea de peer pe care trebuie să o prezinte și locul de unde iese răspunsul. Două circuite înseamnă două seturi complete. Dacă al doilea set nu are o interfață de terminare sau o cale de întoarcere, nu ai o intrare de rezervă; ai o înregistrare DNS care descrie o intenție.

Aparatul și versiunea acestuia trebuie să susțină și ele aranjamentul. O înregistrare DNS nu poate deschide un serviciu pe altă interfață, iar pe multe platforme ascultătorul se configurează pe adresă, nu pe dispozitiv. IPsec bazat pe interfață pe un ASA leagă hărțile criptografice și grupurile de tunel de interfața exterioară, deci un al doilea uplink are nevoie de politică aplicată acolo unde acele pachete ajung de fapt. Proiectele bazate pe rute se comportă diferit: ascultătorul se poate lega de fiecare adresă sau de o singură adresă numită, iar această alegere decide dacă ISP B poate răspunde deloc.

Verifică dacă al doilea WAN răspunde cu adevărat

Testează din afara ambelor circuite, nu de pe o mașină din spatele gateway-ului, și testează exact numele pe care îl folosește profilul clientului. Pentru un ascultător TLS, verificarea rapidă este openssl s_client -connect ADDRESS:443 -servername vpn.example.com -showcerts rulat de pe un host din afara rețelei tale. Vrei un handshake finalizat a cărui lanț să corespundă numelui din profil, nu doar un port TCP care acceptă o conexiune.

RFC 9525 explică ce verifică clientul: identitatea pe care intenționa să o atingă, comparată cu certificatul pe care îl prezintă serviciul. O a doua intrare care returnează certificatul intrării principale, sau un certificat implicit care nu listează niciunul dintre nume, eșuează acest test chiar dacă portul este deschis și firewall-ul îl permite.

Două tipare explică majoritatea defecțiunilor de aici. O conexiune care se blochează înseamnă de obicei că nu există ascultător pe acea interfață, o regulă de acces care permite doar subrețelele principale, sau un echipament de operator din fața celui de-al doilea circuit care aruncă portul. Un handshake care se termină cu identitatea greșită înseamnă de obicei un alt trustpoint, un host virtual implicit sau o configurație copiată de la cea principală fără ajustarea identității.

Urmărește răspunsul, nu doar cererea

Al doilea WAN se strică de obicei pe drumul de întoarcere. O cerere ajunge pe ISP B, aparatul răspunde, iar răspunsul iese prin ruta implicită pe ISP A cu o adresă sursă pe care clientul nu a cerut-o niciodată. Traducerea cu stare înrăutățește lucrurile: dacă maparea a fost construită pentru interfața principală, pachetul de întoarcere ratează traducerea sau poartă o sursă pe care firewall-ul clientului o aruncă. Furnizorii aruncă și adresele sursă care nu aparțin circuitului pe care ți l-au dat, motiv pentru care asta arată ca o gaură neagră unidirecțională în loc de o eroare de protocol curată.

Verifică decizia de rutare pentru traficul cu sursa în a doua intrare. Răspunsul ar trebui să iasă prin interfața pe care a ajuns cererea, sau cel puțin să poarte o adresă pe care partea îndepărtată o acceptă ca aparținând acelei căi. Pe platformele cu rutare bazată pe politică, asta înseamnă o regulă legată de interfața de intrare sau de sursa tradusă, plus o instrucțiune de traducere legată de fiecare interfață exterioară. Capturează simultan pe ambele interfețe în timp ce clientul se conectează; un SYN care intră pe ISP B cu SYN-ACK care iese pe ISP A lămurește întrebarea într-o singură rulare.

Dă clientului o cale de a afla despre a doua intrare

Failover-ul este o decizie pe partea clientului, iar fiecare familie de clienți află despre alternative diferit. Pe un ASA, lista de servere de rezervă este livrată prin atributele webvpn ale politicii de grup, în timp ce alți clienți așteaptă o listă în profil sau un al doilea profil manual pe care utilizatorul îl alege. Ghidul Cisco pentru politicile de conexiune descrie atât informațiile de rezervă configurate în client, cât și pe cele furnizate de gateway, iar aceste detalii specifice protocolului nu trebuie generalizate la orice client sau mod de tunel. Confirmă ce mecanism implementează clientul instalat înainte de a construi a doua intrare în jurul celui greșit.

Indiferent de mecanism, clientul trebuie să poată rezolva numele alternativ înainte de a pierde calea principală. Acea dependență este cea pe care oamenii o ratează: dacă numele de rezervă este răspuns de un resolver accesibil doar prin tunelul care tocmai a căzut, rezerva nu poate nici măcar să înceapă. Publică al doilea nume într-un resolver care răspunde local sau prin internet. Așteaptă-te la o autentificare nouă și la o sesiune nouă de aplicație după mutare, pentru că failover-ul clientului nu este failover cu stare, iar sesiunile de durată nu supraviețuiesc.

O adresă la doi furnizori este un alt produs

A menține o singură adresă publică accesibilă prin ambele circuite este un serviciu de rutare, nu o bifă în VPN. Are nevoie de spațiu de adrese pe care ambii furnizori sunt dispuși să îl transporte, anunțat într-un mod pe care rețelele lor îl acceptă, iar asta oferă multihoming-ul cu spațiu independent de furnizor și BGP. Atribuirea adresei ISP A interfeței ISP B nu te duce acolo; pachetul ajunge într-o rețea care nu a anunțat niciodată prefixul și este aruncat în amonte.

Nu ai nevoie de nimic din toate acestea pentru a publica două intrări. Dacă clientul poate ține două nume și poate face failover între ele, două intrări independente sunt suficiente, iar tu eviți un număr AS, o înțelegere de peering și un prefix care trebuie acceptat peste tot. Ia în calcul opțiunea adresei portabile doar când ai cu adevărat nevoie de un punct de intrare stabil pe care clienții să nu poată fi reconfigurați să îl înlocuiască, sau când failover-ul bazat pe DNS cu întârzierea sa TTL este prea lent pentru întreruperea pentru care proiectezi.

Ce să verifici în continuare

Lucrează spre exterior de la intrarea care eșuează, în ordinea aceasta: răspunde a doua adresă din exterior, prezintă identitatea pe care clientul o așteaptă, iese răspunsul pe drumul pe care a venit cererea și poate clientul afla numele înainte de a avea nevoie de el. Unde răspunsul este nu, repară acel strat și retestează cu profilul instalat, nu cu un host de test, pentru că un handshake din laborator dovedește mai puțin decât o conexiune finalizată a clientului real.

Ține o evidență scurtă per WAN, cu adresă, port, interfață de terminare, nume de certificat, cale de întoarcere și regulă de traducere, și reverific-o ori de câte ori se schimbă un circuit, un dispozitiv NAT sau o versiune de client. Căile de rezervă inactive putrezesc în liniște: nimic nu alertează despre intrarea pe care nu o folosește nimeni până în ziua în care toți depind de ea.