Den andra WAN-VPN-ingången misslyckas medan den primära fortfarande fungerar

Den primära tunneln ligger kvar, användarna fortsätter arbeta och den andra ISP-kretsen står oanvänd oavsett vad du ändrar. Du publicerade en adress för reservkretsen, pekade ett namn mot den, kanske lade till en reservingång i klienten, och klienten antingen testar den aldrig eller autentiserar och dör sedan. I de fall jag har följt upp var redundansfunktionen oftast i ordning; det som saknades var en av de fem saker som gör en ingång användbar. Ett namn kan lösas till reservadressen medan ingenting lyssnar på det gränssnittet, och en lyssnare kan acceptera en anslutning medan svaret går ut genom den primära. Behandla varje WAN som en egen ingång med sitt eget kontrakt, och felet slutar se ut som en klientbugg.

Varje WAN behöver sitt eget ingångskontrakt

Registrera fem fält per WAN: det publika namnet och adressen, transporten och porten, gränssnittet eller kontexten som avslutar den, identiteten den ska presentera för motparten och var svaret går ut. Två kretsar betyder två kompletta uppsättningar. Om den andra uppsättningen saknar avslutande gränssnitt eller returväg har du ingen reservväg in; du har en DNS-post som beskriver en avsikt.

Enheten och dess version måste också stödja upplägget. En DNS-post kan inte öppna en tjänst på ett annat gränssnitt, och på många plattformar konfigureras lyssnaren per adress och inte per enhet. Gränssnittsbaserad IPsec på en ASA binder kryptokartor och tunnelgrupper till det yttre gränssnittet, så en andra uplänk behöver policy där paketen faktiskt kommer in. Ruttbaserade konstruktioner beter sig annorlunda: lyssnaren kan bindas till alla adresser eller till en namngiven adress, och det valet avgör om ISP B kan svara över huvud taget.

Kontrollera att den andra WAN:en verkligen svarar

Testa utifrån båda kretsarna, inte från en maskin bakom gatewayen, och testa det exakta namn som klientprofilen använder. För en TLS-lyssnare är den snabba kontrollen openssl s_client -connect ADDRESS:443 -servername vpn.example.com -showcerts körd från en värd utanför ditt nätverk. Du vill ha en slutförd handskakning vars kedja matchar namnet i profilen, inte bara en TCP-port som accepterar en anslutning.

RFC 9525 förklarar vad klienten kontrollerar: identiteten den avsåg att nå, jämförd med certifikatet tjänsten presenterar. En andra ingång som lämnar tillbaka den primära ingångens certifikat, eller ett standardcertifikat som inte listar något av namnen, fallerar detta test även om porten är öppen och brandväggen tillåter den.

Två mönster förklarar de flesta felen här. En anslutning som hänger sig betyder oftast att det inte finns någon lyssnare på det gränssnittet, en åtkomstregel som bara tillåter de primära subnäten, eller en operatörsenhet framför den andra kretsen som släpper porten. En handskakning som avslutas med fel identitet betyder oftast en annan trustpoint, en standard virtuell värd, eller konfiguration kopierad från den primära utan att identiteten justerats.

Följ svaret, inte bara begäran

Den andra WAN:en går oftast sönder på vägen tillbaka. En begäran kommer in på ISP B, enheten svarar, och svaret går ut via standardrutten på ISP A med en källadress som klienten aldrig bad om. Tillståndsfull översättning gör det värre: om mappningen byggdes för det primära gränssnittet missar returpaketet översättningen eller bär en källa som klientens brandvägg kastar. Leverantörer kastar också källadresser som inte hör till kretsen de gav dig, och därför ser detta ut som ett enkelriktat svart hål i stället för ett rent protokollfel.

Kontrollera routingbeslutet för trafik med källa i den andra ingången. Svaret ska lämna gränssnittet som begäran kom in på, eller åtminstone bära en adress som andra sidan accepterar som hörande till den vägen. På plattformar med policy-routing betyder det en regel knuten till det inkommande gränssnittet eller den översatta källan, plus ett översättningsuttalande bundet till varje yttre gränssnitt. Fånga på båda gränssnitten samtidigt medan klienten ansluter; en SYN som kommer in på ISP B med SYN-ACK som går ut på ISP A avgör frågan i en enda körning.

Ge klienten ett sätt att få veta om ingång två

Redundansväxling är ett beslut på klientsidan, och varje klientfamilj får veta om alternativen på olika sätt. På en ASA levereras reservserverlistan via grupppolicyens webvpn-attribut, medan andra klienter förväntar sig en lista i profilen eller en manuell andra profil som användaren väljer. Ciscos vägledning för anslutningspolicy beskriver både klientkonfigurerad och gateway-levererad reservinformation, och dessa protokollspecifika detaljer bör inte generaliseras till varje klient eller tunnelmod. Bekräfta vilken mekanism den utplacerade klienten implementerar innan du bygger den andra ingången kring fel sådan.

Oavsett mekanism måste klienten kunna lösa det alternativa namnet innan den tappar den primära vägen. Det beroendet är det folk missar: om reservnamnet besvaras av en resolver som bara nås genom tunneln som just föll kan reserven inte ens börja. Publicera det andra namnet i en resolver som svarar lokalt eller över internet. Räkna med en ny autentisering och en ny applikationssession efter flytten, eftersom klientredundans inte är tillståndsfull redundans och långlivade sessioner överlever den inte.

En adress hos två leverantörer är en annan produkt

Att hålla en enda publik adress nåbar genom båda kretsarna är en routingtjänst, inte en kryssruta i VPN:en. Det kräver adressutrymme som båda leverantörerna är villiga att transportera, annonserat på ett sätt som deras nätverk accepterar, och det är vad multihoming med leverantörsoberoende utrymme och BGP ger. Att tilldela ISP A:s adress till ISP B:s gränssnitt tar dig inte dit; paketet når ett nätverk som aldrig annonserade prefixet och kastas uppströms.

Du behöver ingenting av detta för att publicera två ingångar. Om klienten kan hålla två namn och växla mellan dem räcker två oberoende ingångar, och du slipper ett AS-nummer, en peeringöverenskommelse och ett prefix som måste accepteras överallt. Överväg alternativet med flyttbar adress bara när du verkligen behöver en stabil ingångspunkt som klienterna inte kan konfigureras om för att byta ut, eller när DNS-baserad redundans med sin TTL-fördröjning är för långsam för det avbrott du dimensionerar för.

Vad du bör kontrollera härnäst

Arbeta dig utåt från ingången som fallerar i den här ordningen: svarar den andra adressen utifrån, presenterar den identiteten klienten förväntar sig, lämnar svaret den väg begäran kom in, och kan klienten lära sig namnet innan den behöver det. Där svaret är nej, åtgärda det lagret och testa om med den utplacerade profilen och inte en testvärd, eftersom en handskakning från labbet bevisar mindre än en slutförd anslutning från den riktiga klienten.

Håll en kort anteckning per WAN med adress, port, avslutande gränssnitt, certifikatnamn, returväg och översättningsregel, och kontrollera den igen varje gång en krets, en NAT-enhet eller en klientversion ändras. Oanvända reservvägar ruttnar i tysthet: ingenting larmar om ingången ingen använder, ända till den dag alla är beroende av den.