Een tweede WAN-VPN-ingang werkt niet terwijl de primaire nog werkt

De primaire tunnel blijft overeind, gebruikers blijven werken en het tweede ISP-circuit blijft ongebruikt, wat je ook verandert. Je hebt een adres voor het back-upcircuit gepubliceerd, er een naam naar laten wijzen, misschien een back-upingang aan de client toegevoegd, en de client probeert het nooit of authenticeert en sterft daarna. In de gevallen die ik heb nagelopen, was de failoverfunctie meestal in orde; wat ontbrak was een van de vijf dingen die een ingang bruikbaar maken. Een naam kan naar het back-upadres verwijzen terwijl er niets op die interface luistert, en een listener kan een verbinding accepteren terwijl het antwoord via de primaire naar buiten gaat. Behandel elke WAN als een aparte ingang met een eigen contract, en de storing ziet er niet langer uit als een clientbug.

Elke WAN heeft een eigen ingangscontract nodig

Leg vijf velden per WAN vast: de openbare naam en het adres, het transport en de poort, de interface of context die hem termineert, de peer-identiteit die hij moet presenteren, en waar het antwoord naar buiten gaat. Twee circuits betekenen twee complete sets. Als de tweede set geen terminerende interface of geen retourpad heeft, heb je geen back-upingang; je hebt een DNS-record dat een bedoeling beschrijft.

Het apparaat en de release ervan moeten de opzet ook ondersteunen. Een DNS-record kan geen dienst op een andere interface openen, en op veel platforms wordt de listener per adres en niet per apparaat geconfigureerd. Interfacegebaseerde IPsec op een ASA koppelt cryptomaps en tunnelgroepen aan de buiteninterface, dus een tweede uplink heeft beleid nodig waar die pakketten werkelijk binnenkomen. Routegebaseerde ontwerpen gedragen zich anders: de listener kan aan elk adres of aan één genoemd adres binden, en die keuze bepaalt of ISP B überhaupt kan antwoorden.

Controleer of de tweede WAN echt antwoordt

Test van buiten beide circuits, niet vanaf een machine achter de gateway, en test de exacte naam die het clientprofiel gebruikt. Voor een TLS-listener is de snelle controle openssl s_client -connect ADDRESS:443 -servername vpn.example.com -showcerts uitgevoerd vanaf een host buiten je netwerk. Je wilt een voltooide handshake waarvan de keten overeenkomt met de naam in het profiel, niet slechts een TCP-poort die een verbinding accepteert.

RFC 9525 legt uit wat de client controleert: de identiteit die hij wilde bereiken, vergeleken met het certificaat dat de dienst presenteert. Een tweede ingang die het certificaat van de primaire ingang teruggeeft, of een standaardcertificaat dat geen van beide namen vermeldt, faalt voor deze test, ook al is de poort open en staat de firewall het toe.

Twee patronen verklaren de meeste storingen hier. Een verbinding die blijft hangen betekent meestal dat er geen listener op die interface is, een toegangsregel die alleen de primaire subnetten toestaat, of een carrierapparaat vóór het tweede circuit dat de poort laat vallen. Een handshake die met de verkeerde identiteit eindigt betekent meestal een ander trustpoint, een standaard virtuele host, of configuratie die van de primaire is gekopieerd zonder de identiteit aan te passen.

Volg het antwoord, niet alleen het verzoek

De tweede WAN breekt meestal op de terugweg. Een verzoek komt binnen op ISP B, het apparaat antwoordt, en het antwoord gaat via de standaardroute op ISP A naar buiten met een bronadres waar de client nooit om vroeg. Stateful vertaling maakt het erger: als de mapping voor de primaire interface is gebouwd, mist het retourpakket de vertaling of draagt het een bron die de firewall van de client weggooit. Providers laten ook bronadressen vallen die niet bij het geleverde circuit horen, en daarom ziet dit eruit als een eenrichtings-zwart gat in plaats van een nette protocolfout.

Controleer de routeringsbeslissing voor verkeer dat van de tweede ingang afkomstig is. Het antwoord moet de interface verlaten waar het verzoek binnenkwam, of op zijn minst een adres dragen dat de andere kant als bij dat pad horend accepteert. Op platforms met beleidsroutering betekent dat een regel gekoppeld aan de inkomende interface of de vertaalde bron, plus een vertaalstatement dat aan elke buiteninterface is gebonden. Leg op beide interfaces tegelijk een capture vast terwijl de client verbinding maakt; een SYN die op ISP B binnenkomt met een SYN-ACK die op ISP A naar buiten gaat, beslecht de vraag in één run.

Geef de client een manier om van ingang twee te weten

Failover is een beslissing aan de clientkant, en elke clientfamilie leert alternatieven op een andere manier kennen. Op een ASA wordt de lijst met back-upservers geleverd via de webvpn-attributen van het groepsbeleid, terwijl andere clients een lijst in het profiel verwachten of een handmatig tweede profiel dat de gebruiker kiest. De gids van Cisco voor verbindingsbeleid beschrijft zowel door de client geconfigureerde als door de gateway geleverde back-upinformatie, en die protocolspecifieke details moeten niet worden veralgemeend naar elke client of tunnelmodus. Bevestig welk mechanisme de uitgerolde client implementeert voordat je de tweede ingang rond het verkeerde bouwt.

Wat het mechanisme ook is, de client moet de alternatieve naam kunnen resolven voordat hij het primaire pad verliest. Die afhankelijkheid is degene die mensen missen: als de back-upnaam wordt beantwoord door een resolver die alleen bereikbaar is via de tunnel die net uitviel, kan de fallback niet eens beginnen. Publiceer de tweede naam in een resolver die lokaal of via internet antwoordt. Verwacht een nieuwe authenticatie en een nieuwe applicatiesessie na de overstap, want clientfailover is geen stateful failover en langdurige sessies overleven hem niet.

Eén adres bij twee providers is een ander product

Eén openbaar adres via beide circuits bereikbaar houden is een routeringsdienst, geen vinkje op de VPN. Er is adresruimte voor nodig die beide providers willen dragen, aangekondigd op een manier die hun netwerken accepteren, en dat is precies wat multihoming met provideronafhankelijke ruimte en BGP biedt. Het adres van ISP A aan de interface van ISP B toewijzen brengt je daar niet; het pakket komt aan bij een netwerk dat het prefix nooit heeft aangekondigd en wordt stroomopwaarts weggegooid.

Je hebt niets daarvan nodig om twee ingangen te publiceren. Als de client twee namen kan vasthouden en daartussen kan falen, zijn twee onafhankelijke ingangen genoeg, en vermijd je een AS-nummer, een peeringafspraak en een prefix die overal geaccepteerd moet worden. Overweeg de optie met draagbaar adres alleen als je echt één stabiel ingangspunt nodig hebt dat clients niet kunnen vervangen door zich te herconfigureren, of als DNS-gebaseerde failover met zijn TTL-vertraging te traag is voor de storing waarop je ontwerpt.

Wat je hierna moet controleren

Werk van de falende ingang naar buiten toe in deze volgorde: antwoordt het tweede adres van buiten, presenteert het de identiteit die de client verwacht, verlaat het antwoord de weg waarlangs het verzoek binnenkwam, en kan de client de naam leren voordat hij hem nodig heeft. Waar het antwoord nee is, repareer je die laag en test je opnieuw met het uitgerolde profiel in plaats van een testhost, want een handshake uit het lab bewijst minder dan een voltooide verbinding van de echte client.

Houd per WAN een korte registratie bij met adres, poort, terminerende interface, certificaatnaam, retourpad en vertaalregel, en controleer die opnieuw telkens wanneer een circuit, een NAT-apparaat of een clientversie verandert. Ongebruikte back-uppaden rotten stil weg: niets waarschuwt voor de ingang die niemand gebruikt, tot de dag dat iedereen ervan afhangt.