Įjungti IP persiuntimą esamame GCE VPN šliuze
canIpForward yra atnaujinama savybė, o ne priežastis perstatyti VM. Eksportuokite išteklių, pakeiskite vieną eilutę, patikrinkite ir tada pritaikykite su refresh.
VM buvo sukurta be IP persiuntimo, ji jau vykdo VPN programinę įrangą, ir instinktas sako ją perstatyti iš šablono su įjungta vėliavėle. Tas perstatymas nereikalingas. Compute Engine pateikia canIpForward kaip atnaujinamą savybę, o dokumentuotas atnaujinimo kelias ją pritaiko su refresh, o ne su perkrovimu. Tai, ką vėliavėlė iš tikrųjų kontroliuoja, yra siaura: be jos platforma numeta paketus, kurie atkeliauja į instanciją, bet nėra adresuoti į pačios instancijos adresą. Šliuzas, kuris persiunčia kitų mašinų srautą, daro būtent tai, todėl vėliavėlė turi būti įjungta. Viskas po to yra svečio konfigūracija ir maršrutizavimas, kurių vėliavėlė neliečia.
Ką vėliavėlė leidžia, o ko ne
Kai persiuntimas išjungtas, platforma instanciją traktuoja kaip galinį tašką. Paketai, kurių paskirties vieta yra pačios instancijos adresas, pristatomi; paketai, kuriuos instancija turėtų perduoti toliau kito vardu, nepristatomi.
Kai persiuntimas įjungtas, instancija gali veikti kaip kitas šuolis VPC maršrutui, ir tai yra vaidmuo, kurio reikia VPN įrenginiui. Vėliavėlė nieko nesako apie ugniasienes, svečio maršrutizavimą, tunelio konfigūraciją ar grįžimo kelius, ir true reikšmė sugedusiame šliuze vis tiek yra sugedęs šliuzas.
Perskaitykite dabartinę savybę
Patikrinkite nustatymą prieš ką nors keisdami, naudodami tik skaitymui skirtą describe numatytai instancijai, projektui ir zonai:
gcloud compute instances describe VM_NAME --project PROJECT_ID --zone ZONE --format='value(canIpForward)'
false reikšmė svarbi tik jei ši VM turėtų būti kitas šuolis. Jei taip, likusią kelio dalį vis tiek reikia tikrinti atskirai, nes savybė yra viena eilutė ilgesnėje grandinėje.
Atnaujinkite esamą instanciją
„Google“ instancijos savybių atnaujinimo procedūra eksportuoja dabartinį išteklių, pakeičia savybę ir pateikia rezultatą. Tai kitas darbo srautas nei kūrimo metu naudojama vėliavėlė --can-ip-forward, ir būtent jis veikia veikiančioje VM.
Pirmiausia eksportuokite apibrėžimą į vietinį failą ir pasilikite nepakeistą kopiją palyginimui:
gcloud compute instances export VM_NAME --project PROJECT_ID --zone ZONE --destination=instance.yaml
Tame eksportuotame faile nustatykite savybę ir nieko kito nekeiskite:
canIpForward: true
Išsaugokite visą išteklių, įskaitant jo piršto atspaudą. Failo pakeitimas vienos eilutės YAML dokumentu arba nesusijusių mašinos tipo, disko ar sąsajos pakeitimų sujungimas į tą patį pateikimą yra kelias, kuriuo savybės pakeitimas tampa sutrikimu.
Paprašykite atnaujinimo mechanizmo patikrinti failą ir pranešti, ko prireiktų, prieš leidžiant bet kokį faktinį pakeitimą:
gcloud compute instances update-from-file VM_NAME --project PROJECT_ID --zone ZONE --source=instance.yaml --most-disruptive-allowed-action=NO_EFFECT
Tas patikros paleidimas neįjungia persiuntimo. Perskaitykite atsakymą apie negaliojančias savybes ir apie veiksmą, kuris sakomas esąs būtinas. Šiam izoliuotam pakeitimui dokumentuotas veiksmas yra REFRESH. Jei rezultatas prašo perkrovimo, faile yra daugiau nei savybė, kurią norėjote pakeisti, todėl patikrinkite jį, o ne suteikite perkrovimą.
Pritaikykite peržiūrėtą failą su refresh riba:
gcloud compute instances update-from-file VM_NAME --project PROJECT_ID --zone ZONE --source=instance.yaml --most-disruptive-allowed-action=REFRESH
Patikrinkite, ar operacija baigta, ir dar kartą paleiskite describe komandą. Jei piršto atspaudas nebeatitinka, kažkas kitas pakeitė instanciją jums redaguojant, todėl eksportuokite naują kopiją ir dar kartą peržiūrėkite pakeitimą, o ne stumkite savo pasenusį failą.
Svečias vis tiek turi maršrutizuoti paketą
Debesies leidimas nepadaro įrenginio maršrutizatoriumi. Patvirtinkite, kad VPC maršrutas pasirenka šią VM kaip kitą šuolį paskirties prefiksui, ir kad svečias maršrutizuoja tarp tunelio ir tinkamos sąsajos su įjungta savo persiuntimo politika.
Ugniasienės politika turi leisti tiek vidinį srautą, tiek išorinį klausytoją. Atidaryti tik VPN prievadą apibūdina šifruotą transportą ir nieko nesako apie programos mainus jo viduje.
Galiausiai paskirties vieta turi turėti grįžimo kelią į klientų baseiną, arba dizainas turi sąmoningai versti šaltinius. Jei paskirties vieta mato verčiamą srautą, patikrinkite verstą šaltinį; jei dizainas išsaugo baseiną, patikrinkite tą baseiną grįžimo maršrute ir prieigos taisyklėse. NAT pridėjimas prieš nusprendžiant, kokio dizaino norite, paslepia trūkstamą maršrutą ir pakeičia politiką, kurią mato paskirties vieta.
Linux šliuze branduolio persiuntimas yra svečio konfigūracijos dalis. pfSense įrenginys turi savo atitikmenį, ir Linux sysctl komandos kopijavimas į jį nėra atitinkamas žingsnis.
Patikrinkite iš kliento, kuriam reikia prieigos
Testuokite iš VPN kliento į vieną tikslinę paslaugą, o ne iš paties šliuzo. Šliuze pradėtas ryšys naudoja kitą šaltinį ir niekada neįgyvendina persiuntimo taisyklių, kurias ką tik įjungėte.
Užfiksuokite savybę tame, kas valdo įrenginį. Rankiniu būdu pataisyta VM veikia tol, kol kitas pakeitimas tyliai grąžina pradinį nustatymą, ir ta klaida atrodys kaip VPN programinės įrangos regresija.
Darbo tvarka: perskaitykite savybę, eksportuokite ir redaguokite vieną eilutę, patikrinkite su NO_EFFECT, pritaikykite su REFRESH, patvirtinkite, kad svečias persiunčia, tada testuokite iš kliento.