Limity Cloud VPN, ktoré nenastavíte: životnosť IKE a NAT protistrany

Dajte vzdialenému zariadeniu životnosť fázy 1 24 hodín a tunel Cloud VPN zostane dole, aj keď je na strane Google všetko správne nakonfigurované. Peer navrhuje hodnotu, ktorú odpovedajúca strana neprijme, takže vyjednávanie buď úplne zlyhá, alebo sa donekonečna reštartuje. Cloud VPN obmedzuje fázu 1 na 36,000 sekúnd, teda desať hodín, a tento strop nie je nastavenie, ktoré by ste mohli zvýšiť. Zmena patrí vzdialenému zariadeniu.

Peer sa pýta, odpovedajúca strana rozhoduje

IKE je cvičenie zhody medzi dvoma sadami návrhov. Tunel vznikne len tam, kde sa sady prekrývajú v medziach, ktoré odpovedajúca strana prijíma, a preto životnosť mimo rozsahu nevytvorí vôbec žiadny čiastočný tunel. Zvyčajnou chybou je brať konfiguráciu peera ako zoznam želaní, nie ako návrh. Prázdny prienik nechá tunel dole, nech je smerovanie a selektory akokoľvek správne.

Prečítajte si vlastný stav tunela, skôr než otvoríte prípad, pretože podrobný stav zvyčajne pomenuje fázu, ktorá zlyhala:

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

Porovnajte, čo sa vráti, s podporovanou sadou pre váš typ brány a verziu IKE a oba selektory prevádzky si tam rovno zapíšte. Nezhoda selektora dáva rovnaký príznak tunela dole ako nezhoda algoritmu, a na rozdiel od algoritmu je táto na vás.

36,000 sekúnd je strop

Fáza 1 sa zastaví na 36,000 sekundách. Zariadenie nastavené na 86,400 žiada niečo, s čím odpovedajúca strana nikdy nebude súhlasiť, a opakovanie pokusu jej názor nezmení. Vráťte vzdialený návrh do rozsahu a rovnaká konfigurácia sa nadviaže; asymetria je celá lekcia, pretože svoju hodnotu znížiť môžete, ale hodnotu Google zvýšiť nemôžete.

Zapíšte zvolenú hodnotu do poznámok k návrhu. Inak ďalší inžinier zopakuje experiment s 24 hodinami a narazí na tú istú stenu.

Podporovaná sada sa zverejňuje pre každý typ brány a verziu IKE v prehľade Cloud VPN, takže čítajte časť pre svoju topológiu, nie všeobecného sprievodcu IKE.

Tunel, ktorý padá podľa rozvrhu

Fáza 2 sa správa inak: keď sa oba konce nezhodnú, obnova kľúčov nasleduje kratší interval. Peer, ktorý nezhodu považuje za fatálnu, tunel radšej zhodí, takže jedna nezhoda môže vyzerať ako dve nesúvisiace poruchy. Sledujte rytmus obnovy kľúčov, nielen prvé pripojenie. Tunel, ktorý naskočí a potom padá v pravidelnom takte, je častejšie nezhoda životnosti než porucha smerovania.

Tie časové značky pádov prepojte s vlastnými logmi peera, skôr než čokoľvek upravíte, pretože zmena selektora alebo trasy môže rovnaký rytmus napodobniť. Ak takt zodpovedá časovaču fázy 2, príčina je nájdená bez zásahu do návrhu.

Sady vychádzajú z typu brány

Sady šifrovania a integrity nie sú profil pre jednotlivý tunel, ktorý by ste upravovali, ako to umožňuje strongSwan. Vyberiete ich podľa typu brány a verzie IKE a hľadanie profilu, ktorý neexistuje, stratí celé popoludnie.

Staršie zariadenie, ktoré v podporovanej sade neponúka nič, necháva dve poctivé cesty: zariadenie vymeniť, alebo ukončiť na softvérovej bráne, ktorú ovládate, a odtiaľ smerovať do VPC. Čokoľvek iné je obchádzka, ktorá neprejde najbližšou revíziou.

Jedna externá adresa na zariadenie

Externá adresa peera sa musí mapovať jedna-ku-jednej na jeho internú adresu. Preťažený fond PAT nemôže fungovať, pretože niekoľko hostiteľov za jedinou verejnou adresou nedáva odpovedajúcej strane žiadny spôsob, ako ich oddeliť. Tam, kde sa musí niekoľko hostiteľov deliť o adresu, musí tunel končiť niekde, kde ich dokážu rozlíšiť.

Udržujte tú externú adresu tiež stabilnú. Presuňte zariadenie za iný NAT a spojenie sa preruší, aj keď každý návrh stále sedí. Stojí za to zapísať si, ktoré hodnoty sú Googlu a ktoré vaše: životnosti, sady a NAT jedna-ku-jednej sú pevné na ich strane, zatiaľ čo návrhy, selektory, smerovanie a priority BGP sú vaše.