GCP Classic VPN in Terraform: den Tunnel routenbasiert machen

Bei Classic VPN entscheidet das Label nicht über das Verhalten. Routenbasiert heißt: lokaler Selektor 0.0.0.0/0, passende Remote-Selektoren und eine explizite Route.

Der Plan wird sauber angewendet, der Tunnel kommt hoch, und die Konsole nennt ihn richtlinienbasiert. Der Verkehr fließt trotzdem nicht, und die Suche nach einem routenbasierten Schalter in der Terraform-Ressource führt nirgendwohin, weil es dieses Feld nicht gibt. Bei Classic VPN ist routenbasiertes Verhalten kein Modus, den man auswählt. Man bekommt es, wenn der lokale Traffic-Selektor 0.0.0.0/0 ist, die Remote-Selektoren die tatsächlich gewünschten Netze auflisten und eine Route auf den Tunnel zeigt. Drei Dinge, und das Label folgt.

Der Mythos: ein Feld für den Tunnelmodus

Das Konsolen-Label spiegelt wider, was die API in den Selektoren sieht. Nichts in der Ressource sagt routenbasiert, es gibt also nichts, was man auf wahr setzen könnte.

Die Suche nach diesem Feld kostet die erste Stunde des Problems, während das Lesen der Selektorwerte die letzten fünf Minuten braucht.

Was routenbasiert hier bedeutet

Google dokumentiert routenbasierte Tunnel von Classic VPN als richtlinienbasierte Tunnel, deren lokaler Selektor 0.0.0.0/0 ist. Nur die Remote-Bereiche werden benannt, und die lokale Seite wird als beliebige Adresse behandelt. Deshalb ist die Markierung in Ihrer Konfiguration ein Wert und kein Modus. Schreiben Sie beide Selektoren explizit und lesen Sie sie in der Plan-Ausgabe:

local_traffic_selector  = ["0.0.0.0/0"]
remote_traffic_selector = ["10.20.0.0/16"]

Das Peer-Präfix in diesem Ausschnitt ist illustrativ; die Form ist das, worauf es ankommt.

Die Route ist ein separates Objekt

Ein Tunnelobjekt installiert keine Route. Pakete können zur Richtlinie des Tunnels passen und trotzdem nirgendwohin gelangen, weil die VPC-Routingtabelle den nächsten Hop bestimmt. Die Route braucht den Zielbereich, das Netz, den Tunnel als nächsten Hop und eine Priorität, die gegen alles Breitere gewinnt. Wer das vergisst, bekommt einen Tunnel, der etabliert meldet, und einen Ping, der die VPC nie verlässt.

resource "google_compute_route" "office" {
  name                = "office-via-vpn"
  dest_range          = "10.20.0.0/16"
  network             = google_compute_network.vpc.name
  next_hop_vpn_tunnel = google_compute_vpn_tunnel.to_office.id
  priority            = 1000
}

Legen Sie die Route im selben Modul wie den Tunnel an, damit die beiden im Review nicht auseinanderdriften.

Spiegeln Sie die Selektoren beim Peer

Das Remote-Gerät muss spiegelbildlich konfiguriert werden: sein lokaler Bereich ist Ihr Remote-Selektor, und sein Remote-Bereich muss die GCP-Subnetze abdecken, die Sie nutzen wollen. Verengt eine Seite, scheitert Phase 2, obwohl Phase 1 gelingt. Das ist die häufigste Form einer Konfiguration, die in der Konsole richtig aussieht und keinen Verkehr trägt.

Drucken Sie die Selektoren beider Seiten während des Änderungs-Reviews nebeneinander aus.

Teilen Sie die statische Adresse in zwei Anwendungen auf

Die reservierte Adresse und den Tunnel, der darauf verweist, in einer Anwendung anzulegen, ist eine bekannte Quelle von Nacharbeit, weil die Adresse existieren muss, bevor die Weiterleitungsregel sie nutzen kann. Wenden Sie zuerst nur die Adressressource an, ergänzen Sie dann Gateway, Weiterleitungsregeln und Tunnel und wenden Sie erneut an. Terraform liest die vorhandene Adresse beim zweiten Lauf aus dem State und verwendet sie weiter. Wer das überspringt, kann bei jeder Anwendung eine neue öffentliche Adresse bekommen, was die Peer-Konfiguration jedes Mal bricht.

Zwei Anwendungen jetzt sind billiger als eine Peer-Änderung bei jedem Release.

Prüfen Sie die Aushandlung, nicht das Label

Prüfen Sie nach dem Anwenden drei getrennte Fakten: Der Tunnel meldet etabliert, die Route existiert mit dem beabsichtigten nächsten Hop, und der Peer meldet Phase 1 und Phase 2 als aktiv.

Ein Tunnel, der steht, während Phase 2 unten ist, bedeutet, dass die beiden Seiten sich über die Selektoren uneinig sind:

  • Eine Seite listet ein Subnetz, die andere nicht.
  • Eine Seite verwendet ein Aggregat, das die andere verengt hat.
  • Die Route existiert, zeigt aber auf einen anderen Tunnel.

Classic VPN ist ein einzelner Tunnel mit niedrigerem SLA als HA VPN, und HA VPN nutzt zwei Schnittstellen, zwei Tunnel und BGP mit anderen Ressourcentypen. Ein klassisches Beispiel in eine HA-Konfiguration zu kopieren und zu erwarten, dass sich die Selektor-Felder gleich verhalten, ist ein eigener Fehler, den es zu vermeiden lohnt. Die Tunnel-Felder selbst sind dokumentiert in der Referenz zu google_compute_vpn_tunnel.

Ähnliche Artikel