Warum Ihre GCP-VM nicht auf den OpenVPN-IPv6-Pool antworten kann

Ihr IPv6-VPN-Client erreicht die Workload, die Workload antwortet in den Tunnel, und die Antwort kommt nie an. Der Instinkt ist, die Firewall oder den Tunnel verantwortlich zu machen, und meistens liegt keiner von beiden im Fehler. Eine Adresse, die von OpenVPN ausgegeben wird, ist ein inneres Netz, das nur im Tunnel existiert; Google Cloud weiß nichts davon, dass fd42:90::/64 hinter einer bestimmten VM liegen soll, bis Sie es mitteilen.

Zwei getrennte Systeme müssen diese Tatsache lernen, und nur eines davon ist OpenVPN. Das VPC braucht eine Route, bevor es etwas zurücksenden kann, und die VM muss das Weiterleiten des Ankommenden dürfen. Ist eine der beiden Hälften falsch, sieht das Symptom identisch aus.

Der Pool ist ein inneres Netz, kein Subnetz

OpenVPN kann IPv6-Adressen aus einem Bereich ausgeben, den Sie wählen, und dieser Bereich ist eine Fiktion, auf die sich die beiden Tunnelendpunkte einigen. Er ist kein Google-Cloud-Subnetz, er erscheint nicht in der VPC-Subnetzliste, und die Netzwerkschnittstelle der VM erhält diese Adressen nicht. Eine Workload, die einem Client antwortet, sendet daher ein Paket an eine Adresse, die das Fabric als nicht routbar betrachtet.

Halten Sie den Pool aus jedem Bereich heraus, den das VPC bereits nutzt. Halten Sie ihn auch aus den Bereichen hinter Ihren anderen Tunneln heraus. Überschneidungen machen aus einem sauberen Routingfehler einen sporadischen, der nur unter Last auftritt.

Unique-Local-Adressierung wie fd42:90::/64 ist eine vernünftige Wahl für dieses innere Netz. Das Präfix erinnert zugleich daran, dass das Design von Grund auf privat ist. Nichts an einem ULA-Pool macht ihn zu einer legitimen Quelle im öffentlichen Internet.

Geben Sie dem VPC ein Ziel und einen Next Hop

Die Antwort braucht eine VPC-Route, deren Ziel der Pool und deren Next Hop die VPN-VM ist. Die aktuelle Dokumentation zu statischen Routen behandelt IPv6-Zielbereiche und listet, welche Next-Hop-Typen zulässig sind; prüfen Sie daher die unterstützte Form für Ihre Topologie, statt ein älteres IPv4-Beispiel zu kopieren.

Eine Next-Hop-Adresse muss eine sein, die tatsächlich der Cloud-Schnittstelle der Instanz zugewiesen ist. Die innere Tunneladresse der VM ist diese Adresse nicht. Sie trotzdem zu verwenden erzeugt eine Route, die sauber installiert und nie ein Paket trifft. Lesen Sie die Schnittstellenliste, bevor Sie die Route schreiben.

Die Routenpriorität ist genauso wichtig wie der Eintrag selbst. Subnetz-Routen sind spezifischer als die benutzerdefinierten Routen, die Sie hinzufügen, daher verliert ein Pool, der aus einem bestehenden Subnetzbereich herausgeschnitten ist, gegen die Subnetz-Route, egal wie die benutzerdefinierte Route geschrieben ist. Wählen Sie einen eigenen Pool und bestätigen Sie dann, dass die Route die Instanz als Next Hop und das richtige Zielpräfix anzeigt:

gcloud compute routes create vpn6-return \
  --network=vpn-vpc \
  --destination-range=fd42:90::/64 \
  --next-hop-instance=openvpn-vm \
  --next-hop-instance-zone=europe-west1-b

Weiterleitung muss zweimal aktiviert werden

Eine Route stellt das Paket an die Instanz zu. Sie macht die Instanz nicht bereit, etwas weiterzuleiten, das nicht an sie adressiert ist, und diese Erlaubnis existiert auf zwei Ebenen.

Die Cloud-Seite braucht die aktivierte Instanz-Weiterleitung; das ist die Einstellung, die eine VM Datenverkehr für Adressen annehmen und weitergeben lässt, die ihr nicht gehören. Die Gastseite braucht ihre eigene IPv6-Weiterleitung, weil der Kernel nach dem Eintreffen des Pakets eine separate Entscheidung trifft. Beides muss an sein, bevor eine einzige Antwort den Tunnel überquert.

sysctl -w net.ipv6.conf.all.forwarding=1

Firewall-Regeln müssen dann den inneren Quellbereich in beide Richtungen zulassen. Google Cloud wertet das entkapselte Paket aus, daher verwirft eine Regel, die nur das VPC-Subnetz abdeckt, den Pool-Datenverkehr, nachdem der Tunnel bereits erfolgreich war. Fügen Sie den Pool als Quellbereich in die Ingress-Regel ein und prüfen Sie, dass keine benutzerdefinierte Egress-Richtlinie die Antwort blockiert. Die implizite Allow-Regel deckt den Standardfall ab, eine handgeschriebene Egress-Regel nicht.

Sagen Sie OpenVPN, wem was gehört

OpenVPN leitet an einen Client weiter, wenn es weiß, dass dieser Client das Ziel besitzt. Client-Adressen aus dem Pool werden von der Server-Direktive verwaltet, die den Pool definiert, aber ein Subnetz hinter einem Client ist eine andere Anordnung und braucht einen ausdrücklichen Eigentumseintrag für diesen Client.

Die beiden zu verwechseln erzeugt einen Tunnel, in dem Pings an den Server funktionieren und nichts dahinter. Entscheiden Sie, welchen Fall Sie bauen, und schreiben Sie dann den passenden Eintrag, statt eine zweite Push-Zeile hinzuzufügen und zu hoffen.

Halten Sie den Internet-Egress aus diesem Design heraus

Privater Zugang und Internetzugang sind getrennte Pläne. Ein ULA-Pool kann VPC-Workloads über den Tunnel erreichen, sobald Routing und Weiterleitung übereinstimmen, und derselbe Pool hat keinen Pfad zum öffentlichen Internet durch das VPC, weil das Cloud-Gateway eine beliebige Tunnelquelle nicht als eigene akzeptiert.

Wenn Clients auch Internet-Egress brauchen, planen Sie dafür ein unterstütztes Adressierungs- und Routing-Design, halten Sie es unabhängig vom privaten Pool und testen Sie die beiden Pfade getrennt. Ein funktionierender Pfad sagt nichts über den anderen aus, und ein Design, das beide vermischt, scheitert auf eine Weise, die wie ein defekter Tunnel aussieht.