Cloud VPN al VM en GCP: uzu la internan IP, ne la NAT-IP

Kiam surloka reto atingas VPC per Cloud VPN, la celo por servo de Compute Engine kutime estas la interna adreso de la VM. La ekstera IPv4-adreso ne estas dua adreso, kiun vi povas meti en la saman privatan itineron. Plej multo de la konfuzo ĉi tie venas de tio, ke tri adresoj kun tri taskoj estas traktataj kiel interŝanĝeblaj, do komencu nomante, kiun uzas donita pako.

Tri adresoj, tri taskoj

Nomu ĉiujn tri antaŭ ol sencimigi iun ajn el ili, ĉar la respondo ŝanĝas la objekton, kiun vi inspektos poste.

La unua apartenas al la tunelo. La dua apartenas al via itinera kaj fajroŝirma dezajno. La tria apartenas al envenanta interreta aliro kaj estas mapata, ne alkroĉata. Dezajno, kiu funkcias por unu el ili, diras nenion pri la aliaj du.

Kial la ekstera adreso ne estas dua interfaco

La adresada gvidilo estas la aŭtoritato pri tio, kiel internaj kaj eksteraj atingebloj malsamas en Compute Engine. Ekstera IPv4 de Compute Engine estas unu-al-unu mapado sur la sola interna NIC de la instanco, do la gasto neniam vidas duan interfacon nek duan adreson sur tiu NIC. Tio, kion la VM raportas interne, restas unu ĉefa interna adreso.

Tial privata kliento, kiu enkursigas tra la tunelo al 10.24.1.7, kaj kliento celanta la eksteran adreson de la VM estas sur malsamaj vojoj. Malfermi fajroŝirman regulon por la publika adreso ŝanĝas nenion en la VPC-itinero, kiu devas porti la tunelan trafikon, kaj redakti gastan itineron ne movas la mapadon de la platformo. Elektu la adreson, kiun via itinero nomas, kaj poste kontrolu nur la objektojn, kiuj regas ĝin. Tiu disciplino forigas plej multon de la divenado el ĉi tiu problemserĉa vojo.

Iru la vojon per gcloud

Komencu ĉe la instanco kaj legu ambaŭ adresojn el la sama objekto, por ke vi sciu, pri kiu parolas via dokumentaro:

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

Poste konfirmu la enkursigon kaj la permeson, de kiuj la vojo efektive dependas:

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

Legu la anoncitajn kaj lernitajn gamojn de la tunelo, la VPC-itineron por la subreto de la laborŝarĝo, kaj la fajroŝirman regulon, kiu permesas la surlokan fonton. Tiuj tri devas kongrui antaŭ ol aŭskultanto sur la gasto entute gravas.

Poste kontrolu la gaston: ĉu la servo aŭskultas sur la interna adreso, kaj ĉu ĝia revena vojo iras returne tra la VPC? Aŭskultanto ligita nur al publika adreso malsukcesos ĉi tiun teston eĉ kiam ĉiu objekto sur la nuba flanko estas ĝusta.

Publika prefikso estas alia demando

Nenio el la supraj aferoj signifas, ke ĉiu adreso portata ene de VPN devas esti RFC1918. Malproksima reto povas laŭleĝe esti numerita el publika spaco, kondiĉe ke la platformo subtenas la enkursigon kaj la operatoro posedas la adresan aŭtoritaton. Tio estas normala dezajna elekto.

Tio ne samas al trakti ordinaran eksteran NAT-adreson kvazaŭ ĝi estus alia interna subreta adreso. Unu estas prefikso, kiun vi enkursigas; la alia estas mapado, kiun la platformo aplikas al envenanta aliro.

Ekstera IPv6 kaj speciale dizajnitaj adresaj aranĝoj havas proprajn semantikojn. Se via plano dependas de unu el ili, legu la platforman dokumentaron por tiu funkcio anstataŭ ĝeneraligi el la IPv4-kazo. La IPv4-mapado estas la ordinara kazo, ne la sola, kaj la esceptoj havas ĉiu siajn proprajn regulojn.

Interkovrantaj gamoj estas alia problemo

Interkovrantaj privataj gamoj estas reala kialo, kial homoj ekprenas la publikan adreson, kaj ĝi estas la malĝusta levilo. Ŝanĝi la celon al la NAT-adreso de la VM ne solvas la interkovron; ĝi ŝanĝas, por kiu adreso la pako asertas esti, sen difini kiel funkcias la revena vojo.

Solvu la interkovron intence: renumeru, uzu subtenatan tradukan dezajnon, aŭ enkursigu tra reto, kie la prefiksoj ne kolizias. Ĉiu el tiuj estas dezajno kun posedanto. La NAT-adreso ne estas dezajno.

Dokumentu la du kampojn aparte

Registru la tunelan kunulon kaj la celon de la laborŝarĝo kiel du apartajn runbook-kampojn, ĉiu kun la itinero kaj fajroŝirma regulo, kiuj subtenas ĝin. IPsec-tunelo, kiu supreniĝas, nur diras al vi, ke la flankoj konsentas; ĝi diras nenion pri tio, sur kiu adreso la laborŝarĝo atingeblas, nek pri tio, ĉu ĝia privata itinero estas kompleta.

Kontrolu per reala kliento sur la alia flanko: solvu la nomon, konfirmu, ke ĝi redonas la internan adreson, konektiĝu kaj kontrolu la revenan trafikon. La dokumentaro pri IP-adresoj de Compute Engine estas la referenco por la distingo inter interna kaj ekstera uzita supre.