Activarea redirecționării IP pe un gateway GCE VPN existent

VM-ul a fost creat fără redirecționare IP, rulează deja software-ul VPN, iar instinctul este să îl reconstruiești din șablon cu indicatorul activat. Acea reconstrucție este inutilă. Compute Engine expune canIpForward ca proprietate actualizabilă, iar calea de actualizare documentată o aplică cu un refresh în locul unei reporniri. Ce controlează indicatorul de fapt este îngust: fără el, platforma aruncă pachetele care ajung la instanță dar nu sunt adresate spre adresa proprie a instanței. Un gateway care redirecționează traficul altor mașini face exact asta, așa că indicatorul trebuie să fie activ. Tot ce urmează ține de configurația invitatului și de rutare, pe care indicatorul nu le atinge.

Ce permite indicatorul și ce nu

Cu redirecționarea dezactivată, platforma tratează instanța ca punct final. Pachetele a căror destinație este adresa proprie a instanței sunt livrate; pachetele pe care instanța ar trebui să le transmită mai departe în numele altcuiva nu sunt.

Cu redirecționarea activată, instanța poate acționa ca următorul salt pentru o rută VPC, iar acesta este rolul de care are nevoie un aparat VPN. Indicatorul nu spune nimic despre firewall-uri, rutarea invitatului, configurația tunelului sau căile de întoarcere, și o valoare true pe un gateway defect rămâne un gateway defect.

Citiți proprietatea curentă

Inspectați setarea înainte de a schimba ceva, cu un describe doar-citire asupra instanței, proiectului și zonei dorite:

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

O valoare false contează doar dacă acest VM trebuie să fie următorul salt. Dacă este, restul căii trebuie totuși verificat separat, pentru că proprietatea este o singură linie într-un lanț mai lung.

Actualizați instanța existentă

Procedura Google de actualizare a proprietăților instanței exportă resursa curentă, modifică proprietatea și trimite rezultatul. Acesta este un flux de lucru diferit de indicatorul --can-ip-forward din momentul creării, și este cel care funcționează pe un VM aflat în execuție.

Exportați mai întâi definiția într-un fișier local și păstrați o copie neschimbată pentru comparație:

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

În acel fișier exportat, setați proprietatea și nu schimbați nimic altceva:

canIpForward: true

Păstrați întreaga resursă, inclusiv amprenta ei. Înlocuirea fișierului cu un document YAML de o singură linie, sau gruparea unor modificări fără legătură la tipul mașinii, discul sau interfața în aceeași trimitere, este modul în care o modificare de proprietate devine o întrerupere.

Rugați mecanismul de actualizare să valideze fișierul și să raporteze ce ar necesita, înainte de a fi permisă orice modificare efectivă:

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

Acea rulare de validare nu activează redirecționarea. Citiți răspunsul pentru proprietăți invalide și pentru acțiunea declarată necesară. Pentru această modificare izolată, acțiunea documentată este REFRESH. Dacă rezultatul cere o repornire, fișierul conține mai mult decât proprietatea pe care voiați să o schimbați, așa că inspectați-l în loc să acordați repornirea.

Aplicați fișierul revizuit cu limita refresh:

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

Verificați că operația s-a încheiat și rulați din nou comanda describe. Dacă amprenta nu mai corespunde, altcineva a modificat instanța în timp ce editai, așa că exportați o copie proaspătă și revedeți modificarea, în loc să forțați fișierul învechit.

Invitatul trebuie încă să ruteze pachetul

O permisiune în cloud nu transformă aparatul într-un router. Confirmați că o rută VPC selectează acest VM ca următor salt pentru prefixul de destinație și că invitatul rutează între tunel și interfața corectă cu propria politică de redirecționare activată.

Politica firewall-ului trebuie să permită fluxul interior, precum și ascultătorul exterior. Deschiderea doar a portului VPN descrie transportul criptat și nu spune nimic despre schimbul aplicației din interior.

În final, destinația are nevoie de o cale de întoarcere către grupul de clienți, sau proiectarea trebuie să traducă sursele în mod deliberat. Dacă destinația vede trafic tradus, verificați sursa tradusă; dacă proiectarea păstrează grupul, verificați acel grup în ruta de întoarcere și în regulile de acces. Adăugarea NAT înainte de a decide ce proiectare doriți ascunde o rută lipsă și schimbă politica pe care o vede destinația.

Pe un gateway Linux, redirecționarea din nucleu face parte din configurația invitatului. Un aparat pfSense are echivalentul propriu, iar copierea unei comenzi sysctl de Linux în el nu este pasul corespunzător.

Verificați de la clientul care are nevoie de acces

Testați de la un client VPN către un singur serviciu țintă, nu de la gateway-ul însuși. O conexiune pornită pe gateway folosește altă sursă și nu exersează niciodată regulile de redirecționare pe care tocmai le-ați activat.

Înregistrați proprietatea în orice administrează aparatul. Un VM corectat manual funcționează până când următoarea înlocuire reintroduce în tăcere setarea originală, iar acea defecțiune va arăta ca o regresie în software-ul VPN.

Ordinea lucrării: citiți proprietatea, exportați și editați o linie, validați cu NO_EFFECT, aplicați cu REFRESH, confirmați că invitatul redirecționează, apoi testați de la un client.