IKEv2 non é un único intercambio: IKE SA, autenticación e despois CHILD SA
A resposta dunha pasarela demostra alcance, non identidade. Segue IKE_SA_INIT, IKE_AUTH e o primeiro CHILD SA, e despois comproba que debe cumprirse antes de que o tráfico circule.
Podes pensar que unha conexión IKEv2 é un único intercambio que remata co teu tráfico cifrado. Son polo menos dous, e o primeiro non autentica a ninguén. Os pares comezan con mensaxes de control, acordan parámetros criptográficos, demostran identidade e só despois negocian o estado que transporta os paquetes de aplicación. Esa orde explica o desaxuste que a xente informa constantemente: a pasarela responde, o cliente di conectado e a aplicación privada segue esgotando o tempo de espera. Velaquí o que fai realmente cada etapa e que debe cumprirse despois dela.
O mito: se a pasarela responde, estás conectado
Unha resposta á primeira mensaxe demostra que o extremo é alcanzable e está disposto a falar. Non demostra que se aceptase unha conta, que se validase unha cadea de certificados nin que se instalase algunha política de datos.
Eses fallos ocorren máis tarde e producen síntomas distintos. O rexeitamento dun certificado ou un fallo de EAP chega despois de que o primeiro intercambio xa tivese éxito, e por iso un ping a UDP 500 e unha icona verde no cliente din tan pouco.
IKE_SA_INIT: acordar parámetros, non identidade
O primeiro intercambio leva as propostas para a asociación de seguridade IKE: algoritmos de cifrado e integridade, unha función pseudoaleatoria e un grupo Diffie-Hellman. Os pares tamén intercambian nonces, e cada lado deriva o material de chaves para o IKE SA a partir do segredo compartido que producen eses valores. Nada neste intercambio establece quen é a outra parte. Establece que ambos os lados poden calcular as mesmas chaves e que coinciden nunha proposta. Un respondedor ao que non lle gusta ningunha proposta rexeita aquí o intercambio, e por iso un desaxuste de versión ou de algoritmo parece que o servidor está caído.
O IKE SA creado neste punto protexe todos os intercambios de xestión posteriores. Ese é o seu traballo, e é un traballo distinto de protexer os teus paquetes.
IKE_AUTH: demostrar identidade e despois construír o primeiro CHILD SA
O segundo intercambio leva a identidade. Con certificados, cada par asina coa súa clave privada e presenta unha cadea que o outro debe validar; con EAP, o respondedor desafía o iniciador mediante o método escollido. Aquí é onde por fin aparecen un nome de servidor incorrecto, un certificado caducado ou un contrasinal rexeitado.
No caso normal, IKE_AUTH tamén negocia o primeiro CHILD SA, así que a protección de datos acórdase na mesma viaxe de ida e volta. O iniciador propón selectores de tráfico, o respondedor estréitaos ou rexeitaos, e as chaves para a ruta de datos derívanse do IKE SA. Iso significa que un só intercambio pode fallar en dous lugares moi distintos: a identidade ou a política. Le a carga útil de notificación ou o erro en lugar do fallo xenérico de negociación, porque a solución para un é un certificado e a solución para o outro é un desaxuste de subrede.
Dous SA, dous traballos
| Asociación | Protexe | Comportamento da vixencia |
|---|---|---|
| IKE SA | Intercambios de xestión: renovación de chaves, borrado, cargas útiles de configuración | Renvóvase segundo o seu propio calendario; a ruta de datos pode sobrevivir ao cambio |
| CHILD SA | Tráfico de aplicación que coincide cos selectores de tráfico | Renvóvase de forma independente, a miúdo con máis frecuencia |
Mantalos separados explica dous comportamentos que parecen erros. Un túnel pode mostrarse establecido mentres unha renovación de chaves falla en segundo plano, e un CHILD SA pode substituírse sen que o cliente perda a conexión.
En strongSwan, a referencia de configuración de IKEv2 e swanctl --list-sas mostran ambos os niveis, e ip xfrm state máis ip xfrm policy mostran o que o núcleo instalou realmente. Comparar esas dúas vistas é a forma máis rápida de ver se a negociación rematou ou só o pareceu. Se o daemon lista un CHILD SA para o que o núcleo non ten estado, a instalación fallou en silencio. Se o núcleo mantén estado que o daemon descoñece, estás a ver un resto dun intento anterior.
Que debe seguir sendo certo co túnel levantado
Os selectores de tráfico definen que enderezos quedan cubertos. Se o cliente propón unha subrede e o servidor espera outra, o CHILD SA instálase pero non transporta nada útil, e o erro aparece como un problema de encamiñamento e non de negociación. Despois a pila local ten que colaborar: reenvío activado onde o host encamiña, rutas que apuntan ao túnel, regras de cortafogos que permiten os paquetes desencapsulados e un resolvedor interno se hai nomes privados implicados. Cada un deses falla por separado e ningún se arranxa reiniciando o daemon IKE.
Mantén o rexistro visible mentres diagnosticas: o intercambio inicial, despois a validación de identidade, logo a autenticación de usuario cando corresponda, a continuación a instalación do CHILD e por último o tráfico de aplicación. A etapa que se detén é a que hai que corrixir, e un fallo de encamiñamento posterior nunca é motivo para relaxar as comprobacións de identidade que xa pasaron.