IP-doorsturen inschakelen op een bestaande GCE VPN-gateway
canIpForward is een bijwerkbare eigenschap, geen reden om de VM opnieuw te bouwen. Exporteer de resource, wijzig één regel, valideer en pas dan toe met een refresh.
De VM is aangemaakt zonder IP-doorsturen, draait al de VPN-software, en de reflex is hem opnieuw te bouwen uit de sjabloon met de vlag aan. Die herbouw is onnodig. Compute Engine biedt canIpForward aan als bijwerkbare eigenschap, en het gedocumenteerde updatepad past die toe met een refresh in plaats van een herstart. Wat de vlag werkelijk bestuurt is smal: zonder de vlag laat het platform pakketten vallen die bij het instance aankomen maar niet aan het eigen adres van het instance geadresseerd zijn. Een gateway die verkeer van andere machines doorstuurt doet precies dat, dus de vlag moet aan staan. Alles daarna is gastconfiguratie en routering, waar de vlag niets mee doet.
Wat de vlag toestaat, en wat niet
Met doorsturen uitgeschakeld behandelt het platform het instance als een eindpunt. Pakketten waarvan de bestemming het eigen adres van het instance is, worden afgeleverd; pakketten die het instance namens iemand anders moet doorgeven, niet.
Met doorsturen ingeschakeld mag het instance dienen als volgende hop voor een VPC-route, en dat is de rol die een VPN-appliance nodig heeft. De vlag zegt niets over firewalls, gastroutering, tunnelconfiguratie of retourpaden, en een true-waarde op een kapotte gateway is nog steeds een kapotte gateway.
Lees de huidige eigenschap
Controleer de instelling voordat je iets wijzigt, met een alleen-lezen describe tegen het beoogde instance, project en de zone:
gcloud compute instances describe VM_NAME --project PROJECT_ID --zone ZONE --format='value(canIpForward)'
Een false-waarde is alleen van belang als deze VM de volgende hop moet zijn. Is dat zo, dan moet de rest van het pad nog steeds apart worden gecontroleerd, omdat de eigenschap één regel is in een langere keten.
Werk het bestaande instance bij
De procedure van Google voor het bijwerken van instance-eigenschappen exporteert de huidige resource, wijzigt de eigenschap en dient het resultaat in. Dat is een andere werkstroom dan de vlag --can-ip-forward bij het aanmaken, en dat is degene die werkt op een draaiende VM.
Exporteer eerst de definitie naar een lokaal bestand, en bewaar een ongewijzigde kopie om te vergelijken:
gcloud compute instances export VM_NAME --project PROJECT_ID --zone ZONE --destination=instance.yaml
Stel in dat geëxporteerde bestand de eigenschap in en wijzig niets anders:
canIpForward: true
Behoud de hele resource, inclusief de vingerafdruk. Het bestand vervangen door een YAML-document van één regel, of losse wijzigingen aan machinetype, schijf of interface in dezelfde indiening bundelen, is de manier waarop een eigenschapswijziging een storing wordt.
Vraag het updatemechanisme het bestand te valideren en te melden wat het zou vereisen, voordat een daadwerkelijke wijziging wordt toegestaan:
gcloud compute instances update-from-file VM_NAME --project PROJECT_ID --zone ZONE --source=instance.yaml --most-disruptive-allowed-action=NO_EFFECT
Die validatierun schakelt doorsturen niet in. Lees het antwoord op ongeldige eigenschappen en op de actie die volgens het antwoord nodig is. Voor deze geïsoleerde wijziging is de gedocumenteerde actie REFRESH. Als het resultaat om een herstart vraagt, bevat het bestand meer dan de eigenschap die je wilde wijzigen, dus inspecteer het in plaats van de herstart toe te staan.
Pas het nagekeken bestand toe met de refresh-limiet:
gcloud compute instances update-from-file VM_NAME --project PROJECT_ID --zone ZONE --source=instance.yaml --most-disruptive-allowed-action=REFRESH
Controleer dat de bewerking is voltooid en voer de describe-opdracht opnieuw uit. Als de vingerafdruk niet meer overeenkomt, heeft iemand anders het instance gewijzigd terwijl je aan het bewerken was, dus exporteer een verse kopie en bekijk de wijziging opnieuw in plaats van je verouderde bestand erdoor te drukken.
De gast moet het pakket nog steeds routeren
Cloudrechten maken de appliance geen router. Bevestig dat een VPC-route deze VM als volgende hop kiest voor het bestemmingsprefix, en dat de gast routeert tussen de tunnel en de juiste interface met zijn eigen doorstuurbeleid ingeschakeld.
Het firewallbeleid moet zowel de binnenkomende stroom als de externe luisteraar toestaan. Alleen de VPN-poort openen beschrijft het versleutelde transport en zegt niets over de applicatie-uitwisseling erbinnen.
Ten slotte heeft de bestemming een retourpad naar de clientpool nodig, of het ontwerp moet bronnen bewust vertalen. Ziet de bestemming vertaald verkeer, controleer dan de vertaalde bron; behoudt het ontwerp de pool, controleer dan die pool in de retourroute en de toegangsregels. NAT toevoegen voordat je besluit welk ontwerp je wilt, verbergt een ontbrekende route en verandert het beleid dat de bestemming ziet.
Op een Linux-gateway is kernel-doorsturen onderdeel van de gastconfiguratie. Een pfSense-appliance heeft zijn eigen equivalent, en een Linux-sysctl-opdracht erin kopiëren is niet de juiste stap.
Verifieer vanaf de client die toegang nodig heeft
Test vanaf een VPN-client naar één doeldienst, niet vanaf de gateway zelf. Een verbinding die op de gateway begint, gebruikt een andere bron en oefent nooit de doorstuurregels uit die je net hebt ingeschakeld.
Leg de eigenschap vast in wat de appliance ook beheert. Een handmatig gecorrigeerde VM werkt tot de volgende vervanging de oorspronkelijke instelling stil terugzet, en die fout zal op een regressie in de VPN-software lijken.
Werkvolgorde: lees de eigenschap, exporteer en bewerk één regel, valideer met NO_EFFECT, pas toe met REFRESH, bevestig dat de gast doorstuurt, en test dan vanaf een client.