Cloud VPN ribos, kurių negalima sureguliuoti: IKE trukmė ir peer NAT

Suteikite nuotoliniam įrenginiui 24 valandų 1-osios fazės trukmę ir Cloud VPN tunelis liks išjungtas, nors Google pusėje viskas sukonfigūruota teisingai. Peer siūlo reikšmę, kurios atsakiklis nepriims, todėl derybos arba visiškai žlunga, arba prasideda iš naujo be galo. Cloud VPN riboja 1-ąją fazę iki 36,000 sekundžių, tai yra dešimt valandų, ir ši riba nėra nustatymas, kurį galėtumėte pakelti. Pakeitimas priklauso nuotoliniam įrenginiui.

Peer klausia, atsakiklis nusprendžia

IKE yra dviejų pasiūlymų rinkinių suderinimo pratimas. Tunelis susidaro tik ten, kur rinkiniai persidengia atsakiklio priimamose ribose, todėl už diapazono esanti trukmė nesukuria jokio dalinio tunelio. Įprasta klaida yra traktuoti peer konfigūraciją kaip pageidavimų sąrašą, o ne kaip pasiūlymą. Tuščia sankirta palieka tunelį išjungtą, kad ir kokie teisingi būtų maršrutizavimas ir selektoriai.

Prieš atidarydami atvejį perskaitykite paties tunelio būseną, nes išsami būsena paprastai įvardija nepavykusį etapą:

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

Palyginkite tai, kas grįžta, su palaikomu rinkiniu jūsų šliuzo tipui ir IKE versijai, ir ten būdami užrašykite abu srauto selektorius. Selektoriaus neatitikimas duoda tuos pačius tunelio išjungimo simptomus kaip algoritmo neatitikimas, ir, skirtingai nei algoritmas, šį turite sutvarkyti patys.

36,000 sekundžių yra lubos

1-oji fazė sustoja ties 36,000 sekundžių. Įrenginys, nustatytas 86,400, prašo to, su kuo atsakiklis niekada nesutiks, o kartojimas nekeičia jo nuomonės. Grąžinkite nuotolinį pasiūlymą į diapazoną ir ta pati konfigūracija užsimezga; asimetrija yra visa pamoka, nes savo reikšmę galite sumažinti, o Google reikšmės padidinti negalite.

Įrašykite pasirinktą reikšmę į projektavimo pastabas. Priešingu atveju kitas inžinierius pakartos 24 valandų eksperimentą ir atsitrenks į tą pačią sieną.

Palaikomas rinkinys skelbiamas pagal šliuzo tipą ir IKE versiją Cloud VPN apžvalgoje, todėl skaitykite savo topologijos skyrių, o ne bendrą IKE vadovą.

Tunelis, kuris krenta pagal grafiką

2-oji fazė elgiasi kitaip: kai du galai nesutaria, raktų atnaujinimas seka trumpesnį intervalą. Peer, kuris neatitikimą laiko mirtinu, vietoj to numeta tunelį, todėl vienas neatitikimas gali atrodyti kaip du nesusiję gedimai. Stebėkite raktų atnaujinimo ritmą, ne tik pirmąjį prisijungimą. Tunelis, kuris pakyla ir paskui krenta reguliariu taktu, dažniau yra trukmės neatitikimas nei maršrutizavimo defektas.

Prieš ką nors keisdami susiekite tuos kritimo laiko žymenis su paties peer žurnalais, nes selektoriaus ar maršruto pakeitimas gali imituoti tą patį ritmą. Jei taktas sutampa su 2-osios fazės timeriu, priežastis rasta neliečiant pasiūlymo.

Rinkiniai kyla iš šliuzo tipo

Šifravimo ir vientisumo rinkiniai nėra profilis vienam tuneliui, kurį redaguotumėte kaip leidžia strongSwan. Juos renkatės pagal šliuzo tipą ir IKE versiją, o neegzistuojančio profilio paieška praranda popietę.

Senas įrenginys, kuris nieko nesiūlo palaikomo rinkinio viduje, palieka du sąžiningus kelius: pakeiskite įrenginį arba užbaikite programiniame šliuze, kurį kontroliuojate, ir iš ten maršrutizuokite į VPC. Visa kita yra apeinamasis sprendimas, kuris žlugs kitos peržiūros metu.

Vienas išorinis adresas vienam įrenginiui

Peer išorinis adresas turi atitikti jo vidinį adresą vienas-su-vienu. Perkrauta PAT talpykla negali veikti, nes keli pagrindiniai kompiuteriai už vieno viešo adreso nesuteikia atsakikliui jokio būdo jų atskirti. Kai keli pagrindiniai kompiuteriai turi dalytis adresu, tunelis turi baigtis ten, kur juos galima atskirti.

Išlaikykite tą išorinį adresą stabiliu. Perkelkite įrenginį už kito NAT ir ryšys nutrūksta, nors kiekvienas pasiūlymas vis dar atitinka. Verta užrašyti, kurios reikšmės yra Google, o kurios jūsų: trukmės, rinkiniai ir vienas-su-vienu NAT yra fiksuoti jų pusėje, o pasiūlymai, selektoriai, maršrutizavimas ir BGP prioritetai yra jūsų.