Aktiveer IP-forwarding op ’n bestaande GCE VPN-gateway

Die VM is geskep sonder IP-forwarding, dit loop reeds die VPN-sagteware, en die instink is om dit uit die sjabloon te herbou met die vlag gestel. Daardie herbou is onnodig. Compute Engine stel canIpForward as ’n opdateerbare eienskap beskikbaar, en die gedokumenteerde opdateringspad pas dit toe met ’n refresh eerder as ’n herbegin. Wat die vlag werklik beheer, is eng: sonder dit laat die platform pakkette val wat by die instansie aankom maar nie aan die instansie se eie adres geadresseer is nie. ’n Gateway wat ander masjiene se verkeer aanstuur, doen presies dit, so die vlag moet aan wees. Alles daarna is gaskonfigurasie en roetering, en die vlag raak dit nie.

Wat die vlag toelaat, en wat nie

Met forwarding gedeaktiveer behandel die platform die instansie as ’n eindpunt. Pakkette wie se bestemming die instansie se eie adres is, word afgelewer; pakkette wat die instansie namens iemand anders moet deurgee, word nie.

Met forwarding geaktiveer mag die instansie as ’n volgende sprong vir ’n VPC-roete optree, en dit is die rol wat ’n VPN-toestel nodig het. Die vlag sê niks oor firewalls, gasroetering, tonnelkonfigurasie of terugpaaie nie, en ’n ware waarde op ’n stukkende gateway is steeds ’n stukkende gateway.

Lees die huidige eienskap

Ondersoek die instelling voordat jy iets verander, met ’n lees-alleen describe teen die beoogde instansie, projek en sone:

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

’n Valse waarde maak net saak as hierdie VM ’n volgende sprong moet wees. As dit die geval is, moet die res van die pad steeds apart nagegaan word, want die eienskap is een reël in ’n langer ketting.

Dateer die bestaande instansie op

Google se prosedure vir die opdatering van instansie-eienskappe voer die huidige hulpbron uit, verander die eienskap en dien die resultaat in. Dit is ’n ander werkvloei as die skeppingstydvlag --can-ip-forward, en dit is die een wat op ’n lopende VM werk.

Eksporteer eers die definisie na ’n plaaslike lêer, en hou ’n onveranderde kopie vir vergelyking:

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

Stel in daardie geëksporteerde lêer die eienskap en verander niks anders nie:

canIpForward: true

Behou die hele hulpbron, insluitend sy vingerafdruk. Om die lêer met ’n eenreël-YAML-dokument te vervang, of om onverwante wysigings aan masjientipe, skyf of koppelvlak in dieselfde indiening te bondel, is hoe ’n eienskapverandering ’n onderbreking word.

Vra die opdateringsmeganisme om die lêer te valideer en te rapporteer wat dit sou vereis, voordat enige werklike verandering toegelaat word:

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

Daardie valideringsloop aktiveer nie forwarding nie. Lees die antwoord vir ongeldige eienskappe en vir die aksie wat dit sê nodig is. Vir hierdie geïsoleerde verandering is die gedokumenteerde aksie REFRESH. As die resultaat ’n herbegin vra, bevat die lêer meer as die eienskap wat jy wou verander, so ondersoek dit eerder as om die herbegin toe te staan.

Pas die nagegane lêer toe met die refresh-limiet:

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

Kontroleer dat die bewerking voltooi is en voer die describe-opdrag weer uit. As die vingerafdruk nie meer ooreenstem nie, het iemand anders die instansie verander terwyl jy geredigeer het, so eksporteer ’n vars kopie en gaan die verandering weer na eerder as om jou verouderde lêer deur te dwing.

Die gas moet steeds die pakket roeteer

Wolktoestemming maak nie die toestel ’n roeteerder nie. Bevestig dat ’n VPC-roete hierdie VM as die volgende sprong vir die bestemmingsprefiks kies, en dat die gas tussen die tonnel en die regte koppelvlak roeteer met sy eie forwarding-beleid geaktiveer.

Firewall-beleid moet die innerlike vloei sowel as die buitenste luisteraar toelaat. Om net die VPN-poort oop te maak, beskryf die geïnkripteerde transport en sê niks oor die toepassingwisseling daarbinne nie.

Laastens het die bestemming ’n terugpad na die kliëntpoel nodig, of die ontwerp moet bronne doelbewus vertaal. As die bestemming vertaalde verkeer sien, kontroleer die vertaalde bron; as die ontwerp die poel behou, kontroleer daardie poel in die terugroete en die toegangsreëls. Om NAT by te voeg voordat jy besluit watter ontwerp jy wil hê, versteek ’n ontbrekende roete en verander die beleid wat die bestemming sien.

Op ’n Linux-gateway is kernel-forwarding deel van die gaskonfigurasie. ’n pfSense-toestel het sy eie ekwivalent, en om ’n Linux-sysctl-opdrag daarin te kopieer is nie dieselfde stap nie.

Verifieer vanaf die kliënt wat toegang nodig het

Toets vanaf ’n VPN-kliënt na een teikendiens, nie vanaf die gateway self nie. ’n Verbinding wat op die gateway begin word, gebruik ’n ander bron en oefen nooit die forwarding-reëls wat jy pas geaktiveer het nie.

Teken die eienskap aan in wat die toestel ook al bestuur. ’n Handmatig gekorrigeerde VM werk totdat sy volgende vervanging die oorspronklike instelling stilweg weer invoer, en daardie fout sal soos ’n regressie in die VPN-sagteware lyk.

Werkorde: lees die eienskap, eksporteer en wysig een reël, valideer met NO_EFFECT, pas toe met REFRESH, bevestig dat die gas forward, en toets dan vanaf ’n kliënt.