GCP Cloud VPN: kontroller gateway, tunnel og brannmur i rekkefølge

Konsollen din viser en grønn tunnel, overvåking på stedet når fortsatt ikke en eneste instans, og å bygge tunnelen på nytt ser ut som den åpenbare løsningen. Det er den sjelden. En etablert tunnel beviser bare at to gateways fullførte IKE-utvekslingen. Den sier ingenting om hvorvidt en pakke noen gang ble sluppet inn i VPC-en din.

Fire beslutninger står mellom det grønne ikonet og et svar, og de feiler i en forutsigbar rekkefølge. Ta dem billigst først.

Tre objekter, og bare ett av dem krypterer

En VPN-gateway eier den eksterne adressen som peeren din krypterer til. I konsollen oppretter du den aldri manuelt: velg eller reserver en adresse i tilkoblingsskjemaet, og gatewayen vises med den. En HA-gateway tar to adresser på to grensesnitt, noe som teller ved kvotekontrollen senere.

En tunnel er paringen mellom den gatewayen og peeren. Den bærer den delte hemmeligheten og trafikkselektorene den lover å beskytte. Det er i disse selektorene de fleste stille feilene begynner. En tunnel der den lokale selektoren dekker 10.0.0.0/24, leverer ikke 10.0.1.0/24, uansett hvor sunn statusen ser ut.

Den fjerne enden holder sin egen liste, vanligvis kalt et krypteringsdomene, og maskinvaren som terminerer sammenligner den med din. Ingen side forhandler om en selektor den aldri har fått.

Rutetypen avgjør hva som når rutetabellen

Cloud VPN tilbyr tre ruteformer, og de blandes ikke rent. Politikkbasert ruting beholder de statiske selektorparene, rutebasert ruting forventer at du legger til statiske ruter selv, og dynamisk ruting annonserer prefikser gjennom en Cloud Router over BGP. Velg én med vilje.

En dynamisk tunnel med håndskrevne statiske ruter ved siden av gir en rutetabell som tømmes hver gang BGP-økten vipper.

Dynamisk er den eneste formen som lar de beskyttede prefiksene endre seg uten å bygge tunnelen på nytt, og den drar Cloud Router inn i settet med objekter du må verifisere. Statiske selektorer forblir brukbare når peeren er en maskinvarebrannmur som ikke kan snakke BGP. Da trenger begge ender de samme områdene, og den mer spesifikke oppføringen må vinne på begge. Et par som er uenige om ett subnett, etableres og bærer deretter halvparten av trafikken din.

Den implisitte nektelsen sitter bak tunnelen

Inngående trafikk vurderes mot en implisitt nektelse med lavest prioritet, og den regelen bryr seg ikke om at pakken kom kryptert. Inntil en brannmurregel navngir området på stedet og porten som brukes, blir pakken dekryptert, inspisert og droppet. VPN-loggen forblir ren hele veien, fordi tunnelen gjorde nøyaktig det den lovet.

Les i stedet brannmurens avvisningslogg når tunnelen er oppe og sonderingen går ut, og begrens deretter en regel til kildeområdet og portene du trenger:

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 brannmurspor

Utgående trafikk oppfører seg annerledes, fordi den implisitte tillatelsesregelen lar instanser sende hvor som helst. Et datasenter som ikke når en VM, sitter ofte bak en perfekt fungerende utgående vei i den andre retningen. Den asymmetrien skiller en brannmurutelatelse fra en rutingfeil, siden en rutingfeil bryter begge retningene på én gang. Test den motsatte retningen før du redigerer enda en regel.

Oppretting av adresser er også en kvoteoperasjon. Et prosjekt nær grensen for eksterne adresser i bruk avviser tilkoblingen med en feil som høres ut som en tillatelsesfeil.

Selektorer, kvoter, så de fire kontrollene

Tunneler opprettet i konsollen returnerer noen ganger en tom ekstern trafikkselektor fra gcloud compute vpn-tunnels describe, mens genererte ruter bærer trafikken riktig. Sammenlign det API-et registrerer med områdene du faktisk beskytter, før du konkluderer med at tunnelen er feil. Å opprette den via API eller SDK holder selektoren eksplisitt.

Kvoter er den andre enkle utelatelsen. Be om økningen før vedlikeholdsvinduet, ikke under det, og kontroller adresseantallet i samme prosjekt som gatewayen.

Arbeid utenfra og inn: peer-status, begge selektorlistene, en rute for hver side, en inngående regel for kildeområdet og porten, deretter en pakkefangst. Skriv gatewayadressen, begge selektorlistene og rutetypen i endringsbilletten mens tunnelen er ny, fordi den neste ingeniøren som legger til et subnett, trenger alle tre.