Az IKEv2-töredezettség megkülönböztetése a tanúsítványlánc problémájától

Az alagút működött az irodai hálózaton, és otthon elakad, a napló pedig azt mutatja, hogy az első csere befejeződik, mielőtt bármi más történne. Ez a minta a hitelesítési cserére utal, nem a hitelesítő adatokra: a tanúsítványlánc sokkal nagyobbá teszi ezt az üzenetet az előzőnél, és egy nagy adatgrammokat nem kedvelő útvonal csendben eldobja. Két különböző töredezettségi mechanizmus van jelen, és annak tudása, melyiket látja, eldönti a javítást.

Két töredezettségi mechanizmus, egy tünet

Az IKEv2-nek saját töredezettségi kiterjesztése van, amelyet a RFC 7383 definiál, és a védett IKE-üzeneteket kisebb IKE-üzenetekre bontja. A felek tárgyalnak erről a képességről, és az üzenetet az IKE megvalósítása állítja össze újra, nem az IP-réteg.

A hagyományos IP-töredezettség más mechanizmus, más hibaüzemmóddal. A felek közötti útválasztó feldarabol egy nagy adatgrammot, vagy eldobja, és olyan ICMP-üzenetet küld vissza, amely talán soha nem ér el a feladóhoz. Egyes hálózatok csendben eldobják a töredékeket, és egyes köztes eszközök kezelik az első töredéket, de a többit nem. Az alkalmazás szemszögéből mindhárom eset azonosnak tűnik.

A NAT-átjárás egy harmadik változót ad hozzá, mert ilyenkor az ESP UDP-be csomagolódik, és a külső csomag nagyobb lesz, miközben a 4500-as porton szokásos UDP-forgalomnak látszik. Egy útvonal, amely jól átengedi az UDP-t, még mindig meghiúsulhat egy olyan adatgrammon, amely már nem fér bele.

Olvassa el a meghiúsult cserét

A hiba helyett az átmenetet keresse. Az a napló, amely az első cserét elküldöttként és megválaszoltként mutatja, majd semmit, azt mondja, hogy a következő üzenet soha nem fejeződött be. Ideiglenesen emelje a naplózási szintet, és hasonlítsa össze a jelentett méreteket mindkét félen.

Azt szeretné megállapítani, hogy a válaszadó egyáltalán látta-e a kérést. Ha a kezdeményező küldött valamit, és a válaszadónak nincs erről semmilyen nyilvántartása, a probléma a kézbesítés. Ha a válaszadó elemezte a kérést és elutasította, maga a tanúsítvány a probléma, és a töredezettség elterelés. Ez a megkülönböztetés többet ér egy oldal időtúllépési üzenetnél.

Az útvonalat változtassa, ne a tanúsítványt

Tesztelje ugyanazt az ügyfelet, ugyanazt a tanúsítványt és ugyanazt a konfigurációt egy másik hálózatról. A mobil hotspot általában a legolcsóbb második útvonal, és valóban különbözik az irodai kapcsolattól, nem csak névleg.

Ha a kézfogás a második útvonalon befejeződik, a tanúsítványlánc rendben van, és az első útvonal a változó. Ha mindkettőn azonosan meghiúsul, hagyja abba a hálózatok tesztelését, és nézze meg magukat az üzeneteket. Ez az egyetlen összehasonlítás a lehetséges magyarázatok mintegy felét kizárja.

Mérje meg a cserét, mielőtt bármit szerkesztene

Szerezze meg a lánc méretét és az útvonal méretét. Mindkét szám korlátozza, mit küldhet a kézfogás, és mindkettő olcsón mérhető:

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'

Az első kettő a tanúsítványok számát és a fájlméretet adja, ami ésszerű mutató arra, mekkora lesz a hitelesítési üzenet. A ping-próba jelenti, hogy egy ekkora adatgramm túléli-e az útvonalat, az interfész-számlálók pedig megmutatják, hogy az Ön oldalán eldobták-e a töredékeket. Windowson az egyenértékű próba egy ping a do-not-fragment kapcsolóval és kifejezett hasznos teher mérettel.

Ismételje a próbát lefelé, amíg nem sikerül. A legnagyobb átmenő méret az adott útvonal munkaköltségvetése, és hasznosabb bármely közzétett alapértéknél.

A valóban törött réteget javítsa

Ha az útvonal eldobja a nagy adatgrammokat, engedélyezze az IKE-töredezettséget mindkét félen, és erősítse meg, hogy a kiterjesztést megtárgyalták, nem csak felajánlották. Ha az útvonal az IP-szinten rosszul kezeli a töredékeket, a javítás oda vagy a külső interfész MTU-jába tartozik, nem a tanúsítványtárba.

Ha a lánc szükségtelenül hosszú, rövidítse le azokra a köztes tanúsítványokra, amelyekre egy félnek valóban szüksége van. Egy olyan gyökér eltávolítása, amelyben az ügyfél már megbízik, ésszerű karbantartás; egy köztes eltávolítása nem az, és az ellenőrzés kikapcsolása egy üzenet kicsinyítéséért a kézbesítési problémát biztonsági problémára cseréli.

Írja le, melyik mechanizmust változtatta meg, és hogyan nézett ki utána a kézfogás. A következő előfordulás általában egy másik hálózaton történik ugyanazzal a tünettel, és a feljegyzés az, ami két órát tíz perccé tesz.