Az IKEv2 nem egyetlen kézfogás: IKE SA, hitelesítés, majd CHILD SA
Az átjáró válasza elérhetőséget bizonyít, nem identitást. Kövesd az IKE_SA_INIT, az IKE_AUTH és az első CHILD SA folyamatát, majd ellenőrizd, mi kell teljesüljön a forgalom indulása előtt.
Lehet, hogy azt hiszed, az IKEv2 kapcsolat egyetlen csere, amely a forgalom titkosításával ér véget. Legalább kettő, és az első senkit nem hitelesít. A felek vezérlőüzenetekkel kezdenek, megállapodnak a kriptográfiai paraméterekben, igazolják az identitásukat, és csak ezután tárgyalják meg az állapotot, amely az alkalmazáscsomagokat szállítja. Ez a sorrend magyarázza azt az ellentmondást, amelyről az emberek folyamatosan beszámolnak: az átjáró válaszol, a kliens kapcsolódottnak jelzi magát, a privát alkalmazás mégis időtúllép. Íme, mit tesz valójában az egyes szakaszok, és mi kell utána teljesüljön.
A mítosz: ha az átjáró válaszol, kapcsolódva vagy
Az első üzenetre adott válasz bizonyítja, hogy a végpont elérhető és hajlandó beszélni. Nem bizonyítja, hogy elfogadtak egy fiókot, hogy érvényesült egy tanúsítványlánc, vagy hogy telepítettek bármilyen adatházirendet.
Ezek a hibák később történnek, és más tüneteket okoznak. A tanúsítvány elutasítása vagy az EAP-hiba azután érkezik, hogy az első csere már sikerült, ezért mond olyan keveset egy UDP 500-ra küldött ping és egy zöld kliensikon.
IKE_SA_INIT: egyezz meg a paraméterekről, ne az identitásról
Az első csere hordozza az IKE biztonsági társítás javaslatait: titkosítási és integritási algoritmusokat, egy pszeudo-véletlen függvényt és egy Diffie-Hellman csoportot. A felek nonce-okat is cserélnek, és mindkét oldal az IKE SA kulcsanyagát azokból az értékekből származtatja, amelyek megosztott titkot hoznak létre. Ebben a cserében semmi nem rögzíti, ki a másik fél. Azt rögzíti, hogy mindkét oldal ki tudja számítani ugyanazokat a kulcsokat, és hogy egyetértenek egy javaslatban. Az a válaszadó, amelynek egyik javaslat sem tetszik, itt utasítja el a cserét, ezért tűnik egy verzió- vagy algoritmuseltérés úgy, mintha a kiszolgáló állna.
Az itt létrejött IKE SA minden későbbi kezelési cserét véd. Ez a feladata, és ez más feladat, mint a csomagjaid védelme.
IKE_AUTH: igazold az identitást, majd építsd fel az első CHILD SA-t
A második csere identitást hordoz. Tanúsítványokkal mindkét fél a saját privát kulcsával ír alá, és olyan láncot mutat be, amelyet a másiknak érvényesítenie kell; EAP-vel a válaszadó a választott módszerrel kihívás elé állítja a kezdeményezőt. Itt bukkan fel végül a rossz kiszolgálónév, a lejárt tanúsítvány vagy az elutasított jelszó.
Normál esetben az IKE_AUTH az első CHILD SA-t is megtárgyalja, így az adatvédelem ugyanabban a körben jön létre. A kezdeményező forgalomválasztókat javasol, a válaszadó szűkíti vagy elutasítja azokat, és az adatút kulcsai az IKE SA-ból származnak. Ez azt jelenti, hogy egyetlen csere két nagyon különböző helyen hiúsulhat meg: identitásban vagy házirendben. Az értesítési terhet vagy a hibát olvasd, ne az általános kézfogáshibát, mert az egyiknél a megoldás egy tanúsítvány, a másiknál egy alhálózat-eltérés.
Két SA, két feladat
| Társítás | Védi | Élettartam viselkedése |
|---|---|---|
| IKE SA | Kezelési cserék: kulcsújraképzés, törlés, konfigurációs terhek | Saját ütemezése szerint újul; az adatút túlélheti a változást |
| CHILD SA | A forgalomválasztóknak megfelelő alkalmazásforgalom | Függetlenül újul, gyakran sűrűbben |
Külön tartásuk két olyan viselkedést magyaráz, amelyek hibának tűnnek. Az alagút létrehozottnak látszhat, miközben a háttérben a kulcsújraképzés meghiúsul, és a CHILD SA lecserélhető anélkül, hogy a kliens elveszítené a kapcsolatot.
A strongSwanon a IKEv2 konfigurációs referencia és a swanctl --list-sas is mutatja mindkét szintet, valamint a ip xfrm state a ip xfrm policy mellett megmutatja, mit telepített valójában a kernel. E két nézet összehasonlítása a leggyorsabb módja annak megállapítására, hogy a tárgyalás befejeződött-e vagy csak befejezettnek látszott. Ha a daemon olyan CHILD SA-t listáz, amelyhez a kernelnek nincs állapota, a telepítés csendben meghiúsult. Ha a kernel olyan állapotot tart, amelyet a daemon nem ismer, egy korábbi kísérlet maradványát látod.
Mi kell még teljesüljön, miután az alagút felállt
A forgalomválasztók határozzák meg, mely címek tartoznak bele. Ha a kliens egy alhálózatot javasol, a kiszolgáló pedig egy másikat vár, a CHILD SA települ, de semmi hasznosat nem szállít, és a hiba útválasztási problémaként jelenik meg, nem tárgyalási problémaként. Utána a helyi veremnek együtt kell működnie: továbbítás engedélyezve ott, ahol a gazdagép útválaszt, az alagútra mutató útvonalak, a dekapszulált csomagokat engedélyező tűzfalszabályok és belső feloldó, ha privát nevek is érintettek. Ezek mindegyike külön-külön hibásodik meg, és egyiket sem javítja az IKE daemon újraindítása.
Tartsd láthatóan a naplót a diagnózis alatt: a kezdeti csere, majd az identitás érvényesítése, aztán a felhasználói hitelesítés ahol alkalmazható, majd a CHILD telepítése, végül az alkalmazásforgalom. Az a szakasz áll meg, amelyet javítani kell, és egy későbbi útválasztási hiba soha nem ok arra, hogy lazítsunk a már átment identitásellenőrzéseken.