Dual-Stack-VPN-Pools: beide Adressfamilien in strongSwan bedienen

Ein Gateway kann einem Road Warrior sowohl eine virtuelle IPv4- als auch eine IPv6-Adresse geben, während der äußere Tunnel weiterhin über IPv4 läuft. Das sind unabhängige Entscheidungen, und genau deren Behandlung als eine ist der Punkt, an dem Dual-Stack-Pläne gewöhnlich auseinanderfallen. Die inneren Familien des Clients, die geschützten Präfixe, die er erreichen darf, und der Transport, der die Kapselung trägt, sind drei getrennte Entscheidungen.

Der meiste Wirrwarr entsteht dadurch, dass das Wort Dual-Stack auf ein Design angewendet wird, das nur an einer Stelle Dual-Stack ist. Ein Dienst kann intern Dual-Stack sein, auf seiner Außenadresse Single-Stack, und trotzdem für Clients einwandfrei funktionieren. Was er nicht kann, ist zufällig funktionieren.

Zwei Familien innen, ein Pfad außen

Die äußere Verbindung ist IKE über UDP und braucht eine erreichbare Adressfamilie von dort, wo der Client sich gerade befindet. Eine innere IPv6-Adresse erfordert keinen IPv6-fähigen Provider, denn das innere Paket ist Nutzlast im äußeren. Viele funktionierende Installationen transportieren IPv6-Präfixe über einen reinen IPv4-Uplink.

Was der äußere Pfad tatsächlich einschränkt, sind Erreichbarkeit und NAT-Traversal. Wenn das Gateway nur eine IPv4-Adresse bekannt gibt, kann ein Client in einem reinen IPv6-Netz überhaupt keine Verbindung aufbauen, egal welche Pools Sie konfiguriert haben. Entscheiden Sie die äußere Familie nach Ihrer Client-Population, nicht nach dem inneren Adressplan.

Geben Sie dem Client eine Adresse in jeder Familie

Beide Familien anzufordern ist clientseitig eine einzige Zeile, vorausgesetzt, das Gateway hat etwas zu vergeben. Benannte Pools halten die Quellen von den Dienstnetzen getrennt, und genau diese Eigenschaft macht Firewall-Regeln auch sechs Monate später lesbar.

pools {
  pool4 { addrs = 10.90.0.0/24 }
  pool6 { addrs = fd42:90::/64 }
}
connections {
  private-access {
    version = 2
    pools = pool4, pool6
    local  { auth = pubkey  certs = gateway.pem  id = vpn.example.com }
    remote { auth = pubkey  cacerts = ca.pem  vips = 0.0.0.0, :: }
    children {
      private { local_ts = 10.60.0.0/16, fd42:60::/48  remote_ts = dynamic }
    }
  }
}

Der vips Wert fragt eine Adresse aus jeder Familie an, und die Pool-Liste entscheidet, woher diese Adressen kommen. Die strongSwan-Dokumentation zu virtuellen IP-Adressen deckt mehrere Anfragen und die Pool-Zuweisung ab, einschließlich des Punktes, dass ein Client, der eine bestimmte Adresse anfragt, lediglich eine Präferenz äußert, die der Responder überstimmen darf. Bauen Sie keine Zugriffsregel, die annimmt, der Client erhalte immer denselben Wert.

Erzeugen Sie Ihr eigenes eindeutiges lokales Präfix, statt das Beispiel zu kopieren. Zwei Organisationen, die beide fd42::/16 einsetzen, werden die Kollision beim ersten Zusammenschalten entdecken, und deren Diagnose ist unangenehm.

Selektoren beschreiben Ziele, nicht Quellen

Die lokalen Traffic-Selektoren der Child-SA sagen, welche geschützten Netze hinter dem Gateway liegen, und die Remote-Selektoren beschreiben, was der Client als Quelle verwenden darf. Eine virtuelle Pool-Adresse gehört auf die Quellseite dieser Policy; sie in die Zielliste zu setzen ist ein verbreitetes Missverständnis der Konfiguration.

Beide Familien brauchen Rückrouten und erlaubte Weiterleitung auf dem Gateway. Ein Präfix zu einem Selektor hinzuzufügen, ohne eine Route zurück zum Pool, erzeugt einen Tunnel, der sich aufbaut, eine Verkehrsrichtung durchlässt und die Antwort stillschweigend verwirft. Der Selektor ist Policy, nicht Routing.

Halten Sie Pools und Dienstpräfixe in getrennten Blöcken Ihres Adressplans. Wenn sie sich überschneiden, kann eine Route, die einen geschützten Host erreichen sollte, auf eine Pool-Adresse passen und im Tunnel verschwinden.

DNS und der Antwortpfad entscheiden, ob es fertig wirkt

Resolver-Antworten sind unabhängig vom Transport, mit dem der Resolver erreicht wird. Ein Name kann einen A-Record, einen AAAA-Record oder beides zurückgeben, und der Client wählt nach seinen eigenen Präferenzregeln . Wenn ein interner Dienst einen AAAA-Record veröffentlicht, aber nichts dieses Präfix routet, versuchen Clients in Dual-Stack-Netzen zuerst den IPv6-Pfad und bleiben dort sitzen, bis er scheitert. An der Tunnelkonfiguration sieht dabei nichts falsch aus.

Entscheiden Sie also pro Name, welche Familien nutzbar sein sollen, und prüfen Sie dann, ob das entsprechende Präfix im Selektor steht und eine Rückroute hat. Das ist eine Entscheidung pro Dienst. Das pauschale Veröffentlichen beider Record-Typen ist der Weg, auf dem ein funktionierender reiner IPv4-Dienst für die Hälfte seiner Nutzer in Timeouts läuft.

Prüfen Sie beide Familien, bevor Sie es für erledigt erklären

Konfiguration, die lädt, ist keine Konfiguration, die funktioniert. Lesen Sie den Zustand, den der Daemon meldet, bestätigen Sie die Pool-Zuweisungen und sehen Sie sich dann die Routen an, die der Client tatsächlich installiert hat.

swanctl --list-sas
swanctl --list-pools
ip -6 addr show scope global
ip -6 route get fd42:60::10

Die ersten beiden Befehle zeigen die aufgebauten Child-SAs und welche Pools noch Adressen frei haben, sodass ein Plan sichtbar wird, der beim ersten Client funktioniert und beim zehnten scheitert. Die letzten beiden zeigen, ob der Client eine globale IPv6-Adresse aus dem Pool erhalten hat und wohin Verkehr zu einem geschützten Präfix tatsächlich ginge. Vergleichen Sie die zugewiesene Adresse mit dem Pool, den Sie konfiguriert haben, nicht mit der Adresse, auf die Sie gehofft hatten. Wenn der Responder unter seiner Policy einen anderen Wert gewählt hat, müssen Routen und Firewall-Regeln weiterhin zu seiner Wahl passen.

Testen Sie dann einen geschützten Host pro Familie und einen Namen, der sich in beide auflöst. Ein Test mit nur einer Familie sagt Ihnen nichts über die Hälfte des Plans, die Sie nicht geübt haben, und dort liegt gewöhnlich die fehlende Route.