GCP Cloud VPN: Gateway, Tunnel und Firewall in der richtigen Reihenfolge prüfen

Ein Tunnel, der den Status hergestellt meldet, während jede Prüfung in ein Timeout läuft, hat meist keine VPC-Firewall-Regel. Prüfen Sie Gateway, Selektoren und Routingtyp in dieser Reihenfolge.

Ihre Konsole zeigt einen grünen Tunnel, die Monitoring-Systeme vor Ort erreichen weiterhin keine einzige Instanz, und ein Neuaufbau des Tunnels wirkt wie die naheliegende Lösung. Das ist er selten. Ein aufgebauter Tunnel beweist nur, dass zwei Gateways den IKE-Austausch abgeschlossen haben. Er sagt nichts darüber aus, ob ein Paket jemals in Ihre VPC gelangen durfte.

Vier Entscheidungen stehen zwischen diesem grünen Symbol und einer Antwort, und sie scheitern in vorhersehbarer Reihenfolge. Arbeiten Sie sie vom günstigsten Fall an ab.

Drei Objekte, und nur eines davon verschlüsselt

Ein VPN-Gateway besitzt die externe Adresse, zu der Ihr Peer verschlüsselt. In der Konsole legen Sie es nie von Hand an: Wählen oder reservieren Sie eine Adresse im Verbindungsformular, und das Gateway erscheint damit. Ein HA-Gateway belegt zwei Adressen an zwei Schnittstellen, was später bei der Quotenprüfung zählt.

Ein Tunnel ist die Paarung zwischen diesem Gateway und dem Peer. Er trägt das gemeinsame Geheimnis und die Traffic-Selektoren, deren Schutz er verspricht. In diesen Selektoren beginnen die meisten stillen Fehlschläge. Ein Tunnel, dessen lokaler Selektor 10.0.0.0/24 abdeckt, liefert kein 10.0.1.0/24, so gesund der Status auch aussieht.

Die Gegenseite führt ihre eigene Liste, meist Verschlüsselungsdomäne genannt, und die abschließende Hardware vergleicht sie mit Ihrer. Keine Seite verhandelt einen Selektor, den sie nie erhalten hat.

Der Routingtyp entscheidet, was die Routentabelle erreicht

Cloud VPN bietet drei Routingformen, und sie mischen sich nicht sauber. Richtlinienbasiertes Routing behält die statischen Selektorpaare, routenbasiertes Routing erwartet, dass Sie statische Routen selbst hinzufügen, und dynamisches Routing bewirbt Präfixe über einen Cloud Router per BGP. Wählen Sie eine bewusst.

Ein dynamischer Tunnel mit handgeschriebenen statischen Routen daneben erzeugt eine Routentabelle, die sich leert, sobald die BGP-Sitzung schwankt.

Dynamisch ist die einzige Form, die geschützte Präfixe ohne Neuaufbau des Tunnels ändern lässt, und sie zieht den Cloud Router in die Menge der Objekte, die Sie prüfen müssen. Statische Selektoren bleiben praktikabel, wenn der Peer eine Hardware-Firewall ist, die kein BGP spricht. Dann brauchen beide Enden dieselben Bereiche, und der spezifischere Eintrag muss auf beiden Seiten gewinnen. Ein Paar, das um ein Subnetz auseinanderliegt, baut auf und trägt danach die Hälfte Ihres Verkehrs.

Das implizite Verweigern sitzt hinter dem Tunnel

Eingehender Verkehr wird gegen ein implizites Verweigern mit niedrigster Priorität bewertet, und diese Regel kümmert nicht, dass das Paket verschlüsselt ankam. Bis eine Firewall-Regel den Bereich vor Ort und den verwendeten Port nennt, wird das Paket entschlüsselt, geprüft und verworfen. Das VPN-Log bleibt durchweg sauber, weil der Tunnel genau das tat, was er versprach.

Lesen Sie stattdessen das Ablehnungslog der Firewall, wenn der Tunnel steht und die Prüfung ausläuft, und begrenzen Sie dann eine Regel auf den Quellbereich und die benötigten Ports:

gcloud compute firewall-rules create allow-from-dc \
  --network=vpn-vpc \
  --direction=INGRESS \
  --source-ranges=192.168.10.0/24 \
  --allow=tcp:22,tcp:5432,icmp

Eine funktionierende Richtung ist ein Firewall-Hinweis

Ausgehender Verkehr verhält sich anders, weil die implizite Erlauben-Regel Instanzen überallhin senden lässt. Ein Rechenzentrum, das eine VM nicht erreicht, sitzt oft hinter einem einwandfrei funktionierenden ausgehenden Pfad in die andere Richtung. Diese Asymmetrie trennt eine Firewall-Lücke von einem Routingfehler, denn ein Routingfehler bricht beide Richtungen zugleich. Testen Sie die Gegenrichtung, bevor Sie eine weitere Regel bearbeiten.

Auch das Anlegen von Adressen ist eine Quotenoperation. Ein Projekt nahe seinem Limit für genutzte externe Adressen weist die Verbindung mit einem Fehler ab, der wie ein Berechtigungsproblem klingt.

Selektoren, Quoten, dann die vier Prüfungen

In der Konsole erstellte Tunnel liefern manchmal einen leeren Remote-Traffic-Selektor aus gcloud compute vpn-tunnels describe, während generierte Routen den Verkehr korrekt tragen. Vergleichen Sie, was die API festhält, mit den Bereichen, die Sie tatsächlich schützen, bevor Sie den Tunnel für falsch halten. Das Anlegen über API oder SDK hält den Selektor explizit.

Quoten sind der andere leichte Fehlgriff. Beantragen Sie die Erhöhung vor dem Wartungsfenster und nicht währenddessen, und prüfen Sie die Adressanzahl im selben Projekt wie das Gateway.

Arbeiten Sie von außen nach innen: Peer-Status, beide Selektorlisten, eine Route je Seite, eine Eingangsregel für Quellbereich und Port, dann ein Paketmitschnitt. Schreiben Sie die Gateway-Adresse, beide Selektorlisten und den Routingtyp ins Change-Ticket, solange der Tunnel neu ist, denn der nächste Ingenieur, der ein Subnetz hinzufügt, braucht alle drei.

Ähnliche Artikel