Den andre WAN-VPN-inngangen feilar medan den primære verkar

Den primære tunnelen held seg oppe, brukarane held fram med å arbeide, og den andre ISP-linja står ubrukt uansett kva du endrar. Du publiserte ei adresse for reservelinja, peika eit namn mot ho, kanskje la du til ein reserveinngang i klienten, og klienten prøver han anten aldri eller autentiserer og døyr etterpå. I sakene eg har spora opp, var failover-funksjonen vanlegvis i orden; det som mangla var ein av dei fem tinga som gjer ein inngang brukande. Eit namn kan slåast opp til reserveadressa medan ingenting lyttar på det grensesnittet, og ein lyttar kan godta ei tilkopling medan svaret går ut gjennom den primære. Behandle kvar WAN som ein eigen inngang med sin eigen kontrakt, og feilen sluttar å sjå ut som ein klientfeil.

Kvar WAN treng sin eigen inngangskontrakt

Før opp fem felt per WAN: det offentlege namnet og adressa, transporten og porten, grensesnittet eller konteksten som avsluttar han, identiteten han skal presentere overfor motparten, og kvar svaret går ut. To linjer tyder to komplette sett. Viss det andre settet ikkje har noko avsluttande grensesnitt eller ingen returveg, har du ingen reserveinngang; du har ein DNS-post som skildrar ei meining.

Apparatet og programvara det køyrer, må også støtte oppsettet. Ein DNS-post kan ikkje opne ei teneste på eit anna grensesnitt, og på mange plattformer blir lyttaren konfigurert per adresse og ikkje per eining. Grensesnittbasert IPsec på ein ASA bind kryptokart og tunnelgrupper til det ytre grensesnittet, så ein andre uplink treng policy der pakkane faktisk kjem inn. Rutebaserte design oppfører seg annleis: lyttaren kan bindast til alle adresser eller til éi namngitt adresse, og det valet avgjer om ISP B kan svare i det heile.

Kontroller at den andre WAN-en faktisk svarar

Test frå utsida av begge linjene, ikkje frå ein maskin bak gatewayen, og test det nøyaktige namnet klientprofilen brukar. For ein TLS-lyttar er den raske kontrollen openssl s_client -connect ADDRESS:443 -servername vpn.example.com -showcerts køyrd frå ein vert utanfor nettverket ditt. Du vil ha eit fullført handtrykk der kjeda samsvarar med namnet i profilen, ikkje berre ein TCP-port som godtar ei tilkopling.

RFC 9525 forklarar kva klienten sjekkar: identiteten han hadde tenkt å nå, samanlikna med sertifikatet tenesta presenterer. Ein andre inngang som leverer sertifikatet til den primære inngangen, eller eit standardsertifikat som ikkje listar nokon av namna, feilar denne testen sjølv om porten er open og brannmuren tillèt han.

To mønster forklarar dei fleste feila her. Ei tilkopling som heng betyr vanlegvis at det ikkje finst nokon lyttar på det grensesnittet, ein tilgangsregel som berre tillèt dei primære subnettane, eller ei operatøreining framfor den andre linja som droppar porten. Eit handtrykk som blir fullført med feil identitet betyr vanlegvis eit anna trustpoint, ein standard virtuell vert, eller konfigurasjon kopiert frå den primære utan å justere identiteten.

Følg svaret, ikkje berre førespurnaden

Den andre WAN-en bryt vanlegvis saman på vegen tilbake. Ein førespurnad kjem inn på ISP B, apparatet svarar, og svaret går ut gjennom standardruta på ISP A med ei kildeadresse klienten aldri bad om. Tilstandsfull omsetjing gjer det verre: viss mappinga vart bygd for det primære grensesnittet, bommar returpakken på omsetjinga eller ber ei kjelde brannmuren til klienten kastar. Leverandørar droppar også kildeadresser som ikkje høyrer til linja dei gav deg, og difor ser dette ut som eit einsretta svart hol i staden for ein rein protokollfeil.

Sjekk rutingsavgjerda for trafikk med kjelde i den andre inngangen. Svaret skal gå ut gjennom grensesnittet førespurnaden kom inn på, eller i det minste bere ei adresse den andre sida godtar som høyrer til den vegen. På plattformer med policy-ruting betyr det ein regel knytt til det innkommande grensesnittet eller den omsette kjelda, pluss ei omsetjingssetning bunden til kvart ytre grensesnitt. Ta opp på begge grensesnitta samtidig medan klienten koplar til; ein SYN som kjem inn på ISP B med SYN-ACK som går ut på ISP A avgjer spørsmålet i éin køyring.

Gje klienten ein måte å lære om inngang to

Failover er ei avgjerd på klientsida, og kvar klientfamilie lærer om alternativ på sin måte. På ein ASA blir reserveserverlista levert gjennom webvpn-attributta til gruppepolicyen, medan andre klientar ventar ei liste i profilen eller ein manuell andre profil brukaren vel. Rettleiinga til Cisco for tilkoplingspolicy skildrar både klientkonfigurert og gateway-levert reserveinformasjon, og desse protokollspesifikke detaljane bør ikkje generaliserast til kvar klient eller tunnelmodus. Stadfest kva mekanisme den utrulla klienten implementerer før du byggjer den andre inngangen rundt den gale.

Uansett mekanisme må klienten kunne slå opp det alternative namnet før han mistar den primære vegen. Den avhengigheita er den folk går glipp av: viss reservenamnet blir svara av ein resolver som berre er tilgjengeleg gjennom tunnelen som nettopp feila, kan reserven ikkje ein gong starte. Publiser det andre namnet i ein resolver som svarar lokalt eller over internett. Vent ny autentisering og ei ny applikasjonsøkt etter flyttinga, fordi klientfailover ikkje er tilstandsfull failover, og langvarige økter overlever han ikkje.

Éi adresse hos to leverandørar er eit anna produkt

Å halde éi offentleg adresse tilgjengeleg gjennom begge linjene er ei ruteteneste, ikkje ein avkrysningsboks i VPN-en. Det krev adresserom begge leverandørane er viljuge til å frakte, annonsert på ein måte nettverka deira godtar, og det er nettopp det multihoming med leverandøruavhengig adresserom og BGP gir. Å tildele adressa til ISP A til grensesnittet til ISP B kjem deg ikkje dit; pakken kjem til eit nettverk som aldri annonserte prefikset og blir droppa oppstraums.

Du treng ingenting av dette for å publisere to inngangar. Viss klienten kan halde to namn og feile mellom dei, er to uavhengige inngangar nok, og du unngår eit AS-nummer, eit peering-oppsett og eit prefiks som må godtakast overalt. Vurder alternativet med flyttbar adresse berre når du verkeleg treng eitt stabilt inngangspunkt klientane ikkje kan omkonfigurerast til å erstatte, eller når DNS-basert failover med TTL-forsinkinga si er for treg for avbrotet du dimensjonerer for.

Kva du bør sjekke neste gong

Arbeid deg utover frå inngangen som feilar, i denne rekkjefølgja: svarar den andre adressa frå utsida, presenterer han identiteten klienten ventar, går svaret ut slik førespurnaden kom inn, og kan klienten lære namnet før han treng det. Der svaret er nei, rett opp i det laget og test på nytt med den utrulla profilen og ikkje ein testvert, fordi eit handtrykk frå laboratoriet beviser mindre enn ei fullført tilkopling frå den ekte klienten.

Hald ei kort oversikt per WAN med adresse, port, avsluttande grensesnitt, sertifikatnamn, returveg og omsetjingsregel, og kontroller ho på nytt kvar gong ei linje, ei NAT-eining eller ein klientversjon blir endra. Ubrukte reservevegar råtner i stillheit: ingenting varslar om inngangen ingen brukar, heilt til dagen alle er avhengige av han.