Zweiter WAN-VPN-Eintrag schlägt fehl, während der primäre weiterläuft

Der primäre Tunnel bleibt bestehen, die Nutzer arbeiten weiter, und die zweite ISP-Leitung liegt brach, egal was Sie ändern. Sie haben eine Adresse für die Backup-Leitung veröffentlicht, einen Namen darauf gezeigt, vielleicht einen Backup-Eintrag im Client ergänzt, und der Client versucht es entweder nie oder authentifiziert sich und stirbt dann. In den Fällen, die ich nachverfolgt habe, war die Failover-Funktion meist in Ordnung; es fehlte eines der fünf Dinge, die einen Eintrag nutzbar machen. Ein Name kann auf die Backup-Adresse auflösen, während auf dieser Schnittstelle nichts lauscht, und ein Listener kann eine Verbindung annehmen, während die Antwort über die primäre Schnittstelle hinausgeht. Behandeln Sie jedes WAN als eigenen Eintrag mit eigenem Vertrag, dann sieht der Fehler nicht mehr wie ein Client-Bug aus.

Jedes WAN braucht seinen eigenen Eintragsvertrag

Halten Sie fünf Felder pro WAN fest: den öffentlichen Namen und die Adresse, Transport und Port, die Schnittstelle oder den Kontext, der ihn terminiert, die Peer-Identität, die er präsentieren soll, und wo die Antwort hinausgeht. Zwei Leitungen bedeuten zwei vollständige Sätze. Hat der zweite Satz keine terminierende Schnittstelle oder keinen Rückweg, haben Sie keinen Backup-Eintrag; Sie haben einen DNS-Eintrag, der eine Absicht beschreibt.

Auch das Gerät und seine Version müssen die Anordnung unterstützen. Ein DNS-Eintrag kann keinen Dienst auf einer anderen Schnittstelle öffnen, und auf vielen Plattformen wird der Listener pro Adresse statt pro Gerät konfiguriert. Schnittstellenbasiertes IPsec auf einer ASA bindet Kryptomaps und Tunnelgruppen an die Außenschnittstelle, also braucht ein zweiter Uplink eine Policy dort, wo diese Pakete tatsächlich ankommen. Routenbasierte Designs verhalten sich anders: Der Listener kann an jede Adresse oder an eine benannte Adresse binden, und diese Wahl entscheidet, ob ISP B überhaupt antworten kann.

Prüfen Sie, ob das zweite WAN wirklich antwortet

Testen Sie von außerhalb beider Leitungen, nicht von einem Rechner hinter dem Gateway, und testen Sie genau den Namen, den das Client-Profil verwendet. Für einen TLS-Listener ist die schnelle Prüfung openssl s_client -connect ADDRESS:443 -servername vpn.example.com -showcerts von einem Host außerhalb Ihres Netzes ausgeführt. Sie wollen einen abgeschlossenen Handshake, dessen Kette zum Namen im Profil passt, nicht bloß einen TCP-Port, der eine Verbindung annimmt.

RFC 9525 erklärt, was der Client prüft: die Identität, die er erreichen wollte, verglichen mit dem Zertifikat, das der Dienst präsentiert. Ein zweiter Eintrag, der das Zertifikat des primären Eintrags zurückgibt, oder ein Standardzertifikat, das keinen der beiden Namen listet, scheitert an diesem Test, obwohl der Port offen ist und die Firewall ihn zulässt.

Zwei Muster erklären die meisten Fehler hier. Eine Verbindung, die hängt, bedeutet meist keinen Listener auf dieser Schnittstelle, eine Zugriffsregel, die nur die primären Subnetze erlaubt, oder ein Carrier-Gerät vor der zweiten Leitung, das den Port verwirft. Ein Handshake, der mit der falschen Identität endet, bedeutet meist einen anderen Trustpoint, einen Standard-Virtual-Host oder eine vom primären kopierte Konfiguration ohne angepasste Identität.

Folgen Sie der Antwort, nicht nur der Anfrage

Das zweite WAN bricht meist auf dem Rückweg. Eine Anfrage kommt über ISP B an, das Gerät antwortet, und die Antwort geht über die Standardroute auf ISP A hinaus, mit einer Quelladresse, nach der der Client nie gefragt hat. Stateful-Übersetzung verschlimmert es: Wurde das Mapping für die primäre Schnittstelle gebaut, verfehlt das zurückkehrende Paket die Übersetzung oder trägt eine Quelle, die die Firewall des Clients verwirft. Anbieter verwerfen zudem Quelladressen, die nicht zur Leitung gehören, die sie Ihnen gegeben haben, deshalb sieht es wie ein einseitiges schwarzes Loch aus statt wie ein sauberer Protokollfehler.

Prüfen Sie die Routing-Entscheidung für Verkehr, der aus dem zweiten Eintrag stammt. Die Antwort sollte die Schnittstelle verlassen, auf der die Anfrage ankam, oder zumindest eine Adresse tragen, die die Gegenseite als zu diesem Pfad gehörig akzeptiert. Auf Policy-Routing-Plattformen bedeutet das eine Regel, die an der eingehenden Schnittstelle oder der übersetzten Quelle hängt, plus eine Übersetzungsanweisung, die an jede Außenschnittstelle gebunden ist. Zeichnen Sie gleichzeitig auf beiden Schnittstellen auf, während der Client sich verbindet; ein SYN, das auf ISP B ankommt, mit dem SYN-ACK, das auf ISP A hinausgeht, klärt die Frage in einem Durchlauf.

Geben Sie dem Client einen Weg, von Eintrag zwei zu erfahren

Failover ist eine Entscheidung auf Client-Seite, und jede Client-Familie lernt Alternativen anders kennen. Auf einer ASA wird die Backup-Server-Liste über die webvpn-Attribute der Gruppenrichtlinie ausgeliefert, während andere Clients eine Liste im Profil oder ein manuelles zweites Profil erwarten, das der Nutzer auswählt. Ciscos Leitfaden zur Verbindungsrichtlinie beschreibt sowohl client-konfigurierte als auch gateway-bereitgestellte Backup-Informationen, und diese protokollspezifischen Details sollten nicht auf jeden Client oder Tunnelmodus verallgemeinert werden. Bestätigen Sie, welchen Mechanismus der eingesetzte Client implementiert, bevor Sie den zweiten Eintrag um den falschen herum bauen.

Welcher Mechanismus auch immer: Der Client muss den alternativen Namen auflösen können, bevor er den primären Pfad verliert. Diese Abhängigkeit wird übersehen: Wird der Backup-Name von einem Resolver beantwortet, der nur über den gerade ausgefallenen Tunnel erreichbar ist, kann das Fallback gar nicht starten. Veröffentlichen Sie den zweiten Namen in einem Resolver, der lokal oder über das Internet antwortet. Erwarten Sie nach dem Wechsel eine neue Authentifizierung und eine neue Anwendungssitzung, denn Client-Failover ist kein zustandsbehaftetes Failover, und langlebige Sitzungen überleben es nicht.

Eine Adresse bei zwei Anbietern ist ein anderes Produkt

Eine einzige öffentliche Adresse über beide Leitungen erreichbar zu halten ist ein Routing-Dienst, kein Häkchen im VPN. Er braucht Adressraum, den beide Anbieter zu tragen bereit sind, angekündigt so, dass ihre Netze ihn akzeptieren, und genau das leistet Multihoming mit anbieterunabhängigem Raum und BGP. Die Adresse von ISP A der Schnittstelle von ISP B zuzuweisen, führt nicht dorthin; das Paket kommt in einem Netz an, das das Präfix nie angekündigt hat, und wird stromaufwärts verworfen.

Nichts davon brauchen Sie, um zwei Einträge zu veröffentlichen. Kann der Client zwei Namen halten und zwischen ihnen ausweichen, genügen zwei unabhängige Einträge, und Sie vermeiden eine AS-Nummer, eine Peering-Vereinbarung und ein Präfix, das überall akzeptiert werden muss. Erwägen Sie die Option mit portabler Adresse nur, wenn Sie wirklich einen stabilen Einstiegspunkt brauchen, den Clients nicht per Neukonfiguration ersetzen können, oder wenn DNS-basiertes Failover mit seiner TTL-Verzögerung zu langsam für den Ausfall ist, gegen den Sie planen.

Was als Nächstes zu prüfen ist

Arbeiten Sie sich vom fehlerhaften Eintrag nach außen vor, in dieser Reihenfolge: Antwortet die zweite Adresse von außen, präsentiert sie die Identität, die der Client erwartet, verlässt die Antwort den Weg, auf dem die Anfrage ankam, und kann der Client den Namen lernen, bevor er ihn braucht. Wo die Antwort nein lautet, reparieren Sie diese Schicht und testen erneut mit dem eingesetzten Profil statt mit einem Testhost, denn ein Handshake aus dem Labor beweist weniger als eine abgeschlossene Verbindung des echten Clients.

Führen Sie pro WAN eine kurze Aufzeichnung mit Adresse, Port, terminierender Schnittstelle, Zertifikatsnamen, Rückweg und Übersetzungsregel und prüfen Sie sie erneut, wann immer sich eine Leitung, ein NAT-Gerät oder eine Client-Version ändert. Untätige Backup-Pfade verrotten still: nichts warnt vor dem Eintrag, den niemand nutzt, bis zu dem Tag, an dem alle von ihm abhängen.