Cloud VPN GCP:n VM:ään: käytä sisäistä IP:tä, älä NAT-IP:tä

Kun paikallinen verkko saavuttaa VPC:n Cloud VPN:n kautta, Compute Engine -palvelun kohde on yleensä VM:n sisäinen osoite. Ulkoinen IPv4-osoite ei ole toinen osoite, jonka voisit laittaa samaan yksityiseen reittiin. Suurin osa tämän alueen sekaannuksesta johtuu siitä, että kolmea osoitetta kolmella tehtävällä kohdellaan vaihdettavina, joten aloita nimeämällä, mitä tietty paketti käyttää.

Kolme osoitetta, kolme tehtävää

Nimeä kaikki kolme ennen kuin alat vianetsintään millään niistä, sillä vastaus muuttaa objektia, jota tutkit seuraavaksi.

Ensimmäinen kuuluu tunnelille. Toinen kuuluu reitti- ja palomuurisuunnitteluusi. Kolmas kuuluu saapuvalle internetyhteydelle ja se kartoitetaan, ei liitetä. Suunnittelu, joka toimii yhdelle niistä, ei kerro mitään kahdesta muusta.

Miksi ulkoinen osoite ei ole toinen verkkoliitäntä

Osoitteistusopas on auktoriteetti siitä, miten sisäinen ja ulkoinen saavutettavuus eroavat Compute Enginessä. Compute Enginen ulkoinen IPv4 on yksi-yhteen-kartoitus instanssin ainoaan sisäiseen NIC:iin, joten vieras ei koskaan näe toista liitäntää tai toista osoitetta siinä NIC:ssä. Se, mitä VM raportoi sisältä, on edelleen yksi ensisijainen sisäinen osoite.

Siksi yksityinen asiakas, joka reitittää tunnelin kautta osoitteeseen 10.24.1.7, ja asiakas, joka kohdistaa VM:n ulkoiseen osoitteeseen, ovat eri poluilla. Palomuurisäännön avaaminen julkiselle osoitteelle ei muuta mitään VPC-reitillä, jonka on kannettava tunneliliikenne, eikä vieraan reitin muokkaaminen siirrä alustan kartoitusta. Valitse osoite, jonka reittisi nimeää, ja tarkista sitten vain ne objektit, jotka sitä hallitsevat. Tämä kurinalaisuus poistaa suurimman osan arvailusta tältä vianetsintäpolulta.

Kävele polku gcloudilla

Aloita instanssista ja lue molemmat osoitteet samasta objektista, jotta tiedät, kummasta dokumentaatiosi puhuu:

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

Vahvista sitten reititys ja käyttöoikeus, joista polku todella riippuu:

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

Lue tunnelin ilmoittamat ja oppimat alueet, työkuorman aliverkon VPC-reitti ja palomuurisääntö, joka sallii paikallisen lähteen. Näiden kolmen on oltava yhtä mieltä ennen kuin vieraan kuuntelija on edes merkityksellinen.

Tarkista sitten vieras: kuunteleeko palvelu sisäisessä osoitteessa ja kulkeeko sen paluupolku takaisin VPC:n kautta? Vain julkiseen osoitteeseen sidottu kuuntelija epäonnistuu tässä testissä, vaikka jokainen pilven puolen objekti olisi oikein.

Julkinen etuliite on toinen kysymys

Mikään yllä olevasta ei tarkoita, että jokaisen VPN:n sisällä kuljetetun osoitteen on oltava RFC1918. Etäverkko voidaan laillisesti numeroida julkisesta avaruudesta, jos alusta tukee reititystä ja operaattorilla on osoitteen valtuus. Se on tavallinen suunnitteluvalinta.

Se ei ole sama kuin kohdella tavallista ulkoista NAT-osoitetta ikään kuin se olisi toinen sisäinen aliverkko-osoite. Toinen on etuliite, jonka reitität; toinen on kartoitus, jota alusta soveltaa saapuvaan käyttöön.

Ulkoisella IPv6:lla ja erityisesti suunnitelluilla osoitejärjestelyillä on oma semantiikkansa. Jos suunnitelmasi riippuu jommastakummasta, lue alustan dokumentaatio siitä ominaisuudesta sen sijaan, että yleistäisit IPv4-tapauksesta. IPv4-kartoitus on tavallinen tapaus, ei ainoa, ja poikkeuksilla on kullakin omat sääntönsä.

Päällekkäiset alueet ovat eri ongelma

Päällekkäiset yksityiset alueet ovat todellinen syy siihen, miksi ihmiset tarttuvat julkiseen osoitteeseen, ja se on väärä vipu. Kohteen vaihtaminen VM:n NAT-osoitteeseen ei ratkaise päällekkäisyyttä; se muuttaa sitä, minkä osoitteen paketti väittää olevansa, määrittelemättä miten paluupolku toimii.

Ratkaise päällekkäisyys tarkoituksella: numeroi uudelleen, käytä tuettua käännössuunnittelua tai reititä verkon kautta, jossa etuliitteet eivät törmää. Jokainen näistä on suunnittelu, jolla on omistaja. NAT-osoite ei ole suunnittelu.

Dokumentoi kaksi kenttää erikseen

Kirjaa tunnelikumppani ja työkuorman kohde kahtena erillisenä runbook-kenttänä, kumpikin sen tukevan reitin ja palomuurisäännön kanssa. Nouseva IPsec-tunnel kertoo vain, että osapuolet ovat samaa mieltä; se ei kerro, missä osoitteessa työkuorma on saavutettavissa, eikä sitä, onko sen yksityinen reitti täydellinen.

Vahvista todellisella asiakkaalla toisella puolella: ratkaise nimi, vahvista että se palauttaa sisäisen osoitteen, yhdistä ja tarkista paluuliikenne. Compute Enginen IP-osoitedokumentaatio on viite yllä käytetylle sisäisen ja ulkoisen erolle.