LCP terminado polo par en PPTP: active MPPE primeiro

Que o par termine LCP nunha ligazón PPTP é un desaxuste da política PPP. Compare os requisitos de MPPE, lea o rexistro de pppd e comprobe os nomes dos hooks antes de tocar as credenciais.

A ligazón autentícase, o cliente informa de que está conectado e, un segundo despois, o rexistro péchase con LCP terminado polo par. Esa liña vén da negociación PPP dentro do túnel GRE, así que o transporte xa funcionaba e os dous extremos non coincidían nas opcións da ligazón. Os contrasinais e os enderezos do servidor adoitan ser inocentes aquí. A política de cifrado é o primeiro que hai que comparar e, en Linux, o ficheiro de par de pppd é o primeiro lugar onde mirar.

Que di o fallo de LCP sobre a etapa PPP

PPTP envolve PPP dentro de GRE: a conexión de control TCP 1723 prepara a chamada, GRE leva a carga e despois LCP negocia opcións como o protocolo de autenticación, a compresión e MPPE. O par termina LCP cando unha opción obrigatoria non é aceptable pola súa parte. Un rexistro no que o intercambio CHAP ou MSCHAPv2 se completa e LCP remata xusto despois é un rexeitamento de política, non un fallo de accesibilidade. Se o túnel non chega nunca á negociación, revise pppd e o seu complemento antes de ler a liña de LCP.

Hai dúas condicións previas fáciles de pasar por alto. O binario pppd debe existir e o complemento PPTP indicado no ficheiro de par debe estar instalado; un paquete ausente remata a chamada antes de que se discuta calquera opción.

Active MPPE no lado que o esixe

A decisión real é que extremo posúe a política de cifrado. Un cliente pode ofrecer MPPE, esixilo ou rexeitalo, e o servidor fai a mesma elección. Cando ambos o esixen, a ligazón sobe; cando un o esixe e o outro o rexeita, LCP remata.

pty "pptp vpn.example.net --nolaunchpppd"
name alice
remotename PPTP
require-mppe-128

Cargue o módulo con modprobe ppp_mppe antes de marcar, porque require-mppe-128 falla sen el. En Windows o control equivalente é a lapela de seguridade da entrada VPN, onde hai que indicar ao cliente que esixa cifrado en lugar de aceptar o que ofreza o servidor. Se o servidor segue terminando LCP, pregunte ao seu operador se MPPE é obrigatorio, opcional ou está desactivado, xa que un cliente non pode negociar unha protección que o servidor rexeita. Desactivar o cifrado para que a mensaxe desapareza é a dirección equivocada: elimina a única protección que ten este protocolo.

Garde o ficheiro de par que funciona antes de editalo. Unha liña require-mppe mal escrita reproduce o mesmo fallo xenérico de LCP e devólveo ao principio.

Lea o rexistro propio de pppd en lugar do applet

Os applets de escritorio mostran a desconexión e ocultan o motivo, así que lea o relato do daemon sobre un intento. Nos sistemas con systemd a mensaxe acaba no journal; as configuracións máis antigas escriben nos ficheiros de rexistro tradicionais.

journalctl --since "10 min ago" | grep -i -E "pppd|lcp|mppe"
tail -n 50 /var/log/syslog

Busque nunha xanela arredor dunha soa chamada en lugar dun día enteiro de reconexións, para que a opción rexeitada sexa fácil de ver. pppd adoita nomear a opción e a resposta do par, o que lle di se debe cambiar a súa propia proposta ou pedir ao lado do servidor que relaxe o seu requisito. Manteña os intentos con marca de tempo, porque comparar dous rexistros só serve cando sabe que liñas pertencen a que chamada. Cando non aparece ningún intercambio LCP, a avaría está máis arriba na cadea e MPPE non é o sospeitoso.

Manteña a corrección entre reconexións: nomes de hooks e MTU

Unha vez que a ligazón se mantén, dous detalles deciden se sobrevive a unha reconexión. Os hooks viven en /etc/ppp/ip-up.d e /etc/network/if-up.d, e run-parts procesa ambos directorios, cun filtro de nomes de ficheiro que rexeita todo o que conteña un punto. Por iso omítese un script chamado set-pptp.sh, mentres que set-pptp se executa. Comprobe o nome antes de depurar o contido do script e, despois, fixe a MTU máis pequena desde dentro dese hook para que cada nova interface ppp a herde sen un comando manual.

run-parts --test /etc/ppp/ip-up.d
ip link set dev ppp0 mtu 1200

Para terminar unha sesión a propósito, apunte ao pid rexistrado por pppd en lugar de facer coincidir nomes de procesos, porque matar todo o que conteña ppp tamén derruba ligazóns non relacionadas. PPTP está obsoleto e MS-CHAPv2 é débil, así que trate estas comprobacións como mantemento dunha ligazón que debe seguir funcionando, non como un motivo para despregar PPTP en ningún sitio novo.

Artigos relacionados