Por que PPTP e L2TP/IPsec se deteñen antes do nome de usuario?

Que non apareza o nome de usuario é un agasallo diagnóstico: PPP aínda non arrincou, así que a conta, o contrasinal e a política de dominio aínda non se consultaron. Nunha conexión PPTP ou L2TP/IPsec o cliente pide credenciais só despois de que o túnel exista e o servidor iniciase unha sesión PPP. Todo o que pode fallar antes dese momento é transporte, intercambio de claves ou montaxe do túnel, unha superficie moito menor que «a VPN está rota».

Un aviso ausente reduce o fallo a tres etapas

Anote a última etapa que tivese éxito visible, porque cada unha ten un dono distinto e unha solución distinta. Adiviñar a configuración da conta mentres está atascado dúas etapas antes é como se perde unha tarde.

Un cliente que expira sen aviso nunca obtivo unha asociación IPsec, así que o fallo está en IKE ou en se os seus paquetes chegan sequera á pasarela. O que informa que está verificando credenciais e logo cae chegou máis lonxe do que suxire a mensaxe. Un aviso seguido dun rexeitamento é autenticación PPP, e iso pertence a un artigo de conta, non a este.

Primeira etapa: o protocolo que unha devasa descarta en silencio

PPTP necesita TCP 1723 para o seu canal de control e o protocolo IP 47 para a ruta de datos, e os dous viaxan por separado. Moitas redes reenvían 1723 e descartan o protocolo 47, o que produce un túnel que negocia e despois non transporta absolutamente nada. Un encamiñador que fai NAT tamén necesita un paso compatible con GRE, e unha ruta de acceso só IPv6 non pode transportar PPTP baixo ningunha configuración.

L2TP sobre IPsec gasta o porto 500 en IKE e o porto 4500 na travessía de NAT, e despois envolve o propio tráfico L2TP en 1701, mentres ESP transporta a carga protexida en canto existe a asociación. Permita os dous portos de control pero non ESP e obterá exactamente o síntoma do título: progreso visible e logo un cliente morto antes de calquera diálogo de credenciais. Probar desde un punto de acceso móbil é unha forma barata de separar un problema de cliente dun problema de ruta.

Segunda etapa: unha clave que non é a clave, unha proposta que non se ofrece

Unha clave precompartida que non coincide falla rápido e en silencio, e a versión habitual é unha clave que parece correcta na pantalla mentres leva un salto de liña pegado ou un espazo final. Nun cliente Linux o diálogo non é necesariamente a fonte da verdade: o complemento L2TP de NetworkManager garda segredos en ficheiros baixo /etc/ipsec.d/, e un ficheiro antigo por conexión que /etc/ipsec.secrets aínda inclúe usarase no canto do que acaba de escribir. Copie ese ficheiro a un lugar seguro, sáqueo da ruta de inclusión e despois volva escribir a clave a man.

A outra metade desta etapa é a proposta. Os dous extremos deben poñerse de acordo no mesmo conxunto de algoritmos de fase 1 — cifrado, integridade e grupo Diffie-Hellman — e en transformacións ESP coincidentes para a fase 2, ou a asociación non se forma en absoluto. Unha pasarela que só ofrece 3DES, SHA1 e MODP1024 rexeitará un cliente configurado para algoritmos máis fortes, e o seu rexistro nomea a transformación rexeitada. O rexistro nomea a discrepancia se o le en lugar de reiniciar o servizo outra vez. En vez de copiar unha cadea de algoritmos dun fío de foro, pregunte á pasarela que transformacións negociará realmente: ike-scan apuntado ao seu enderezo devolve as transformacións que negociará. Se a única oferta é criptografía que a súa política xa non permite, a corrección corresponde á pasarela, non a unha degradación do cliente.

En Windows a clave e o método de autenticación viven no perfil de VPN, e unha discrepancia aparece antes do aviso de credenciais e non despois. Cando o receptor é un Windows Server, confirme que o rol de acceso remoto está instalado, que o certificado coincide co nome ao que se conectan os clientes e que ningún filtro de portos é máis estreito que os protocolos anteriores.

Terceira etapa: o túnel existe e PPP nunca arrinca

Cando IKE remata e o aviso segue sen aparecer, mire o daemon do túnel en lugar da devasa. L2TP necesita algo escoitando en UDP 1701 — xl2tpd ou kl2tpd en Linux, o servizo de acceso remoto en Windows — e un servizo instalado pero detido vese desde o cliente igual que un paquete descartado. Comprobe o oínte antes de reabrir regras que xa verificou. Despois PPP ten que negociar, e o primeiro intercambio LCP é onde adoita aterrar un fallo silencioso.

Unha trampa desta etapa non é ningún fallo de rede: Windows permite unha soa conexión dun tipo de VPN dado á vez, así que un segundo intento devolve o erro 937, «outra conexión deste tipo está en uso». É unha regra local, e a forma de sortearla é outro dispositivo, outro tipo de túnel ou compartir a única conexión que xa existe.

Lea o rexistro en orde de etapas en lugar de adiviñar

Detña o cliente, volva inicialo e lea os compoñentes na orde en que escriben no rexistro. É dicir, primeiro o daemon IPsec — strongSwan ou Libreswan, e ipsec --version dille cal — logo o daemon L2TP, logo pppd. O compoñente que escribise en último lugar antes do fallo marca a etapa que hai que investigar, porque todo o que vén despois na secuencia non se executou en absoluto.

Verifique cunha conexión nova e non cunha sesión gardada, porque un cliente que se reconecta desde a caché pode saltarse partes do intercambio e reproducir un resultado obsoleto. Confirme alcance, intercambio de claves, túnel e PPP un a un, nesa orde. Entón o aviso ausente deixa de ser un misterio e convértese na segunda liña dunha lista coa que realmente se pode traballar. Esa lista é tamén o que lle entrega ao equipo de rede, ao que doutro modo se pediría que revisase a devasa por un fallo que vive nun daemon non iniciado.