Aktivér IP-videresendelse på en eksisterende GCE VPN-gateway
canIpForward er en opdaterbar egenskab, ikke en grund til at genopbygge VM'en. Eksportér ressourcen, ret én linje, validér, og anvend derefter med et refresh.
VM'en blev oprettet uden IP-videresendelse, den kører allerede VPN-softwaren, og instinktet er at genopbygge den ud fra skabelonen med flaget sat. Den genopbygning er unødvendig. Compute Engine eksponerer canIpForward som en opdaterbar egenskab, og den dokumenterede opdateringsvej anvender den med et refresh i stedet for en genstart. Det, flaget faktisk styrer, er snævert: uden det dropper platformen pakker, der ankommer til instansen, men ikke er adresseret til instansens egen adresse. En gateway, der videresender andre maskiners trafik, gør præcis det, så flaget skal være slået til. Alt derefter er gæstekonfiguration og routing, som flaget ikke rører.
Hvad flaget tillader, og hvad det ikke gør
Med videresendelse deaktiveret behandler platformen instansen som et endepunkt. Pakker, hvis destination er instansens egen adresse, leveres; pakker, som instansen skal sende videre på vegne af en anden, gør ikke.
Med videresendelse aktiveret kan instansen fungere som næste hop for en VPC-rute, og det er den rolle, en VPN-appliance har brug for. Flaget siger intet om firewalls, gæsterouting, tunnelkonfiguration eller returveje, og en true-værdi på en defekt gateway er stadig en defekt gateway.
Læs den nuværende egenskab
Undersøg indstillingen, før du ændrer noget, med en skrivebeskyttet describe mod den tilsigtede instans, projekt og zone:
gcloud compute instances describe VM_NAME --project PROJECT_ID --zone ZONE --format='value(canIpForward)'
En false-værdi betyder kun noget, hvis denne VM skal være næste hop. Er den det, skal resten af vejen stadig kontrolleres separat, fordi egenskaben er én linje i en længere kæde.
Opdatér den eksisterende instans
Googles procedure for opdatering af instansens egenskaber eksporterer den aktuelle ressource, ændrer egenskaben og indsender resultatet. Det er en anden arbejdsgang end flaget --can-ip-forward ved oprettelsen, og det er den, der virker på en kørende VM.
Eksportér først definitionen til en lokal fil, og gem en uændret kopi til sammenligning:
gcloud compute instances export VM_NAME --project PROJECT_ID --zone ZONE --destination=instance.yaml
I den eksporterede fil sætter du egenskaben og ændrer intet andet:
canIpForward: true
Behold hele ressourcen, inklusive dens fingeraftryk. At erstatte filen med et YAML-dokument på én linje eller at samle uvedkommende rettelser af maskintype, disk eller interface i samme indsendelse er måden, hvorpå en egenskabsændring bliver et nedbrud.
Bed opdateringsmekanismen validere filen og rapportere, hvad den ville kræve, før nogen effektiv ændring tillades:
gcloud compute instances update-from-file VM_NAME --project PROJECT_ID --zone ZONE --source=instance.yaml --most-disruptive-allowed-action=NO_EFFECT
Den valideringskørsel aktiverer ikke videresendelse. Læs svaret for ugyldige egenskaber og for den handling, den siger er nødvendig. For denne isolerede ændring er den dokumenterede handling REFRESH. Hvis resultatet beder om en genstart, indeholder filen mere end den egenskab, du ville ændre, så undersøg den i stedet for at give genstarten.
Anvend den gennemgåede fil 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
Kontrollér, at operationen er fuldført, og kør describe-kommandoen igen. Hvis fingeraftrykket ikke længere passer, har nogen andre ændret instansen, mens du redigerede, så eksportér en frisk kopi og gennemgå ændringen igen i stedet for at presse din forældede fil igennem.
Gæsten skal stadig route pakken
Skyttilladelse gør ikke applikationen til en router. Bekræft, at en VPC-rute vælger denne VM som næste hop for destinationspræfikset, og at gæsten router mellem tunnelen og det rigtige interface med sin egen videresendelsespolitik aktiveret.
Firewallpolitik skal tillade den indre strøm såvel som den ydre lytter. At åbne kun VPN-porten beskriver den krypterede transport og siger intet om applikationsudvekslingen indeni.
Endelig har destinationen brug for en returvej til klientpuljen, eller også skal designet oversætte kilder bevidst. Hvis destinationen ser oversat trafik, så kontrollér den oversatte kilde; hvis designet bevarer puljen, så kontrollér den pulje i returruten og adgangsreglerne. At tilføje NAT, før du beslutter, hvilket design du vil have, skjuler en manglende rute og ændrer den politik, destinationen ser.
På en Linux-gateway er kernel-videresendelse en del af gæstekonfigurationen. En pfSense-appliance har sin egen ækvivalent, og at kopiere en Linux-sysctl-kommando ind i den er ikke det tilsvarende trin.
Verificér fra den klient, der har brug for adgang
Test fra en VPN-klient til én målstjeneste, ikke fra gatewayen selv. En forbindelse startet på gatewayen bruger en anden kilde og udøver aldrig de videresendelsesregler, du netop har aktiveret.
Registrér egenskaben i hvad der end styrer applikationen. En manuelt rettet VM virker, indtil dens næste udskiftning stille genindfører den oprindelige indstilling, og den fejl vil se ud som en regression i VPN-softwaren.
Arbejdsrækkefølge: læs egenskaben, eksportér og redigér én linje, validér med NO_EFFECT, anvend med REFRESH, bekræft at gæsten videresender, og test derefter fra en klient.