Aktivera IP-vidarebefordran på en befintlig GCE VPN-gateway

VM:en skapades utan IP-vidarebefordran, den kör redan VPN-programvaran, och instinkten är att bygga om den från mallen med flaggan satt. Den ombyggnaden är onödig. Compute Engine exponerar canIpForward som en uppdateringsbar egenskap, och den dokumenterade uppdateringsvägen tillämpar den med en refresh i stället för en omstart. Det flaggan faktiskt styr är smalt: utan den släpper plattformen paket som anländer till instansen men som inte är adresserade till instansens egen adress. En gateway som vidarebefordrar andra maskiners trafik gör precis det, så flaggan måste vara på. Allt därefter är gästkonfiguration och routning, som flaggan inte rör.

Vad flaggan tillåter, och vad den inte gör

Med vidarebefordran avstängd behandlar plattformen instansen som en ändpunkt. Paket vars destination är instansens egen adress levereras; paket som instansen ska skicka vidare för någon annans räkning gör det inte.

Med vidarebefordran påslagen kan instansen fungera som nästa hopp för en VPC-rutt, och det är rollen som en VPN-apparat behöver. Flaggan säger ingenting om brandväggar, gästroutning, tunnelkonfiguration eller returvägar, och ett true-värde på en trasig gateway är fortfarande en trasig gateway.

Läs den aktuella egenskapen

Granska inställningen innan du ändrar något, med en skrivskyddad describe mot den avsedda instansen, projektet och zonen:

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

Ett false-värde spelar bara roll om den här VM:en ska vara nästa hopp. Är den det måste resten av vägen ändå kontrolleras separat, eftersom egenskapen är en rad i en längre kedja.

Uppdatera den befintliga instansen

Googles procedur för uppdatering av instansegenskaper exporterar den aktuella resursen, ändrar egenskapen och skickar in resultatet. Det är ett annat arbetsflöde än flaggan --can-ip-forward vid skapandet, och det är den som fungerar på en körande VM.

Exportera först definitionen till en lokal fil, och behåll en oförändrad kopia för jämförelse:

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

I den exporterade filen anger du egenskapen och ändrar inget annat:

canIpForward: true

Behåll hela resursen, inklusive dess fingeravtryck. Att ersätta filen med ett YAML-dokument på en rad, eller att bunta ihop orelaterade ändringar av maskintyp, disk eller gränssnitt i samma inskickning, är hur en egenskapsändring blir ett avbrott.

Be uppdateringsmekanismen att validera filen och rapportera vad den skulle kräva, innan någon faktisk ändring tillåts:

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

Den valideringskörningen aktiverar inte vidarebefordran. Läs svaret om ogiltiga egenskaper och om den åtgärd som sägs behövas. För den här isolerade ändringen är den dokumenterade åtgärden REFRESH. Om resultatet begär en omstart innehåller filen mer än den egenskap du ville ändra, så granska den i stället för att bevilja omstarten.

Tillämpa den granskade filen med refresh-gränsen:

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

Kontrollera att åtgärden slutfördes och kör describe-kommandot igen. Om fingeravtrycket inte längre stämmer har någon annan ändrat instansen medan du redigerade, så exportera en färsk kopia och granska ändringen igen i stället för att tvinga igenom din inaktuella fil.

Gästen måste fortfarande routa paketet

Ett molntillstånd gör inte apparaten till en router. Bekräfta att en VPC-rutt väljer den här VM:en som nästa hopp för destinationsprefixet, och att gästen routar mellan tunneln och rätt gränssnitt med sin egen vidarebefordringspolicy aktiverad.

Brandväggsprincipen måste tillåta det inre flödet såväl som den yttre lyssnaren. Att bara öppna VPN-porten beskriver den krypterade transporten och säger ingenting om applikationsutbytet inuti den.

Slutligen behöver destinationen en returväg till klientpoolen, eller så måste designen medvetet översätta källor. Om destinationen ser översatt trafik, kontrollera den översatta källan; om designen bevarar poolen, kontrollera den poolen i returrutten och åtkomstreglerna. Att lägga till NAT innan du bestämt vilken design du vill ha döljer en saknad rutt och ändrar den princip som destinationen ser.

På en Linux-gateway är kärnans vidarebefordran en del av gästkonfigurationen. En pfSense-apparat har sin egen motsvarighet, och att kopiera ett Linux-sysctl-kommando in i den är inte det motsvarande steget.

Verifiera från klienten som behöver åtkomst

Testa från en VPN-klient till en måljänst, inte från gatewayen själv. En anslutning som startas på gatewayen använder en annan källa och utövar aldrig de vidarebefordringsregler du just aktiverade.

Registrera egenskapen i det som hanterar apparaten. En manuellt korrigerad VM fungerar tills dess nästa utbyte tyst återinför den ursprungliga inställningen, och det felet kommer att se ut som en regression i VPN-programvaran.

Arbetsordning: läs egenskapen, exportera och redigera en rad, validera med NO_EFFECT, tillämpa med REFRESH, bekräfta att gästen vidarebefordrar och testa sedan från en klient.