Ŝalti IP-plusendadon sur ekzistanta GCE VPN-pordego

La VM estis kreita sen IP-plusendado, ĝi jam rulas la VPN-programaron, kaj la instinkto estas rekonstrui ĝin el la ŝablono kun la flago agordita. Tiu rekonstruo estas nenecesa. Compute Engine elmontras canIpForward kiel ĝisdatigeblan econ, kaj la dokumentita ĝisdatiga vojo aplikas ĝin per refresh anstataŭ restartigo. Kion la flago fakte regas estas mallarĝa: sen ĝi la platformo forĵetas pakaĵojn, kiuj alvenas al la instanco sed ne estas adresitaj al la propra adreso de la instanco. Pordego, kiu plusendas la trafikon de aliaj maŝinoj, faras precize tion, do la flago devas esti ŝaltita. Ĉio post tio estas konfiguro de la gasto kaj enkursigado, kiujn la flago ne tuŝas.

Kion la flago permesas, kaj kion ne

Kun plusendado malŝaltita, la platformo traktas la instancon kiel finpunkton. Pakaĵoj, kies celo estas la propra adreso de la instanco, estas liverataj; pakaĵoj, kiujn la instanco devus plusendi nome de iu alia, ne.

Kun plusendado ŝaltita, la instanco povas agi kiel sekva salteto por VPC-itinero, kio estas la rolo, kiun bezonas VPN-aparato. La flago diras nenion pri fajroŝirmiloj, enkursigado de la gasto, tunela konfiguro aŭ revenaj vojoj, kaj valoro true sur difektita pordego ankoraŭ estas difektita pordego.

Legu la nunan econ

Ekzamenu la agordon antaŭ ol ŝanĝi ion, per nurlega describe kontraŭ la celata instanco, projekto kaj zono:

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

Valoro false gravas nur se ĉi tiu VM devas esti sekva salteto. Se jes, la resto de la vojo ankoraŭ devas esti kontrolata aparte, ĉar la eco estas unu linio en pli longa ĉeno.

Ĝisdatigu la ekzistantan instancon

La proceduro de Google por ĝisdatigi instancajn ecojn eksportas la nunan rimedon, modifas la econ kaj sendas la rezulton. Tio estas alia laborfluo ol la flago --can-ip-forward ĉe kreo, kaj ĝi estas tiu, kiu funkcias sur kuranta VM.

Unue eksportu la difinon al loka dosiero, kaj konservu neŝanĝitan kopion por komparo:

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

En tiu eksportita dosiero agordu la econ kaj ŝanĝu nenion alian:

canIpForward: true

Konservu la tutan rimedon, inkluzive ĝian fingrospuron. Anstataŭigi la dosieron per unulinia YAML-dokumento, aŭ kunigi nerilatajn ŝanĝojn de maŝintipo, disko aŭ interfaco en la sama sendo, estas la maniero kiel eca ŝanĝo fariĝas interrompo.

Petu la ĝisdatigan mekanismon validigi la dosieron kaj raporti, kion ĝi postulus, antaŭ ol permesi ajnan efektivan ŝanĝon:

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

Tiu validiga rulo ne ŝaltas plusendadon. Legu la respondon pri nevalidaj ecoj kaj pri la ago, kiun ĝi diras esti necesa. Por ĉi tiu izolita ŝanĝo la dokumentita ago estas REFRESH. Se la rezulto petas restartigon, la dosiero enhavas pli ol la econ, kiun vi intencis ŝanĝi, do ekzamenu ĝin anstataŭ doni la restartigon.

Apliku la reviziitan dosieron kun la refresh-limo:

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

Kontrolu, ke la operacio finiĝis, kaj rulu la komandon describe denove. Se la fingrospuro ne plu kongruas, iu alia ŝanĝis la instancon dum vi redaktis, do eksportu freŝan kopion kaj revizu la ŝanĝon denove anstataŭ trudi vian malaktualan dosieron.

La gasto ankoraŭ devas enkursigi la pakaĵon

Permeso en la nubo ne faras la aparaton enkursigilo. Konfirmu, ke VPC-itinero elektas ĉi tiun VM kiel sekvan salteton por la celprefikso, kaj ke la gasto enkursigas inter la tunelo kaj la ĝusta interfaco kun sia propra plusenda politiko ŝaltita.

La fajroŝirmila politiko devas permesi la internan fluon same kiel la eksteran aŭskultanton. Malfermi nur la VPN-porton priskribas la ĉifritan transporton kaj diras nenion pri la aplika interŝanĝo ene.

Fine, la celo bezonas revenan vojon al la klienta aro, aŭ la dezajno devas intence traduki la fontojn. Se la celo vidas tradukitan trafikon, kontrolu la tradukitan fonton; se la dezajno konservas la aron, kontrolu tiun aron en la revena itinero kaj la alirreguloj. Aldoni NAT antaŭ ol decidi, kiun dezajnon vi volas, kaŝas mankan itinieron kaj ŝanĝas la politikon, kiun la celo vidas.

Sur Linux-pordego, kernplusendado estas parto de la konfiguro de la gasto. PfSense-aparato havas sian propran ekvivalenton, kaj kopii Linux-sysctl-komandon en ĝin ne estas la responda paŝo.

Kontrolu de la kliento, kiu bezonas aliron

Testu de VPN-kliento al unu cela servo, ne de la pordego mem. Konekto komencita sur la pordego uzas alian fonton kaj neniam ekzercas la plusendajn regulojn, kiujn vi ĵus ŝaltis.

Registru la econ en kio ajn administras la aparaton. Mane korektita VM funkcias ĝis ĝia sekva anstataŭigo silente reenkondukos la originan agordon, kaj tiu fiasko aspektos kiel regreso en la VPN-programaro.

Ordo de laboro: legu la econ, eksportu kaj redaktu unu linion, validigu per NO_EFFECT, apliku per REFRESH, konfirmu ke la gasto plusendas, poste testu de kliento.