Cloud VPN către o VM din GCP: folosiți IP-ul intern, nu IP-ul NAT

Când o rețea locală ajunge la un VPC prin Cloud VPN, destinația pentru un serviciu Compute Engine este de obicei adresa internă a VM-ului. Adresa IPv4 externă nu este o a doua adresă pe care să o puteți pune în aceeași rută privată. Cea mai mare parte a confuziei din acest domeniu vine din tratarea a trei adrese cu trei sarcini ca fiind interschimbabile, așa că începeți prin a numi pe care o folosește un anumit pachet.

Trei adrese, trei sarcini

Numiți toate trei înainte de a depana vreuna dintre ele, pentru că răspunsul schimbă obiectul pe care îl inspectați în continuare.

Prima aparține tunelului. A doua aparține proiectului rutei și al paravanului. A treia aparține accesului de intrare din internet și este mapată, nu atașată. Un proiect care funcționează pentru una dintre ele nu spune nimic despre celelalte două.

De ce adresa externă nu este o a doua interfață

Ghidul de adresare este autoritatea pentru modul în care accesibilitatea internă și cea externă diferă în Compute Engine. O adresă IPv4 externă în Compute Engine este o mapare unu-la-unu pe singura placă de rețea internă a instanței, așa că invitatul nu vede niciodată o a doua interfață sau o a doua adresă pe acea placă. Ceea ce raportează VM-ul din interior rămâne o singură adresă internă primară.

De aceea un client privat care rutează prin tunel către 10.24.1.7 și un client care țintește adresa externă a VM-ului sunt pe căi diferite. Deschiderea unei reguli de paravan pentru adresa publică nu schimbă nimic în ruta VPC care trebuie să transporte traficul tunelului, iar editarea unei rute pe invitat nu mută maparea platformei. Alegeți adresa pe care o numește ruta dumneavoastră, apoi inspectați doar obiectele care o guvernează. Această disciplină elimină cea mai mare parte a presupunerilor din această cale de depanare.

Parcurgeți calea cu gcloud

Începeți de la instanță și citiți ambele adrese din același obiect, ca să știți despre care vorbește documentația dumneavoastră:

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

Apoi confirmați rutarea și permisiunea de care depinde de fapt calea:

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

Citiți intervalele anunțate și învățate ale tunelului, ruta VPC pentru subrețeaua sarcinii de lucru și regula de paravan care permite sursa locală. Acestea trei trebuie să fie de acord înainte ca un ascultător de pe invitat să fie relevant.

Apoi verificați invitatul: serviciul ascultă pe adresa internă și calea lui de întoarcere trece din nou prin VPC? Un ascultător legat doar de o adresă publică va eșua acest test chiar și atunci când fiecare obiect din partea cloud este corect.

Un prefix public este o altă întrebare

Nimic din cele de mai sus nu înseamnă că fiecare adresă transportată într-un VPN trebuie să fie RFC1918. O rețea îndepărtată poate fi numerotată legitim din spațiul public, cu condiția ca platforma să accepte rutarea și operatorul să dețină autoritatea asupra adresei. Este o alegere de proiect normală.

Aceasta nu este același lucru cu a trata o adresă NAT externă obișnuită ca și cum ar fi o altă adresă de subrețea internă. Una este un prefix pe care îl rutați; cealaltă este o mapare pe care platforma o aplică accesului de intrare.

IPv6 extern și aranjamentele de adrese proiectate special au propria semantică. Dacă planul dumneavoastră depinde de unul dintre ele, citiți documentația platformei pentru acea funcție în loc să generalizați din cazul IPv4. Maparea IPv4 este cazul obișnuit, nu singurul, iar excepțiile au fiecare propriile reguli.

Intervalele suprapuse sunt o altă problemă

Intervalele private suprapuse sunt un motiv real pentru care oamenii apelează la adresa publică, și este pârghia greșită. Schimbarea destinației în adresa NAT a VM-ului nu rezolvă suprapunerea; schimbă adresa pentru care pachetul afirmă că este, fără a defini cum funcționează calea de întoarcere.

Rezolvați suprapunerea în mod deliberat: renumerotați, folosiți un proiect de traducere acceptat sau rutați printr-o rețea în care prefixele nu se ciocnesc. Fiecare dintre acestea este un proiect cu un responsabil. Adresa NAT nu este un proiect.

Documentați cele două câmpuri separat

Înregistrați partenerul tunelului și destinația sarcinii de lucru ca două câmpuri separate de runbook, fiecare cu ruta și regula de paravan care îl susțin. Un tunel IPsec care urcă vă spune doar că părțile sunt de acord; nu spune nimic despre adresa la care sarcina de lucru este accesibilă, nici despre dacă ruta ei privată este completă.

Verificați cu un client real de cealaltă parte: rezolvați numele, confirmați că returnează adresa internă, conectați-vă și verificați traficul de întoarcere. documentația adreselor IP din Compute Engine este referința pentru distincția dintre intern și extern folosită mai sus.