Zapnutí předávání IP na existující bráně GCE VPN
canIpForward je aktualizovatelná vlastnost, ne důvod znovu vytvářet VM. Exportujte prostředek, změňte jeden řádek, ověřte a poté použijte s refresh.
VM byla vytvořena bez předávání IP, už běží VPN software a instinkt velí znovu ji postavit ze šablony s nastaveným příznakem. Taková přestavba je zbytečná. Compute Engine vystavuje canIpForward jako aktualizovatelnou vlastnost a dokumentovaná cesta aktualizace ji uplatní s refresh, nikoli s restartem. Co příznak skutečně řídí, je úzké: bez něj platforma zahazuje pakety, které dorazí do instance, ale nejsou adresované na vlastní adresu instance. Brána, která předává provoz jiných strojů, dělá právě to, takže příznak musí být zapnutý. Vše po tom je konfigurace hosta a směrování, kterých se příznak netýká.
Co příznak povoluje a co ne
Při vypnutém předávání považuje platforma instanci za koncový bod. Pakety, jejichž cílem je vlastní adresa instance, se doručí; pakety, které má instance předat dál za někoho jiného, ne.
Při zapnutém předávání může instance působit jako další skok pro trasu VPC, což je role, kterou VPN zařízení potřebuje. Příznak neříká nic o firewallech, směrování hosta, konfiguraci tunelu ani zpětných cestách a hodnota true na rozbité bráně je pořád rozbitá brána.
Přečtěte aktuální vlastnost
Prohlédněte nastavení, než cokoli změníte, pomocí describe pouze pro čtení proti zamýšlené instanci, projektu a zóně:
gcloud compute instances describe VM_NAME --project PROJECT_ID --zone ZONE --format='value(canIpForward)'
Hodnota false je důležitá jen tehdy, má-li být tato VM dalším skokem. Pokud ano, zbytek cesty je stále třeba ověřit samostatně, protože vlastnost je jeden řádek v delším řetězu.
Aktualizujte existující instanci
Postup Google pro aktualizaci vlastností instance exportuje aktuální prostředek, upraví vlastnost a odešle výsledek. To je jiný pracovní postup než příznak --can-ip-forward při vytváření a právě ten funguje na běžící VM.
Nejprve exportujte definici do místního souboru a ponechte nezměněnou kopii pro srovnání:
gcloud compute instances export VM_NAME --project PROJECT_ID --zone ZONE --destination=instance.yaml
V tomto exportovaném souboru nastavte vlastnost a nic jiného neměňte:
canIpForward: true
Zachovejte celý prostředek včetně jeho otisku. Nahrazení souboru jednorádkovým dokumentem YAML nebo sloučení nesouvisejících úprav typu stroje, disku či rozhraní do stejného odeslání je způsob, jak se změna vlastnosti stane výpadkem.
Požádejte mechanismus aktualizace, aby soubor ověřil a oznámil, co by vyžadoval, než bude povolena jakákoli skutečná změna:
gcloud compute instances update-from-file VM_NAME --project PROJECT_ID --zone ZONE --source=instance.yaml --most-disruptive-allowed-action=NO_EFFECT
Toto ověřovací spuštění předávání nezapne. Přečtěte odpověď kvůli neplatným vlastnostem a kvůli akci, která je podle ní potřeba. Pro tuto izolovanou změnu je dokumentovanou akcí REFRESH. Pokud výsledek žádá restart, soubor obsahuje víc než vlastnost, kterou jste chtěli změnit, takže ho prohlédněte, místo abyste restart povolili.
Použijte zkontrolovaný soubor s limitem refresh:
gcloud compute instances update-from-file VM_NAME --project PROJECT_ID --zone ZONE --source=instance.yaml --most-disruptive-allowed-action=REFRESH
Zkontrolujte, že operace skončila, a spusťte příkaz describe znovu. Pokud už otisk nesouhlasí, někdo jiný změnil instanci, zatímco jste editovali, takže exportujte čerstvou kopii a změnu znovu zkontrolujte, místo abyste protlačili svůj zastaralý soubor.
Host musí paket stále směrovat
Oprávnění v cloudu nedělá ze zařízení router. Potvrďte, že trasa VPC vybírá tuto VM jako další skok pro cílový prefix, a že host směruje mezi tunelem a správným rozhraním se zapnutou vlastní politikou předávání.
Politika firewallu musí povolit vnitřní tok i vnější naslouchání. Otevření jen portu VPN popisuje šifrovaný přenos a nic neříká o výměně aplikace uvnitř.
Nakonec cíl potřebuje zpětnou cestu k fondu klientů, nebo musí návrh zdroje záměrně překládat. Pokud cíl vidí přeložený provoz, zkontrolujte přeložený zdroj; pokud návrh fond zachovává, zkontrolujte tento fond ve zpětné trase a v pravidlech přístupu. Přidání NAT dřív, než rozhodnete, který návrh chcete, skrývá chybějící trasu a mění politiku, kterou cíl vidí.
Na linuxové bráně je předávání v jádru součástí konfigurace hosta. Zařízení pfSense má svůj ekvivalent a kopírování linuxového příkazu sysctl do něj není odpovídajícím krokem.
Ověřte z klienta, který potřebuje přístup
Testujte z VPN klienta na jednu cílovou službu, ne z brány samotné. Spojení zahájené na bráně používá jiný zdroj a nikdy neprocvičí pravidla předávání, která jste právě zapnuli.
Zapište vlastnost do toho, co zařízení spravuje. Ručně opravená VM funguje do dalšího nahrazení, které tiše vrátí původní nastavení, a tento výpadek bude vypadat jako regrese VPN softwaru.
Pořadí práce: přečtěte vlastnost, exportujte a upravte jeden řádek, ověřte s NO_EFFECT, použijte s REFRESH, potvrďte, že host předává, a poté testujte z klienta.