IKEv2 szervercím vs identitás: amit a kliens valójában ellenőrzött

A címet módosító átjáró továbbra is működhet, miközben az új tanúsítvány mögötti átjáró leáll, és ennek fordítottja is megtörténik. A cím megmondja az ügyfélnek, hogy hova küldje a csomagokat; a hitelesített identitás megmondja az ügyfélnek, hogy a válaszadó partnerben kell-e megbíznia. A IKEv2 ezeket két különálló mezőként tartja meg, ami hasznos, ha már nem kezeli őket egyetlen karakterláncként. Különböző helyeken vannak beállítva, így az egyik lehet helyes, míg a másik rossz.

Ellenőrizze őket ebben a sorrendben, és hagyja abba az első eltérésnél, mert a későbbi ellenőrzések azt feltételezik, hogy a korábbiak sikeresek voltak.

Először is, melyik érték a cím

A kapcsolati cím az, amit a kliens tárcsáz: egy IP-cím, egy DNS név, amely az egyikre feloldódik, vagy egy terheléselosztó előtér. Ez közlekedési információ és semmi több. Az identitás bekerül a IKEv2 ID hasznos teherbe, majd összeveti a társ tanúsítványával. A címmezőben szereplő DNS név nem lesz az elvárt identitás, és a nyers IP nem válik identitássá csak azért, mert a socket csatlakozik hozzá.

A strongSwan kifejezéssel a cím right vagy left, a várt azonosság pedig rightid vagy leftid, és ezt írja le az IKEv2 konfigurációs dokumentációja. Ha csak a címet szerkesztette, akkor a pár felét konfigurálta.

Másodszor, mit tud a tanúsítvány igazolni

Az identitásnak van típusa, és a tanúsítványnak egy megfelelő nevet kell viselnie. A DNS azonosságot kielégíti a dNSName bejegyzés a tárgy alternatív névkiterjesztésében; egy IP-azonosítóhoz iPAddress bejegyzésre van szükség. A vpn.example.com-ra kiállított igazolás semmit sem bizonyít a szó szerinti címről 203.0.113.10, az erre a címre kiállított pedig semmit sem a névről. Ezért az újbóli kiadás egy másik névre nem jelenti a beugró cserét, még akkor sem, ha ugyanazt a kulcsot és a CA újrafelhasználják.

A modern kliensek figyelmen kívül hagyják a közönséges nevet, ha létezik alternatív név, sokan pedig teljesen figyelmen kívül hagyják. Ha a SAN lista nem tartalmazza az ügyfél által ellenőrzött értéket, a kézfogás meghiúsul, miután a tanúsítványt már elfogadták megbízhatónak, ezért a napló identitáshibaként jelenik meg, nem pedig bizalmi hibaként.

Harmadszor, hogy az egyes ügyfelek hogyan fogalmazzák meg az elvárásokat

A Windows az Ön által beírt szervernevet vagy címet veszi fel, és megköveteli, hogy a tanúsítvány megegyezzen vele, így az IP beírása IP elvárást hoz létre. A Android IKEv2 kliense ugyanúgy viselkedik, és mindkettő elutasít egy érvényes, nyilvánosan megbízható tanúsítványt, amely más gazdagépet nevez meg. Egy profil meghibásodhat pusztán azért, mert valaki az áttelepítés során a gazdagépnevet a címére cserélte. Nézze meg, mit kért az ügyfél, mielőtt megnézné, mit tartalmaz a tanúsítvány.

A strongSwan-on az elvárás kifejezett: állítsa be a rightid-t a szerver által ténylegesen bemutatott identitásra, amely eltérhet a jobbtól. Ha a %any értékre állítja, az elfogad mindent, amit a társ kínál, és pontosan eltávolítja azt a csekket, amelyet megtartani próbál.

Negyedszer, különítse el a felhasználói bejelentkezést a peer identitástól

A EAP hitelesítés és a szerver azonossága különböző kérdésekre ad választ. Egy EAP identitás, például [email protected] mondja meg, hogy ki a felhasználó, miután a kliens úgy döntött, hogy a szerver a megfelelő. A jelszó elforgatásával nem lehet kijavítani a peer identitás eltérését, mert a kapcsolat soha nem éri el a felhasználói bejelentkezési szakaszt.

A megtisztított jelentésnek meg kell neveznie mindkettőt: az ügyfél által várt identitást, a szerver által bemutatott identitást és a tanúsítvány SAN bejegyzéseit.

Ötödször, módosítsa egy ellenőrzött csatornán keresztül

Amikor az átjáró jogszerűen mozog, először frissítse a címet, és hagyja békén az identitást, mert ez az eset IKEv2 jól kezeli. Amikor maga az identitás megváltozik, kezelje bizalmi eseményként, és szerezze be az új értéket egy olyan forrásból, amelyben már megbízik, nem pedig az éppen meghibásodott végponttól. Az ellenőrizni kívánt kapcsolaton keresztül kézbesített üzenet nem bizonyíték a kapcsolatra.

Rögzítse a végleges címet, az identitást és a SAN listát együtt a profiljegyzetekben. A következő személy, aki megérinti a tanúsítványt, látni fogja, hogy a három közül melyik mozoghat.