Hogyan megy át az IKEv1 hibrid hitelesítése az IKEv2 felhasználói hitelesítésébe
A hibrid mód szétválasztotta az átjáró bizonyítékát a felhasználó bizonyítékától. Az IKEv2-re váltás megőrzi ezt a szétválasztást, de megváltoztatja a cserét, az EAP-módszert és a tanúsítvány-ellenőrzéseket.
Minden régi VPN-profil, amely először kiszolgáló-tanúsítványt, majd felhasználónevet kér, két hitelesítési eseményt hordoz egyetlen cserében, és ez a forma tovább él, mint a bevezető protokoll. Az IKEv1 hibrid módja pontosan erre épült: az átjáró nyilvános kulccsal bizonyítja magát, a felhasználó pedig később XAuth-szal bizonyítja magát. Az IKEv2 ugyanazt a kétlépéses gondolatot más gépezettel fejezi ki, és a migrációk éppen ezekben a különbségekben vallanak kudarcot. Semmilyen verziószám nem alakítja át az egyiket a másikká, és a régi opciónevek új profilba másolása olyan klienst ad, amely tárgyal, majd semmit nem hitelesít.
Mit tett a hibrid mód az IKEv1 belsejében
Egy hibrid profilban a válaszoló fél az első fázis cseréjét a saját tanúsítványával írja alá, míg a kezdeményező szándékosan egyet sem mutat be. A személyazonosság bizonyítéka tehát aszimmetrikus, és ez tette lehetővé, hogy az átjáró megtartsa meglévő PKI-jét, a felhasználók pedig a címtár-jelszavaikat. Amikor az első fázis véget ér, az XAuth kérésként és válaszként fut, amely a felhasználónevet és a jelszót a most már titkosított ISAKMP-csatornán belül szállítja.
Figyelje meg, hová kerül a bizalom. A tanúsítvány azt válaszolja meg, melyik átjáróhoz ért el a kliens; az XAuth azt válaszolja meg, melyik felhasználó kér hozzáférést. Egyik sem helyettesíti a másikat, és az a kliens, amelyet bármely kiszolgáló-tanúsítvány elfogadására állítottak be, csendesen eldobta az első választ. A hibrid címkét a megosztott kulcsos agresszív mód és az XAuth kombinációjára is használják, amely más elrendezés ugyanazzal a felhasználói élménnyel, ezért a profilt olvassa, ne a nevet. Mindkét változat olyan tervezetekből származik, amelyek soha nem lettek szabványok, és ezért két gyártó is megvalósíthatja a hibrid módot, és egyikkel sem tud együttműködni.
Hogyan jut el az IKEv2 ugyanahhoz a két bizonyítékhoz
Az IKEv2 az IKE_SA_INIT és az IKE_AUTH között osztja meg a munkát. Az első csere identitások nélkül egyeztet ajánlatokat és kulcsokat; a második szállítja az IDi-t, az IDr-t és az AUTH-terheléseket. EAP alatt a kezdeményező első AUTH-terhelése üresen megy ki, a válaszoló fél először a saját tanúsítványával és aláírásával hitelesít, majd az EAP-beszélgetés az IKE_AUTH üzenetein belül zajlik.
A mechanizmus, amely ezt biztonságossá teszi, a kulcsanyag. Egy sikeres EAP-módszer munkamenet-kulcsot exportál, és a kezdeményező utolsó AUTH-terhelése ebből számolódik, így a felhasználó bizonyítéka és az alagút kulcsai összekapcsolódnak. Az XAuth-nak nincs megfelelője: attribútumai az első fázis után érkeznek, és semmit nem adnak a kulcsokhoz. Pontosan ezt a rést hivatott bezárni az IKEv2 keretrendszere, és ezért ellenőrzi egy működő IKEv2-bejelentkezés a kiszolgáló tanúsítványát, mielőtt bármit kérne.
Ez a sorrend hasznos diagnózis is. Amikor a kliens a hitelesítő adatokra panaszkodik, mielőtt tanúsítványt mutatna Önnek, egyáltalán nem folytat IKEv2 EAP-cserét.
Tartsa külön a három identitást
A migráció akkor megy félre, amikor három identitás egyetlen mezőbe omlik. Ott van az átjáró identitása, amelyet a kliens ellenőriz, általában DNS-név a tanúsítvány subject vagy SAN mezőjében. Ott van az EAP-ban bemutatott felhasználói identitás, esetleg tartományi bejelentkezés, cím vagy kifejezett EAP-identitáslánc. És ott van az engedélyezési forrás, amely ezt a felhasználót hálózatokhoz és útvonalakhoz rendeli.
A strongSwan swanctl szintaxisa láthatóvá teszi a szétválasztást: a kapcsolat az átjáróhoz remote { auth = pubkey }-t, a felhasználóhoz local { auth = eap-mschapv2 }-t állít be, az EAP-identitást külön szállítva.
Amikor az új profilban a felhasználói identitás eltér a régi XAuth-attribútumoktól, például UPN a rövid név helyett, a hitelesítési kiszolgáló ismeretlen felhasználót lát, és a hiba rossz jelszónak látszik. A hitelesítő adatok ellenőrzése előtt ellenőrizze az identitásláncot.
Térképezze fel az opciókat, majd számítson a csapdákra
A leképezés rövid, és minden sorban van egy csapda, amely csak a hitelesítés pillanatában jelenik meg.
| Legacy hybrid element | IKEv2 equivalent | Where it bites |
|---|---|---|
| Gateway certificate, no client certificate | Responder authenticated with pubkey, initiator with EAP | The server needs an EAP method configured, not just a certificate |
| XAuth username and password | EAP-MSCHAPv2 or an inner method | Password policy and account format differ from the old directory field |
| XAuth attribute replies | IKEv2 configuration payload | Attribute numbering is unrelated; nothing is renamed |
| Proxy IDs from quick mode | TS_i and TS_r in IKE_AUTH | Narrowing on the responder can leave an IKE SA with no child SA |
Egyik sor sem csupán átnevezés. A konfigurációs terhelés típusos attribútumlistán keresztül szállítja a címeket és a feloldókat, míg az XAuth attribútumtere a saját találmánya volt; ezeket kicserélhetőnek tekinteni az az út, amelyen a profil végül olyan beállítást kér, amelyet az átjáró soha nem fog elküldeni.
A forgalomszelektorok saját figyelmeztetést érdemelnek. Az IKEv1 a quick mode cseréhez kötött proxy ID-ken keresztül fejezte ki az érdekes forgalmat, míg az IKEv2 az IKE_AUTH során tárgyal a szelektorokról, és a válaszoló fél szűkítheti azokat. Az eltérés olyan létrejött IKE SA-t eredményez, amelynek nincs child SA-ja, és amelyet egyes kliensek boldogan kapcsolódóként jelenítenek meg.
Tekintse a régi kapcsolatot határvonalnak
Az RFC 9395 elavulttá nyilvánítja az IKEv1-et, ezért a régi hibrid kapcsolat dátumozott kompatibilitási határvonal, nem alap. Futtassa a két profilt egymás mellett a váltás alatt, mert a fontos próba nem az, hogy feljön-e az új profil, hanem hogy ugyanaz a felhasználó ugyanazon az eszközön ugyanazokhoz az erőforrásokhoz jut-e.
Tartsa szigorún a tanúsítványok ellenőrzését végig. Amint a kliens abbahagyja a saját tanúsítványának bemutatását, a kísértés az, hogy lazítson a kiszolgáló ellenőrzésén, amíg a kézfogás be nem fejeződik, és ez az egyetlen fennmaradó bizonyítékot cseréli zöld ikonra.
Írjon le négy dolgot, mielőtt nyugdíjazza a régi profilt: az EAP-módszert, az identitásláncot, az engedélyezési forrást és a támogatás végének dátumát.