Cloud VPN į GCP VM: naudokite vidinį IP, o ne NAT IP

Kai vietinis tinklas pasiekia VPC per Cloud VPN, Compute Engine paslaugos paskirties vieta paprastai yra vidinis VM adresas. Išorinis IPv4 adresas nėra antras adresas, kurį galėtumėte įdėti į tą patį privatų maršrutą. Didžioji dalis sumaišties šioje srityje kyla dėl to, kad trys adresai su trimis užduotimis laikomi keičiamais, todėl pradėkite įvardydami, kurį naudoja konkretus paketas.

Trys adresai, trys užduotys

Įvardykite visus tris prieš derindami bet kurį iš jų, nes atsakymas pakeičia objektą, kurį tikrinsite toliau.

Pirmasis priklauso tuneliui. Antrasis priklauso jūsų maršruto ir užkardos dizainui. Trečiasis priklauso gaunamajai interneto prieigai ir yra atvaizduojamas, o ne prijungiamas. Dizainas, kuris veikia vienam iš jų, nieko nesako apie kitus du.

Kodėl išorinis adresas nėra antra sąsaja

Adresų vadovas yra autoritetas, kaip Compute Engine skiriasi vidinis ir išorinis pasiekiamumas. Compute Engine išorinis IPv4 yra vienas-su-vienu atvaizdavimas į vienintelę vidinę instancijos NIC, todėl svečias niekada nemato antros sąsajos ar antro adreso toje NIC. Tai, ką VM praneša iš vidaus, vis dar yra vienas pagrindinis vidinis adresas.

Štai kodėl privatus klientas, nukreipiantis per tunelį į 10.24.1.7, ir klientas, nukreiptas į išorinį VM adresą, yra skirtinguose keliuose. Užkardos taisyklės atidarymas viešajam adresui nieko nekeičia VPC maršrute, kuris turi nešti tunelio srautą, o svečio maršruto redagavimas nepajudina platformos atvaizdavimo. Pasirinkite adresą, kurį įvardija jūsų maršrutas, ir tada tikrinkite tik tuos objektus, kurie jį valdo. Ši disciplina pašalina didžiąją dalį spėlionių iš šio trikčių šalinimo kelio.

Pereikite kelią su gcloud

Pradėkite nuo instancijos ir perskaitykite abu adresus iš to paties objekto, kad žinotumėte, apie kurį kalba jūsų dokumentacija:

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

Tada patvirtinkite maršrutizavimą ir leidimą, nuo kurių kelias iš tikrųjų priklauso:

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

Perskaitykite tunelio skelbiamus ir išmoktus diapazonus, VPC maršrutą darbo krūvio poačiui ir užkardos taisyklę, kuri leidžia vietinį šaltinį. Šie trys turi sutapti, kol svečio klausytojas apskritai taps svarbus.

Tada patikrinkite svečią: ar paslauga klausosi vidiniame adrese, ir ar jos grįžimo kelias vėl eina per VPC? Klausytojas, susietas tik su viešu adresu, nepraeis šio testo net tada, kai kiekvienas debesų pusės objektas yra teisingas.

Viešasis prefiksas yra kitas klausimas

Niekas iš aukščiau ne reiškia, kad kiekvienas VPN viduje perduodamas adresas turi būti RFC1918. Nuotolinį tinklą galima teisėtai numeruoti iš viešos erdvės, jei platforma palaiko maršrutizavimą ir operatorius turi adreso įgaliojimus. Tai normalus dizaino pasirinkimas.

Tai nėra tas pats, kas įprastą išorinį NAT adresą traktuoti kaip dar vieną vidinį poačio adresą. Vienas yra prefiksas, kurį maršrutuojate; kitas yra atvaizdavimas, kurį platforma taiko gaunamajai prieigai.

Išorinis IPv6 ir specialiai suprojektuoti adresų išdėstymai turi savo semantiką. Jei jūsų planas priklauso nuo vieno iš jų, skaitykite tos funkcijos platformos dokumentaciją, o ne apibendrinkite iš IPv4 atvejo. IPv4 atvaizdavimas yra įprastas atvejis, bet ne vienintelis, ir kiekviena išimtis turi savo taisykles.

Persidengiantys diapazonai yra kita problema

Persidengiantys privatūs diapazonai yra tikra priežastis, kodėl žmonės griebiasi viešo adreso, ir tai yra netinkama svirtis. Paskirties vietos keitimas į VM NAT adresą neišsprendžia persidengimo; jis pakeičia, kuriam adresui paketas teigia esąs, neapibrėždamas, kaip veikia grįžimo kelias.

Išspręskite persidengimą sąmoningai: pernumeruokite, naudokite palaikomą vertimo dizainą arba maršrutizuokite per tinklą, kuriame prefiksai nesusiduria. Kiekvienas iš jų yra dizainas su savininku. NAT adresas nėra dizainas.

Dokumentuokite du laukus atskirai

Įrašykite tunelio partnerį ir darbo krūvio paskirties vietą kaip du atskirus runbook laukus, kiekvieną su jį palaikančiu maršrutu ir užkardos taisykle. Pakilęs IPsec tunelis tik pasako, kad šalys sutaria; jis nieko nesako apie tai, kuriame adrese darbo krūvis pasiekiamas, ir nieko apie tai, ar jo privatus maršrutas yra išsamus.

Patikrinkite tikru klientu kitoje pusėje: išspręskite vardą, patvirtinkite, kad jis grąžina vidinį adresą, prisijunkite ir patikrinkite grįžtamąjį srautą. Compute Engine IP adresų dokumentacija yra nuoroda į aukščiau naudojamą vidinio ir išorinio skirtumą.