Cloud VPN-gränser du inte kan justera: IKE-livstid och peer-NAT

Ge fjärrenheten en fas 1-livstid på 24 timmar och Cloud VPN-tunneln ligger kvar nere, även om allt på Googles sida är korrekt konfigurerat. Peeren föreslår ett värde som respondern inte accepterar, så förhandlingen misslyckas antingen helt eller startar om i oändlighet. Cloud VPN begränsar fas 1 till 36,000 sekunder, tio timmar, och den gränsen är inte en inställning du kan höja. Ändringen hör hemma på fjärrenheten.

Peeren frågar, respondern bestämmer

IKE är en matchningsövning mellan två förslagsset. Tunneln bildas bara där seten överlappar inom de gränser som respondern accepterar, och därför ger en livstid utanför intervallet ingen delvis tunnel alls. Det vanliga misstaget är att behandla peerens konfiguration som en önskelista i stället för som ett förslag. En tom snittmängd låter tunneln ligga nere, hur korrekt routningen och väljarna än är.

Läs tunnelns eget tillstånd innan du öppnar ett ärende, eftersom den detaljerade statusen oftast namnger fasen som misslyckades:

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

Jämför det som kommer tillbaka med den uppsatta mängden för din gateway-typ och IKE-version, och anteckna båda trafikväljarna medan du är där. En väljaravvikelse ger samma symptom på en nere tunnel som en algoritmavvikelse, och till skillnad från algoritmen är den här din att åtgärda.

36,000 sekunder är taket

Fas 1 stannar vid 36,000 sekunder. En enhet inställd på 86,400 begär något som respondern aldrig kommer att gå med på, och ett nytt försök ändrar inte dess uppfattning. Skruva tillbaka fjärrförslaget inom intervallet och samma konfiguration upprättas; asymmetrin är hela lärdomen, eftersom du kan sänka ditt eget värde men inte höja Googles.

Skriv det valda värdet i designanteckningarna. Annars upprepar nästa ingenjör 24-timmarsförsöket och träffar samma vägg.

Den uppsatta mängden publiceras per gateway-typ och IKE-version i Cloud VPN-översikten, så läs avsnittet för din topologi i stället för en allmän IKE-guide.

En tunnel som faller enligt ett schema

Fas 2 beter sig annorlunda: när de två ändarna inte är överens följer nyckelbytet det kortare intervallet. En peer som behandlar avvikelsen som fatal släpper i stället tunneln, så en avvikelse kan se ut som två oberoende fel. Håll koll på rytmen i nyckelbytet, inte bara den första anslutningen. En tunnel som kommer upp och sedan faller i jämn takt är oftare en livstidsavvikelse än ett routingfel.

Korrelera de falltidsstämplarna med peerens egna loggar innan du ändrar något, eftersom en väljar- eller ruttändring kan härma samma rytm. Om takten stämmer med fas 2-timern är orsaken hittad utan att röra ett förslag.

Seten kommer från gateway-typen

Cipher- och integritetsseten är inte en profil per tunnel som du redigerar så som strongSwan tillåter. Du väljer dem efter gateway-typ och IKE-version, och att jaga en profil som inte finns slösar bort en eftermiddag.

En äldre enhet som inte erbjuder något inom den uppsatta mängden lämnar två ärliga vägar: byt ut enheten, eller avsluta på en programvarugateway som du kontrollerar och routa därifrån in i VPC:n. Allt annat är en kringgång som faller i nästa granskning.

En extern adress per enhet

Peerens externa adress måste mappas en-till-en till dess interna adress. En överbelastad PAT-pool kan inte fungera, eftersom flera värdar bakom en enda offentlig adress inte ger respondern något sätt att skilja dem åt. Där flera värdar måste dela en adress måste tunneln sluta någonstans som kan skilja dem åt.

Håll också den externa adressen stabil. Flytta enheten bakom en annan NAT och kopplingen bryts trots att varje förslag fortfarande matchar. Det är värt att skriva ner vilka värden som är Googles och vilka som är dina: livstider, set och en-till-en-NAT är fasta på deras sida, medan förslag, väljare, routning och BGP-prioriteter är dina.