Voller Tunnel in strongSwan braucht 0.0.0.0/0 auf beiden Peers

Ein voller Tunnel braucht 0.0.0.0/0 als remote_ts des Clients und als local_ts des Gateways, dazu Weiterleitung, NAT und einen Rückweg. Prüfen Sie alle vier.

Eine strongSwan-Verbindung, die für ein einzelnes privates Subnetz funktioniert, überträgt keinen Internetverkehr, nur weil jemand eine einzelne Zeile bearbeitet hat. Ein voller Tunnel ist eine Vereinbarung zwischen zwei Peers darüber, welche Adressen die child SA schützt, und jeder Peer benennt die Gegenseite relativ zu sich selbst. Bringen Sie eine Seite richtig und die andere falsch hin, und die child SA kommt entweder nicht hoch oder schmaler als beabsichtigt. Die fünf Prüfungen unten folgen dieser Vereinbarung vom Client über den Gateway bis ins Internet.

Prüfen Sie zuerst den Selektor des Clients

Der Client beschreibt, was er auf der Gegenseite schützen will, als remote_ts, und alles, was er sendet, stammt von seiner eigenen zugewiesenen Adresse. Für Internetverkehr muss dieser Wert die Ziele abdecken, die der Benutzer tatsächlich erreicht, was praktisch den gesamten IPv4-Raum bedeutet. Ein Client, der weiterhin ein Subnetz auflistet, verlangt einen Split-Tunnel, wie auch immer das Profil in der Oberfläche heißt. Die Quellseite ist normalerweise dynamic, weil die Adresse beim Verbindungsaufbau zugewiesen wird. Eine dort eingetragene feste Quelle bricht, sobald sich der Pool ändert.

children {
    net {
        local_ts  = dynamic
        remote_ts = 0.0.0.0/0
    }
}

Das Fragment ist keine vollständige Verbindungsdatei, und dieses setzt voraus, dass Authentifizierung, Identitäten und der Pool virtueller Adressen bereits konfiguriert sind. Der Quellselektor des Clients und die vom Server zugewiesene Adresse müssen weiterhin übereinstimmen, sonst kommt die child SA mit einem Umfang hoch, den keine Seite erwartet hat. Laden Sie es mit swanctl --load-all und lesen Sie die Ausgabe, bevor Sie Erfolg annehmen. Eine Datei, die sich parsen lässt, kann trotzdem wegen eines Selektors abgelehnt werden, der sich nicht mit dem Vorschlag des Peers überschneidet.

Prüfen Sie den Selektor des Gateways auf seiner Seite

Der Gateway liest dasselbe Konzept aus der Gegenrichtung. Internetziele sind für den Gateway lokal, also ist sein local_ts der breite und remote_ts beschreibt den Client-Pool. Diese Umkehrung ist der häufigste Fehler in einer Volltunnel-Konfiguration, und sie übersteht die Prüfung, weil beide Zeilen für sich genommen plausibel aussehen.

children {
    rw {
        local_ts  = 0.0.0.0/0
        remote_ts = 10.77.0.0/24
    }
}

Das Kopieren des Client-Fragments in die Gateway-Datei erzeugt ein Selektorpaar, das nichts Nützliches beschreibt, weil beide Seiten dieselbe Rolle beanspruchen würden. Die strongSwan-Weiterleitungsanleitung dokumentiert die Paarung von Client und Gateway ausdrücklich, und es lohnt sich, sie neben der Verbindungsdatei zu lesen statt nach dem Fehlschlag. Die Gateway-Datei braucht außerdem die Pool-Definition, auf die remote_ts verweist. Ein Selektor, der einen nicht existierenden Pool nennt, lädt ohne Beschwerde und scheitert beim Verbindungsaufbau.

Das alte ipsec.conf verwendet linke und rechte Rollen mit unterschiedlichen Schlüsseln, und eine rightsubnet-Zeile ist kein direkter Ersatz für den swanctl-Wert. Halten Sie die beiden Syntaxen in getrennten Dateien, statt eine in die andere einzufügen. Sie in einem Verzeichnis zu mischen, ist der Weg, auf dem eine funktionierende Verbindung nach einem Neustart still zurückfällt.

Prüfen Sie die ausgehandelte child SA, nicht die Datei

Eine gespeicherte Konfiguration beweist Absicht und nichts weiter. Ein Peer kann das Angeforderte verengen, und eine bestehende child SA wird nicht ersetzt, nur weil sich die Datei darunter geändert hat. Bestätigen Sie, was tatsächlich installiert ist, bevor Sie etwas anderes ändern.

swanctl --list-conns
swanctl --list-sas
ip xfrm policy list

Der erste Befehl zeigt, was der Daemon geladen hat, der zweite die aufgebauten child SAs und der dritte die Richtlinien, die der Kernel anwenden wird. Wenn die Datei 0.0.0.0/0 sagt und die Auflistung ein einzelnes Subnetz zeigt, hat die Aushandlung den Umfang verengt, und ein erneutes Lesen der Datei wird das nicht erklären. Beenden Sie die child, starten Sie sie neu und vergleichen Sie alle drei Ausgaben erneut. Eine child, die mit demselben engen Umfang zurückkommt, wird von der Gegenseite verengt und nicht von der lokalen Datei, und das ist ein Gespräch mit dem anderen Administrator statt einer lokalen Änderung.

Lesen Sie beide Richtungen in der Richtlinienauflistung, denn ein Tunnel, der eine Richtung installiert und die andere nicht, ist ein Routingproblem im Konfigurationskostüm. Die Vorwärts- und Rückwärtsrichtlinien sollten dasselbe Selektorpaar spiegelbildlich nennen, und ein fehlender Spiegel ist ein Defekt im Daemon oder im Vorschlag und nicht im Selektor-Text.

Prüfen Sie Weiterleitung und Rückweg

Ein Selektor lässt Verkehr zum Gateway zu; er bringt den Gateway nicht dazu, diesen Verkehr weiterzuleiten. Weiterleitung muss aktiviert sein, die Firewall muss den Fluss erlauben, und die Antwort muss den Weg zurück zum Client-Pool finden. Das sind drei getrennte Anforderungen, und jede scheitert mit einem anderen Symptom. Eine fehlende Weiterleitungsregel verhält sich wie ein schwarzes Loch, während eine fehlende Rückroute sich wie ein Einwegtunnel verhält.

sysctl net.ipv4.ip_forward
iptables -t nat -S | grep -i masq
ip route get 1.1.1.1

Private Client-Adressen brauchen meist eine bewusste Quellübersetzung, bevor sie eine öffentliche Schnittstelle verlassen, während eine explizit geroutete Zuteilung anders behandelt werden muss. Wenn NAT im Spiel ist, behalten Sie die von der Implementierung unterstützten Ausnahmen bei, damit Verkehr, den eine Sicherheitsrichtlinie prüfen soll, nicht daran vorbei übersetzt wird. Eine breite Masquerade-Regel, die von einem anderen Gateway kopiert wurde, ändert weit mehr Flüsse als ihr Autor beabsichtigt hat. Schreiben Sie die Regel nur für den Client-Pool und hinterlassen Sie einen Kommentar, warum sie existiert.

Bestätigen Sie auf dem Client die Routen, die das Backend installiert hat, statt der Routen, die Sie angenommen haben. Ein Manager mit deaktivierter Routeninstallation braucht ein manuell gepflegtes Routing-Design, und dieses Design muss aktualisiert werden, wann immer sich der Tunnel ändert. Prüfen Sie die Routing-Tabelle nach einer erneuten Verbindung, nicht nur nach einem frischen Start.

Prüfen Sie, was der Tunnel weiterhin nicht abdeckt

Das Selektorpaar deckt IPv4 ab und sonst nichts. IPv6, DNS und jede Richtlinie auf Anwendungsebene sind getrennte Entscheidungen, die ein breiter IPv4-Selektor still ignoriert. Ein Tunnel, der jedes IPv4-Paket trägt, kann trotzdem jede Namensabfrage nach außen dringen lassen.

Benennen Sie den beabsichtigten DNS-Pfad ausdrücklich, denn ein voller Tunnel, der Namen weiterhin über den lokalen Resolver auflöst, lässt Abfragen außerhalb des Tunnels austreten und bricht private Namen. Wenn dem Client eine IPv6-Adresse zugewiesen wird, braucht diese Adressfamilie dieselbe Behandlung, sonst bevorzugt der Host einen Pfad, den der Tunnel nicht schützt. Testen Sie mit einem Namen, den nur die private Seite beantworten kann, und behandeln Sie eine öffentliche Antwort als Leck.

resolvectl query intranet.example.internal
traceroute -n 1.1.1.1

Bestätigen Sie die Kette mit diesen beiden Befehlen plus den ausgehandelten Selektoren aus der Auflistung oben. Wenn der traceroute den lokalen Router als ersten Hop zeigt, nutzt der Verkehr den Tunnel nicht, egal was die Selektoren behaupten. Internetzugang ist erst vollständig, wenn der gewählte Verkehr durch den entworfenen Gateway zugelassen, weitergeleitet und zurückgebracht wird. 0.0.0.0/0 in einem Profil zu finden ist der Anfang dieser Kette und nicht ihr Beweis.

Ähnliche Artikel