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

Gje fjerneninga ei fase 1-levetid på 24 timar, og Cloud VPN-tunnelen blir liggjande nede sjølv om alt på sida til Google er rett konfigurert. Peeren føreslår ein verdi responsøren ikkje vil godta, så forhandlinga feilar anten heilt eller startar på nytt i det uendelege. Cloud VPN avgrensar fase 1 til 36,000 sekund, ti timar, og denne grensa er ikkje ei innstilling du kan heve. Endringa høyrer heime på fjerneninga.

Peeren spør, responsøren bestemmer

IKE er ei matcheøving mellom to forslagssett. Tunnelen blir berre danna der setta overlappar innanfor grensene responsøren godtek, og difor gir ei levetid utanfor området ingen delvis tunnel i det heile. Den vanlege feilen er å handsame konfigurasjonen til peeren som ei ønskeliste i staden for eit forslag. Eit tomt snitt lèt tunnelen liggje nede, uansett kor rett rutinga og selektorane er.

Les tilstanden til sjølve tunnelen før du opnar ei sak, for den detaljerte statusen nemner vanlegvis fasen som feila:

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

Samanlikn det som kjem tilbake med det støtta settet for gateway-typen og IKE-versjonen din, og noter båe trafikkselektorane medan du er der. Uoverenskomst i ein selektor gir same symptomet på ein tunnel som ligg nede som uoverenskomst i ein algoritme, og i motsetnad til algoritmen er denne din å rette.

36,000 sekund er taket

Fase 1 stoggar ved 36,000 sekund. Eininga som er sett til 86,400 ber om noko responsøren aldri vil godta, og gjentekne forsøk endrar ikkje meininga hans. Skru det fjernaste forslaget tilbake innanfor området, og same konfigurasjonen blir etablert; asymmetrien er heile lærdomen, for du kan senke din eigen verdi og kan ikkje heve den til Google.

Skriv den valde verdien i designnotata. Elles gjer den neste ingeniøren om 24-timars-eksperimentet og treffer same veggen.

Det støtta settet blir publisert per gateway-type og IKE-versjon i Cloud VPN-oversynet, så les avsnittet for topologien din i staden for ein generell IKE-vegvisar.

Ein tunnel som fell etter ein tidsplan

Fase 2 oppfører seg annleis: når dei to endane er usamde, følgjer nøkkelfornyinga det kortare intervallet. Ein peer som handsamar uoverenskomsten som fatal, slepp i staden tunnelen, så éin uoverenskomst kan sjå ut som to uavhengige feil. Følg med på rytmen i nøkkelfornyinga, ikkje berre den første tilkoplinga. Ein tunnel som kjem opp og deretter fell i jamn takt, er oftare ein levetidsuoverenskomst enn ein rutingfeil.

Korreler desse falltidspunkta med loggane til peeren sjølv før du endrar noko, for ei selektor- eller ruteendring kan etterlikne same rytmen. Viss takten passar med fase 2-timeren, er årsaka funnen utan å røre eit forslag.

Setta kjem frå gateway-typen

Cipher- og integritetssett er ikkje ein profil per tunnel som du redigerer slik strongSwan lèt deg. Du vel dei etter gateway-type og IKE-versjon, og å jage etter ein profil som ikkje finst sløser bort ein ettermiddag.

Ei eldre eining som ikkje tilbyd noko innanfor det støtta settet, lèt etter seg to ærlege vegar: byt ut eininga, eller avslutt på ein programvaregateway du kontrollerer og rut derifrå inn i VPC-en. Alt anna er ein omveg som feilar i neste gjennomgang.

Éin ekstern adresse per eining

Den eksterne adressa til peeren må mappast ein-til-ein til den interne adressa hans. Ein overbelasta PAT-pool kan ikkje fungere, fordi fleire vertar bak éi einskild offentleg adresse ikkje gir responsøren nokon måte å skilje dei på. Der fleire vertar må dele ei adresse, må tunnelen enda på ein stad som kan skilje dei.

Hald òg den eksterne adressa stabil. Flytt eininga bak ein annan NAT, og tilknytinga blir broten sjølv om kvart forslag framleis passar. Det er verdt å skrive ned kva verdiar som er Google sine og kva som er dine: levetider, sett og ein-til-ein NAT er faste på deira side, medan forslag, selektorar, ruting og BGP-prioritetar er dine.