Hyrja e dytë VPN e WAN dështon ndërsa ajo kryesore vazhdon të punojë

Tuneli kryesor mbetet i hapur, përdoruesit vazhdojnë të punojnë, dhe qarku i dytë i ISP qëndron i papunë pa marrë parasysh çfarë ndryshoni. Keni publikuar një adresë për qarkun rezervë, keni drejtuar një emër drejt saj, ndoshta keni shtuar një hyrje rezervë te klienti, dhe klienti ose nuk e provon kurrë ose vërtetohet dhe pastaj vdes. Në rastet që kam ndjekur, funksioni i kalimit rezervë ishte zakonisht në rregull; mungonte një nga pesë gjërat që e bëjnë një hyrje të përdorshme. Një emër mund të zgjidhet në adresën rezervë ndërsa asgjë nuk dëgjon në atë ndërfaqe, dhe një dëgjues mund të pranojë një lidhje ndërsa përgjigja del përmes asaj kryesore. Trajtoni çdo WAN si një hyrje të veçantë me kontratën e vet dhe dështimi nuk duket më si gabim i klientit.

Çdo WAN ka nevojë për kontratën e vet të hyrjes

Regjistroni pesë fusha për çdo WAN: emrin dhe adresën publike, transportin dhe portën, ndërfaqen ose kontekstin që e përfundon, identitetin e palës që duhet të paraqesë dhe ku del përgjigja. Dy qarqe nënkuptojnë dy grupe të plota. Nëse grupi i dytë nuk ka ndërfaqe përfunduese ose nuk ka rrugë kthimi, nuk keni një hyrje rezervë; keni një regjistrim DNS që përshkruan një qëllim.

Pajisja dhe versioni i saj duhet të mbështesin gjithashtu këtë rregullim. Një regjistrim DNS nuk mund të hapë një shërbim në një ndërfaqe tjetër, dhe në shumë platforma dëgjuesi konfigurohet sipas adresës dhe jo sipas pajisjes. IPsec i bazuar në ndërfaqe në një ASA lidh hartat kriptografike dhe grupet e tuneleve me ndërfaqen e jashtme, kështu që një uplink i dytë kërkon politikë të vendosur atje ku ato paketa mbërrijnë vërtet. Dizajnet e bazuara në rrugë sillen ndryshe: dëgjuesi mund të lidhet me çdo adresë ose me një adresë të emërtuar, dhe kjo zgjedhje vendos nëse ISP B mund të përgjigjet fare.

Kontrolloni nëse WAN-i i dytë përgjigjet vërtet

Testoni nga jashtë të dy qarqeve, jo nga një makinë pas portës, dhe testoni emrin e saktë që përdor profili i klientit. Për një dëgjues TLS, kontrolli i shpejtë është openssl s_client -connect ADDRESS:443 -servername vpn.example.com -showcerts i ekzekutuar nga një host jashtë rrjetit tuaj. Dëshironi një shtrëngim duarsh të përfunduar, zinxhiri i të cilit përputhet me emrin në profil, jo thjesht një portë TCP që pranon një lidhje.

RFC 9525 shpjegon çfarë kontrollon klienti: identitetin që synonte të arrinte, krahasuar me certifikatën që paraqet shërbimi. Një hyrje e dytë që kthen certifikatën e hyrjes kryesore, ose një certifikatë e parazgjedhur që nuk liston asnjë nga emrat, dështon në këtë test edhe pse porta është e hapur dhe firewalling e lejon.

Dy modele shpjegojnë shumicën e dështimeve këtu. Një lidhje që varet zakonisht do të thotë se nuk ka dëgjues në atë ndërfaqe, një rregull hyrjeje që lejon vetëm nënrjetet kryesore, ose një pajisje operatori përpara qarkut të dytë që e hedh portën. Një shtrëngim duarsh që përfundon me identitetin e gabuar zakonisht do të thotë një pikë tjetër besimi, një host virtual i parazgjedhur, ose konfigurim i kopjuar nga ai kryesor pa rregulluar identitetin.

Ndiqni përgjigjen, jo vetëm kërkesën

WAN-i i dytë zakonisht prishet në rrugën e kthimit. Një kërkesë mbërrin në ISP B, pajisja përgjigjet, dhe përgjigja del përmes rrugës së parazgjedhur në ISP A me një adresë burimore që klienti nuk e kërkoi kurrë. Përkthimi me gjendje e përkeqëson: nëse hartëzimi u ndërtua për ndërfaqen kryesore, paketa e kthimit humbet përkthimin ose mbart një burim që firewalling i klientit e hedh. Ofruesit gjithashtu hedhin adresat burimore që nuk i përkasin qarkut që ju dhanë, prandaj kjo duket si një vrimë e zezë njëdrejtimëshe në vend të një gabimi të pastër protokolli.

Kontrolloni vendimin e rrugëtimit për trafikun me burim hyrjen e dytë. Përgjigja duhet të dalë përmes ndërfaqes ku mbërriti kërkesa, ose të paktën të mbartë një adresë që ana e largët e pranon si pjesë të asaj rruge. Në platformat me rrugëtim politikash, kjo do të thotë një rregull i lidhur me ndërfaqen hyrëse ose burimin e përkthyer, plus një deklaratë përkthimi e lidhur me çdo ndërfaqe të jashtme. Kapni njëkohësisht në të dy ndërfaqet ndërsa klienti lidhet; një SYN që hyn në ISP B me SYN-ACK që del në ISP A e zgjidh çështjen në një ekzekutim.

Jepini klientit një mënyrë për të mësuar për hyrjen e dytë

Kalimi rezervë është një vendim në anën e klientit, dhe çdo familje klientësh i mëson alternativat ndryshe. Në një ASA, lista e serverëve rezervë dorëzohet përmes atributeve webvpn të politikës së grupit, ndërsa klientët e tjerë presin një listë brenda profilit ose një profil të dytë manual që përdoruesi zgjedh. Udhëzuesi i Cisco për politikat e lidhjes përshkruan si informacionin rezervë të konfiguruar në klient ashtu edhe atë të ofruar nga porta, dhe këto detaje specifike për protokollin nuk duhen përgjithësuar për çdo klient ose mënyrë tuneli. Konfirmoni cilin mekanizëm zbaton klienti i vendosur përpara se të ndërtoni hyrjen e dytë rreth të gabuarit.

Cilido mekanizëm, klienti duhet të jetë në gjendje të zgjidhë emrin alternativ përpara se të humbasë rrugën kryesore. Kjo varësi është ajo që njerëzit e humbin: nëse emri rezervë përgjigjet nga një zgjidhës i arritshëm vetëm përmes tunelit që sapo dështoi, rezerva nuk mund të fillojë fare. Publikoni emrin e dytë në një zgjidhës që përgjigjet lokalisht ose përmes internetit. Prisni një vërtetim të ri dhe një sesion të ri aplikacioni pas zhvendosjes, sepse kalimi rezervë i klientit nuk është kalim me gjendje dhe sesionet e gjata nuk i mbijetojnë.

Një adresë në dy ofrues është një produkt tjetër

Mbajtja e një adrese të vetme publike të arritshme përmes të dy qarqeve është një shërbim rrugëtimi, jo një kuti zgjedhjeje në VPN. Kërkon hapësirë adresash që të dy ofruesit janë të gatshëm ta mbajnë, e shpallur në një mënyrë që rrjetet e tyre e pranojnë, dhe këtë e ofron multihoming me hapësirë të pavarur nga ofruesi dhe BGP. Caktimi i adresës së ISP A ndërfaqes së ISP B nuk ju çon atje; paketa mbërrin në një rrjet që nuk e shpalli kurrë prefiksin dhe hidhet në rrjedhën e sipërme.

Nuk keni nevojë për asgjë nga këto për të publikuar dy hyrje. Nëse klienti mund të mbajë dy emra dhe të kalojë mes tyre, dy hyrje të pavarura mjaftojnë, dhe shmangni një numër AS, një marrëveshje peering dhe një prefiks që duhet pranuar kudo. Merrni parasysh opsionin e adresës së lëvizshme vetëm kur ju nevojitet vërtet një pikë e vetme e qëndrueshme hyrjeje që klientët nuk mund të rikonfigurohen ta zëvendësojnë, ose kur kalimi i bazuar në DNS me vonesën e TTL është shumë i ngadaltë për ndërprerjen për të cilën po projektitoni.

Çfarë të kontrolloni më pas

Punoni nga brenda jashtë nga hyrja që dështon në këtë rend: a përgjigjet adresa e dytë nga jashtë, a paraqet identitetin që klienti pret, a del përgjigja në rrugën nga e cila erdhi kërkesa, dhe a mund ta mësojë klienti emrin përpara se t'i duhet. Aty ku përgjigja është jo, rregulloni atë shtresë dhe ritestoni me profilin e vendosur dhe jo me një host testi, sepse një shtrëngim duarsh nga laboratori provon më pak se një lidhje e përfunduar e klientit të vërtetë.

Mbani një regjistër të shkurtër për çdo WAN, me adresë, portë, ndërfaqe përfunduese, emër certifikate, rrugë kthimi dhe rregull përkthimi, dhe rikontrollojeni sa herë ndryshon një qark, një pajisje NAT ose një version klienti. Rrugët rezervë të papërdorura kalben në heshtje: asgjë nuk sinjalizon hyrjen që askush nuk e përdor deri në ditën kur të gjithë varen prej saj.