L2TP/IPsec falla: illa IPsec, autenticación do túnel ou inicio de sesión PPP

Tres cousas autentícanse dentro dunha soa conexión L2TP/IPsec, e só unha delas implica a persoa que marca. IPsec demostra os extremos do túnel, a conexión de control L2TP pode volver demostrar os pares co seu propio segredo, e despois PPP demostra a conta de usuario dentro da sesión. Un fallo en calquera etapa parece un erro xenérico de inicio de sesión no diálogo do cliente e parece completamente distinto nun rexistro do servidor. Percorre as etapas en orde e detente na primeira que falle, porque toda etapa por debaixo dunha non probada tamén está sen probar.

Tres etapas de autenticación, tres identidades distintas

IPsec demostra quen posúe os extremos, usando unha clave precompartida ou un certificado. Esa identidade pertence a máquinas ou pasarelas, nunca á persoa no teclado. Cando os pares non se poñen de acordo nesta etapa, non se intercambia ningún paquete L2TP.

A conexión de control L2TP pode engadir un segundo intercambio desafío-resposta, independente, guiado por un segredo compartido que ambos os extremos deben ter.

RFC 2661 fai opcional esa autenticación da conexión de control, o que explica por que o mesmo erro produce síntomas distintos en dous servidores. Unha implantación que nunca configurou un segredo de túnel salta a etapa por completo; unha que o configurou nun só lado falla antes de que se ofreza PPP. PPP autentica entón o usuario con PAP, CHAP ou MSCHAPv2 e entrega o nome a un almacén de contas que pode ser local, en chap-secrets ou en RADIUS. Un contrasinal incorrecto nese punto déixache cun túnel que funciona e unha sesión fallida.

Le o punto de parada antes de editar unha configuración

Comeza con ipsec --version para saber se a saída de estado pertence a strongSwan ou a Libreswan. Despois le o rexistro do servidor, non o diálogo do cliente, porque o servidor rexistra que etapa rexeitou.

Unha liña adoita resolver o ticket: unha queixa de IKE ou de propostas é a etapa un, unha mensaxe da conexión de control é a etapa dous e un rexeitamento de método PPP ou de conta é a etapa tres. Copia esa liña no ticket coa marca de tempo. Adiviñar desde o lado do cliente desperdicia a única proba que xa tes.

Mantén o material de clave e os contrasinais fóra dese texto pegado; o nome da etapa encamiña o traballo, e unha clave precompartida filtrada reabre o ticket con consecuencias peores.

Etapa un: ten IPsec unha asociación?

Executa ipsec statusall en strongSwan ou ipsec whack --status en Libreswan e busca unha asociación filla establecida con contadores distintos de cero. ip xfrm state mostra a visión do núcleo en ambos. Un par de SAs instalado con contadores que soben significa que a etapa un está feita e podes continuar.

A ausencia total de asociación apunta ao enderezo do par, ao conxunto de propostas ou á clave precompartida, e ás veces a un dispositivo que reescribe UDP 500 mentres descarta UDP 4500. Unha asociación que se establece e logo desaparece tras uns segundos adoita ser un desaxuste de tempo de vida entre os dous extremos e non un problema de credenciais. Comproba se ambos os lados listan as mesmas propostas de cifrado e hash antes de volver escribir nada. Se non o fan, ningunha clave funcionará xamais.

Detente mentres falta a asociación. Editar as opcións de PPP nese punto non cambia nada e oculta o fallo real á seguinte persoa.

Etapa dous: autenticouse a conexión de control L2TP?

Unha vez IPsec está arriba, observa o daemon L2TP para ver unha conexión de control que acade un estado establecido, xa que PPP non pode comezar antes diso. Un rexeitamento na conexión de control significa que o segredo do túnel difire entre os extremos, ou que un extremo esixe un segredo que o outro nunca envía. Os clientes adoitan expoñer un único campo etiquetado shared secret, e normalmente pertence a IPsec e non a L2TP. Enchéndoo non se configura o segredo do túnel, e borralo non o desactiva.

Se ningún dos lados ten un segredo de túnel configurado, salta esta etapa e trata un fallo da conexión de control como un problema de accesibilidade. Confirma que UDP 1701 chega ao daemon e que ambos os extremos concordan na mesma encapsulación. Unha regra de firewall escrita para unha desas dúas condicións é unha causa habitual dunha conexión que abre a medias.

Só unha sesión que comeza a negociar PPP superou realmente a etapa do túnel.

Etapa tres: está PPP a rexeitar a conta?

Un fallo de PPP vese distinto desde fóra: o túnel está establecido, a sesión comeza e o daemon rexistra un fallo do método de autenticación ou un rexeitamento da conta. Le o método nomeado nesa mensaxe. PAP e CHAP fallan por motivos distintos, e un servidor que rexeita un rexeitará un cliente que só ofreza ese.

Nun servidor Linux, inspecciona o ficheiro de opcións que o daemon pasa a PPP, normalmente /etc/ppp/options.xl2tpd, e confirma que métodos se aceptan e onde se resolven as contas. Un nome que existe en RADIUS pero non no ficheiro de segredos local falla limpiamente e parece un contrasinal incorrecto. Despois comproba que o cliente ofrece un método que o servidor acepta, en vez dun máis forte que o servidor rexeita negociar. Cambiar a clave precompartida para reparar esta etapa desperdicia unha tarde e non cambia nada.

Cando a sesión por fin se levanta, a asignación de enderezos, o DNS e as rutas aínda están sen comprobar, e cada unha falla en silencio á súa maneira. Mantén as tres capas separadas nas túas notas: unha clave correcta cunha conta incorrecta falla sempre, e reparar unha capa nunca repara outra.