Cloud VPN egy GCP-s VM-hez: a belső IP-t használja, ne a NAT IP-t

Amikor egy helyszíni hálózat Cloud VPN-en keresztül eléri a VPC-t, a Compute Engine-szolgáltatás célja általában a VM belső címe. A külső IPv4-cím nem egy második cím, amelyet ugyanabba a privát útvonalba be lehetne tenni. A legtöbb zavar ezen a területen abból ered, hogy három címet három feladattal felcserélhetőnek tekintenek, ezért kezdje azzal, hogy megnevezi, melyiket használja egy adott csomag.

Három cím, három feladat

Nevezze meg mindhármat, mielőtt bármelyiket is hibakeresné, mert a válasz megváltoztatja a következőként vizsgálandó objektumot.

Az első az alagúthoz tartozik. A második az útvonal- és tűzfaltervhez. A harmadik a bejövő internetes hozzáféréshez tartozik, és leképeződik, nem csatolódik. Egy olyan terv, amely az egyikhez működik, semmit sem mond a másik kettőről.

Miért nem második interfész a külső cím

A címzési útmutató a mérvadó abban, hogyan különbözik a belső és a külső elérhetőség a Compute Engine-en. A Compute Engine külső IPv4-címe egy-az-egyhez leképezés a példány egyetlen belső hálókártyájára, így a vendég soha nem lát második interfészt vagy második címet azon a hálókártyán. Amit a VM belülről jelent, az továbbra is egyetlen elsődleges belső cím.

Ezért van az, hogy egy privát kliens, amely az alagúton át a 10.24.1.7 cím felé irányít, és egy kliens, amely a VM külső címét célozza, különböző útvonalakon jár. Egy tűzfalszabály megnyitása a nyilvános címhez semmit sem változtat azon a VPC-útvonalon, amelynek az alagút forgalmát vinnie kell, és egy vendégútvonal szerkesztése nem mozdítja el a platform leképezését. Válassza azt a címet, amelyet az útvonala megnevez, majd csak azokat az objektumokat vizsgálja, amelyek irányítják. Ez a fegyelem kiveszi a találgatás nagy részét ebből a hibakeresési útvonalból.

Járja végig az útvonalat a gclouddal

Kezdje a példánynál, és olvassa ki mindkét címet ugyanabból az objektumból, hogy tudja, melyikről beszél a dokumentációja:

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

Ezután erősítse meg az útvonalvezérlést és az engedélyt, amelyektől az útvonal valóban függ:

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

Olvassa ki az alagút meghirdetett és megtanult tartományait, a munkaterhelés alhálózatának VPC-útvonalát és a helyszíni forrást engedélyező tűzfalszabályt. Ennek a háromnak meg kell egyeznie ahhoz, hogy egy vendégoldali fogadó egyáltalán releváns legyen.

Ezután ellenőrizze a vendéget: a szolgáltatás a belső címen figyel-e, és a visszaútja újra a VPC-n keresztül vezet-e? Egy csak nyilvános címhez kötött fogadó ezen a teszten elbukik akkor is, ha minden felhőoldali objektum helyes.

A nyilvános előtag más kérdés

A fentiek egyike sem jelenti, hogy minden VPN-en belül szállított címnek RFC1918-nak kell lennie. Egy távoli hálózat jogszerűen számozható nyilvános tartományból, feltéve hogy a platform támogatja az útvonalvezérlést, és az üzemeltető rendelkezik a cím feletti jogosultsággal. Ez normális tervezési döntés.

Ez nem ugyanaz, mint egy közönséges külső NAT-címet úgy kezelni, mintha az egy másik belső alhálózati cím lenne. Az egyik egy előtag, amelyet irányít; a másik egy leképezés, amelyet a platform a bejövő hozzáférésre alkalmaz.

A külső IPv6-nak és a különlegesen tervezett címelrendezéseknek saját szemantikájuk van. Ha a terve egyikükre támaszkodik, olvassa el a platform dokumentációját arról a funkcióról, ahelyett hogy az IPv4-es esetből általánosítana. Az IPv4-leképezés a szokásos eset, nem az egyetlen, és a kivételeknek megvannak a saját szabályaik.

Az átfedő tartományok más probléma

Az átfedő privát tartományok valódi okai annak, hogy az emberek a nyilvános címhez nyúlnak, és ez a rossz eszköz. A cél átállítása a VM NAT-címére nem oldja meg az átfedést; megváltoztatja, hogy a csomag melyik címre hivatkozik, anélkül hogy meghatározná, hogyan működik a visszaút.

Oldja meg az átfedést tudatosan: számozza újra, használjon támogatott fordítási tervet, vagy irányítson olyan hálózaton keresztül, ahol az előtagok nem ütköznek. Ezek mindegyike felelőssel rendelkező terv. A NAT-cím nem terv.

Dokumentálja a két mezőt külön

Rögzítse az alagútpartneret és a munkaterhelés célját két külön runbook-mezőként, mindegyiket a támogató útvonallal és tűzfalszabállyal együtt. Egy feljövő IPsec-alagút csak azt mondja meg, hogy a felek egyetértenek; semmit sem mond arról, melyik címen érhető el a munkaterhelés, és arról sem, hogy a privát útvonala teljes-e.

Ellenőrizze valódi klienssel a túloldalon: oldja fel a nevet, erősítse meg, hogy a belső címet adja vissza, csatlakozzon, és ellenőrizze a visszirányú forgalmat. A Compute Engine IP-címes dokumentációja a fent használt belső és külső megkülönböztetés hivatkozása.