Dua WAN-VPN-eniro malsukcesas dum la ĉefa ankoraŭ funkcias

La ĉefa tunelo restas supre, uzantoj daŭre laboras, kaj la dua ISP-cirkvito sidas senokupa, kion ajn vi ŝanĝas. Vi publikigis adreson por la rezerva cirkvito, direktis nomon al ĝi, eble aldonis rezervan eniron al la kliento, kaj la kliento aŭ neniam provas ĝin aŭ aŭtentikigas kaj tiam mortas. En la kazoj, kiujn mi spuradis, la malsukces-transira funkcio kutime estis en ordo; mankis unu el la kvin aferoj, kiuj igas eniron uzebla. Nomo povas solviĝi al la rezerva adreso dum nenio aŭskultas sur tiu interfaco, kaj aŭskultanto povas akcepti konekton dum la respondo eliras tra la ĉefa. Traktu ĉiun WAN kiel apartan eniron kun propra kontrakto, kaj la paneo ĉesas aspekti kiel klienta cimo.

Ĉiu WAN bezonas propran enirkontrakton

Notu kvin kampojn por ĉiu WAN: la publika nomo kaj adreso, la transporto kaj pordo, la interfaco aŭ kunteksto, kiu ĝin finas, la identeco de la samtavolano, kiun ĝi devas prezenti, kaj kie la respondo eliras. Du cirkvitoj signifas du kompletajn arojn. Se la dua aro ne havas finan interfacon aŭ ne havas revenan vojon, vi ne havas rezervan eniron; vi havas DNS-rikordon, kiu priskribas intencon.

La aparato kaj ĝia versio ankaŭ devas subteni la aranĝon. DNS-rikordo ne povas malfermi servon sur alia interfaco, kaj sur multaj platformoj la aŭskultanto agordiĝas laŭ adreso anstataŭ laŭ aparato. Interfac-bazita IPsec sur ASA ligas kriptomapojn kaj tunelgrupojn al la ekstera interfaco, do dua suprenligo bezonas politikon ligitan tie, kie tiuj pakaĵoj vere alvenas. Itin-bazitaj dezajnoj kondutas alie: la aŭskultanto povas ligiĝi al ĉiu adreso aŭ al unu nomita adreso, kaj tiu elekto decidas, ĉu ISP B povas entute respondi.

Kontrolu, ĉu la dua WAN vere respondas

Testu de ekstere de ambaŭ cirkvitoj, ne de maŝino malantaŭ la enirejo, kaj testu la ĝustan nomon, kiun uzas la klienta profilo. Por TLS-aŭskultanto, la rapida kontrolo estas openssl s_client -connect ADDRESS:443 -servername vpn.example.com -showcerts ruligita de gastiganto ekster via reto. Vi volas kompletigitan manpremon, kies ĉeno kongruas kun la nomo en la profilo, ne nur TCP-pordon, kiu akceptas konekton.

RFC 9525 klarigas, kion kontrolas la kliento: la identecon, kiun ĝi intencis atingi, komparitan kun la atestilo, kiun la servo prezentas. Dua eniro, kiu redonas la atestilon de la ĉefa eniro, aŭ implicita atestilo, kiu listigas neniun el la nomoj, malsukcesas tiun teston eĉ se la pordo estas malferma kaj la fajroŝirmilo permesas ĝin.

Du ŝablonoj klarigas plej multajn paneojn ĉi tie. Konekto, kiu pendas, kutime signifas neniun aŭskultanton sur tiu interfaco, alirregulon, kiu permesas nur la ĉefajn subretojn, aŭ portilan aparaton antaŭ la dua cirkvito, kiu faligas la pordon. Manpremo, kiu finiĝas kun la malĝusta identeco, kutime signifas alian fido-punkton, implicitan virtualan gastiganton aŭ agordon kopiitan de la ĉefa sen adapti la identecon.

Sekvu la respondon, ne nur la peton

La dua WAN kutime rompiĝas sur la revena vojo. Peto alvenas tra ISP B, la aparato respondas, kaj la respondo eliras tra la implicita itinero sur ISP A kun fonta adreso, kiun la kliento neniam petis. Stateful-traduko plimalbonigas ĝin: se la mapado estis konstruita por la ĉefa interfaco, la revenanta pakaĵo maltrafas la tradukon aŭ portas fonton, kiun la fajroŝirmilo de la kliento forĵetas. Provizantoj ankaŭ forĵetas fontajn adresojn, kiuj ne apartenas al la cirkvito, kiun ili donis al vi, tial tio aspektas kiel unudirekta nigra truo anstataŭ pura protokola eraro.

Kontrolu la itinan decidon por trafiko fontanta el la dua eniro. La respondo devus eliri la interfacon, sur kiu la peto alvenis, aŭ almenaŭ porti adreson, kiun la malproksima flanko akceptas kiel apartenantan al tiu vojo. Sur politik-bazitaj itinaj platformoj tio signifas regulon ligitan al la envenanta interfaco aŭ al la tradukita fonto, plus tradukan deklaron ligitan al ĉiu ekstera interfaco. Kaptu samtempe sur ambaŭ interfacoj dum la kliento konektiĝas; SYN alvenanta sur ISP B kun la SYN-ACK eliranta sur ISP A solvas la demandon en unu pasado.

Donu al la kliento manieron ekscii pri la dua eniro

Malsukces-transiro estas decido sur la klienta flanko, kaj ĉiu klienta familio ekscias pri alternativoj alimaniere. Sur ASA la listo de rezervaj serviloj liveriĝas per la webvpn-atributoj de la grupa politiko, dum aliaj klientoj atendas liston ene de la profilo aŭ manan duan profilon, kiun la uzanto elektas. La gvidilo de Cisco pri konekta politiko priskribas kaj kliente agorditan kaj enireje provizitan rezervan informon, kaj tiuj protokol-specifaj detaloj ne generaliĝu al ĉiu kliento aŭ tunela reĝimo. Konfirmu, kiun mekanismon la deplojita kliento efektivigas, antaŭ ol konstrui la duan eniron ĉirkaŭ la malĝusta.

Kia ajn estas la mekanismo, la kliento devas povi solvi la alternativan nomon antaŭ ol ĝi perdas la ĉefan vojon. Tiun dependon homoj maltrafas: se la rezervan nomon respondas solvilo atingebla nur tra la tunelo, kiu ĵus paneis, la retrofalo eĉ ne povas komenciĝi. Publikigu la duan nomon en solvilo, kiu respondas loke aŭ tra la interreto. Atendu novan aŭtentikigon kaj novan aplikaĵan seancon post la translokiĝo, ĉar klienta malsukces-transiro ne estas stateful-transiro kaj longdaŭraj seancoj ne postvivas ĝin.

Unu adreso ĉe du provizantoj estas alia produkto

Teni unu publikan adreson atingebla tra ambaŭ cirkvitoj estas itina servo, ne markobutono en la VPN. Ĝi bezonas adresspacon, kiun ambaŭ provizantoj pretas porti, anoncitan tiel, ke iliaj retoj akceptas ĝin, kaj tion donas multhejmigo kun provizant-neŭtrala spaco kaj BGP. Asigni la adreson de ISP A al la interfaco de ISP B ne kondukas tien; la pakaĵo alvenas en reton, kiu neniam anoncis la prefikson, kaj estas forĵetita supre.

Vi bezonas neniun el tio por publikigi du enirojn. Se la kliento povas teni du nomojn kaj malsukces-transiri inter ili, du sendependaj eniroj sufiĉas, kaj vi evitas AS-numeron, samtavolan interkonsenton kaj prefikson, kiu devas esti akceptita ĉie. Konsideru la opcion de portebla adreso nur kiam vi vere bezonas unu stabilan enirpunkton, kiun klientoj ne povas reagordi por anstataŭigi, aŭ kiam DNS-bazita malsukces-transiro kun sia TTL-prokrasto estas tro malrapida por la interrompo, kontraŭ kiu vi desegnas.

Kion kontroli poste

Laboru eksteren de la paneinta eniro laŭ ĉi tiu ordo: ĉu la dua adreso respondas de ekstere, ĉu ĝi prezentas la identecon, kiun la kliento atendas, ĉu la respondo eliras la vojon, kiun la peto alvenis, kaj ĉu la kliento povas ekscii la nomon antaŭ ol ĝi bezonas ĝin. Kie la respondo estas ne, riparu tiun tavolon kaj retestu kun la deplojita profilo anstataŭ testa gastiganto, ĉar manpremo el la laboratorio pruvas malpli ol kompletigita konekto de la reala kliento.

Tenu mallongan rikordon por ĉiu WAN kun adreso, pordo, fina interfaco, atestila nomo, revena vojo kaj traduka regulo, kaj rekontrolu ĝin ĉiufoje, kiam cirkvito, NAT-aparato aŭ klienta versio ŝanĝiĝas. Senokupaj rezervaj vojoj putriĝas silente: nenio avertas pri la eniro, kiun neniu uzas, ĝis la tago, kiam ĉiuj dependas de ĝi.