Paganahin ang pagpapasa ng IP sa umiiral na GCE VPN gateway

Ang VM ay ginawa nang walang pagpapasa ng IP, tumatakbo na ang VPN software, at ang instinct ay muling itayon ito mula sa template na naka-on ang flag. Ang muling pagtatayo ay hindi kailangan. Inilalantad ng Compute Engine ang canIpForward bilang naa-update na property, at inilalapat ito ng dokumentadong update path gamit ang refresh sa halip na restart. Ang tunay na kinokontrol ng flag ay makitid: kung wala ito, itinatapon ng platform ang mga packet na dumarating sa instance pero hindi naka-address sa sariling address ng instance. Ang gateway na nagpapasa ng traffic ng ibang machine ay ganoon mismo ang ginagawa, kaya dapat bukas ang flag. Ang lahat ng kasunod ay configuration ng guest at routing, na hindi ginagalaw ng flag.

Ano ang pinapayagan ng flag, at ano ang hindi

Kapag naka-off ang pagpapasa, tinatrato ng platform ang instance bilang endpoint. Ang mga packet na ang destinasyon ay sariling address ng instance ay ipinapadala; ang mga packet na dapat ipasa ng instance para sa iba ay hindi ipinapadala.

Kapag naka-on ang pagpapasa, maaaring kumilos ang instance bilang susunod na hop para sa isang VPC route, at iyon ang papel na kailangan ng VPN appliance. Wala ring sinasabi ang flag tungkol sa firewall, routing ng guest, configuration ng tunnel o mga return path, at ang value na true sa sirang gateway ay sirang gateway pa rin.

Basahin ang kasalukuyang property

Suriin ang setting bago baguhin ang anuman, gamit ang read-only na describe laban sa nilalayong instance, project at zone:

gcloud compute instances describe VM_NAME --project PROJECT_ID --zone ZONE --format='value(canIpForward)'

Mahalaga lamang ang value na false kung ang VM na ito ay dapat maging susunod na hop. Kung gayon, kailangan pa ring suriin nang hiwalay ang natitirang bahagi ng path, dahil ang property ay isang linya sa mas mahabang chain.

I-update ang umiiral na instance

Ang prosedur ng Google sa pag-update ng mga property ng instance ay nag-e-export ng kasalukuyang resource, nagbabago ng property at nagsusumite ng resulta. Iba itong workflow kaysa sa flag na --can-ip-forward noong paggawa, at ito ang gumagana sa tumatakbong VM.

I-export muna ang depinisyon sa lokal na file, at magtago ng hindi binagong kopya para sa paghahambing:

gcloud compute instances export VM_NAME --project PROJECT_ID --zone ZONE --destination=instance.yaml

Sa na-export na file, itakda ang property at huwag baguhin ang iba pa:

canIpForward: true

Panatilihin ang buong resource, kasama ang fingerprint nito. Ang pagpapalit ng file ng isang linyang YAML document, o ang pagsasama ng walang kaugnayang pagbabago sa machine type, disk o interface sa isang submission, ang paraan para maging outage ang pagbabago ng property.

Hilingin sa update mechanism na i-validate ang file at iulat kung ano ang kakailanganin, bago payagan ang anumang epektibong pagbabago:

gcloud compute instances update-from-file VM_NAME --project PROJECT_ID --zone ZONE --source=instance.yaml --most-disruptive-allowed-action=NO_EFFECT

Hindi binubuksan ng validation run na iyon ang pagpapasa. Basahin ang tugon para sa mga invalid na property at para sa aksyong sinasabing kailangan. Para sa hiwalay na pagbabagong ito, ang dokumentadong aksyon ay REFRESH. Kung humihingi ng restart ang resulta, may laman ang file na higit pa sa property na gusto mong baguhin, kaya suriin ito sa halip na payagan ang restart.

Ilapat ang nasuring file gamit ang limitasyon ng refresh:

gcloud compute instances update-from-file VM_NAME --project PROJECT_ID --zone ZONE --source=instance.yaml --most-disruptive-allowed-action=REFRESH

Tiyakin na natapos ang operasyon at patakbuhin muli ang describe command. Kung hindi na tumutugma ang fingerprint, may ibang nagbago ng instance habang nag-edit ka, kaya mag-export ng bagong kopya at suriin muli ang pagbabago sa halip na pilitin ang luma mong file.

Kailangan pa ring i-route ng guest ang packet

Hindi ginagawang router ng cloud permission ang appliance. Kumpirmahin na pinipili ng isang VPC route ang VM na ito bilang susunod na hop para sa destination prefix, at nagra-route ang guest sa pagitan ng tunnel at tamang interface na bukas ang sarili nitong patakaran sa pagpapasa.

Dapat payagan ng firewall policy ang panloob na daloy at gayundin ang panlabas na listener. Ang pagbubukas lamang ng VPN port ay naglalarawan ng naka-encrypt na transport at walang sinasabi tungkol sa palitan ng application sa loob nito.

Sa huli, kailangan ng destinasyon ng return path patungo sa client pool, o kailangang sadyang isalin ng disenyo ang mga source. Kung nakikita ng destinasyon ang naisaling traffic, suriin ang naisaling source; kung pinapanatili ng disenyo ang pool, suriin ang pool na iyon sa return route at sa access rules. Ang pagdaragdag ng NAT bago magpasya kung aling disenyo ang gusto mo ay nagtatago ng kulang na route at nagbabago ng patakarang nakikita ng destinasyon.

Sa Linux gateway, ang pagpapasa sa kernel ay bahagi ng configuration ng guest. Ang pfSense appliance ay may sariling katumbas, at ang pagkopya ng Linux sysctl command dito ay hindi ang tugmang hakbang.

I-verify mula sa client na nangangailangan ng access

Subukan mula sa VPN client patungo sa isang target na serbisyo, hindi mula sa gateway mismo. Ang koneksyong sinimulan sa gateway ay gumagamit ng ibang source at hindi kailanman ginagamit ang mga patakaran sa pagpapasa na binuksan mo lang.

Itala ang property sa kahit anong namamahala sa appliance. Ang VM na manu-manong itinama ay gumagana hanggang sa susunod na pagpapalit nito ay tahimik na ibalik ang orihinal na setting, at ang pagkabigo na iyon ay magmumukhang regression sa VPN software.

Pagkakasunod ng trabaho: basahin ang property, i-export at i-edit ang isang linya, i-validate gamit ang NO_EFFECT, ilapat gamit ang REFRESH, kumpirmahin na nagpapasa ang guest, pagkatapos ay subukan mula sa isang client.