Den andre WAN-VPN-inngangen feilar mens den primære virkar

Den primære tunnelen holder seg oppe, brukerne fortsetter å jobbe, og den andre ISP-linjen står ubrukt uansett hva du endrer. Du publiserte en adresse for reservelinjen, pekte et navn mot den, kanskje la til en reserveinngang i klienten, og klienten prøver den enten aldri eller autentiserer og dør etterpå. I sakene jeg har sporet opp, var failover-funksjonen vanligvis i orden; det som manglet var en av de fem tingene som gjør en inngang brukbar. Et navn kan slås opp til reserveadressen mens ingenting lytter på det grensesnittet, og en lytter kan godta en tilkobling mens svaret går ut gjennom den primære. Behandle hver WAN som en egen inngang med sin egen kontrakt, og feilen slutter å se ut som en klientfeil.

Hver WAN trenger sin egen inngangskontrakt

Før opp fem felt per WAN: det offentlige navnet og adressen, transporten og porten, grensesnittet eller konteksten som avslutter den, identiteten den skal presentere overfor motparten, og hvor svaret går ut. To linjer betyr to komplette sett. Hvis det andre settet ikke har noe avsluttende grensesnitt eller ingen returvei, har du ingen reserveinngang; du har en DNS-post som beskriver en intensjon.

Apparatet og programvaren det kjører, må også støtte oppsettet. En DNS-post kan ikke åpne en tjeneste på et annet grensesnitt, og på mange plattformer konfigureres lytteren per adresse og ikke per enhet. Grensesnittbasert IPsec på en ASA binder kryptokart og tunnelgrupper til det ytre grensesnittet, så en andre uplink trenger policy der pakkene faktisk kommer inn. Rutebaserte design oppfører seg annerledes: lytteren kan bindes til alle adresser eller til én navngitt adresse, og det valget avgjør om ISP B kan svare i det hele tatt.

Kontroller at den andre WAN-en faktisk svarer

Test fra utsiden av begge linjene, ikke fra en maskin bak gatewayen, og test det nøyaktige navnet klientprofilen bruker. For en TLS-lytter er den raske kontrollen openssl s_client -connect ADDRESS:443 -servername vpn.example.com -showcerts kjørt fra en vert utenfor nettverket ditt. Du vil ha et fullført håndtrykk der kjeden samsvarer med navnet i profilen, ikke bare en TCP-port som godtar en tilkobling.

RFC 9525 forklarer hva klienten sjekker: identiteten den hadde tenkt å nå, sammenlignet med sertifikatet tjenesten presenterer. En andre inngang som leverer sertifikatet til den primære inngangen, eller et standardsertifikat som ikke lister noen av navnene, feiler denne testen selv om porten er åpen og brannmuren tillater den.

To mønstre forklarer de fleste feilene her. En tilkobling som henger betyr vanligvis at det ikke finnes noen lytter på det grensesnittet, en tilgangsregel som bare tillater de primære subnettnene, eller en operatørenhet foran den andre linjen som dropper porten. Et håndtrykk som fullføres med feil identitet betyr vanligvis et annet trustpoint, en standard virtuell vert, eller konfigurasjon kopiert fra den primære uten å justere identiteten.

Følg svaret, ikke bare forespørselen

Den andre WAN-en bryter vanligvis sammen på veien tilbake. En forespørsel kommer inn på ISP B, apparatet svarer, og svaret går ut gjennom standardruten på ISP A med en kildeadresse klienten aldri ba om. Tilstandsfull oversetting gjør det verre: hvis mappingen ble bygget for det primære grensesnittet, bommer returpakken på oversettingen eller bærer en kilde klientens brannmur forkaster. Leverandører dropper også kildeadresser som ikke tilhører linjen de ga deg, og derfor ser dette ut som et ensrettet svart hull i stedet for en ren protokollfeil.

Sjekk rutingsbeslutningen for trafikk med kilde i den andre inngangen. Svaret skal gå ut gjennom grensesnittet forespørselen kom inn på, eller i det minste bære en adresse den andre siden godtar som tilhørende den veien. På plattformer med policy-ruting betyr det en regel knyttet til det innkommende grensesnittet eller den oversatte kilden, pluss en oversettingssetning bundet til hvert ytre grensesnitt. Ta opp på begge grensesnittene samtidig mens klienten kobler til; en SYN som kommer inn på ISP B med SYN-ACK som går ut på ISP A avgjør spørsmålet i én kjøring.

Gi klienten en måte å lære om inngang to

Failover er en beslutning på klientsiden, og hver klientfamilie lærer om alternativer på sin måte. På en ASA leveres reserveserverlisten gjennom gruppepolicyens webvpn-attributter, mens andre klienter forventer en liste i profilen eller en manuell andre profil brukeren velger. Ciscos veiledning for tilkoblingspolicy beskriver både klientkonfigurert og gateway-levert reserveinformasjon, og disse protokollspesifikke detaljene bør ikke generaliseres til enhver klient eller tunnelmodus. Bekreft hvilken mekanisme den installerte klienten implementerer før du bygger den andre inngangen rundt den gale.

Uansett mekanisme må klienten kunne slå opp det alternative navnet før den mister den primære veien. Den avhengigheten er den folk går glipp av: hvis reservenavnet besvares av en resolver som bare er tilgjengelig gjennom tunnelen som nettopp feilet, kan reserven ikke engang starte. Publiser det andre navnet i en resolver som svarer lokalt eller over internett. Forvent en ny autentisering og en ny applikasjonsøkt etter flyttingen, fordi klientfailover ikke er tilstandsfull failover, og langvarige økter overlever den ikke.

Én adresse hos to leverandører er et annet produkt

Å holde én offentlig adresse tilgjengelig gjennom begge linjene er en rutetjeneste, ikke en avkrysningsboks i VPN-en. Det krever adresserom begge leverandørene er villige til å frakte, annonsert på en måte nettverkene deres godtar, og det er nettopp det multihoming med leverandøruavhengig adresserom og BGP gir. Å tildele ISP As adresse til ISP Bs grensesnitt kommer deg ikke dit; pakken ankommer et nettverk som aldri annonserte prefikset og blir droppet oppstrøms.

Du trenger ingenting av dette for å publisere to innganger. Hvis klienten kan holde to navn og feile mellom dem, er to uavhengige innganger nok, og du unngår et AS-nummer, et peering-oppsett og et prefiks som må godtas overalt. Vurder alternativet med flyttbar adresse bare når du virkelig trenger ett stabilt inngangspunkt klientene ikke kan omkonfigureres til å erstatte, eller når DNS-basert failover med TTL-forsinkelsen er for treg for avbruddet du dimensjonerer for.

Hva du bør sjekke neste gang

Arbeid deg utover fra inngangen som feiler, i denne rekkefølgen: svarer den andre adressen fra utsiden, presenterer den identiteten klienten forventer, går svaret ut slik forespørselen kom inn, og kan klienten lære navnet før den trenger det. Der svaret er nei, rett opp i det laget og test på nytt med den distribuerte profilen og ikke en testvert, fordi et håndtrykk fra laboratoriet beviser mindre enn en fullført tilkobling fra den ekte klienten.

Hold en kort oversikt per WAN med adresse, port, avsluttende grensesnitt, sertifikatnavn, returvei og oversettingsregel, og kontroller den på nytt hver gang en linje, en NAT-enhet eller en klientversjon endres. Ubrukte reserveveier råtner i stillhet: ingenting varsler om inngangen ingen bruker, helt til dagen alle er avhengige av den.