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

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

Peeren spør, responsøren bestemmer

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

Les tunnelens egen tilstand før du åpner en sak, for den detaljerte statusen navngir 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 nede tunnel som uoverensstemmelse i en algoritme, og i motsetning til algoritmen er denne din å rette.

36,000 sekunder er taket

Fase 1 stopper ved 36,000 sekunder. En enhet satt til 86,400 ber om noe responsøren aldri vil godta, og gjentatte forsøk endrer ikke meningen hans. Skru det fjernede forslaget tilbake innenfor området, og samme konfigurasjon etableres; asymmetrien er hele leksen, for du kan senke din egen verdi og kan ikke heve Googles.

Skriv den valgte verdien i designnotatene. Ellers gjentar den neste ingeniøren 24-timers-eksperimentet og treffer samme vegg.

Det støttede settet publiseres per gateway-type og IKE-versjon i Cloud VPN-oversikten, så les avsnittet for din topologi i stedet for 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 kortere intervallet. En peer som behandler uoverensstemmelsen som fatal, slipper i stedet tunnelen, så én uoverensstemmelse kan se ut som to uavhengige feil. Følg med på rytmen i nøkkelfornyelsen, ikke bare den første tilkoblingen. En tunnel som kommer opp og deretter faller i jevn takt, er oftere en levetidsuoverensstemmelse enn en rutingfeil.

Korreler disse falltidspunktene med peerens egne logger før du endrer noe, for en selektor- eller ruteendring kan etterligne samme rytme. Hvis takten passer 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 lar deg. Du velger dem etter gateway-type og IKE-versjon, og å jakte på en profil som ikke finnes sløser bort 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 kontrollerer og rut derfra inn i VPC-en. Alt annet er en omvei som feiler i neste gjennomgang.

Én ekstern adresse per enhet

Peerens eksterne adresse 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. Flytt enheten bak en annen NAT, og tilknytningen brytes 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.