Slå på IP-vidaresending på ein eksisterande GCE VPN-gateway

VM-en vart oppretta utan IP-vidaresending, han køyrer allereie VPN-programvara, og instinktet er å byggje han på nytt frå malen med flagget sett. Den gjenoppbygginga er unødvendig. Compute Engine eksponerer canIpForward som ein oppdaterbar eigenskap, og den dokumenterte oppdateringsvegen brukar han med ein refresh i staden for ein omstart. Det flagget faktisk styrer er smalt: utan det slepp plattforma pakkar som kjem til instansen, men som ikkje er adresserte til instansen si eiga adresse. Ein gateway som vidaresender trafikken til andre maskinar gjer nettopp det, så flagget må vere på. Alt etter det er gjestekonfigurasjon og ruting, som flagget ikkje rører.

Kva flagget tillèt, og kva det ikkje gjer

Med vidaresending deaktivert handsamar plattforma instansen som eit endepunkt. Pakkar der destinasjonen er instansen si eiga adresse, vert leverte; pakkar instansen skal senda vidare på vegner av nokon andre, vert ikkje leverte.

Med vidaresending aktivert kan instansen fungere som neste hopp for ei VPC-rute, og det er rolla ein VPN-appliance treng. Flagget seier ingenting om brannmurar, gjesteruting, tunnelkonfigurasjon eller returvegar, og ein true-verdi på ein øydelagd gateway er framleis ein øydelagd gateway.

Les den gjeldande eigenskapen

Undersøk innstillinga før du endrar noko, med ein skriveverna describe mot den tiltenkte instansen, prosjektet og sona:

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

Ein false-verdi har berre noko å seie viss denne VM-en skal vere neste hopp. Er han det, må resten av vegen framleis kontrollerast separat, fordi eigenskapen er éi linje i ei lengre kjede.

Oppdater den eksisterande instansen

Prosedyren til Google for oppdatering av instanseigenskapar eksporterer den gjeldande ressursen, endrar eigenskapen og sender inn resultatet. Det er ein annan arbeidsflyt enn flagget --can-ip-forward ved opprettinga, og det er den som fungerer på ein køyrande VM.

Eksporter definisjonen til ei lokal fil først, og ta vare på ein uendra kopi for samanlikning:

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

I den eksporterte fila set du eigenskapen og endrar ingenting anna:

canIpForward: true

Hald på heile ressursen, inkludert fingeravtrykket. Å byta ut fila med eit YAML-dokument på éi linje, eller å slå saman urelaterte endringar av maskintype, disk eller grensesnitt i same innsending, er måten ein eigenskapsendring vert eit avbrot.

Be oppdateringsmekanismen validere fila og rapportere kva han ville krevje, før noka faktisk endring vert tillaten:

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

Den valideringskøyringa aktiverer ikkje vidaresending. Les svaret for ugyldige eigenskapar og for handlinga det seier er nødvendig. For denne isolerte endringa er den dokumenterte handlinga REFRESH. Viss resultatet ber om ein omstart, inneheld fila meir enn eigenskapen du ville endre, så undersøk henne i staden for å innvilge omstarten.

Bruk den gjennomgåtte fila med refresh-grensa:

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

Kontroller at operasjonen er fullført og køyr describe-kommandoen på nytt. Viss fingeravtrykket ikkje lenger stemmer, har nokon andre endra instansen medan du redigerte, så eksporter ein fersk kopi og gå gjennom endringa igjen i staden for å tvinge gjennom den utdaterte fila di.

Gjesten må framleis rute pakken

Skyrtilgang gjer ikkje apparatet til ein ruter. Stadfest at ei VPC-rute vel denne VM-en som neste hopp for destinasjonsprefikset, og at gjesten rutar mellom tunnelen og rett grensesnitt med sin eigen vidaresendingspolitikk aktivert.

Brannmurpolitikken må tillate den indre straumen så vel som den ytre lyttaren. Å opne berre VPN-porten skildrar den krypterte transporten og seier ingenting om applikasjonsutvekslinga inni han.

Til slutt treng destinasjonen ein returveg til klientpoolen, eller så må designet omsetje kjelder med vilje. Viss destinasjonen ser omsett trafikk, kontroller den omsette kjelda; viss designet bevarer poolen, kontroller den poolen i returruta og tilgangsreglane. Å leggje til NAT før du avgjer kva design du vil ha, gøymer ei manglande rute og endrar politikken destinasjonen ser.

På ein Linux-gateway er kjernevidaresending ein del av gjestekonfigurasjonen. Ein pfSense-appliance har sin eigen ekvivalent, og å kopiere ein Linux-sysctl-kommando inn i han er ikkje det tilsvarande trinnet.

Verifiser frå klienten som treng tilgang

Test frå ein VPN-klient til éin måltjeneste, ikkje frå gatewayen sjølv. Ei tilkopling som vert starta på gatewayen, brukar ei anna kjelde og utøver aldri vidaresendingsreglane du nettopp slo på.

Registrer eigenskapen i det som styrer apparatet. Ein manuelt korrigert VM fungerer til den neste utskiftinga hans stille fører inn den opphavlege innstillinga igjen, og den feilen vil sjå ut som ein regresjon i VPN-programvara.

Arbeidsrekkjefølgje: les eigenskapen, eksporter og rediger éi linje, valider med NO_EFFECT, bruk med REFRESH, stadfest at gjesten vidaresender, og test deretter frå ein klient.