Limity Cloud VPN, které nenastavíte: životnost IKE a NAT protistrany

Dejte vzdálenému zařízení životnost fáze 1 24 hodin a tunel Cloud VPN zůstane dole, i když je na straně Google vše správně nakonfigurované. Protistrana navrhuje hodnotu, kterou odpovídající strana nepřijme, takže vyjednávání buď úplně selže, nebo se donekonečna restartuje. Cloud VPN omezuje fázi 1 na 36,000 sekund, tedy deset hodin, a tento strop není nastavení, které byste mohli zvednout. Změna patří vzdálenému zařízení.

Protistrana se ptá, odpovídající strana rozhoduje

IKE je cvičení shody mezi dvěma sadami návrhů. Tunel vznikne jen tam, kde se sady překrývají v mezích, které odpovídající strana přijímá, a proto životnost mimo rozsah nevytvoří vůbec žádný částečný tunel. Obvyklou chybou je brát konfiguraci protistrany jako seznam přání, ne jako návrh. Prázdný průnik nechá tunel dole, ať je směrování a selektory jakkoli správné.

Přečtěte si vlastní stav tunelu, než otevřete případ, protože podrobný stav obvykle pojmenuje fázi, která selhala:

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

Porovnejte, co se vrátí, s podporovanou sadou pro váš typ brány a verzi IKE a oba selektory provozu si tam rovnou zapište. Neshoda selektoru dává stejný příznak tunelu dole jako neshoda algoritmu, a na rozdíl od algoritmu je tahle na vás.

36,000 sekund je strop

Fáze 1 se zastaví na 36,000 sekundách. Zařízení nastavené na 86,400 žádá něco, s čím odpovídající strana nikdy nebude souhlasit, a opakování pokusu její názor nezmění. Vraťte vzdálený návrh do rozsahu a stejná konfigurace se naváže; asymetrie je celá lekce, protože svou hodnotu snížit můžete, ale hodnotu Google zvýšit nemůžete.

Zapište zvolenou hodnotu do poznámek k návrhu. Jinak další inženýr zopakuje experiment s 24 hodinami a narazí na stejnou zeď.

Podporovaná sada se zveřejňuje pro každý typ brány a verzi IKE v přehledu Cloud VPN, takže čtěte část pro svou topologii, ne obecného průvodce IKE.

Tunel, který padá podle rozvrhu

Fáze 2 se chová jinak: když se oba konce neshodnou, obnova klíčů následuje kratší interval. Protistrana, která neshodu považuje za fatální, tunel raději shodí, takže jedna neshoda může vypadat jako dvě nesouvisející závady. Sledujte rytmus obnovy klíčů, ne jen první připojení. Tunel, který naskočí a pak padá v pravidelném taktu, je častěji neshoda životnosti než závada směrování.

Ty časové značky pádů propojte s vlastními logy protistrany, než cokoli upravíte, protože změna selektoru nebo trasy může stejný rytmus napodobit. Pokud takt odpovídá časovači fáze 2, příčina je nalezena bez zásahu do návrhu.

Sady vycházejí z typu brány

Sady šifrování a integrity nejsou profil pro jednotlivý tunel, který byste upravovali, jak to umožňuje strongSwan. Vyberete je podle typu brány a verze IKE a hledání profilu, který neexistuje, ztratí celé odpoledne.

Starší zařízení, které v podporované sadě nenabízí nic, nechává dvě poctivé cesty: zařízení vyměnit, nebo ukončit na softwarové bráně, kterou ovládáte, a odtud směrovat do VPC. Cokoli jiného je obchvat, který neprojde příští revizí.

Jedna externí adresa na zařízení

Externí adresa protistrany se musí mapovat jedna ku jedné na její interní adresu. Přetížený fond PAT nemůže fungovat, protože několik hostitelů za jedinou veřejnou adresou nedává odpovídající straně žádný způsob, jak je od sebe oddělit. Tam, kde se musí několik hostitelů dělit o adresu, musí tunel končit někde, kde je dokážou rozlišit.

Udržujte tu externí adresu také stabilní. Přesuňte zařízení za jiný NAT a spojení se přeruší, i když každý návrh stále sedí. Stojí za to zapsat si, které hodnoty jsou Googlu a které vaše: životnosti, sady a NAT jedna ku jedné jsou pevné na jejich straně, zatímco návrhy, selektory, směrování a priority BGP jsou vaše.