Cloud VPN-grænser, du ikke kan justere: IKE-levetid og peer-NAT

Giv fjernemheden en fase 1-levetid på 24 timer, og Cloud VPN-tunnelen bliver nede, selv om alt på Googles side er konfigureret korrekt. Peer'en foreslår en værdi, som responder'en ikke vil acceptere, så forhandlingen fejler enten helt eller genstarter i det uendelige. Cloud VPN begrænser fase 1 til 36,000 sekunder, ti timer, og den grænse er ikke en indstilling, du kan hæve. Ændringen hører til på fjernemheden.

Peer'en spørger, responder'en beslutter

IKE er en matchningsøvelse mellem to sæt forslag. Tunnelen dannes kun, hvor sættene overlapper inden for de grænser, responder'en accepterer, og derfor giver en levetid uden for intervallet slet ingen delvis tunnel. Den sædvanlige fejl er at behandle peer'ens konfiguration som en ønskeliste i stedet for et forslag. Et tomt snit lader tunnelen være nede, uanset hvor korrekt routing og selectors er.

Læs tunnelens egen tilstand, før du åbner en sag, for den detaljerede status navngiver normalt det trin, der fejlede:

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

Sammenlign det, der kommer tilbage, med det understøttede sæt for din gateway-type og IKE-version, og notér begge trafik-selectors, mens du er der. Uoverensstemmelse i en selector giver samme symptom på en nede tunnel som uoverensstemmelse i en algoritme, og i modsætning til algoritmen er den her din at rette.

36,000 sekunder er loftet

Fase 1 stopper ved 36,000 sekunder. En enhed sat til 86,400 beder om noget, som responder'en aldrig vil acceptere, og gentagne forsøg ændrer ikke dens mening. Skru det fjernede forslag tilbage inden for intervallet, og samme konfiguration etableres; asymmetrien er hele lektionen, for du kan sænke din egen værdi og kan ikke hæve Googles.

Skriv den valgte værdi i designnoterne. Ellers gentager den næste ingeniør 24-timers-eksperimentet og rammer den samme mur.

Det understøttede sæt offentliggøres pr. gateway-type og IKE-version i Cloud VPN-oversigten, så læs afsnittet for din topologi i stedet for en generel IKE-guide.

En tunnel, der falder efter en tidsplan

Fase 2 opfører sig anderledes: når de to ender er uenige, følger genindlæsning af nøgler det kortere interval. En peer, der behandler uoverensstemmelsen som fatal, dropper i stedet tunnelen, så én uoverensstemmelse kan se ud som to uafhængige fejl. Hold øje med rytmen for nøglefornyelse, ikke kun den første forbindelse. En tunnel, der kommer op og derefter falder i en regelmæssig takt, er oftere en levetidsuoverensstemmelse end en routingfejl.

Korrelér de fald-tidsstempler med peer'ens egne logfiler, før du ændrer noget, for en selector- eller ruteændring kan efterligne den samme rytme. Hvis takten passer til fase 2-timeren, er årsagen fundet uden at røre et forslag.

Sættene kommer fra gateway-typen

Cipher- og integritetssæt er ikke en profil pr. tunnel, du redigerer, som strongSwan lader dig. Du vælger dem efter gateway-type og IKE-version, og at jagte en profil, der ikke findes, spilder en eftermiddag.

En ældre enhed, der ikke tilbyder noget inden for det understøttede sæt, efterlader to ærlige veje: udskift enheden, eller terminér på en softwaregateway, du kontrollerer, og rut derfra ind i VPC'en. Alt andet er en omvej, der fejler den næste gennemgang.

Én ekstern adresse pr. enhed

Peer'ens eksterne adresse skal mappes en-til-en til dens interne adresse. En overbelastet PAT-pulje kan ikke fungere, fordi flere værter bag en enkelt offentlig adresse ikke giver responder'en nogen måde at skelne dem på. Hvor flere værter skal dele en adresse, skal tunnelen ende et sted, der kan skelne dem.

Hold også den eksterne adresse stabil. Flyt enheden bag en anden NAT, og tilknytningen bryder, selv om hvert forslag stadig matcher. Det er værd at skrive ned, hvilke værdier der er Googles, og hvilke der er dine: levetider, sæt og en-til-en NAT er faste på deres side, mens forslag, selectors, routing og BGP-prioriteter er dine.