Cloud VPN papunta sa VM sa GCP: gamitin ang panloob na IP, hindi ang NAT IP

Kapag naabot ng isang lokal na network ang VPC sa pamamagitan ng Cloud VPN, ang destinasyon para sa serbisyo ng Compute Engine ay karaniwang panloob na address ng VM. Ang panlabas na IPv4 address ay hindi isang pangalawang address na maaari mong ipalit sa parehong pribadong ruta. Karamihan ng kalituhan sa larangang ito ay nagmumula sa pagtrato sa tatlong address na may tatlong tungkulin na parang mapagpapalit, kaya magsimula sa pagpangalan kung alin ang ginagamit ng isang partikular na packet.

Tatlong address, tatlong tungkulin

Pangalanan ang tatlo bago i-debug ang alinman sa kanila, dahil binabago ng sagot ang bagay na susuriin mo sa susunod.

Ang una ay pag-aari ng tunnel. Ang ikalawa ay pag-aari ng disenyo ng ruta at firewall. Ang ikatlo ay pag-aari ng papasok na access sa internet at ito ay naka-map, hindi nakakabit. Ang disenyong gumagana para sa isa sa kanila ay walang sinasabi tungkol sa dalawa pa.

Bakit hindi pangalawang interface ang panlabas na address

Ang gabay sa pag-address ay ang awtoridad sa kung paano naiiba ang panloob at panlabas na maabot sa Compute Engine. Ang panlabas na IPv4 ng Compute Engine ay isang isa-sa-isang mapping sa nag-iisang panloob na NIC ng instance, kaya hindi kailanman nakikita ng bisita ang pangalawang interface o pangalawang address sa NIC na iyon. Ang iniuulat ng VM mula sa loob ay isa pa ring pangunahing panloob na address.

Iyon ang dahilan kung bakit ang pribadong kliyente na nagruruta sa tunnel patungo sa 10.24.1.7 at ang kliyenteng tumututok sa panlabas na address ng VM ay nasa magkaibang landas. Ang pagbubukas ng firewall rule para sa pampublikong address ay walang binabago sa ruta ng VPC na dapat magdala ng trapiko ng tunnel, at ang pag-edit ng ruta sa bisita ay hindi gumagalaw sa mapping ng platform. Piliin ang address na pinapangalanan ng iyong ruta, pagkatapos ay suriin lamang ang mga bagay na namamahala dito. Ang disiplinang ito ay nag-aalis ng karamihan ng hula mula sa landas na ito ng pag-troubleshoot.

Lakarin ang landas gamit ang gcloud

Magsimula sa instance at basahin ang dalawang address mula sa parehong bagay, upang malaman mo kung alin ang tinutukoy ng iyong dokumentasyon:

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

Pagkatapos ay kumpirmahin ang routing at ang pahintulot na talagang nakasalalay ang landas:

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

Basahin ang inihayag at natutunang mga saklaw ng tunnel, ang ruta ng VPC para sa subnet ng workload, at ang firewall rule na pumapayag sa lokal na pinagmulan. Ang tatlong ito ay dapat magkasundo bago maging may kaugnayan ang isang tagapakinig sa bisita.

Pagkatapos ay suriin ang bisita: nakikinig ba ang serbisyo sa panloob na address, at dumadaan ba muli ang pabalik na landas nito sa VPC? Ang tagapakinig na nakakabit lamang sa pampublikong address ay mabibigo sa pagsubok na ito kahit na tama ang bawat bagay sa panig ng cloud.

Ang pampublikong prefix ay ibang tanong

Wala sa nabanggit ang nangangahulugang bawat address na dinadala sa loob ng VPN ay dapat na RFC1918. Ang malayong network ay maaaring lehitimong lagyan ng numero mula sa pampublikong espasyo, basta sinusuportahan ng platform ang routing at may awtoridad sa address ang operator. Iyon ay isang normal na pagpili sa disenyo.

Ito ay hindi kapareho ng pagtrato sa isang ordinaryong panlabas na NAT address na parang isa pang panloob na subnet address. Ang isa ay prefix na iruruta mo; ang isa ay mapping na inilalapat ng platform sa papasok na access.

Ang panlabas na IPv6 at ang mga espesyal na dinisenyong kaayusan ng address ay may sariling semantika. Kung ang iyong plano ay nakasalalay sa isa sa mga ito, basahin ang dokumentasyon ng platform para sa tampok na iyon sa halip na mag-generalisa mula sa kaso ng IPv4. Ang mapping ng IPv4 ay ang karaniwang kaso, hindi ang tanging, at ang bawat eksepsiyon ay may sariling patakaran.

Ang magkakapatong na saklaw ay ibang problema

Ang magkakapatong na pribadong saklaw ay tunay na dahilan kung bakit lumalapit ang mga tao sa pampublikong address, at maling lever iyon. Ang pagbabago ng destinasyon sa NAT address ng VM ay hindi nilulutas ang pagpatong; binabago nito kung anong address ang sinasabi ng packet, nang hindi tinutukoy kung paano gumagana ang pabalik na landas.

Lutasin ang pagpatong nang sinasadya: muling mag-numero, gumamit ng sinusuportahang disenyo ng pagsasalin, o rumesa sa isang network kung saan hindi nagbabanggaan ang mga prefix. Ang bawat isa sa mga ito ay disenyong may may-ari. Ang NAT address ay hindi disenyo.

Idokumento ang dalawang field nang hiwalay

Itala ang peer ng tunnel at ang destinasyon ng workload bilang dalawang magkahiwalay na field ng runbook, bawat isa ay may ruta at firewall rule na sumusuporta dito. Ang IPsec tunnel na tumataas ay nagsasabi lamang na nagkasundo ang mga panig; wala itong sinasabi tungkol sa kung aling address maaabot ang workload, at wala rin tungkol sa kung kumpleto ang pribadong ruta nito.

I-verify gamit ang tunay na kliyente sa kabilang panig: i-resolve ang pangalan, kumpirmahin na ibinabalik nito ang panloob na address, kumonekta, at suriin ang pabalik na trapiko. Ang dokumentasyon ng IP address ng Compute Engine ang sanggunian para sa pagkakaiba ng panloob at panlabas na ginamit sa itaas.