IKEv2 enderezo do servidor vs identidade: o que realmente comproba o cliente

Unha pasarela que cambia de enderezo pode seguir funcionando mentres se detén a mesma pasarela detrás dun novo certificado, e tamén ocorre o contrario. O enderezo indica ao cliente onde enviar os paquetes; a identidade autenticada di ao cliente se o compañeiro que responde é no que debería confiar. IKEv2 mantén aqueles como dous campos separados, o que é útil cando deixas de tratalos como unha cadea. Tamén están configurados en diferentes lugares, polo que un pode ser correcto mentres que o outro está equivocado.

Comprobe-os nesta orde e detéñase na primeira falta de coincidencia, porque as comprobacións posteriores supoñen que as anteriores pasaron.

En primeiro lugar, que valor é o enderezo

O enderezo de conexión é o que marque o cliente: unha IP, un nome DNS que se resolve en un ou un front end con equilibrio de carga. Iso é información de transporte e nada máis. A identidade aparece na carga útil de ID IKEv2 e logo corresponde co certificado do compañeiro. Un nome DNS na caixa de enderezos non se converte na identidade esperada, e unha IP bruta non se converte na identidade só porque o socket se conecte a ela.

En termos strongSwan, o enderezo é right ou left, e a identidade esperada é rightid ou leftid, e iso é o que describe a documentación de configuración de IKEv2. Se só editaches o enderezo, configuraches a metade do par.

En segundo lugar, o que pode demostrar o certificado

A identidade ten un tipo e o certificado debe levar un nome coincidente. Unha identidade DNS é satisfeita cunha entrada dNSName na extensión do nome alternativo do asunto; unha identidade IP necesita unha entrada iPAddress. Un certificado emitido para vpn.example.com non proba nada sobre o enderezo literal 203.0.113.10, e outro emitido para ese enderezo non proba nada sobre o nome. Polo tanto, volver a emitir por un nome diferente non é unha substitución directa, aínda que se reutilicen a mesma chave e CA.

Os clientes modernos ignoran o nome común cando existe un nome alternativo de asunto, e moitos o ignoran por completo. Se a lista SAN non contén o valor que o cliente comproba, o apretón de mans falla despois de que o certificado xa foi aceptado como fiable, polo que o rexistro aparece como un erro de identidade e non como un erro de confianza.

En terceiro lugar, como cada cliente afirma a expectativa

Windows toma o nome ou enderezo do servidor que escribiu e require que o certificado coincida con el, polo que escribir unha IP crea unha expectativa de IP. O cliente IKEv2 de Android compórtase do mesmo xeito e ambos rexeitan un certificado válido e de confianza pública que nomea un host diferente. Un perfil pode comezar a fallar só porque alguén substituíu o nome de host polo seu enderezo durante unha migración. Mira o que pediu o cliente antes de mirar o que contén o certificado.

En strongSwan a expectativa é explícita: establece rightid na identidade que realmente presenta o servidor, que pode diferir da dereita. Configuralo como %any acepta o que ofreza o compañeiro e elimina exactamente a verificación que estás a manter.

En cuarto lugar, separar o inicio de sesión do usuario da identidade dos pares

A autenticación EAP e a identidade do servidor responden a diferentes preguntas. Unha identidade EAP como [email protected] di quen é o usuario, despois de que o cliente decida que o servidor é o correcto. Ao xirar ese contrasinal non se pode corrixir unha falta de coincidencia de identidade de pares, porque a conexión nunca chega á fase de inicio de sesión do usuario.

Un informe desinfectado debería nomear ambos: a identidade que esperaba o cliente, a identidade que presentou o servidor e as entradas SAN do certificado.

En quinto lugar, cámbiao a través dunha canle verificada

Cando a pasarela se move lexitimamente, actualice primeiro o enderezo e deixe a identidade só, porque é o caso que IKEv2 manexa ben. Cando a propia identidade cambie, trátaa como un evento de confianza e obtén o novo valor dunha fonte na que xa confías, non do punto final que está fallando actualmente. Unha mensaxe enviada a través da conexión que estás tentando validar non é proba desa conexión.

Anota o enderezo final, a identidade e a lista SAN xuntos nas notas do perfil. A seguinte persoa en tocar o certificado verá entón cal dos tres pode moverse.