Jak rozeznat fragmentaci IKEv2 od problému s řetězem certifikátů

Tunel fungoval v kancelářské síti a doma se zasekává, a log ukazuje, že první výměna skončí, než se stane cokoli dalšího. Tento vzorec ukazuje na autentizační výměnu, ne na přihlašovací údaje: řetěz certifikátů dělá tuto zprávu mnohem větší než předchozí a cesta, která nemá ráda velké datagramy, ji tiše zahodí. Zapojeny jsou dva různé mechanismy fragmentace a vědomí, na který se díváte, rozhoduje o opravě.

Dva mechanismy fragmentace, jeden symptom

IKEv2 má vlastní rozšíření fragmentace definované v RFC 7383, které dělí chráněné zprávy IKE na menší zprávy IKE. Protistrany o tuto schopnost vyjednávají a zprávu znovu skládá implementace IKE, nikoli IP vrstva.

Běžná IP fragmentace je jiný mechanismus s jiným režimem selhání. Router mezi protistranami fragmentuje velký datagram, nebo jej zahodí a vrátí zprávu ICMP, která se k odesílateli nemusí nikdy dostat. Některé sítě fragmenty tiše zahazují a některá mezilehlá zařízení zpracují první fragment, ale ne zbytek. Z pohledu aplikace vypadají všechny tři případy stejně.

Průchod NAT přidává třetí proměnnou, protože ESP se pak obaluje do UDP a vnější paket se zvětší, přitom vypadá jako běžný provoz UDP na portu 4500. Cesta, která UDP propouští dobře, může stále selhat na datagramu, který se už nevejde.

Přečtěte si výměnu, která selhala

Hledejte přechod, ne chybu. Log, který ukazuje odeslání a odpověď počáteční výměny a poté nic, vám říká, že následující zpráva nikdy nedokončila. Dočasně zvyšte úroveň logu a porovnejte hlášené velikosti na obou stranách.

Chcete zjistit, zda protistrana požadavek vůbec viděla. Pokud iniciátor něco odeslal a protistrana o tom nemá žádný záznam, problém je v doručení. Pokud protistrana požadavek rozebrala a odmítla, problém je v samotném certifikátu, a fragmentace je rozptýlení. Toto rozlišení má větší cenu než stránka zpráv o vypršení časového limitu.

Změňte cestu, ne certifikát

Otestujte stejného klienta, stejný certifikát a stejnou konfiguraci z jiné sítě. Mobilní hotspot je obvykle nejlevnější druhá cesta a skutečně se liší od kancelářského spoje, ne jen nominálně.

Pokud handshake na druhé cestě skončí, řetěz certifikátů je v pořádku a proměnnou je první cesta. Pokud selže stejně na obou, přestaňte testovat sítě a podívejte se na samotné zprávy. Toto jediné srovnání odstraní asi polovinu možných vysvětlení.

Změřte výměnu, než cokoli upravíte

Získejte velikost řetězu a velikost cesty. Obě čísla omezují, co handshake může odeslat, a obě se dají levně změřit:

openssl crl2pkcs7 -nocrl -certfile chain.pem | openssl pkcs7 -print_certs -noout | grep -c subject
ls -l chain.pem
ping -M do -s 1400 198.51.100.7
ip -s link show eth0 | sed -n '1,6p'

První dvě dávají počet certifikátů a velikost souboru, což je rozumný ukazatel toho, jak velká autentizační zpráva bude. Sonda ping hlásí, zda datagram této velikosti cestu přežije, a čítače rozhraní ukazují, zda byly fragmenty zahozeny na vaší straně. Ve Windows je ekvivalentní sondou ping s příznakem do-not-fragment a výslovnou velikostí užitečného zatížení.

Opakujte sondu směrem dolů, dokud neuspěje. Největší velikost, která projde, je pracovní rozpočet pro danou cestu a je užitečnější než jakákoli zveřejněná výchozí hodnota.

Opravte vrstvu, která je skutečně rozbitá

Pokud cesta zahazuje velké datagramy, zapněte fragmentaci IKE na obou stranách a potvrďte, že rozšíření bylo vyjednáno, ne jen nabídnuto. Pokud cesta zachází s fragmenty na úrovni IP špatně, oprava patří tam nebo do MTU vnějšího rozhraní, ne do úložiště certifikátů.

Pokud je řetěz zbytečně dlouhý, zkraťte jej na zprostředkující certifikáty, které protistrana skutečně potřebuje. Odebrání kořene, kterému klient už důvěřuje, je rozumná údržba; odebrání zprostředkujícího ne, a vypnutí ověřování kvůli zmenšení zprávy mění problém doručení za problém bezpečnosti.

Zapište, který mechanismus jste změnili a jak handshake potom vypadal. Příští výskyt bývá v jiné síti se stejným symptomem a poznámka je to, co dvě hodiny promění v deset minut.