Cloud VPN zu enger GCP-VM: benotzt d’intern IP, net d’NAT-IP

Wann en lokalen Netz iwwer Cloud VPN eng VPC erreecht, ass d’Zil fir e Compute Engine-Déngscht normalerweis déi intern Adress vun der VM. D’extern IPv4-Adress ass keng zweet Adress, déi een an déiselwecht privat Route setze kann. Dee meeschte Verwiesselung hei entsteet duerch d’Behandlung vun dräi Adressen mat dräi Aufgaben als austauschbar, also fänkt domat un ze benennen, wéi eng ee bestëmmte Pak benotzt.

Dräi Adressen, dräi Aufgaben

Benennt all dräi, ier Dir eng dovun debuggt, well d’Äntwert d’Objekt ännert, dat Dir duerno inspizéiert.

Déi éischt gehéiert zum Tunnel. Déi zweet gehéiert zu Ärem Route- a Firewall-Design. Déi drëtt gehéiert zum agehende Internetzougrëff a gëtt gemappt, net ugehaang. En Design, deen fir eng dovun funktionéiert, seet näischt iwwer déi aner zwee.

Firwat déi extern Adress keen zweeten Interface ass

Den Adresséierungsguide ass d’Autoritéit dofir, wéi sech intern an extern Erreechbarkeet op Compute Engine ënnerscheeden. Eng extern IPv4 op Compute Engine ass eng Een-zu-Een-Mapping op déi eenzeg intern NIC vun der Instanz, also gesäit de Gast ni en zweeten Interface oder eng zweet Adress op där NIC. Wat d’VM dobannen mëttelt, bleift eng primär intern Adress.

Dofir sinn e private Client, deen iwwer den Tunnel op 10.24.1.7 leet, an e Client, deen déi extern Adress vun der VM uviséiert, op verschiddene Weeër. Eng Firewallregel fir déi ëffentlech Adress opzemaachen ännert näischt un der VPC-Route, déi den Tunnelverkéier droe muss, an eng Gastroute z’änneren verréckelt d’Mapping vun der Plattform net. Wielt d’Adress, déi Är Route benennt, a kontrolléiert dann nëmmen d’Objete, déi se regéieren. Dës Disziplin hëlt de gréissten Deel vum Rotsen aus dësem Fehlersichwee.

Gitt de Wee mat gcloud

Fänkt bei der Instanz un a liest béid Adressen aus dem selwechten Objekt, sou wësst Dir, vun där Är Dokumentatioun schwätzt:

gcloud compute instances describe app-1 --zone=europe-west1-b \
  --format="value(networkInterfaces[0].networkIP,networkInterfaces[0].accessConfigs[0].natIP)"

Bestätegt duerno d’Routing an d’Berechtegung, vun deenen de Wee wierklech ofhänkt:

gcloud compute routes list --filter="destRange:10.24.1.0/24"
gcloud compute firewall-rules list --filter="sourceRanges:10.99.0.0/24"
gcloud compute vpn-tunnels describe TUNNEL_NAME --region=europe-west1

Liest déi annoncéiert an geléiert Beräicher vum Tunnel, d’VPC-Route fir de Subnet vun der Aarbechtslaascht an d’Firewallregel, déi déi lokal Quell erlaabt. Déi dräi mussen iwwereneestëmmen, ier en Nolauschterer um Gast iwwerhaapt relevant ass.

Kontrolléiert duerno de Gast: lauschtert den Déngscht op der interner Adress, a geet säi Réckwee erëm duerch d’VPC? En Nolauschterer, deen nëmmen un eng ëffentlech Adress gebonnen ass, wäert dësen Test net bestoen, och wann all Objet op der Cloud-Säit richteg ass.

En ëffentleche Prefix ass eng aner Fro

Näischt vun uewen heescht, datt all Adress, déi an engem VPN gedroe gëtt, RFC1918 muss sinn. En entfernten Netz kann rechtmäßeg aus dem ëffentleche Raum nummeréiert ginn, wann d’Plattform d’Routing ënnerstëtzt an den Bedreiwer d’Adressautoritéit huet. Dat ass eng normal Designentscheedung.

Dat ass net datselwecht wéi eng gewéinlech extern NAT-Adress ze behandelen, wéi wann se eng aner intern Subnetadress wier. Déi eng ass e Prefix, deen Dir leet; déi aner ass eng Mapping, déi d’Plattform op den agehenden Zougrëff uwent.

Extern IPv6 an eextra gestalt Adressarrangementer hunn hir eege Semantik. Wann Äre Plang vun engem dovun ofhänkt, liest d’Plattformdokumentatioun fir déi Funktioun, amplaz vum IPv4-Fall ze generaliséieren. D’IPv4-Mapping ass de gewéinleche Fall, net deen eenzegen, an d’Ausnamen hunn all hir eege Regelen.

Iwwerlappend Beräicher sinn en anert Problem

Iwwerlappend privat Beräicher sinn en echte Grond, firwat Leit no der ëffentlecher Adress gräifen, an et ass de falsche Hebel. D’Zil op d’NAT-Adress vun der VM z’änneren léist d’Iwwerlappung net; et ännert, fir wéi eng Adress de Pak sech ausgëtt, ouni ze definéieren, wéi de Réckwee funktionéiert.

Léist d’Iwwerlappung bewosst: nummeréiert nei, benotzt en ënnerstëtzten Iwwersetzungsdesign oder leet duerch en Netz, an deem d’Prefixen net kollidéieren. Jidderee vun dësen ass en Design mat engem Verantwortlechen. D’NAT-Adress ass keen Design.

Dokumentéiert déi zwee Felder getrennt

Hält den Tunnelpeer an d’Zil vun der Aarbechtslaascht als zwee getrennt Runbook-Felder fest, jiddwerengem mat der Route an der Firewallregel, déi se stäipen. En IPsec-Tunnel, deen eropkënnt, seet Iech just, datt d’Säiten sech eens sinn; hie seet näischt doriwwer, op wéi enger Adress d’Aarbechtslaascht erreechbar ass, an näischt doriwwer, ob seng privat Route komplett ass.

Verifizéiert mat engem richtege Client op der anerer Säit: léist den Numm op, bestätegt, datt en déi intern Adress zréckgëtt, verbënnt Iech a kontrolléiert de Réckverkéier. D’Compute Engine-Dokumentatioun iwwer IP-Adressen ass d’Referenz fir den Ënnerscheed tëscht intern an extern, deen uewen benotzt gëtt.