Bigarren WAN VPN sarrera huts egiten du lehena lanean jarraitzen duen bitartean

Lehen tunela zutik dago, erabiltzaileek lanean jarraitzen dute eta bigarren ISP zirkuitua alferrik dago, edozer aldatuta ere. Babes-zirkuiturako helbide bat argitaratu duzu, izen bat hara bideratu duzu, agian babes-sarrera bat gehitu diozu bezeroari, eta bezeroak edo ez du inoiz probatzen edo autentifikatu eta gero hiltzen da. Jarraitu ditudan kasuetan, failover funtzioa ondo egon ohi zen; falta zena sarrera bat erabilgarri egiten duten bost gauzetako bat zen. Izen batek babes-helbidera ebatzi dezake interfaze horretan ezer entzuten ez den bitartean, eta entzule batek konexio bat onar dezake erantzuna lehenengo bidetik irteten den bitartean. Trata ezazu WAN bakoitza bere kontratua duen sarrera bereizi gisa eta hutsegiteak bezeroaren akatsa izateari utziko dio.

WAN bakoitzak bere sarrera-kontratua behar du

Erregistra itzazu bost eremu WAN bakoitzeko: izen eta helbide publikoa, garraioa eta ataka, amaitzen duen interfazea edo testuingurua, aurkeztu behar duen parearen nortasuna eta erantzuna nondik irteten den. Bi zirkuitu bi multzo oso esan nahi du. Bigarren multzoak amaiera-interfazerik edo itzulera-biderik ez badu, ez duzu babes-sarrerarik; asmo bat deskribatzen duen DNS erregistro bat duzu.

Gailuak eta bere bertsioak ere antolaketa hori onartu behar dute. DNS erregistro batek ezin du zerbitzu bat ireki beste interfaze batean, eta plataforma askotan entzulea helbideka konfiguratzen da, ez gailuka. ASA batean interfazean oinarritutako IPsec-ek kripto-mapak eta tunel-taldeak kanpoko interfazeari lotzen dizkio, beraz bigarren uplink batek politika behar du pakete horiek benetan iristen diren tokian. Ibilbideetan oinarritutako diseinuek bestela jokatzen dute: entzulea helbide guztiei edo izendatutako helbide bati lotu dakizkioke, eta aukera horrek erabakitzen du ISP B-k batere erantzun dezakeen.

Egiaztatu bigarren WAN-ek benetan erantzuten duela

Probatu bi zirkuituetatik kanpo, ez atebidearen atzeko makinatik, eta probatu bezeroaren profileak erabiltzen duen izen zehatza. TLS entzule baterako, egiaztapen azkarra openssl s_client -connect ADDRESS:443 -servername vpn.example.com -showcerts da, zure sareaz kanpoko ostalari batetik exekutatuta. Amaitutako eskuko keinu bat nahi duzu, profileko izenarekin bat datorren katea duena, ez konexio bat onartzen duen TCP ataka soilik.

RFC 9525 dokumentuak azaltzen du bezeroak zer egiaztatzen duen: lortu nahi zuen nortasuna, zerbitzuak aurkezten duen ziurtagiriarekin alderatuta. Lehen sarreraren ziurtagiria itzultzen duen bigarren sarrera batek, edo izenetako bat ere zerrendatzen ez duen ziurtagiri lehenetsi batek, proba hau gainditzen ez du, ataka irekita egon eta suebakiak onartu arren.

Bi ereduk azaltzen dituzte hemen hutsegite gehienak. Zintzilik geratzen den konexio batek normalean esan nahi du ez dagoela entzulerik interfaze horretan, lehen mailako azpisareak soilik onartzen dituen sarbide-arau bat, edo bigarren zirkuituaren aurrean ataka botatzen duen eramaile-gailu bat. Nortasun okerrarekin amaitzen den eskuko keinu batek normalean esan nahi du beste trustpoint bat, host birtual lehenetsi bat edo lehenengotik kopiatutako konfigurazioa nortasuna egokitu gabe.

Jarraitu erantzunari, ez soilik eskaerari

Bigarren WAN normalean itzulera-bidean hausten da. Eskaera bat ISP B-tik iristen da, gailuak erantzuten du, eta erantzuna ISP A-ko ibilbide lehenetsitik irteten da bezeroak inoiz eskatu ez zuen jatorri-helbide batekin. Egoerazko itzulpenak okerrera egiten du: mapaketa lehen interfazerako eraiki bazen, itzultzen den paketeak itzulpena huts egiten du edo bezeroaren suebakiak baztertzen duen jatorria darama. Hornitzaileek ere baztertzen dituzte eman zizuten zirkuituari dagozkion ez diren jatorri-helbideak, eta horregatik honek norabide bakarreko zulo beltz bat dirudi, protokolo-errore garbi bat izan beharrean.

Egiaztatu bigarren sarreratik datozen trafikoaren ibilbide-erabakia. Erantzunak eskaera iritsi zen interfazetik irten behar du, edo gutxienez urrutiko aldeak bide horretakotzat onartzen duen helbide bat eraman behar du. Politikan oinarritutako ibilbide-plataformetan horrek esan nahi du sarrerako interfazeari edo itzulitako jatorriari lotutako arau bat, gehi kanpoko interfaze bakoitzari lotutako itzulpen-adierazpen bat. Grabatu aldi berean bi interfazeetan bezeroa konektatzen ari den bitartean; ISP B-tik iristen den SYN batek eta ISP A-tik irteten den SYN-ACK-ek galdera txanda bakarrean argitzen dute.

Eman bezeroari bigarren sarrera ezagutzeko modua

Failover bezeroaren aldeko erabakia da, eta bezero-familia bakoitzak modu ezberdinean ikasten ditu alternatibak. ASA batean, babes-zerbitzarien zerrenda talde-politikaren webvpn atributuen bidez ematen da, beste bezero batzuek profilean zerrenda bat edo erabiltzaileak hautatzen duen eskuzko bigarren profil bat espero duten bitartean. Cisco-ren konexio-politikaren gidak bezeroan konfiguratutako eta atebideak emandako babes-informazioa deskribatzen ditu, eta protokoloaren berariazko xehetasun horiek ez lirateke bezero edo tunel modu guztietara orokortu behar. Berretsi zabaldutako bezeroak zein mekanismo ezartzen duen, bigarren sarrera okerraren inguruan eraiki aurretik.

Mekanismoa edozein dela ere, bezeroak izen alternatiboa ebatzi ahal izan behar du lehen bidea galdu aurretik. Mendekotasun hori da jendeak ahazten duena: babes-izena berriki huts egin duen tunelaren bidez soilik irisgarria den ebazle batek erantzuten badu, babesak ezin du hasi ere egin. Argitaratu bigarren izena tokian edo interneten bidez erantzuten duen ebazle batean. Espero autentifikazio berria eta aplikazio-saio berria lekualdaketaren ondoren, bezeroaren failoverra ez baita egoerazko failoverra eta saio luzeek ez dute bizirauten.

Helbide bakarra bi hornitzailerekin beste produktu bat da

Helbide publiko bakarra bi zirkuituen bidez irisgarri edukitzea ibilbide-zerbitzua da, ez VPN-eko kontrol-laukia. Bi hornitzaileek eramateko prest dauden helbide-espazioa behar du, haien sareek onartzen duten moduan iragarrita, eta hori ematen du hornitzailearekiko independentea den espazioarekin eta BGP-rekin egindako multihomingak. ISP A-ren helbidea ISP B-ren interfazeari esleitzeak ez du hara eramaten; paketea prefixua inoiz iragarri ez zuen sare batera iristen da eta goian baztertzen da.

Ez duzu horietako ezer behar bi sarrera argitaratzeko. Bezeroak bi izen eduki eta haien artean huts egin dezakeen, bi sarrera independente nahikoa dira, eta AS zenbaki bat, peering akordio bat eta nonahi onartu beharreko prefixu bat saihesten dituzu. Aztertu helbide eramangarriaren aukera benetan behar duzunean bezeroek ordezkatzeko birkonfigura ezin dezaketen sarrera-puntu egonkor bakarra, edo TTL atzerapena duen DNSn oinarritutako failoverra diseinatzen ari zaren etenaldirako motelgia denean.

Zer egiaztatu hurrengo

Lan egin huts egiten duen sarreratik kanpora ordena honetan: bigarren helbideak kanpotik erantzuten du, bezeroak espero duen nortasuna aurkezten du, erantzuna eskaera iritsi zen bidetik irteten da, eta bezeroak izena behar baino lehen ikas dezake. Erantzuna ez bada, konpondu geruza hori eta probatu berriro zabaldutako profilekin, probako ostalari batekin beharrean, laborategiko eskuko keinu batek bezero errealaren konexio osatua baino gutxiago frogatzen baitu.

Mantendu erregistro labur bat WAN bakoitzeko, helbidea, ataka, amaiera-interfazea, ziurtagiriaren izena, itzulera-bidea eta itzulpen-araua barne, eta berrikusi zirkuitu, NAT gailu edo bezero-bertsio bat aldatzen den bakoitzean. Babes-bide alferrak isilka usteltzen dira: inork erabiltzen ez duen sarreraz ezerk ez du abisatzen, denek haren mende dauden egunera arte.