GCP Cloud VPN: kontrollera gateway, tunnel och brandvägg i rätt ordning

En tunnel som rapporterar etablerad medan varje sondering löper ut saknar oftast en VPC-brandväggsregel. Kontrollera gateway, selektorer och rutningstyp i den ordningen.

Din konsol visar en grön tunnel, övervakningen på plats når fortfarande inte en enda instans, och att bygga om tunneln verkar vara den självklara lösningen. Det är den sällan. En etablerad tunnel bevisar bara att två gateways slutförde IKE-utbytet. Den säger ingenting om huruvida ett paket någonsin släpptes in i din VPC.

Fyra beslut står mellan den gröna ikonen och ett svar, och de misslyckas i en förutsägbar ordning. Ta dem billigast först.

Tre objekt, och bara ett av dem krypterar

En VPN-gateway äger den externa adressen som din peer krypterar till. I konsolen skapar du den aldrig för hand: välj eller reservera en adress i anslutningsformuläret och gatewayen visas med den. En HA-gateway tar två adresser på två gränssnitt, vilket spelar roll vid kvotkontrollen senare.

En tunnel är parningen mellan den gatewayen och peeren. Den bär den delade hemligheten och trafikselektorer som den lovar att skydda. Det är i dessa selektorer de flesta tysta fel börjar. En tunnel vars lokala selektor täcker 10.0.0.0/24 levererar inte 10.0.1.0/24, hur frisk statusen än ser ut.

Den bortre änden håller sin egen lista, vanligen kallad en krypteringsdomän, och den terminerande hårdvaran jämför den med din. Ingen sida förhandlar om en selektor som den aldrig har fått.

Rutningstypen avgör vad som når routingtabellen

Cloud VPN erbjuder tre rutningsformer och de blandas inte rent. Policybaserad rutning behåller de statiska selektorparen, ruttbaserad rutning förväntar sig att du lägger till statiska rutter själv, och dynamisk rutning annonserar prefix via en Cloud Router över BGP. Välj en med avsikt.

En dynamisk tunnel med handskrivna statiska rutter bredvid ger en routingtabell som töms varje gång BGP-sessionen vacklar.

Dynamisk är den enda formen som låter de skyddade prefixen ändras utan att bygga om tunneln, och den drar in Cloud Router i mängden objekt du måste verifiera. Statiska selektorer förblir användbara när peeren är en hårdvarubrandvägg som inte kan tala BGP. Då behöver båda ändarna samma intervall, och den mer specifika posten måste vinna på båda. Ett par som skiljer sig åt med ett subnät etableras och bär sedan hälften av din trafik.

Den implicita nekningen sitter bakom tunneln

Inkommande trafik utvärderas mot en implicit nekning med lägst prioritet, och den regeln bryr sig inte om att paketet kom krypterat. Tills en brandväggsregel namnger intervallet på plats och porten som används, dekrypteras paketet, inspekteras och släpps. VPN-loggen förblir ren hela tiden, eftersom tunneln gjorde exakt det den lovade.

Läs i stället brandväggens avvisningslogg när tunneln är uppe och sonderingen löper ut, och begränsa sedan en regel till källintervallet och de portar du behöver:

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

Att en riktning fungerar är en brandväggsledtråd

Utgående trafik beter sig annorlunda, eftersom den implicita tillåtregeln låter instanser skicka var som helst. Ett datacenter som inte når en VM sitter ofta bakom en perfekt fungerande utgående väg i den andra riktningen. Den asymmetrin skiljer en brandväggsmiss från ett rutningsfel, eftersom ett rutningsfel bryter båda riktningarna på en gång. Testa den motsatta riktningen innan du redigerar ännu en regel.

Att skapa adresser är också en kvotoperation. Ett projekt nära sin gräns för externa adresser i bruk avvisar anslutningen med ett fel som låter som ett behörighetsfel.

Selektorer, kvoter, sedan de fyra kontrollerna

Tunnlar som skapats i konsolen returnerar ibland en tom extern trafikselektor från gcloud compute vpn-tunnels describe, medan genererade rutter bär trafiken korrekt. Jämför vad API:et registrerar med de intervall du faktiskt skyddar innan du avgör att tunneln är fel. Att skapa den via API eller SDK håller selektorn explicit.

Kvoter är den andra lätta missen. Begär ökningen före underhållsfönstret, inte under det, och kontrollera adressantalet i samma projekt som gatewayen.

Arbeta utifrån och in: peer-status, båda selektorlistorna, en rutt för varje sida, en inkommande regel för källintervallet och porten, sedan en paketfångst. Skriv gatewayadressen, båda selektorlistorna och rutningstypen i ändringsbiljetten medan tunneln är ny, eftersom nästa ingenjör som lägger till ett subnät behöver alla tre.

Relaterade artiklar