Cloud VPN-grenser du ikke kan justere: IKE-levetid og peer-NAT

Setter du en fase 1-levetid på 24 timer på fjernenheten, blir Cloud VPN-tunnelen liggende nede selv om alt på Googles side er riktig konfigurert. Peeren foreslår en verdi som responsøren ikke vil godta, og dermed feiler forhandlingen enten helt eller starter på nytt i det uendelige. Cloud VPN begrenser fase 1 til 36,000 sekunder, altså ti timer, og denne grensen er ikke en innstilling du kan skru opp. Endringen hører hjemme på fjernenheten.

Peeren spør, responsøren bestemmer

IKE er en øvelse i å matche to sett med forslag. Tunnelen dannes bare der settene overlapper innenfor de grensene responsøren godtar, og derfor gir en levetid utenfor området ingen delvis tunnel i det hele tatt. Den vanlige feilen er å behandle konfigurasjonen til peeren som en ønskeliste i stedet for et forslag. Et tomt snitt lar tunnelen bli liggende nede, uansett hvor riktig rutingen og selektorene er.

Les tilstanden til selve tunnelen før du åpner en sak, for den detaljerte statusen angir vanligvis fasen som feilet:

gcloud compute vpn-tunnels describe office-tunnel \
  --region europe-west1 \
  --format="value(status,detailedStatus)"

Sammenlign det som kommer tilbake med det støttede settet for gateway-typen og IKE-versjonen din, og noter begge trafikkselektorene mens du er der. Uoverensstemmelse i en selektor gir samme symptom på en tunnel som ligger nede som uoverensstemmelse i en algoritme, og i motsetning til algoritmen er det denne du må rette.

36,000 sekunder er taket

Fase 1 stopper ved 36,000 sekunder. En enhet som er satt til 86,400 ber om noe responsøren aldri vil godta, og nye forsøk endrer ikke oppfatningen hans. Skru det fjerne forslaget tilbake innenfor området, og samme konfigurasjon blir etablert; asymmetrien er hele poenget, siden du kan senke din egen verdi men ikke heve Googles.

Skriv den valgte verdien inn i designnotatene. Hvis ikke gjentar den neste ingeniøren 24-timersforsøket og treffer den samme veggen.

Det støttede settet publiseres per gateway-type og IKE-versjon i Cloud VPN-oversikten, så les avsnittet for din topologi framfor en generell IKE-veiledning.

En tunnel som faller etter en tidsplan

Fase 2 oppfører seg annerledes: når de to endene er uenige, følger nøkkelfornyelsen det korteste intervallet. En peer som ser på uoverensstemmelsen som fatal, slipper tunnelen i stedet, slik at én uoverensstemmelse kan se ut som to urelaterte feil. Se på rytmen i nøkkelfornyelsen, ikke bare den første tilkoblingen. En tunnel som kommer opp og deretter faller i jevnt tempo, er oftere en levetidsuoverensstemmelse enn en rutingfeil.

Koble de falltidspunktene mot peerens egne logger før du endrer noe, siden en selektor- eller ruteendring kan etterligne samme rytme. Passer takten med fase 2-timeren, er årsaken funnet uten å røre et forslag.

Settene kommer fra gateway-typen

Cipher- og integritetssett er ikke en profil per tunnel som du redigerer slik strongSwan tillater. Du velger dem etter gateway-type og IKE-versjon, og å lete etter en profil som ikke finnes koster en ettermiddag.

En eldre enhet som ikke tilbyr noe innenfor det støttede settet, etterlater to ærlige veier: bytt ut enheten, eller avslutt på en programvaregateway du selv kontrollerer og rut derfra inn i VPC-en. Alt annet er en omvei som ikke holder i neste gjennomgang.

Én ekstern adresse per enhet

Den eksterne adressen til peeren må mappes en-til-en til dens interne adresse. En overbelastet PAT-pool kan ikke fungere, fordi flere verter bak én enkelt offentlig adresse ikke gir responsøren noen måte å skille dem på. Der flere verter må dele en adresse, må tunnelen ende et sted som kan skille dem.

Hold også den eksterne adressen stabil. Flytter du enheten bak en annen NAT, brytes tilknytningen selv om hvert forslag fortsatt passer. Det er verdt å skrive ned hvilke verdier som er Googles og hvilke som er dine: levetider, sett og en-til-en NAT er faste på deres side, mens forslag, selektorer, ruting og BGP-prioriteter er dine.