Planung von privatem IKEv2-Zugang mit Dual-Stack und strongSwan

Ein Dual-Stack-Tunnel ist nicht eine Entscheidung, sondern drei, und sie lassen sich unterschiedlich beantworten. Über welche Familie der äußere Tunnel läuft, welche Familien der Client innen erhält und auf welchen Familien die geschützten Dienste tatsächlich antworten. Ein Entwurf, der sie als eine einzige Wahl behandelt, trägt entweder IPv6, das nie gebraucht wurde, oder verteilt Adressen, die nichts zurückrouten kann. Trennen Sie die drei, und der Rest der Konfiguration wird fast mechanisch.

Drei Arten von Adressen, getrennt entschieden

Die äußere Adresse ist, wie die beiden Gateways einander erreichen, und sie kann IPv4 sein, während der innere Verkehr beide Familien trägt. Die innere virtuelle Adresse ist die Identität des Clients im Tunnel, und jede Familie braucht ihren eigenen Pool. Die geschützten Präfixe sind das, was der Client erreichen darf, und sie gehören zu den Diensten und nicht zum Tunnel. Die Verwechslung des dritten mit dem zweiten verursacht die meisten Planungsfehler, weil beide wie private Bereiche aussehen.

Äußerer Transport nur über IPv4 mit innerem Dual-Stack-Verkehr ist eine normale und gut unterstützte Anordnung.

Entscheiden Sie jede ausdrücklich und schreiben Sie die Entscheidungen auf. Wenn der äußere Pfad nur IPv4 ist, sagen Sie es und hören Sie auf, sich um die Erreichbarkeit von IPv6-Endpunkten zu sorgen. Wenn eine Familie innen zugewiesen wird, aber nichts darauf antwortet, entfernen Sie sie entweder aus dem Plan oder machen Sie diese Dienste wirklich dual-stack-fähig.

Weisen Sie in jeder Familie eine virtuelle Adresse zu

In einer swanctl-Konfiguration fordert der Client virtuelle Adressen an, und ein Platzhalter in jeder Familie bittet den Responder, je eine zuzuweisen. Der Responder bezieht sie aus Pools, und Pools sind getrennte Objekte von den Netzen hinter dem Gateway. Halten Sie sie auch im Plan getrennt, denn ein Pool, der ein Dienstpräfix überlappt, erzeugt Routing, das korrekt aussieht bis zu dem Moment, in dem Verkehr an einer unbeabsichtigten Stelle landet.

Fordern Sie beide Familien an, wenn Sie beide brauchen, und eine, wenn nicht, denn eine ungenutzte Adresse ist Politikfläche ohne Nutzen. Eine konkrete Anfrage ist eine Anfrage und keine Reservierung, und der Responder kann nach seiner eigenen Politik einen anderen Wert zurückgeben. Dieses Detail zählt überall dort, wo eine Adresse fest in eine Firewall-Regel oder eine Überwachungsprüfung eingetragen ist. Verweisen Sie in der Verbindung namentlich auf Pools und halten Sie Dienstnetze aus ihnen heraus.

vips = 0.0.0.0, ::

Erzeugen Sie für den IPv6-Pool Ihr eigenes Unique-Local-Präfix, statt einen kurzen Beispielwert zu übernehmen. Das Beispiel zeigt die Form der Einstellung, keinen zu erbenden Standardwert.

Beschreiben Sie Ziele getrennt von Pools

Traffic-Selectors beschreiben, was jede Seite auszutauschen erwartet, daher sollten die lokalen Selectors des Gateways geschützte Dienstpräfixe benennen und nicht Client-Pools. Die entfernten Selectors des Clients spiegeln diese Absicht. Wenn die beiden Listen verschiedene Objekte beschreiben, kann der Tunnel hochkommen und dennoch nichts Nützliches tragen.

Dieselben Präfixe brauchen Rückrouten und erlaubte Weiterleitung innerhalb des Gateway-Netzes, für jede Familie, die Sie aktivieren.

Hier hört ein privater IPv6-Plan auf, ausreichend zu sein. Unique-Local-Adressierung erkauft private Erreichbarkeit und erzeugt keinen öffentlichen IPv6-Egress, daher wird ein Entwurf, der annimmt, die unnummerierte Familie folge einfach den IPv4-Maskierungsregeln, seine Nutzer enttäuschen. Wenn öffentlicher IPv6-Zugang Teil der Anforderung ist, braucht er einen gerouteten Plan und ein Upstream, das dem zustimmt. Andernfalls sagen Sie klar, dass die IPv6-Seite nur privat ist, was eine ehrliche Grenze und keine zu verbergende Einschränkung ist.

Machen Sie DNS und Rückwege absichtlich

Namensauflösung folgt nicht dem Transport. Ein Resolver kann A- und AAAA-Einträge über einen reinen IPv4-Tunnel zurückgeben, und der Client versucht dann eine Familie, für die Sie nie geplant haben. Entscheiden Sie, welche Dienstnamen brauchbare Dual-Stack-Antworten tragen sollen, und machen Sie beide Wege absichtlich. Ein Name, der auf eine Familie ohne funktionierenden Weg auflöst, erzeugt ein Stocken statt eines sauberen Fehlers, und Stocken sind weit schwerer zu diagnostizieren.

Dokumentieren Sie die Erreichbarkeit des äußeren Endpunkts getrennt, einschließlich ob NAT-Traversal im Spiel ist und welche Familie es nutzt.

Schreiben Sie den Plan dann in sechs Zeilen: äußerer Endpunkt, IPv4-Pool, IPv6-Pool, IPv4-Dienstpräfix, IPv6-Dienstpräfix und der Router, dem die Antworten für jedes gehören. Ein Plan dieser Form beantwortet die Fragen, die ein Betreiber tatsächlich um drei Uhr morgens stellt. Alles Kürzere lässt Dual-Stack als zweite Adresse an eine reine IPv4-Politik geschraubt, und so endet es meistens halb funktionierend.