Welches Paket muss eine VPN-Richtlinie für zwei WANs treffen?

Anforderungen, das VPN über den zweiten Uplink zu leiten, beschreiben mindestens zwei verschiedene Aufgaben, und die Richtlinie, die eine davon löst, berührt die andere nicht. In der ersten Aufgabe wechselt der verschlüsselte Transport zwischen zwei Endpunkten auf eine andere WAN-Adresse. In der zweiten verlässt der entschlüsselte Anwendungsfluss eines verbundenen Benutzers das Gerät in Richtung eines anderen nächsten Hops. Beides ist legitim, beides nutzt Routing, und jedes braucht eine Übereinstimmung auf einem Paket, das an dem Punkt existiert, an dem die Entscheidung fällt. Gehen Sie die folgenden Prüfungen der Reihe nach durch, denn die erste bestimmt, welches Paket spätere Regeln benennen müssen.

Benennen Sie die beiden Gespräche

Stellen Sie sich einen entfernten Mitarbeiter vor, der an einem Büro-Gateway hängt und HTTPS zu einem internen Anwendungsserver öffnet. Auf der Leitung liegen zwei unabhängige Gespräche, und sie haben an jedem Ende unterschiedliche Adressen. Das äußere Gespräch läuft zwischen den beiden VPN-Endpunkten: Gateway-Adresse zu Peer-Adresse, in welchem Protokoll und Port die Bereitstellung es auch ausgehandelt hat. Das innere Gespräch läuft von der dem Client zugewiesenen Adresse zur Adresse des Anwendungsservers auf Port 443.

Der Zielport der Anwendung ist nicht der Transportport des VPN, und noch so viel Richtlinie auf TCP 443 bewegt den Tunnel nicht. Ebenso sagt eine Regel, die die Transportadresse des Peers umleitet, nichts darüber aus, wohin die HTTP-Anfrage dieses Benutzers nach der Entschlüsselung geht. Schreiben Sie beide Gespräche mit ihren echten Adressen auf, bevor Sie eine Regel anfassen, denn der meiste Wirrwarr in diesem Bereich entsteht daraus, dass man das eine benennt und das andere konfiguriert.

Finden Sie heraus, wo Ihre Richtlinie das Paket tatsächlich sieht

Die Übereinstimmung muss in der Kette und im Namespace ausgewertet werden, in der das Paket noch die beschriebene Form hat. Eine am LAN-Eingang hängende Regel sieht das innere Paket unverschlüsselt, bevor es in Richtung Tunnel geroutet wird. Eine auf lokal erzeugten Verkehr angewandte Regel sieht Pakete, die das Gateway selbst erzeugt, und sie deckt nicht automatisch Verkehr ab, den das Gateway nur weiterleitet. Gekapselte Ausgabe ist wieder ein dritter Fall, der üblicherweise an der Schnittstelle behandelt wird, die den Tunnel trägt, und nicht auf der LAN-Seite.

Deshalb verhält sich dasselbe Konfigurationsschnipsel auf zwei Plattformen unterschiedlich: Die Anhängepunkte unterscheiden sich, und der Richtlinien-Hook eines Herstellers kann vor oder nach dem Verschlüsselungsschritt sitzen. Lesen Sie den Paketpfad für das konkrete Produkt, statt die Reihenfolge aus dem Diagramm eines anderen Herstellers anzunehmen.

Bestätigen Sie den ausgehandelten Transport

Bei UDP-gekapseltem IPsec legt RFC 3948 ESP in UDP und verwendet eine Markierung, die nicht ESP ist, damit IKE auf dem geteilten Port unterscheidbar bleibt. Reines ESP ist ein IP-Protokoll, kein TCP- oder UDP-Port, daher trifft eine Firewallregel, die auf eine Portnummer geschrieben ist, es überhaupt nicht. Diese Unterscheidung entscheidet, ob Ihre WAN-Richtlinie eine UDP-Regel, eine Protokollregel oder beides braucht.

Ausgehandelte Werte schlagen gemerkte. Lesen Sie die aktuellen Ports und Adressen der Assoziation vom Gerät ab, statt TCP 4500 oder einen alten Herstellerport für alle Fälle hinzuzufügen, was fremden Verkehr einfängt und das eigentliche Klassifizierungsproblem verdeckt.

Prüfen Sie den Rückweg, bevor Sie sich festlegen

Erfolg in ausgehender Richtung beweist die Hälfte eines Entwurfs. Ein Paket, das zum Pool der entfernten Clients zurückkehrt, ist unter der Adresse des Clients nicht mehr sichtbar, sobald die Kapselung sie ersetzt: Das äußere Ziel ist die Transportadresse des Peers. Wenn der zweite Uplink diesen Peer über einen anderen Anbieter erreicht, können seine Übersetzung und Filterung von der ersten abweichen, und die Assoziation muss möglicherweise neu aufgebaut statt migriert werden.

Der Zustand der Netzwerkadressübersetzung ist das übliche Opfer eines WAN-Wechsels. Notieren Sie den gewählten Uplink, die erwartete äußere Quelladresse, die verwendete Übersetzung und die Erreichbarkeit des Peers zurück dorthin, und halten Sie den Transport dann erreichbar, ohne ihn in den Tunnel zu schicken, den er trägt.

Prüfen Sie beide Schichten mit zwei Mitschnitten

Ein Mitschnitt an der WAN-Schnittstelle und einer im Tunnel klären die Frage schneller als jeder Konfigurationsvergleich. Führen Sie sie vom Gateway aus aus, während ein freigegebener Client eine einzelne Anfrage stellt, und bewahren Sie beide Dateien auf.

sudo tcpdump -ni wan1 'udp port 4500' -c 20
sudo tcpdump -ni tun0 'tcp port 443 and host 203.0.113.10' -c 20
ip route get 203.0.113.10 from 10.8.0.6

Der erste Mitschnitt sollte das äußere Gespräch zeigen, wie es die beabsichtigte Schnittstelle mit der erwarteten Quelladresse verlässt. Der zweite sollte das innere Gespräch einmal zeigen, nicht doppelt, mit der Client-Adresse als Quelle und dem Anwendungsserver als Ziel. Die Routenabfrage bestätigt, welche Tabelle der Router für dieses Quelle-Ziel-Paar verwenden würde, und dort zeigt sich ein Richtlinienfehler üblicherweise. Erscheint einer der Mitschnitte nicht, liegt der Entscheidungspunkt woanders als dort, wo die Regel angehängt wurde, und die Korrektur gehört dorthin und nicht in eine breitere Übereinstimmung.