LCP finalitzat per l’homòleg a PPTP: activeu primer MPPE
L’LCP finalitzat per l’homòleg en un enllaç PPTP és un desajust de la política PPP. Compareu els requisits d’MPPE, llegiu el registre del pppd i proveu els noms dels hooks abans de tocar les credencials.
L’enllaç s’autentica, el client informa que està connectat i, un segon després, el registre es tanca amb LCP finalitzat per l’homòleg. Aquesta línia prové de la negociació PPP dins del túnel GRE, així que el transport ja funcionava i els dos extrems no es posaven d’acord sobre les opcions de l’enllaç. Les contrasenyes i les adreces del servidor normalment no tenen cap culpa aquí. La política de xifratge és el primer que cal comparar i, a Linux, el fitxer d’homòleg del pppd és el primer lloc on mirar.
Què diu la fallada d’LCP sobre l’etapa PPP
PPTP embolcalla PPP dins de GRE: la connexió de control TCP 1723 prepara la trucada, GRE transporta la càrrega i després LCP negocia opcions com el protocol d’autenticació, la compressió i MPPE. L’homòleg finalitza LCP quan una opció obligatòria no li és acceptable. Un registre on l’intercanvi CHAP o MSCHAPv2 es completa i LCP acaba immediatament després és un rebuig de política, no una fallada d’abastabilitat. Si el túnel no arriba mai a la negociació, reviseu el pppd i el seu connector abans de llegir la línia d’LCP.
Hi ha dues condicions prèvies fàcils de passar per alt. El binari pppd ha d’existir i el connector PPTP indicat al fitxer d’homòleg ha d’estar instal·lat; un paquet que falta acaba la trucada abans que es discuteixi cap opció.
Activeu MPPE al costat que el requereix
La decisió real és quin extrem posseeix la política de xifratge. Un client pot oferir MPPE, exigir-lo o refusar-lo, i el servidor fa la mateixa tria. Quan tots dos l’exigeixen, l’enllaç s’aixeca; quan un l’exigeix i l’altre el refusa, LCP acaba.
pty "pptp vpn.example.net --nolaunchpppd"
name alice
remotename PPTP
require-mppe-128Carregueu el mòdul amb modprobe ppp_mppe abans de marcar, perquè require-mppe-128 falla sense ell. A Windows el control equivalent és la pestanya de seguretat de l’entrada VPN, on cal indicar al client que exigeixi xifratge en lloc d’acceptar el que ofereixi el servidor. Si el servidor encara finalitza LCP, pregunteu al seu operador si MPPE és obligatori, opcional o desactivat, ja que un client no pot negociar una protecció que el servidor refusa. Desactivar el xifratge per fer desaparèixer el missatge és la direcció equivocada: elimina l’única protecció que té aquest protocol.
Desou el fitxer d’homòleg que funciona abans d’editar-lo. Una línia require-mppe mal escrita reprodueix la mateixa fallada genèrica d’LCP i us envia al principi.
Llegiu el registre del pppd en lloc de l’applet
Els applets d’escriptori mostren la desconnexió i amaguen el motiu, així que llegiu el relat del dimoni d’un intent. Als sistemes systemd el missatge va al journal; les instal·lacions més antigues escriuen als fitxers de registre tradicionals.
journalctl --since "10 min ago" | grep -i -E "pppd|lcp|mppe"
tail -n 50 /var/log/syslogCerqueu en una finestra al voltant d’una sola trucada en lloc d’un dia sencer de reconnexions, perquè l’opció rebutjada sigui fàcil de veure. El pppd normalment anomena l’opció i la resposta de l’homòleg, cosa que us diu si heu de canviar la vostra proposta o demanar al costat del servidor que relaxi el seu requisit. Manteniu els intents amb marca de temps, perquè comparar dos registres només és útil quan sabeu quines línies pertanyen a quina trucada. Quan no apareix cap intercanvi LCP, la fallada és més amunt de la cadena i MPPE no és el sospitós.
Mantingueu la correcció entre reconnexions: noms de hooks i MTU
Un cop l’enllaç es manté, dos detalls decideixen si sobreviu a una reconnexió. Els hooks viuen a /etc/ppp/ip-up.d i /etc/network/if-up.d, i run-parts processa tots dos directoris, amb un filtre de noms de fitxer que rebutja qualsevol nom amb un punt. Per tant, un script anomenat set-pptp.sh se salta, mentre que set-pptp s’executa. Comproveu el nom abans de depurar el contingut de l’script i, després, establiu l’MTU més petit des de dins d’aquest hook perquè cada nova interfície ppp l’hereti sense cap ordre manual.
run-parts --test /etc/ppp/ip-up.d
ip link set dev ppp0 mtu 1200Per acabar una sessió expressament, apunteu al pid registrat pel pppd en lloc de fer coincidir noms de processos, perquè matar tot el que contingui ppp també tomba enllaços no relacionats. PPTP està obsolet i MS-CHAPv2 és feble, així que tracteu aquestes comprovacions com a manteniment d’un enllaç que ha de continuar funcionant, no com un motiu per desplegar PPTP enlloc nou.