Cloud VPN GCP VM-iga: kasutage sisemist IP-d, mitte NAT IP-d

Kui kohalik võrk jõuab Cloud VPN-i kaudu VPC-sse, on Compute Engine'i teenuse sihtkoht tavaliselt VM-i sisemine aadress. Väline IPv4-aadress ei ole teine aadress, mille saaksite samasse privaatsesse marsruuti panna. Suurem osa segadusest selles valdkonnas tuleb sellest, et kolme ülesandega kolme aadressi koheldakse vahetatavatena, seega alustage sellest, et nimetage, millist konkreetne pakett kasutab.

Kolm aadressi, kolm ülesannet

Nimetage kõik kolm enne, kui hakkate ükskõik millist neist siluma, sest vastus muudab objekti, mida järgmisena uurite.

Esimene kuulub tunnelile. Teine kuulub teie marsruudi ja tulemüüri disainile. Kolmas kuulub sissetulevale internetiühendusele ja seda kaardistatakse, mitte ei lisata. Disain, mis töötab ühe jaoks, ei ütle midagi kahe teise kohta.

Miks väline aadress ei ole teine liides

Aadressimise juhend on autoriteet selle kohta, kuidas sisemine ja väline kättesaadavus Compute Engine'is erinevad. Compute Engine'i väline IPv4 on üks-ühele vastendus instantsi ainsale sisemisele NIC-ile, seega külaline ei näe kunagi teist liidest ega teist aadressi sellel NIC-il. See, mida VM seest teatab, on endiselt üks peamine sisemine aadress.

Seetõttu on privaatne klient, kes suunab liikluse tunneli kaudu aadressile 10.24.1.7, ja klient, kes sihib VM-i välist aadressi, erinevatel teedel. Avaliku aadressi jaoks tulemüürireegli avamine ei muuda midagi VPC marsruudis, mis peab tunneliliiklust kandma, ja külalise marsruudi muutmine ei nihuta platvormi vastendust. Valige aadress, mille teie marsruut nimetab, ja seejärel kontrollige ainult neid objekte, mis seda juhivad. See distsipliin eemaldab suurema osa oletustest sellest tõrkeotsingu teest.

Käige tee läbi gcloudiga

Alustage instantsist ja lugege mõlemad aadressid samast objektist, et teaksite, millest teie dokumentatsioon räägib:

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

Seejärel kinnitage marsruutimine ja luba, millest tee tegelikult sõltub:

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

Lugege tunnelil teada antud ja õpitud vahemikke, töökoormuse alamvõrgu VPC marsruuti ja tulemüürireeglit, mis lubab kohalikku allikat. Need kolm peavad kokku langema, enne kui kuulaja külalises üldse asjasse puutub.

Seejärel kontrollige külalist: kas teenus kuulab sisemisel aadressil ja kas selle tagasitee läheb uuesti läbi VPC? Ainult avaliku aadressiga seotud kuulaja ebaõnnestub selles testis isegi siis, kui iga pilvepoolne objekt on õige.

Avalik prefiks on teine küsimus

Miski ülaltoodust ei tähenda, et iga VPN-i sees kantud aadress peab olema RFC1918. Kaugvõrku võib seaduslikult nummerdada avalikust ruumist, kui platvorm toetab marsruutimist ja operaatoril on aadressi volitus. See on tavaline disainiotsus.

See ei ole sama, mis kohelda tavalist välist NAT-aadressi nii, nagu oleks see veel üks sisemine alamvõrgu aadress. Üks on prefiks, mida te marsruudite; teine on vastendus, mida platvorm rakendab sissetulevale juurdepääsule.

Välisel IPv6-l ja spetsiaalselt kavandatud aadressilahendustel on oma semantika. Kui teie plaan sõltub ühest neist, lugege selle funktsiooni platvormi dokumentatsiooni, selle asemel et üldistada IPv4 juhtumist. IPv4 vastendus on tavaline juhtum, mitte ainus, ja eranditel on igaühel oma reeglid.

Kattuvad vahemikud on teine probleem

Kattuvad privaatsed vahemikud on tõeline põhjus, miks inimesed avaliku aadressi järele haaravad, ja see on vale hoob. Sihtkoha muutmine VM-i NAT-aadressiks ei lahenda kattuvust; see muudab, mille aadressi jaoks pakett väidab end olevat, ilma et määratleks, kuidas tagasitee töötab.

Lahendage kattuvus teadlikult: nummerdage ümber, kasutage toetatud tõlkedisaini või marsruutige võrgu kaudu, kus prefiksid ei põrka. Igaüks neist on omanikuga disain. NAT-aadress ei ole disain.

Dokumenteerige kaks välja eraldi

Kirjutage tunnelipartner ja töökoormuse sihtkoht kahe eraldi runbooki väljana, kumbki koos marsruudi ja tulemüürireegliga, mis seda toetavad. Üles tõusev IPsec-tunnel ütleb ainult, et pooled on ühel meelel; see ei ütle midagi selle kohta, millisel aadressil on töökoormus kättesaadav, ega selle kohta, kas selle privaatne marsruut on täielik.

Kontrollige teisel poolel päris kliendiga: lahendage nimi, kinnitage, et see tagastab sisemise aadressi, ühenduge ja kontrollige tagasiliiklust. Compute Engine'i IP-aadresside dokumentatsioon on ülal kasutatud sisemise ja välise eristuse viide.