Omejitve Cloud VPN, ki jih ni mogoče nastaviti: življenjska doba IKE in NAT peera

Oddaljeni napravi dajte življenjsko dobo faze 1 24 ur in tunel Cloud VPN ostane spodaj, čeprav je na strani Google vse pravilno konfigurirano. Peer predlaga vrednost, ki je odgovarjalec ne bo sprejel, zato pogajanje bodisi popolnoma propade bodisi se neskončno znova začne. Cloud VPN omejuje fazo 1 na 36,000 sekund, torej deset ur, in ta zgornja meja ni nastavitev, ki bi jo lahko dvignili. Sprememba sodi na oddaljeno napravo.

Peer vpraša, odgovarjalec odloči

IKE je vaja ujemanja med dvema nizoma predlogov. Tunel nastane le tam, kjer se niza prekrivata znotraj meja, ki jih odgovarjalec sprejema, zato življenjska doba zunaj obsega ne ustvari nobenega delnega tunela. Običajna napaka je, da konfiguracijo peera obravnavate kot seznam želja in ne kot predlog. Prazen presek pusti tunel spodaj, ne glede na to, kako pravilna sta usmerjanje in selektorja.

Preden odprete primer, preberite stanje samega tunela, ker podroben status običajno navede fazo, ki je spodletela:

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

Primerjajte vrnjeno s podprtim nizom za vaš tip prehoda in različico IKE ter si tam zapišite oba selektorja prometa. Neujemanje selektorja da enak simptom tunela spodaj kot neujemanje algoritma, in za razliko od algoritma je to vaše, da popravite.

36,000 sekund je zgornja meja

Faza 1 se ustavi pri 36,000 sekundah. Naprava, nastavljena na 86,400, zahteva nekaj, s čimer se odgovarjalec ne bo nikoli strinjal, in ponovno poskušanje tega ne spremeni. Vrnite oddaljeni predlog v obseg in ista konfiguracija se vzpostavi; asimetrija je cela lekcija, saj svojo vrednost lahko znižate, Googleove pa ne morete dvigniti.

Izbrano vrednost zapišite v načrtovalske opombe. Sicer bo naslednji inženir ponovil poskus s 24 urami in naletel na isto steno.

Podprti niz je objavljen za vsak tip prehoda in različico IKE v pregledu Cloud VPN, zato preberite razdelek za svojo topologijo, ne splošnega vodnika po IKE.

Tunel, ki pada po urniku

Faza 2 se obnaša drugače: ko se oba konca ne strinjata, obnavljanje ključev sledi krajšemu intervalu. Peer, ki neujemanje šteje za usodno, tunel raje spusti, zato je eno neujemanje lahko videti kot dve nepovezani okvari. Spremljajte ritem obnavljanja ključev, ne le prve povezave. Tunel, ki se dvigne in nato pada v rednem taktu, je pogosteje neujemanje življenjske dobe kot napaka usmerjanja.

Te časovne žige padcev povežite z lastnimi dnevniki peera, preden karkoli spremenite, ker lahko sprememba selektorja ali poti posnema isti ritem. Če se takt ujema s časovnikom faze 2, je vzrok najden brez dotika predloga.

Nizi izhajajo iz tipa prehoda

Nizi za šifriranje in celovitost niso profil na tunel, ki bi ga urejali, kot to dovoljuje strongSwan. Izberete jih po tipu prehoda in različici IKE, iskanje neobstoječega profila pa zapravi popoldne.

Starejša naprava, ki v podprtem nizu ne ponuja ničesar, pusti dve pošteni poti: zamenjajte napravo ali zaključite na programskem prehodu, ki ga nadzorujete, in od tam usmerjajte v VPC. Vse drugo je obhod, ki ne bo prestal naslednjega pregleda.

En zunanji naslov na napravo

Zunanji naslov peera se mora preslikati ena-na-ena na njegov notranji naslov. Preobremenjen nabor PAT ne more delovati, ker več gostiteljev za enim javnim naslovom odgovarjalcu ne daje nobenega načina, da bi jih ločil. Kjer si mora več gostiteljev deliti naslov, se mora tunel končati nekje, kar jih lahko razlikuje.

Tudi ta zunanji naslov naj bo stabilen. Premaknite napravo za drug NAT in povezava se pretrga, čeprav se vsak predlog še vedno ujema. Vredno je zapisati, katere vrednosti so Googlove in katere vaše: življenjske dobe, nizi in NAT ena-na-ena so fiksni na njihovi strani, medtem ko so predlogi, selektorji, usmerjanje in prioritete BGP vaše.