Aktiver IP-videresending på en eksisterende GCE VPN-gateway

VM-en ble opprettet uten IP-videresending, den kjører allerede VPN-programvaren, og instinktet er å bygge den på nytt fra malen med flagget satt. Den gjenoppbyggingen er unødvendig. Compute Engine eksponerer canIpForward som en oppdaterbar egenskap, og den dokumenterte oppdateringsveien bruker den med en refresh i stedet for en omstart. Det flagget faktisk styrer er smalt: uten det slipper plattformen pakker som ankommer instansen, men som ikke er adressert til instansens egen adresse. En gateway som videresender andre maskiners trafikk gjør nettopp det, så flagget må være på. Alt etter det er gjestekonfigurasjon og ruting, som flagget ikke berører.

Hva flagget tillater, og hva det ikke gjør

Med videresending deaktivert behandler plattformen instansen som et endepunkt. Pakker hvis destinasjon er instansens egen adresse, leveres; pakker instansen skal sende videre på vegne av noen andre, gjør det ikke.

Med videresending aktivert kan instansen fungere som neste hopp for en VPC-rute, og det er rollen en VPN-appliance trenger. Flagget sier ingenting om brannmurer, gjesteruting, tunnelkonfigurasjon eller returveier, og en true-verdi på en ødelagt gateway er fortsatt en ødelagt gateway.

Les den gjeldende egenskapen

Undersøk innstillingen før du endrer noe, med en skrivebeskyttet describe mot den tiltenkte instansen, prosjektet og sonen:

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

En false-verdi har bare betydning hvis denne VM-en skal være neste hopp. Er den det, må resten av veien fortsatt kontrolleres separat, fordi egenskapen er én linje i en lengre kjede.

Oppdater den eksisterende instansen

Googles prosedyre for oppdatering av instansegenskaper eksporterer den gjeldende ressursen, endrer egenskapen og sender inn resultatet. Det er en annen arbeidsflyt enn flagget --can-ip-forward ved opprettelsen, og det er den som fungerer på en kjørende VM.

Eksporter definisjonen til en lokal fil først, og ta vare på en uendret kopi for sammenligning:

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

I den eksporterte filen setter du egenskapen og endrer ingenting annet:

canIpForward: true

Behold hele ressursen, inkludert fingeravtrykket. Å erstatte filen med et YAML-dokument på én linje, eller å slå sammen urelaterte endringer av maskintype, disk eller grensesnitt i samme innsending, er måten en egenskapsendring blir et avbrudd.

Be oppdateringsmekanismen validere filen og rapportere hva den ville kreve, før noen faktisk endring tillates:

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

Den valideringskjøringen aktiverer ikke videresending. Les svaret for ugyldige egenskaper og for handlingen det sier er nødvendig. For denne isolerte endringen er den dokumenterte handlingen REFRESH. Hvis resultatet ber om en omstart, inneholder filen mer enn egenskapen du ville endre, så undersøk den i stedet for å innvilge omstarten.

Bruk den gjennomgåtte filen med refresh-grensen:

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 kjør describe-kommandoen på nytt. Hvis fingeravtrykket ikke lenger stemmer, har noen andre endret instansen mens du redigerte, så eksporter en fersk kopi og gjennomgå endringen igjen i stedet for å tvinge gjennom den utdaterte filen din.

Gjesten må fortsatt rute pakken

Skyrtillatelse gjør ikke apparatet til en ruter. Bekreft at en VPC-rute velger denne VM-en som neste hopp for destinasjonsprefikset, og at gjesten ruter mellom tunnelen og riktig grensesnitt med sin egen videresendingspolicy aktivert.

Brannmurpolicyen må tillate den indre strømmen så vel som den ytre lytteren. Å åpne bare VPN-porten beskriver den krypterte transporten og sier ingenting om applikasjonsutvekslingen inni den.

Til slutt trenger destinasjonen en returvei til klientpoolen, eller så må designet oversette kilder bevisst. Hvis destinasjonen ser oversatt trafikk, kontroller den oversatte kilden; hvis designet bevarer poolen, kontroller den poolen i returruten og tilgangsreglene. Å legge til NAT før du bestemmer hvilket design du vil ha, skjuler en manglende rute og endrer policyen destinasjonen ser.

På en Linux-gateway er kjernevideresending en del av gjestekonfigurasjonen. En pfSense-appliance har sin egen ekvivalent, og å kopiere en Linux-sysctl-kommando inn i den er ikke det tilsvarende trinnet.

Verifiser fra klienten som trenger tilgang

Test fra en VPN-klient til én målteneste, ikke fra gatewayen selv. En tilkobling som startes på gatewayen, bruker en annen kilde og utøver aldri videresendingsreglene du nettopp aktiverte.

Registrer egenskapen i det som styrer apparatet. En manuelt korrigert VM fungerer til dens neste utskiftning stille gjeninnfører den opprinnelige innstillingen, og den feilen vil se ut som en regresjon i VPN-programvaren.

Arbeidsrekkefølge: les egenskapen, eksporter og rediger én linje, valider med NO_EFFECT, bruk med REFRESH, bekreft at gjesten videresender, og test deretter fra en klient.