GCP Cloud VPN: verificați gateway-ul, tunelul și firewall-ul în ordine

Consola arată un tunel verde, monitorizarea locală încă nu ajunge la nicio instanță, iar reconstruirea tunelului pare soluția evidentă. Rar este. Un tunel stabilit dovedește doar că două gateway-uri au terminat schimbul IKE. Nu spune nimic despre dacă un pachet a fost vreodată permis în VPC-ul dumneavoastră.

Patru decizii stau între acea pictogramă verde și un răspuns, și eșuează într-o ordine previzibilă. Începeți cu cea mai ieftină.

Trei obiecte, și doar unul dintre ele criptează

Un gateway VPN deține adresa externă către care criptează partenerul dumneavoastră. În consolă nu îl creați niciodată manual: alegeți sau rezervați o adresă în formularul de conexiune și gateway-ul apare împreună cu ea. Un gateway HA ocupă două adrese pe două interfețe, ceea ce contează la verificarea cotelor mai târziu.

Un tunel este împerecherea dintre acel gateway și partener. Transportă secretul comun și selectorii de trafic pe care promite să îi protejeze. În acești selectori încep majoritatea eșecurilor silențioase. Un tunel al cărui selector local acoperă 10.0.0.0/24 nu va livra 10.0.1.0/24, oricât de sănătos ar arăta statusul.

Capătul îndepărtat ține propria listă, numită de obicei domeniu de criptare, iar hardware-ul de terminare o compară cu a dumneavoastră. Nicio parte nu negociază un selector care nu i-a fost dat niciodată.

Tipul de rutare decide ce ajunge în tabelul de rutare

Cloud VPN oferă trei forme de rutare și ele nu se amestecă curat. Rutarea bazată pe politici păstrează perechile statice de selectori, rutarea bazată pe rute așteaptă să adăugați singur rute statice, iar rutarea dinamică anunță prefixe printr-un Cloud Router pe BGP. Alegeți una în mod deliberat.

Un tunel dinamic cu rute statice scrise de mână alături produce un tabel de rutare care se golește de fiecare dată când sesiunea BGP oscilează.

Dinamica este singura formă care permite prefixelor protejate să se schimbe fără reconstruirea tunelului și atrage Cloud Router în setul de obiecte pe care trebuie să le verificați. Selectorii statici rămân utilizabili când partenerul este un firewall hardware care nu poate vorbi BGP. Atunci ambele capete au nevoie de aceleași intervale, iar intrarea mai specifică trebuie să câștige pe ambele. O pereche care diferă printr-o subrețea se stabilește și apoi transportă jumătate din traficul dumneavoastră.

Refuzul implicit stă în spatele tunelului

Traficul de intrare este evaluat față de un refuz implicit la cea mai joasă prioritate, iar regula respectivă nu-i pasă că pachetul a sosit criptat. Până când o regulă de firewall nu numește intervalul local și portul folosit, pachetul este decriptat, inspectat și aruncat. Jurnalul VPN rămâne curat tot timpul, pentru că tunelul a făcut exact ce a promis.

Citiți în schimb jurnalul de refuzuri al firewall-ului când tunelul este activ și sonda expiră, apoi limitați o regulă la intervalul sursă și la porturile de care aveți nevoie:

gcloud compute firewall-rules create allow-from-dc \
  --network=vpn-vpc \
  --direction=INGRESS \
  --source-ranges=192.168.10.0/24 \
  --allow=tcp:22,tcp:5432,icmp

O singură direcție funcțională este un indiciu de firewall

Traficul de ieșire se comportă diferit, pentru că regula de permisiune implicită lasă instanțele să trimită oriunde. Un centru de date care nu ajunge la o VM stă adesea în spatele unei căi de ieșire perfect funcționale în cealaltă direcție. Această asimetrie separă o omisiune de firewall de o defecțiune de rutare, fiindcă o defecțiune de rutare rupe ambele direcții deodată. Testați direcția inversă înainte de a mai edita o regulă.

Crearea adreselor este și o operațiune de cotă. Un proiect aproape de limita adreselor externe în uz refuză conexiunea cu o eroare care sună ca o lipsă de permisiuni.

Selectori, cote, apoi cele patru verificări

Tunelurile create în consolă returnează uneori un selector de trafic la distanță gol din gcloud compute vpn-tunnels describe, în timp ce rutele generate transportă corect traficul. Comparați ce înregistrează API-ul cu intervalele pe care le protejați cu adevărat înainte de a decide că tunelul este greșit. Crearea lui prin API sau SDK menține selectorul explicit.

Cotele sunt cealaltă ratare ușoară. Solicitați majorarea înainte de fereastra de mentenanță, nu în timpul ei, și verificați numărul de adrese în același proiect cu gateway-ul.

Lucrați din exterior spre interior: starea partenerului, ambele liste de selectori, o rută pentru fiecare parte, o regulă de intrare pentru intervalul sursă și port, apoi o captură de pachete. Notați adresa gateway-ului, ambele liste de selectori și tipul de rutare în tichetul de schimbare cât timp tunelul este nou, pentru că următorul inginer care adaugă o subrețea va avea nevoie de toate trei.