O par IPsec entrante non coincide con ningún perfil? Revise catro campos

O seu par informa de que o túnel está levantado, o seu lado non mostra ningunha asociación de seguridade e o ficheiro de configuración contén claramente un nome de conexión coincidente. As tres afirmacións poden ser certas á vez. Unha negociación entrante compárase coa configuración en execución, usando o enderezo do par, a identidade que presenta e o tráfico que propón. Un ficheiro no disco que nunca se cargou, unha identidade que non coincide co valor esperado ou un par de selectores desviado nun prefixo producirán silencio cada un. Percorra os catro grupos de campos na orde en que o fai o respondedor.

Comece polo paquete, non polo ficheiro

O respondedor recibe unha solicitude IKE, busca unha definición que poida aceptar este par e despois continúa coa autenticación e a selección de tráfico. Se ningunha definición cargada coincide no primeiro paso, a negociación remata antes de que chegue ao usuario algún erro útil.

Por iso «a configuración parece correcta» non é unha proba. A pregunta é que cargou o servizo en execución e que entrada seleccionou para este intento. Unha listaxe de estado responde a iso cun só comando, mentres que o búfer do editor responde a outra pregunta. Revise a listaxe antes de volver cambiar o ficheiro.

Primeiro grupo de campos: a definición que realmente está cargada

Revise o estado en execución coa ferramenta que posúe o daemon: un comando de estado que liste as conexións cargadas, non o búfer do editor. Confirme que a entrada que espera está presente, que está habilitada para o comportamento de arranque que desexa e que se cargou despois da súa última edición. Un ficheiro gardado que non se recargou é a causa máis habitual de «arranxeino e non cambiou nada».

Confirme tamén que ficheiro le o servizo. As distribucións difiren, e unha conexión escrita na inclusión equivocada ignórase en silencio en lugar de rexeitarse. Se a listaxe de estado non mostra a súa entrada en absoluto, sospeite da ruta de inclusión antes que da sintaxe.

Segundo grupo de campos: os extremos non son identidades

O enderezo desde o que se conecta o par e a identidade coa que se autentica son campos separados. Un nome de host, un nome distinguido, un identificador de clave e un enderezo poden servir todos como identidade IKE segundo a configuración, e non teñen por que parecerse en absoluto ao enderezo público.

A coincidencia de extremos tamén pode implicar unha vista NAT: o enderezo visto na rede pode diferir do enderezo que o par cre ter. No modelo de conexións de libreswan, left e right son etiquetas dos dous participantes e non unha orde fixa de local e remoto, e por iso copiar unha configuración que funciona doutro sitio e intercambiar os enderezos non é unha tradución fiable.

Anote a identidade esperada de cada lado e a credencial que a valida. Se esas dúas liñas non coinciden, ningunha cantidade de axuste de enderezos producirá unha coincidencia.

Terceiro grupo de campos: o tráfico que se protexe

Os selectores describen os rangos internos de orixe e destino, a súa familia de enderezos e calquera restrición de protocolo ou porto. Unha proposta para o enderezo dun só host non é a mesma solicitude que para unha subrede enteira, e un respondedor configurado para a subrede pode rexeitala ou estreitala.

Cando os dous extremos non coinciden, compare o fluxo previsto desde ambos os puntos de vista en lugar de ampliar cada selector para que algo conecte. Pregunte a cada administrador que fluxo cre que protexe e logo compare as dúas respostas. A discrepancia adoita ser un prefixo de host nun lado e unha subrede no outro. Un túnel que coincide porque agora o protexe todo é unha decisión de seguridade distinta, e que ninguén aprobou.

Cuarto grupo de campos: está lendo unha implementación

Libreswan, o antigo Openswan e strongSwan teñen ferramentas de xestión distintas, sintaxe de configuración distinta e orde de coincidencia distinta. Un exemplo que funciona nun non di nada preciso sobre a prioridade de selección de perfil ou a redacción de erros doutro, así que verifique coa documentación do daemon deste host.

Correlacione un intento de principio a fin: o enderezo de orixe do iniciador, a identidade ofrecida e os selectores propostos, fronte á mensaxe de selección do respondedor e á entrada cargada que nomea. Os contadores de encapsulación e desencapsulación a cero só din que as asociacións observadas non transportaron eses paquetes; non nomean o extremo que rexeitou a proposta nin proban que existise unha entrada coincidente naquel momento.

Tras unha corrección coordinada, confirme o perfil e a asociación seleccionados e logo probe o servizo realmente permitido e a súa ruta de resposta. Unha coincidencia de perfil habilita a negociación, e a negociación non é a última comprobación de acceso.