Drugi WAN VPN ulaz ne radi dok primarni i dalje radi

Primarni tunel ostaje podignut, korisnici rade dalje, a drugi ISP krug stoji besposlen bez obzira šta promijenite. Objavili ste adresu za rezervni krug, usmjerili ime na nju, možda dodali rezervni ulaz u klijent, i klijent ga ili nikad ne pokuša ili se autentificira i zatim padne. U slučajevima koje sam pratio, funkcija prebacivanja je obično bila ispravna; nedostajala je jedna od pet stvari koje ulaz čine upotrebljivim. Ime se može razriješiti na rezervnu adresu dok na tom interfejsu ništa ne sluša, a slušalac može prihvatiti vezu dok odgovor izlazi kroz primarni. Tretirajte svaki WAN kao zaseban ulaz s vlastitim ugovorom i kvar prestaje izgledati kao greška klijenta.

Svaki WAN treba vlastiti ugovor ulaza

Zabilježite pet polja po WAN-u: javno ime i adresu, transport i port, interfejs ili kontekst koji ga završava, identitet partnera koji treba predstaviti i mjesto s kojeg odgovor izlazi. Dva kruga znače dva kompletna skupa. Ako drugi skup nema završni interfejs ili povratnu putanju, nemate rezervni ulaz; imate DNS zapis koji opisuje namjeru.

Uređaj i njegova verzija također moraju podržavati takav raspored. DNS zapis ne može otvoriti uslugu na drugom interfejsu, a na mnogim platformama slušalac se konfigurira po adresi, a ne po uređaju. IPsec zasnovan na interfejsu na ASA-i veže kripto mape i grupe tunela za vanjski interfejs, pa drugi uzlazni link treba politiku vezanu tamo gdje ti paketi zaista stižu. Rješenja zasnovana na rutama ponašaju se drukčije: slušalac se može vezati za svaku adresu ili za jednu imenovanu adresu, a taj izbor odlučuje može li ISP B uopće odgovoriti.

Provjerite da drugi WAN zaista odgovara

Testirajte izvan oba kruga, ne s mašine iza gatewaya, i testirajte tačno ime koje koristi klijentski profil. Za TLS slušalac brza provjera je openssl s_client -connect ADDRESS:443 -servername vpn.example.com -showcerts pokrenuta s hosta izvan vaše mreže. Želite dovršen handshake čiji lanac odgovara imenu u profilu, a ne samo TCP port koji prihvata vezu.

RFC 9525 objašnjava šta klijent provjerava: identitet do kojeg je namjeravao stići, upoređen s certifikatom koji usluga predstavlja. Drugi ulaz koji vraća certifikat primarnog ulaza, ili zadani certifikat koji ne navodi nijedno od imena, pada na ovom testu iako je port otvoren i firewall ga dopušta.

Dva obrasca objašnjavaju većinu kvarova ovdje. Veza koja visi obično znači da nema slušaoca na tom interfejsu, pravilo pristupa koje dopušta samo primarne podmreže, ili carrierski uređaj ispred drugog kruga koji odbacuje port. Handshake koji završi s pogrešnim identitetom obično znači drugu trustpoint točku, zadani virtualni host ili konfiguraciju kopiranu s primarnog bez prilagođavanja identiteta.

Pratite odgovor, ne samo zahtjev

Drugi WAN se obično lomi na povratku. Zahtjev stiže preko ISP-a B, uređaj odgovara, a odgovor izlazi kroz zadanu rutu na ISP-u A s izvornom adresom koju klijent nikad nije tražio. Stateful prijevod pogoršava stvar: ako je mapiranje napravljeno za primarni interfejs, povratni paket promašuje prijevod ili nosi izvor koji klijentski firewall odbacuje. Provajderi također odbacuju izvorne adrese koje ne pripadaju krugu koji su vam dali, zato to izgleda kao jednosmjerna crna rupa, a ne kao čista protokolna greška.

Provjerite odluku rutiranja za saobraćaj čiji je izvor drugi ulaz. Odgovor treba izaći kroz interfejs na koji je zahtjev stigao, ili barem nositi adresu koju daleka strana prihvata kao pripadajuću tom putu. Na platformama s politikama rutiranja to znači pravilo vezano za ulazni interfejs ili prevedeni izvor, plus izjavu o prijevodu vezanu za svaki vanjski interfejs. Snimajte istovremeno na oba interfejsa dok se klijent spaja; SYN koji stiže preko ISP-a B i SYN-ACK koji izlazi preko ISP-a A rješavaju pitanje u jednom prolazu.

Dajte klijentu način da sazna za drugi ulaz

Prebacivanje je odluka na strani klijenta i svaka klijentska porodica uči o alternativama na svoj način. Na ASA-i se lista rezervnih servera dostavlja kroz webvpn atribute grupne politike, dok drugi klijenti očekuju listu unutar profila ili ručni drugi profil koji korisnik odabere. Cisco vodič za politike veza opisuje i informacije konfigurirane u klijentu i one koje pruža gateway, a te protokolno specifične pojedinosti ne treba generalizirati na svaki klijent ili način tunela. Potvrdite koji mehanizam implementira instalirani klijent prije nego drugi ulaz izgradite oko pogrešnog.

Kakav god mehanizam bio, klijent mora moći razriješiti alternativno ime prije nego izgubi primarni put. Tu zavisnost ljudi propuštaju: ako rezervno ime odgovara resolver dostupan samo kroz tunel koji je upravo pao, rezerva ne može ni početi. Objavite drugo ime u resolveru koji odgovara lokalno ili preko interneta. Očekujte novu autentifikaciju i novu aplikacijsku sesiju nakon prelaska, jer klijentski failover nije stateful failover i dugotrajne sesije ga ne preživljavaju.

Jedna adresa kod dva provajdera je drugi proizvod

Držati jednu javnu adresu dostupnom kroz oba kruga je usluga rutiranja, a ne kućica u VPN-u. Potrebna joj je adresna prostor koja su oba provajdera voljna nositi, objavljena na način koji njihove mreže prihvataju, a to daje multihoming s prostorom neovisnim od provajdera i BGP-om. Dodjela adrese ISP-a A interfejsu ISP-a B ne vodi tamo; paket stiže u mrežu koja nikad nije objavila prefiks i biva odbačen uzvodno.

Ništa od toga vam ne treba da objavite dva ulaza. Ako klijent može držati dva imena i prebacivati se između njih, dva nezavisna ulaza su dovoljna, i izbjegavate AS broj, dogovor o peeringu i prefiks koji mora biti prihvaćen svuda. Razmotrite opciju prenosive adrese samo kada vam zaista treba jedna stabilna ulazna točka koju klijenti ne mogu prekonfigurirati da zamijene, ili kada je DNS-bazirano prebacivanje sa svojim TTL kašnjenjem presporo za prekid protiv kojeg projektujete.

Šta provjeriti dalje

Radite prema van od ulaza koji ne radi ovim redom: odgovara li druga adresa izvana, predstavlja li identitet koji klijent očekuje, izlazi li odgovor putem kojim je zahtjev stigao i može li klijent saznati ime prije nego mu zatreba. Gdje je odgovor ne, popravite taj sloj i ponovo testirajte s instaliranim profilom, a ne s testnim hostom, jer handshake iz laboratorije dokazuje manje od dovršene veze stvarnog klijenta.

Vodite kratak zapis po WAN-u s adresom, portom, završnim interfejsom, imenom certifikata, povratnom putanjom i pravilom prijevoda, i provjeravajte ga iznova kad god se promijeni krug, NAT uređaj ili verzija klijenta. Besposlene rezervne putanje tiho trunu: ništa ne upozorava na ulaz koji nitko ne koristi sve do dana kada svi zavise od njega.