Anden WAN VPN-post fejler, mens den primære stadig virker

Den primære tunnel bliver oppe, brugerne arbejder videre, og den anden ISP-forbindelse ligger uvirksom, uanset hvad du ændrer. Du har offentliggjort en adresse til backup-forbindelsen, peget et navn på den, måske tilføjet en backup-post i klienten, og klienten prøver den enten aldrig eller godkender og dør derefter. I de sager, jeg har fulgt, var failover-funktionen som regel i orden; det, der manglede, var en af de fem ting, der gør en post brugbar. Et navn kan opløses til backup-adressen, mens intet lytter på det interface, og en listener kan acceptere en forbindelse, mens svaret forlader gennem den primære. Behandl hver WAN som en separat post med sin egen kontrakt, og fejlen holder op med at ligne en klientfejl.

Hver WAN har brug for sin egen postkontrakt

Notér fem felter for hver WAN: det offentlige navn og adresse, transport og port, det interface eller den kontekst, der terminerer den, den peer-identitet, den skal præsentere, og hvor svaret forlader. To forbindelser betyder to komplette sæt. Hvis det andet sæt ikke har et terminerende interface eller en returvej, har du ikke en backup-post; du har en DNS-post, der beskriver en hensigt.

Apparatet og dets version skal også understøtte arrangementet. En DNS-post kan ikke åbne en tjeneste på et andet interface, og på mange platforme konfigureres listeneren per adresse i stedet for per enhed. Interfacebaseret IPsec på en ASA binder crypto-maps og tunnelgrupper til det udvendige interface, så en anden uplink har brug for politik knyttet der, hvor de pakker faktisk ankommer. Rutebaserede design opfører sig anderledes: listeneren kan binde til hver adresse eller til én navngivet adresse, og det valg afgør, om ISP B overhovedet kan svare.

Kontrollér, at den anden WAN faktisk svarer

Test udefra begge forbindelser, ikke fra en maskine bag gatewayen, og test præcis det navn, klientprofilen bruger. For en TLS-listener er det hurtige tjek openssl s_client -connect ADDRESS:443 -servername vpn.example.com -showcerts kørt fra en vært uden for dit netværk. Du vil have et fuldført handshake, hvis kæde matcher navnet i profilen, ikke bare en TCP-port, der accepterer en forbindelse.

RFC 9525 forklarer, hvad klienten kontrollerer: den identitet, den havde til hensigt at nå, sammenlignet med det certifikat, tjenesten præsenterer. En anden post, der sender den primære posts certifikat tilbage, eller et standardcertifikat, der ikke lister nogen af navnene, fejler denne test, selv om porten er åben, og firewallen tillader det.

To mønstre forklarer de fleste fejl her. En forbindelse, der hænger, betyder normalt ingen listener på det interface, en adgangsregel, der kun tillader de primære subnets, eller en operatørenhed foran den anden forbindelse, der dropper porten. Et handshake, der slutter med den forkerte identitet, betyder normalt et andet trustpoint, en standard virtuel host eller konfiguration kopieret fra den primære uden at tilpasse identiteten.

Følg svaret, ikke kun anmodningen

Den anden WAN brækker normalt på vejen tilbage. En anmodning ankommer via ISP B, apparatet svarer, og svaret forlader gennem standardruten på ISP A med en kildeadresse, klienten aldrig bad om. Stateful oversættelse gør det værre: hvis mappingen blev bygget til det primære interface, rammer den returnerende pakke ikke oversættelsen eller bærer en kilde, som klientens firewall kasserer. Udbydere dropper også kildeadresser, der ikke hører til den forbindelse, de gav dig, og derfor ligner det et ensrettet sort hul i stedet for en ren protokolfejl.

Kontrollér routingbeslutningen for trafik med kilde i den anden post. Svaret skal forlade det interface, anmodningen ankom på, eller i det mindste bære en adresse, den fjerne side accepterer som hørende til den vej. På policy-routing-platforme betyder det en regel knyttet til det indgående interface eller den oversatte kilde plus en oversættelseserklæring bundet til hvert udvendigt interface. Fang samtidigt på begge interfaces, mens klienten forbinder; et SYN, der ankommer på ISP B, med SYN-ACK, der forlader på ISP A, afgør spørgsmålet i ét kør.

Giv klienten en måde at lære om post to

Failover er en beslutning på klientsiden, og hver klientfamilie lærer om alternativer på sin egen måde. På en ASA leveres backup-serverlisten via gruppepolitikkens webvpn-attributter, mens andre klienter forventer en liste inde i profilen eller en manuel anden profil, brugeren vælger. Ciscos vejledning i forbindelsespolitik beskriver både klientkonfigureret og gateway-leveret backup-information, og disse protokolspecifikke detaljer bør ikke generaliseres til enhver klient eller tunnelmode. Bekræft, hvilken mekanisme den udrullede klient implementerer, før du bygger den anden post op omkring den forkerte.

Uanset mekanismen skal klienten kunne opløse det alternative navn, før den mister den primære vej. Den afhængighed er den, folk overser: hvis backup-navnet besvares af en resolver, der kun kan nås gennem den tunnel, der netop fejlede, kan fallback slet ikke starte. Offentliggør det andet navn i en resolver, der svarer lokalt eller over internettet. Forvent en ny godkendelse og en ny applikationssession efter skiftet, fordi klientens failover ikke er stateful failover, og langvarige sessioner overlever den ikke.

Én adresse på to udbydere er et andet produkt

At holde én offentlig adresse tilgængelig gennem begge forbindelser er en routingtjeneste, ikke et afkrydsningsfelt i VPN'en. Det kræver adresseplads, som begge udbydere vil bære, annonceret på en måde, deres netværk accepterer, og det er, hvad multihoming med udbyderuafhængig plads og BGP giver. At tildele ISP A's adresse til ISP B's interface fører ikke dertil; pakken ankommer til et netværk, der aldrig annoncerede præfikset, og kasseres opstrøms.

Du har ikke brug for noget af det for at offentliggøre to poster. Hvis klienten kan holde to navne og fejle mellem dem, er to uafhængige poster nok, og du undgår et AS-nummer, en peering-aftale og et præfiks, der skal accepteres overalt. Overvej muligheden for bærbar adresse kun, når du virkelig har brug for ét stabilt indgangspunkt, som klienter ikke kan omkonfigureres til at erstatte, eller når DNS-baseret failover med sin TTL-forsinkelse er for langsom til det udfald, du designer imod.

Hvad du skal kontrollere næste gang

Arbejd udad fra den fejlende post i denne rækkefølge: svarer den anden adresse udefra, præsenterer den den identitet, klienten forventer, forlader svaret den vej, anmodningen ankom, og kan klienten lære navnet, før den har brug for det. Hvor svaret er nej, ret den lag og test igen med den udrullede profil i stedet for en testvært, fordi et handshake fra laboratoriet beviser mindre end en fuldført forbindelse fra den rigtige klient.

Hold en kort registrering for hver WAN med adresse, port, terminerende interface, certifikatnavn, returvej og oversættelsesregel, og kontrollér den igen, hver gang en forbindelse, en NAT-enhed eller en klientversion ændres. Uvirksomme backup-veje rådner stille: intet advarer om posten, ingen bruger, før den dag alle er afhængige af den.