GCP Cloud VPN: kontrollér gateway, tunnel og firewall i rækkefølge

En tunnel, der rapporterer etableret, mens hver sondering løber ud, mangler normalt en VPC-firewallregel. Kontrollér gateway, selektorer og rutningstype i den rækkefølge.

Din konsol viser en grøn tunnel, overvågning på stedet kan stadig ikke nå en enkelt instans, og genopbygning af tunnelen ser ud som den oplagte løsning. Det er den sjældent. En etableret tunnel beviser kun, at to gateways har afsluttet IKE-udvekslingen. Den siger intet om, hvorvidt en pakke nogensinde blev lukket ind i din VPC.

Fire beslutninger står mellem det grønne ikon og et svar, og de fejler i en forudsigelig rækkefølge. Tag dem billigst først.

Tre objekter, og kun ét af dem krypterer

En VPN-gateway ejer den eksterne adresse, som din peer krypterer til. I konsollen opretter du den aldrig manuelt: vælg eller reserver en adresse inde i forbindelsesformularen, og gatewayen vises med den. En HA-gateway tager to adresser på to interfaces, hvilket betyder noget ved kvotetjekket senere.

En tunnel er parringen mellem den gateway og peeren. Den bærer den delte hemmelighed og de trafikselektorer, den lover at beskytte. Det er i disse selektorer, de fleste tavse fejl begynder. En tunnel, hvis lokale selektor dækker 10.0.0.0/24, leverer ikke 10.0.1.0/24, uanset hvor sund status ser ud.

Den fjerne ende holder sin egen liste, normalt kaldet et krypteringsdomæne, og det terminerende hardware sammenligner den med din. Ingen side forhandler en selektor, den aldrig har fået.

Rutningstypen afgør, hvad der når rutetabellen

Cloud VPN tilbyder tre rutningsformer, og de blander sig ikke rent. Politikbaseret rutning beholder de statiske selektorpar, rutebaseret rutning forventer, at du selv tilføjer statiske ruter, og dynamisk rutning annoncerer præfikser gennem en Cloud Router over BGP. Vælg én med vilje.

En dynamisk tunnel med håndskrevne statiske ruter ved siden af giver en rutetabel, der tømmes, hver gang BGP-sessionen vipper.

Dynamisk er den eneste form, der lader de beskyttede præfikser ændre sig uden at genopbygge tunnelen, og den trækker Cloud Router ind i det sæt objekter, du skal verificere. Statiske selektorer forbliver brugbare, når peeren er en hardware-firewall, der ikke kan tale BGP. Så skal begge ender bruge de samme områder, og den mere specifikke post skal vinde på begge. Et par, der er uenige om et enkelt subnet, etableres og bærer derefter halvdelen af din trafik.

Det implicitte afslag sidder bag tunnelen

Indgående trafik vurderes mod et implicit afslag med laveste prioritet, og den regel er ligeglad med, at pakken ankom krypteret. Indtil en firewallregel navngiver området på stedet og den anvendte port, dekrypteres pakken, inspiceres og droppes. VPN-loggen forbliver ren hele vejen, fordi tunnelen gjorde præcis det, den lovede.

Læs i stedet firewallens afvisningslog, når tunnelen er oppe, og sonderingen løber ud, og afgræns derefter en regel til kildeområdet og de porte, du har brug for:

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

At én retning virker er et firewallspor

Udgående trafik opfører sig anderledes, fordi den implicitte tilladelsesregel lader instanser sende overalt. Et datacenter, der ikke kan nå en VM, står ofte bag en perfekt fungerende udgående vej i den anden retning. Den asymmetri adskiller en firewalludeladelse fra en rutningsfejl, da en rutningsfejl bryder begge retninger på én gang. Test den omvendte retning, før du redigerer endnu en regel.

Oprettelse af adresser er også en kvoteoperation. Et projekt tæt på sin grænse for eksterne adresser i brug afviser forbindelsen med en fejl, der lyder som en tilladelsesfejl.

Selektorer, kvoter, så de fire tjek

Tunneler oprettet i konsollen returnerer nogle gange en tom fjern-trafikselektor fra gcloud compute vpn-tunnels describe, mens genererede ruter bærer trafikken korrekt. Sammenlign, hvad API'et registrerer, med de områder, du faktisk beskytter, før du beslutter, at tunnelen er forkert. Oprettelse gennem API'et eller SDK'et holder selektoren eksplicit.

Kvoter er den anden nemme udeladelse. Anmod om forhøjelsen før vedligeholdelsesvinduet, ikke under det, og kontrollér adresseantallet i samme projekt som gatewayen.

Arbejd udefra og ind: peer-status, begge selektorlister, en rute for hver side, en indgående regel for kildeområdet og porten, derefter en pakkefangst. Skriv gatewayadressen, begge selektorlister og rutningstypen i ændringsbilletten, mens tunnelen er ny, fordi den næste ingeniør, der tilføjer et subnet, får brug for alle tre.

Relaterede artikler