LCP deur eweknie beëindig op PPTP: aktiveer eers MPPE

Die skakel verifieer, die kliënt rapporteer verbind, en ’n sekonde later sluit die log af met LCP wat deur die eweknie beëindig is. Daardie reël kom uit die PPP-onderhandeling binne die GRE-tonnel, dus die vervoer het reeds gewerk en die twee kante het oor skakelopsies verskil. Wagwoorde en bedieneradresse is hier gewoonlik onskuldig. Enkripsiebeleid is die eerste ding om te vergelyk, en op Linux is die pppd-eweknie-lêer die eerste plek om te kyk.

Wat die LCP-fout oor die PPP-fase sê

PPTP verpak PPP binne GRE: die TCP 1723-beheerverbinding stel die oproep op, GRE dra die vrag, en LCP onderhandel dan opsies soos die verifikasieprotokol, kompressie en MPPE. Die eweknie beëindig LCP wanneer ’n vereiste opsie aan sy kant onaanvaarbaar is. ’n Log waar die CHAP- of MSCHAPv2-uitruiling voltooi word en LCP dadelik daarna eindig, is ’n beleidsverwerping, nie ’n bereikbaarheidsfout nie. As die tonnel glad nie onderhandeling bereik nie, ondersoek pppd en sy inprop voordat jy die LCP-reël lees.

Twee voorwaardes word maklik gemis. Die pppd-program moet bestaan, en die PPTP-inprop wat in die eweknie-lêer genoem word, moet geïnstalleer wees; ’n ontbrekende pakket beëindig die skakel voordat enige opsie bespreek word.

Aktiveer MPPE aan die kant wat dit vereis

Die werklike besluit is watter kant die enkripsiebeleid besit. ’n Kliënt kan MPPE aanbied, vereis of weier, en die bediener maak dieselfde keuse. Wanneer albei dit vereis, kom die skakel op; wanneer een dit vereis en die ander weier, eindig LCP.

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

Laai die module met modprobe ppp_mppe voordat jy skakel, want require-mppe-128 misluk sonder dit. Op Windows is die ekwivalent die sekuriteit-oortjie van die VPN-inskrywing, waar die kliënt aangesê moet word om enkripsie te vereis eerder as om te aanvaar wat die bediener ook al bied. As die bediener steeds LCP beëindig, vra sy operateur of MPPE verpligtend, opsioneel of gedeaktiveer is, want ’n kliënt kan nie beskerming onderhandel wat die bediener weier nie. Om enkripsie af te skakel sodat die boodskap verdwyn, is die verkeerde rigting: dit verwyder die enigste beskerming wat hierdie protokol het.

Stoor die werkende eweknie-lêer voordat jy dit wysig. ’n Verkeerd getikte require-mppe-reël reproduseer dieselfde generiese LCP-fout en stuur jou terug na die begin.

Lees pppd se eie log eerder as die applet

Dekstop-applets wys die ontkoppeling en versteek die rede, so lees die daemon se weergawe van een poging. Op systemd-stelsels beland die boodskap in die joernaal; ouer opstellings skryf na die tradisionele loglêers.

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

Grep ’n venster rondom een enkele skakelpoging eerder as ’n hele dag se herverbindings, sodat die verwerpte opsie maklik opval. pppd noem gewoonlik die opsie en die eweknie se antwoord, wat jou sê of jy jou eie voorstel moet verander of die bedienerkant moet vra om sy vereiste te verslap. Hou pogings van tydstempels voorsien, want om twee logs te vergelyk is net nuttig wanneer jy weet watter reëls by watter oproep hoort. Wanneer daar glad geen LCP-uitruiling verskyn nie, lê die fout vroeër in die ketting en is MPPE nie die verdagte nie.

Hou die regstelling oor herverbindings: haakname en MTU

Sodra die skakel bly staan, besluit twee besonderhede of dit ’n herverbinding oorleef. Hake woon in /etc/ppp/ip-up.d en /etc/network/if-up.d, en albei gidse word deur run-parts verwerk, wie se lêernaamfilter enigiets met ’n punt verwerp. ’n Skrip genaamd set-pptp.sh word dus oorgeslaan, terwyl set-pptp uitgevoer word. Kontroleer die naam voordat jy die skrip se inhoud ontfout, en stel dan die kleiner MTU van binne daardie haak sodat elke nuwe ppp-koppelvlak dit sonder ’n handmatige opdrag erf.

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

Om ’n sessie doelbewus te beëindig, teiken pppd se aangetekende pid eerder as om prosessname patroon te pas, want om alles dood te maak wat ppp bevat, breek ook onverwante skakels af. PPTP is uitgefaseer en MS-CHAPv2 is swak, so behandel hierdie kontroles as instandhouding vir ’n skakel wat moet bly werk, nie as ’n rede om PPTP ergens nuuts te ontplooi nie.