L2TP conéctase pero a negociación PPP falla: que fase?

O túnel IPsec establécese, o cliente mostra un par protexido e despois a conexión morre antes de que algo chegue á subrede privada. Esa fenda é PPP facendo o seu propio traballo: as opcións de enlace, a autenticación de usuario e a asignación de enderezo ocorren todas despois de que o túnel cifrado xa existe. Nada dun intercambio exitoso de primeira fase fornece un contrasinal nin un enderezo interno. Le as fases por orde e o fallo adoita nomearse só.

O túnel é só a primeira capa

L2TP transporta tramas PPP dentro dun túnel protexido por IPsec, o que significa que dúas negociacións independentes deben ter éxito antes de que se poida encamiñar un paquete. A exterior demostra que os dous extremos coinciden en claves e identidades. A interior decide os parámetros do enlace, se o usuario se autentica e que enderezo recibe o cliente.

Un fallo dentro de PPP parece un túnel roto en cada cliente que só mostra unha luz de estado. Tratalo como un problema de túnel leva a rexenerar claves, reiniciar servizos e, ao final, substituír un segredo compartido que nunca estivo mal. A distinción útil é barata: se o intercambio co par se completou e o cliente pasou a unha petición de nome de usuario ou a unha etapa de autenticación, o túnel está ben. Todo o posterior a ese punto pertence a PPP.

Le a última fase que tivo éxito

Percorre o rexistro cara adiante e detente na primeira fase que non se completou. Primeiro vén LCP, despois a autenticación e despois IPCP para os parámetros de IPv4.

sudo journalctl -u xl2tpd -b --no-pager | tail -n 40
sudo journalctl -b --no-pager | grep -i -E 'pppd|lcp|chap|ipcp'
ip -4 address show ppp0

Un tempo de espera de LCP significa que os dous extremos nunca acordaron as opcións básicas do enlace, o que é un perfil que non coincide ou un protocolo interno bloqueado, non un contrasinal incorrecto. Un rexeitamento explícito de autenticación é o caso contrario: o enlace subiu e un lado rexeitou as credenciais. Un tempo de espera de IPCP tras unha autenticación correcta apunta a grupos de enderezos ou á política do servidor. Cada un ten un dono distinto e unha reparación distinta, e por iso a fase importa máis que o texto final do erro.

Garda o fragmento do rexistro xunto co nome da fase no ticket. Unha cola pegada sen a fronteira de fase invita o seguinte lector a adiviñar, e adiviñar aquí custa unha hora.

Acordo entre o cliente e o servidor

Os dous extremos deben aceptar o mesmo método de autenticación, e un perfil gardado pode pedir un que o servidor retirou o trimestre pasado. Os despregamentos xestionados tamén ocultan o lado do servidor, onde o motivo do rexeitamento adoita rexistrarse contra o usuario e non contra o dispositivo.

Activa un método compatible en lugar de cada opción herdada, porque un cliente que ofrece cinco métodos oculta cal fallou. Pide ao administrador a política do lado do servidor e o rexeitamento exacto, o que non esixe que ninguén publique un contrasinal. Un método herdado activado para rescatar un só cliente tende a estenderse a cada perfil que copia o ficheiro.

Verifica o enderezo, non o inicio de sesión

Un inicio de sesión completado non é unha sesión utilizábel. IPCP negocia o enderezo interno, e un grupo esgotado ou unha política que nega o cliente aínda poden deixar un túnel conectado sen nada que encamiñar.

ip -4 address show ppp0
ip route get 10.52.9.1
ping -c 2 10.52.9.1

Comproba primeiro o enderezo interno, despois a ruta e o resolutor para o recurso que realmente necesitas. Un enderezo interno non é a saída pública que informa un sitio web, e confundir as dúas cousas manda a xente cazar unha fuga que non existe. Proba o recurso privado por enderezo antes de probalo por nome, para que un fallo de DNS non se confunda cun fallo de encamiñamento.

Escribe a fase, o método e o enderezo nunha soa nota e póñalle data. Se a mesma conta volve fallar dentro dun mes, esa nota é a diferenza entre unha comprobación de cinco minutos e unha investigación nova. Os fallos en fases distintas son incidentes distintos, aínda que o cliente mostre un só diálogo.