Aktivizo përcjelljen IP në një gateway GCE VPN ekzistues

VM u krijua pa përcjellje IP, tashmë ekzekuton softuerin VPN, dhe instinkti është ta rindërtosh nga shablloni me flamurin e aktivizuar. Ai rindërtim është i panevojshëm. Compute Engine e ekspozon canIpForward si veti të përditësueshme, dhe rruga e dokumentuar e përditësimit e zbaton me një refresh në vend të një rinisjeje. Ajo që flamuri kontrollon në të vërtetë është e ngushtë: pa të, platforma i hedh poshtë paketat që arrijnë në instancë por nuk janë adresuar drejt adresës së vetë instancës. Një gateway që përcjell trafikun e makinave të tjera bën pikërisht këtë, prandaj flamuri duhet të jetë i ndezur. Gjithçka pas kësaj është konfigurim i mysafirit dhe rrugëtim, të cilat flamuri nuk i prek.

Çfarë lejon flamuri, dhe çfarë jo

Me përcjelljen e çaktivizuar, platforma e trajton instancën si pikë fundore. Paketat destinacioni i të cilave është adresa e vetë instancës dorëzohen; paketat që instanca duhet të përcjellë tutje në emër të dikujt tjetër nuk dorëzohen.

Me përcjelljen e aktivizuar, instanca mund të veprojë si hapi tjetër për një rrugë VPC, dhe ky është roli që i duhet një pajisjeje VPN. Flamuri nuk thotë asgjë për muret e zjarrit, rrugëtimin e mysafirit, konfigurimin e tunelit ose rrugët e kthimit, dhe një vlerë true në një gateway të prishur mbetet një gateway i prishur.

Lexo vetinë aktuale

Shqyrto cilësimin përpara se të ndryshosh çdo gjë, me një describe vetëm-lexim ndaj instancës, projektit dhe zonës së synuar:

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

Një vlerë false ka rëndësi vetëm nëse ky VM duhet të jetë hapi tjetër. Nëse është, pjesa tjetër e rrugës duhet gjithsesi kontrolluar veçmas, sepse vetia është një rresht në një zinxhir më të gjatë.

Përditëso instancën ekzistuese

Procedura e Google për përditësimin e vetive të instancës eksporton burimin aktual, modifikon vetinë dhe parashtron rezultatin. Ky është një rrjedhë pune e ndryshme nga flamuri --can-ip-forward në momentin e krijimit, dhe është ai që funksionon në një VM në punë.

Së pari eksporto përkufizimin në një skedar lokal, dhe mbaj një kopje të pandryshuar për krahasim:

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

Në atë skedar të eksportuar, vendos vetinë dhe mos ndrysho asgjë tjetër:

canIpForward: true

Mbaj të gjithë burimin, përfshirë gjurmën e gishtit. Zëvendësimi i skedarit me një dokument YAML një-rresht, ose grumbullimi i ndryshimeve të palidhura të llojit të makinës, diskut ose ndërfaqes në të njëjtin parashtrim, është mënyra se si një ndryshim vetie bëhet ndërprerje.

Kërko nga mekanizmi i përditësimit të validojë skedarin dhe të raportojë çfarë do të kërkonte, përpara se të lejohet çdo ndryshim efektiv:

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

Ai ekzekutim validimi nuk aktivizon përcjelljen. Lexo përgjigjen për veti të pavlefshme dhe për veprimin që thuhet se nevojitet. Për këtë ndryshim të izoluar, veprimi i dokumentuar është REFRESH. Nëse rezultati kërkon një rinisje, skedari përmban më shumë sesa vetia që doje të ndryshoje, prandaj shqyrtoje në vend që të japësh rinisjen.

Zbato skedarin e shqyrtuar me kufirin refresh:

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

Kontrollo që operacioni përfundoi dhe ekzekuto përsëri komandën describe. Nëse gjurma e gishtit nuk përputhet më, dikush tjetër e ndryshoi instancën ndërsa po editonit, prandaj eksporto një kopje të freskët dhe rishqyrto ndryshimin, në vend që të detyrosh skedarin tënd të vjetruar.

Mysafiri duhet ende ta rrugëtojë paketën

Leja në renë nuk e bën pajisjen router. Konfirmo që një rrugë VPC e zgjedh këtë VM si hapin tjetër për prefiksin e destinacionit, dhe që mysafiri rrugëton midis tunelit dhe ndërfaqes së duhur me politikën e vet të përcjelljes të aktivizuar.

Politika e murit të zjarrit duhet të lejojë rrjedhën e brendshme si dhe dëgjuesin e jashtëm. Hapja vetëm e portës VPN përshkruan transportin e kriptuar dhe nuk thotë asgjë për shkëmbimin e aplikacionit brenda tij.

Së fundi, destinacioni ka nevojë për një rrugë kthimi drejt grupit të klientëve, ose dizajni duhet t'i përkthejë burimet me qëllim. Nëse destinacioni sheh trafik të përkthyer, kontrollo burimin e përkthyer; nëse dizajni e ruan grupin, kontrollo atë grup në rrugën e kthimit dhe në rregullat e aksesit. Shtimi i NAT përpara se të vendosësh çfarë dizajni dëshiron fsheh një rrugë që mungon dhe ndryshon politikën që sheh destinacioni.

Në një gateway Linux, përcjellja në kernel është pjesë e konfigurimit të mysafirit. Një pajisje pfSense ka ekuivalentin e vet, dhe kopjimi i një komande sysctl të Linux-it në të nuk është hapi përkatës.

Verifiko nga klienti që ka nevojë për akses

Testo nga një klient VPN drejt një shërbimi të synuar, jo nga gateway-i vetë. Një lidhje e nisur në gateway përdor një burim tjetër dhe nuk i ushtron kurrë rregullat e përcjelljes që sapo aktivizove.

Regjistro vetinë në çdo gjë që e administron pajisjen. Një VM e korrigjuar me dorë funksionon derisa zëvendësimi i saj i radhës të rikthejë në heshtje cilësimin origjinal, dhe ai dështim do të duket si një regres në softuerin VPN.

Rendi i punës: lexo vetinë, eksporto dhe redakto një rresht, valido me NO_EFFECT, zbato me REFRESH, konfirmo që mysafiri përcjell, pastaj testo nga një klient.