L2TP NO_PROPOSAL_CHOSEN: que fase fallou realmente?

NO_PROPOSAL_CHOSEN chega antes de que se examine calquera nome de usuario PPP, o que é un dato útil e tamén a razón pola que a mensaxe engana. Informa de que un lado rexeitou unha proposta; non informa de que parámetro non coincidía e non di nada sobre se o rexeitamento ocorreu ao construír a asociación IKE ou máis tarde, ao negociar a protección do tráfico. Detrás desas dúas posibilidades hai dúas correccións distintas, e só unha implica a caixa PFS á que a xente acode primeiro.

Unha mensaxe, dous conxuntos de propostas

A disposición IKEv1 L2TP/IPsec ten dúas negociacións en secuencia. A fase 1 constrúe a asociación de seguridade IKE a partir dun algoritmo de cifrado, un algoritmo de integridade e un grupo Diffie-Hellman. A fase 2 negocia despois como se protexe o tráfico, e o requisito de PFS pertence a esa segunda conversa.

Como as fases son secuenciais, a posición do fallo diche que lista comparar. Ese é todo o valor de diagnóstico da mensaxe, e paga a pena extraelo antes de tocar calquera axuste.

Por que unha caixa PFS non pode reparar a fase 1

Desactivar PFS cambia unha propiedade da fase 2. Se as partes nunca acordaron a fase 1, a conversa ESP nunca ten lugar, así que a caixa non inflúe en absoluto no rexeitamento, e por iso cambiala produce o mesmo erro cunha marca de tempo distinta.

O erro inverso é igual de común. Unha asociación IKE correcta non demostra que a proposta ESP sexa aceptable e desde logo non demostra que o grupo da fase 2 coincida. Trata un túnel de xestión establecido como evidencia só sobre a fase 1. A xente le a liña verde como «o túnel está activo» e despois pasa unha hora na fase equivocada porque nada lle dixo que a segunda negociación non comezara.

Le o rexistro antes de escoller algoritmos

Recoller as mensaxes inmediatamente anteriores ao rexeitamento do backend que realmente atende a conexión e correlaciónaas co mesmo intento. Sen esa correlación estás lendo o historial doutra conexión e sacando conclusións del.

journalctl -b -u NetworkManager --since "10 min ago"
ipsec statusall          # strongSwan
ipsec whack --status     # Libreswan

A partir desas liñas, responde dúas preguntas: se se estableceu unha asociación de fase 1 e que intercambio fallou. Esas dúas respostas reducen a busca a unha soa lista de atributos. Unha notificación espida sen contexto arredor non pode facelo, por tentador que sexa probar unha proposta dun fío de foro. Copiar unha cadea que funciona dunha máquina con outro backend adoita substituír un rexeitamento por outro, un pouco máis tarde.

A sintaxe do backend non viaxa

Anota a versión de NetworkManager-l2tp e a versión do backend IPsec antes de comparar nada. Libreswan e strongSwan non comparten sintaxe de propostas nin conxuntos de algoritmos idénticos, así que unha cadea que funciona nun é un erro de sintaxe no outro. O backend instalado tamén pode rexeitar IKEv1 por política, e entón ningunha proposta será aceptada xamais.

O README do proxecto documenta esas diferenzas entre backends e mantén separados os campos de fase 1 e fase 2. Léoo como documentación da estrutura, non como unha invitación a habilitar todos os cifrados históricos e un grupo feble, porque unha conexión que só ten éxito facendo iso non é a conexión que che pediron construír.

Acordade o conxunto e despois verificade as etapas

Pregunta ao operador da pasarela que conxuntos IKE e ESP están soportados e aprobados, e despois compara esa resposta coas propostas efectivas do cliente en lugar de co seu ficheiro de configuración. Se o desacordo é concretamente sobre PFS de fase 2, decide un grupo soportado ou unha política sen PFS aprobada explicitamente. Non inferas a política do nome do erro.

Cando o único solapamento require criptografía que a organización xa non acepta, a decisión pertence á pasarela ou a unha migración de protocolo. Ampliar a cadea do cliente ata que algo negocie é un xeito de entregar unha debilidade coñecida cunha marca verde ao lado.

Despois de corrixir a discrepancia real, confirma o establecemento de IPsec antes de investigar L2TP e PPP, e trata calquera rexeitamento de autenticación posterior como pertencente á etapa seguinte. Despois proba a renovación no proceso de probas aprobado, porque establecer a primeira asociación non di nada sobre o resto da súa vida.