Que etapa da VPN fallou: IPsec, o control L2TP ou a autenticación PPP
Atope a última etapa que funcionou e arranxe só esa capa: IPsec, a canle de control L2TP, a autenticación PPP ou a asignación de enderezos.
Cambiou o contrasinal e nada se moveu, porque a falla nunca estivo en PPP. L2TP/IPsec informa dun único erro de conexión para cinco entregas moi distintas, e cada entrega ten a súa propia reparación. Traballa ao revés: atopa a última etapa que funcionou e cambia só o que vén despois. A orde de abaixo tamén decide que probas recolle primeiro.
Responda catro preguntas por orde
Force un intento novo, porque algúns clientes seguen mostrando o erro anterior ata que o perfil se desconecta e se volve conectar. Despois responda isto: había unha asociación de seguridade IPsec, apareceron unha conexión de control L2TP e unha chamada, chegou PPP a un veredicto de autenticación e entregou IPCP un enderezo ao cliente? O primeiro non é a etapa que arranxa. Todo o posterior non se probou, así que un nome de usuario rexeitado non demostra nada cando nunca existiu unha asociación.
Sincronice os reloxos de ambos os extremos antes de comparar. Un reintento que limpou IPsec e fallou en PPP parece unha soa falla cando o cliente só mostra a mensaxe final e o rexistro do servidor aínda garda o intento anterior. Lea por marca de tempo, non pola liña máis ruidosa.
Cando só ten a captura de pantalla do usuario, apóiese na separación máis barata: unha clave precompartida incorrecta e un xl2tpd que nunca responde producen o mesmo texto no diálogo de Windows, pero un precisa un segredo cambiado nos dous extremos e o outro un demo iniciado ou unha regra de devasa no propio servidor. Un dispositivo no medio non pode descartar o 1701 interior unha vez que IPsec en modo transporte o envolveu, así que non busque un filtro de ruta que non existe.
Que posúe realmente cada capa
IPsec protexe os paquetes entre os dous pares; L2TP transporta unha sesión PPP dentro desa ruta protexida, por iso RFC 3193 especifica o modo transporte en lugar dun túnel propio. A etiqueta do cliente di L2TP, así que o túnel e o inicio de sesión parecen un só mecanismo. Non o son: a conexión de control L2TP autentica os extremos do túnel onde un despregamento o habilita, e PPP autentica por separado o usuario con CHAP, PAP ou MS-CHAPv2 segundo a política do servidor.
Esa separación explica os dous segredos que a xente confunde. Unha clave precompartida autentica os pares IPsec. Un usuario e un contrasinal identifican o usuario ante PPP. Reescribir o segredo compartido de Windows nun perfil que se autentica con certificados non cambia nada na etapa que falla, e editar o contrasinal PPP non pode fornecer unha canle protexida ausente. A mesma contención se aplica á comprobación de identidade: non desactive a identidade do par nin a validación do certificado para conseguir un túnel, porque entón o que conecta é a ruta, non o par.
A autenticación tampouco é o final de PPP. Unha vez aceptado o usuario, IPCP negocia o enderezo do cliente e as opcións DNS e WINS que o servidor está disposto a entregar. Un cliente pode pasar CHAP ou MS-CHAPv2 e aínda así quedar sen enderezo, o que é unha falla dentro de PPP e non un problema de encamiñamento. L2TP simple sen IPsec segue sendo válido e desprotexido, así que unha conexión correcta nunca demostra que o tráfico estea protexido; comprobe que esixe o servidor, non a etiqueta do cliente.
Decida pola primeira etapa que falta
Lea a táboa polo primeiro elemento que falta, de esquerda a dereita. A columna da dereita é o único traballo que paga a pena nese momento; todo o que ten á súa esquerda xa está probado, e volver probalo queima a xanela de interrupción sen engadir información.
| First thing missing | What it means | Change this |
|---|---|---|
| No IKE reply on 500 or 4500 | The path or the listener never answered | Firewall, NAT-T forwarding, server listener |
| IKE runs, no IPsec association | Identity, key, or proposal mismatch | Proposal and PFS set, pre-shared key, local and remote ID |
| Association up, no L2TP control connection | Inner signalling never reached xl2tpd | UDP 1701, tunnel and session sections, NAT encapsulation |
| Control connection up, PPP auth refused | The user or method was rejected | Credential format, allowed auth method, account policy |
| PPP auth accepted, no address assigned | IPCP never completed | Address pool in xl2tpd.conf, ms-dns and ms-wins in options.xl2tpd |
| Address assigned, applications fail | The inner path is wrong | Routes, DNS, MTU or MSS, server forwarding |
Tres filas merecen un aviso. A fila 1701 é onde adoitan aterrar os clientes Windows detrás de NAT: a asociación complétase, despois non chega nada, e a causa é a encapsulación, non un contrasinal malo. A fila IPCP é a que se le mal como problema de ruta, porque Windows envolve o enderezo ausente no erro 720 e a icona da bandexa só di que a conexión fallou; esa falla sitúase despois da autenticación e antes do encamiñamento. A última fila non é ningunha falla de IPsec, aínda que a icona diga desconectado.
Comandos que separan as capas
Nun servidor Linux con strongSwan, swanctl --list-sas lista as asociacións establecidas coa identidade do par, e ipsec statusall cobre hosts strongSwan e libreswan máis antigos. Debaixo, ip xfrm state mostra as asociacións reais do núcleo, mentres que ss -lunp | grep 1701 demostra onde está ligado xl2tpd. Execute xl2tpd -D en primeiro plano para ver aparecer as conexións de control e as chamadas, e active a depuración de pppd en /etc/ppp/options.xl2tpd para ver o método ofrecido e a resposta.
Cando os rexistros mostran unha autenticación correcta, a seguinte pregunta é se IPCP se completou. Comprobe que ip range na sección [lns default] de /etc/xl2tpd/xl2tpd.conf aínda teña enderezos libres, e que /etc/ppp/options.xl2tpd leve realmente ms-dns e ms-wins se o cliente os espera. Un conxunto esgotado e unha opción DNS ausente vense distintos no cable: o primeiro deixa o cliente sen enderezo e cun 720, o segundo dá enderezo pero ningún resolvedor, así que os nomes fallan mentres os ping a enderezos crus funcionan. Ningún se arranxa volvendo introducir o contrasinal.
No cliente, o complemento L2TP de NetworkManager escribe a conversación de pppd no diario, así que journalctl -u NetworkManager -b normalmente separa túnel levantado, autenticación rexeitada de ningún túnel. En Windows, Get-VpnConnection informa da configuración real de autenticación do perfil, e os eventos RasClient en Application do Visor de eventos nomean o compoñente que falla. Cando o diálogo é demasiado vago, active netsh ras set tracing * enable.
As capturas requiren unha precaución. Con IPsec en modo transporte, o UDP 1701 interior vai cifrado, así que unha captura na interface exterior mostra ESP, ou UDP 4500 baixo NAT-T, e ningún L2TP. Que falte 1701 nunha captura é esperable e non é proba dun porto bloqueado; observe se se moven os contadores de ESP ou de 4500.
NAT, MTU e rutas: onde a pila o engana
NAT rompe as suposicións antes de que nada estea autenticado. ESP é o seu propio protocolo IP, así que un dispositivo que traduce descártao salvo que os pares encapsulen; iso é o que achega o UDP 4500. Nun servidor Windows que el mesmo está detrás dun router doméstico ou dunha pasarela NAT na nube, a etapa IPsec falla co erro 789 ata que AssumeUDPEncapsulationContextOnSendRule se pon en 2 baixo a clave PolicyAgent e a máquina se reinicia, e a falla segue sendo indistinguible dun porto pechado. Os clientes detrás de NAT son máis fáciles: cun enderezo público no servidor, NAT-T sobre UDP 4500 transpórtaos e ese valor non intervén.
Unha vez levantado PPP, un MTU con burato negro imita un túnel morto: os paquetes pequenos pasan, un aperto de mans TLS ou a carga dunha páxina colgan, e o cliente pode seguir mostrando conectado. Baixe o MTU da interface ou fixe o MSS na pasarela antes de culpar o servidor. O encamiñamento de túnel dividido é o outro impostor; unha subrede enviada coa máscara equivocada deixa o túnel san e unha aplicación inalcanzable. Un nome de host privado engade o seu propio salto: se a consulta sae polo resolvedor local, o nome non se resolve antes de que se probe ningunha ruta.
Lista de comprobación antes de tocar credenciais
Traballa a lista por orde e detense no primeiro elemento que falle. Cada paso é barato, e cada un descarta toda unha clase de edicións.
- Confirme que a asociación existe en ambos os extremos, emparellada pola identidade do par e non por unha etiqueta de conectado.
- Confirme que o UDP 1701 chega a xl2tpd; unha asociación sen chamada é a súa falla.
- Lea o veredicto de PPP e, se autenticou, o resultado de IPCP, antes de supor que o contrasinal é incorrecto.
- Só agora volva introducir as credenciais no formato que espera o servidor, porque un prefixo de dominio cambia a conta.
- Se segue fallando, capture ambos os extremos con marcas de tempo aliñadas e compare etapa por etapa.
Parar no segundo paso significa un problema de ruta ou de encapsulación, e ningunha edición do contrasinal o moverá. Parar no terceiro paso significa que o rexistro xa nomea o método ou o conxunto de enderezos que hai que arranxar. En ambos os casos o seguinte cambio é un que pode xustificar, e deixa de dar voltas a axustes que nunca interviron.