OpenVPN auf GCE: Alias-IP hinzufügen, bevor Routen gepusht werden

Eine gepushte Route macht die VM nicht zum Next Hop. Fügen Sie den Alias-IP-Bereich hinzu, gleichen Sie ihn mit dem Server-Pool ab und legen Sie die VPC-Rückroute an, bevor Sie Clients testen.

Ein Client wählt sich auf dem OpenVPN-Server auf einer Compute-Engine-VM ein, das Statusfenster meldet verbunden, und ein Ping auf einen Host im VPC geht trotzdem nirgendwohin. Der Instinkt ist, eine weitere push-Zeile hinzuzufügen, und das behebt es nie. Compute Engine entscheidet anhand der eigenen Routentabelle und der Adressen, die eine VM-Schnittstelle tatsächlich hält, wohin Pakete gehen, also ist ein Tunnel-Pool, den die VM nicht besitzt, ein Pool, an den niemand zustellt.

Folgen Sie dem scheiternden Paket statt der Konfigurationsdatei, dann erscheinen die fehlenden Teile in der richtigen Reihenfolge.

Beim sterbenden Paket anfangen

Das SYN verlässt den Client, landet im Tunnel und erreicht die VM als gekapseltes Paket für ein Ziel im VPC. OpenVPN entkapselt es und versucht, es über eth0 weiterzuleiten, wo das Fabric vor allem anderen eine Frage stellt: Besitzt diese Instanz die Zieladresse. Ein Tunnel-Pool, der aus dem Subnetz eines anderen herausgeschnitten wurde, scheitert an dieser Frage, und das Paket wird verworfen, bevor irgendeine Route oder Firewall-Regel geprüft wird.

Die Richtung vom Client zum VPC hat also zwei getrennte Anforderungen, und keine davon ist eine push-Direktive. Die VM braucht einen Alias-Bereich, der den Tunnel-Pool abdeckt, und genau das macht sie zur rechtmäßigen Inhaberin dieser Adressen. Der VPC braucht eine Route, die die VM für jedes geschützte Präfix als Next Hop benennt. Fehlt eines von beidem, stirbt das Paket an einer anderen Stelle, während der Client dieselbe Stille sieht.

Lesen Sie den Fehler in dieser Reihenfolge, weil die beiden Bedingungen von der Client-Seite identisch aussehen. Ein Tunnel, der verbunden meldet, während nichts antwortet, ist die Signatur eines Topologieproblems und nicht einer schlechten Verschlüsselung.

Besitzt die Instanz den Tunnel-Pool

Geben Sie der VM einen sekundären Bereich innerhalb ihres eigenen Subnetzes und lassen Sie OpenVPN Adressen genau aus diesem Bereich ausgeben. Bei einer Instanz, deren Primäradresse 10.156.0.10/20 ist, hält ein /28-Alias den Pool von den Adressen getrennt, die andere Instanzen bereits halten:

gcloud compute instances network-interfaces update openvpn-vm \
  --zone=europe-west1-b \
  --aliases=eth0:10.156.1.0/28

Die server-Direktive muss dann denselben Block beschreiben. Ihre erste Adresse wird zum Tunnel-Gateway, und die übrigen Adressen werden an Clients ausgegeben. Zwei Zahlen beschreiben hier einen Block, ein Netz und eine Netzmaske, und das ist die Pool-Syntax, die OpenVPN noch erwartet.

server 10.156.1.0 255.255.255.240

Bestätigen Sie, dass die Adresse wirklich auf der Schnittstelle gelandet ist und nicht nur in der OpenVPN-Konfiguration steht. Das Fabric leitet weiter, was die NIC meldet, nicht was der Daemon glaubt. Ein Befehl klärt es:

ip -4 addr show dev eth0

Eine sekundäre Adresse, die eth0 nie erreicht, oder ein Pool, der ein anderes Subnetz überlappt, zeigt sich später als zeitweiliger Paketverlust und nicht als Startfehler. Der Daemon startet, Clients verbinden sich, und nur manche Ziele verhalten sich falsch. Halten Sie den Alias-Bereich klein, damit der Pool in einer Routentabelle leicht zu erkennen ist. Schneiden Sie ihn niemals aus einem Subnetz heraus, das eine andere Instanz bereits nutzt.

Dem Rückverkehr einen Next Hop geben

Eine Antwort von einem Host im VPC ist an eine Client-Adresse im Tunnel-Pool adressiert, die zu keinem Subnetz gehört, das der VPC kennt. Ohne eine Route für diesen Pool bleibt die Antwort beim ersten Hop ohne Treffer stehen, und die Anfrage kann am entfernten Ende durchaus erfolgreich gewesen sein.

gcloud compute routes create openvpn-return \
  --network=prod-vpc \
  --destination-range=192.168.127.0/24 \
  --next-hop-instance=openvpn-vm \
  --next-hop-instance-zone=europe-west1-b \
  --priority=800

Dieselbe Route ist für jedes Präfix nötig, das hinter einem Client statt im VPC liegt. Diese Präfixe brauchen außerdem einen iroute-Eintrag in der ccd-Datei des jeweiligen Clients. Dieser Eintrag ist Buchhaltung auf der Serverseite: Er sagt dem Server, welcher Client das Präfix besitzt, und er installiert nichts auf dem Client selbst.

Behalten Sie die push-Liste für die Client-Seite des Gesprächs, denn sie fügt nur Routen auf der verbindenden Maschine hinzu. Eine push-Zeile für ein VPC-Subnetz und eine VPC-Route zurück zum Pool sind zwei Hälften desselben Pfades, und jede Hälfte allein erzeugt einen Tunnel, der Anfragen, aber keine Antworten trägt.

Firewalls, Weiterleitung und die Hops dazwischen

Die VPC-Firewall prüft das entkapselte Paket, also muss eine Ingress-Regel den Tunnel-Pool und jedes Site-Präfix zulassen, das die VM auf diesem Weg erreicht. Eine Default-Deny-Haltung scheitert hier still: Das Paket wird nach der Entkapselung verworfen, und das OpenVPN-Log zeigt eine gesunde Sitzung.

Prüfen Sie auf jedem Linux-Host, der weiterleitet statt zu terminieren, ob net.ipv4.ip_forward aktiviert ist. Auch dort gilt die Eigentumsregel: Eine Box, die für ein Subnetz weiterleitet, das sie nicht hält, verwirft das Paket genauso wie die VM. Lesen Sie den Wert, bevor Sie den Tunnel verantwortlich machen.

Wenn genau ein Präfix scheitert

Teilweises Scheitern ist der am leichtesten zu lesende Fall, weil alles andere im Pfad bereits bewiesen ist. Beginnen Sie mit der Routenliste und lesen Sie Zielbereich und Next Hop des Eintrags, der das Präfix abdecken sollte, dann lesen Sie die Instanzbeschreibung und vergleichen Sie ihren Alias-Bereich mit dem Pool, den der Server ausgibt.

gcloud compute routes list --filter=destination-range~10.164.0.0
 gcloud compute instances describe openvpn-vm --format=get(networkInterfaces[0].aliasIpRanges)

Eine fehlende Route zeigt sich als fehlender Next Hop für das Präfix, während ein fehlender Alias sich als am Interface verworfenes Paket zeigt; von der Client-Seite sehen beide gleich aus und in diesen beiden Ausgaben völlig verschieden. Sind beide vorhanden, ist der verbleibende Verdächtige der ccd-iroute für den Client, der das Präfix beansprucht.

Schreiben Sie die vier Werte neben den Tunnel: Alias-Bereich, Server-Pool, gepushte Präfixe, VPC-Routen. Ein veralteter Alias bricht jede Pool-Adresse, eine veraltete Route bricht eine Richtung, ein fehlender Push verbirgt das Präfix vor dem Client, und ein falscher iroute schickt das Präfix zum falschen Peer. Die nächste Person, die ein Subnetz hinzufügt, braucht alle vier an einer Stelle, und die Notiz ist billiger als der Abend.

Ähnliche Artikel