IKEv2 adreça del servidor vs identitat: què comprova realment el client

Una passarel·la que canvia d'adreça pot seguir funcionant mentre la mateixa passarel·la que hi ha darrere d'un certificat nou s'atura, i també passa el contrari. L'adreça indica al client on ha d'enviar els paquets; la identitat autenticada indica al client si l'igual que respon és en qui hauria de confiar. IKEv2 els conserva com a dos camps separats, cosa que és útil quan deixeu de tractar-los com una cadena. També es configuren en diferents llocs, de manera que un pot ser correcte mentre que l'altre està equivocat.

Comproveu-los en aquest ordre i atureu-vos al primer desajust, perquè les comprovacions posteriors suposen que les anteriors han passat.

Primer, quin valor és l'adreça

L'adreça de connexió és qualsevol que marqui el client: una IP, un nom DNS que es resol en un o una interfície equilibrada de càrrega. Això és informació de transport i res més. La identitat es troba a la càrrega útil d'identificació IKEv2 i després es compara amb el certificat del company. Un nom DNS al quadre d'adreces no es converteix en la identitat esperada, i una IP en brut no es converteix en la identitat només perquè el sòcol s'hi connecta.

En termes strongSwan, l'adreça és right o left, i la identitat esperada és rightid o leftid, i això és el que descriu la documentació de configuració IKEv2. Si només heu editat l'adreça, heu configurat la meitat de la parella.

En segon lloc, què pot demostrar el certificat

La identitat té un tipus i el certificat ha de portar un nom coincident. Una identitat DNS es satisfà amb una entrada dNSName a l'extensió de nom alternativa del tema; una identitat IP necessita una entrada iPAddress. Un certificat emès per a vpn.example.com no prova res sobre l'adreça literal 203.0.113.10, i un emès per a aquesta adreça no prova res sobre el nom. Per tant, tornar a emetre un nom diferent no és un reemplaçament, fins i tot quan es reutilitzin la mateixa clau i CA.

Els clients moderns ignoren el nom comú quan existeix un nom alternatiu del subjecte, i molts l'ignoren completament. Si la llista SAN no conté el valor que el client comprova, la connexió de mans fallarà després que el certificat ja s'hagi acceptat com a fiable, per això el registre es llegeix com un error d'identitat en lloc d'un error de confiança.

En tercer lloc, com cada client manifesta l'expectativa

Windows pren el nom o l'adreça del servidor que heu escrit i requereix que el certificat coincideixi amb ell, de manera que escriure una IP crea una expectativa d'IP. El client IKEv2 de Android es comporta de la mateixa manera, i tots dos rebutgen un certificat vàlid i de confiança pública que anomena un amfitrió diferent. Un perfil pot començar a fallar només perquè algú ha substituït el nom d'amfitrió per la seva adreça durant una migració. Mireu què va demanar el client abans de veure què conté el certificat.

A strongSwan l'expectativa és explícita: establiu rightid a la identitat que realment presenta el servidor, que pot ser diferent de la correcta. Si l'estableixes a %any, s'accepta tot el que ofereix el parell i s'elimina exactament el xec que estàs intentant mantenir.

En quart lloc, separar l'inici de sessió de l'usuari de la identitat dels companys

L'autenticació EAP i la identitat del servidor responen a diferents preguntes. Una identitat EAP com [email protected] diu qui és l'usuari, després que el client hagi decidit que el servidor és el correcte. La rotació d'aquesta contrasenya no pot solucionar un desajust d'identitat d'iguals, perquè la connexió mai arriba a l'etapa d'inici de sessió de l'usuari.

Un informe desinfectat hauria d'anomenar tots dos: la identitat que el client esperava, la identitat que presentava el servidor i les entrades SAN del certificat.

En cinquè lloc, canvieu-lo mitjançant un canal verificat

Quan la passarel·la es mou legítimament, actualitzeu primer l'adreça i deixeu la identitat en pau, perquè és el cas que IKEv2 es gestiona bé. Quan la pròpia identitat canviï, tracteu-la com un esdeveniment de confiança i obteniu el nou valor d'una font en la qual ja confieu, no del punt final que està fallant actualment. Un missatge enviat a través de la connexió que esteu intentant validar no és una prova d'aquesta connexió.

Anoteu l'adreça final, la identitat i la llista SAN junts a les notes del perfil. La següent persona que toqui el certificat veurà quin dels tres pot moure's.