LCP afbrudt af peer på PPTP: aktivér MPPE først

Forbindelsen godkendes, klienten rapporterer tilsluttet, og et sekund senere lukker loggen med LCP afbrudt af peer. Den linje kommer fra PPP-forhandlingen inde i GRE-tunnelen, så transporten virkede allerede, og de to ender var uenige om forbindelsens indstillinger. Adgangskoder og serveradresser er normalt uskyldige her. Krypteringspolitikken er det første, der skal sammenlignes, og på Linux er pppd-peerfilen det første sted at kigge.

Hvad LCP-fejlen siger om PPP-fasen

PPTP pakker PPP ind i GRE: TCP 1723-kontrolforbindelsen opretter kaldet, GRE bærer nyttelasten, og derefter forhandler LCP indstillinger som godkendelsesprotokol, komprimering og MPPE. Peeren afbryder LCP, når en krævet indstilling ikke er acceptabel på dens side. En log, hvor CHAP- eller MSCHAPv2-udvekslingen fuldføres, og LCP slutter umiddelbart efter, er en politikafvisning, ikke en fejl i nåbarheden. Hvis tunnelen slet ikke når forhandlingen, skal du undersøge pppd og dets plugin, før du læser LCP-linjen.

To forudsætninger er nemme at overse. pppd-binæren skal findes, og det PPTP-plugin, der er nævnt i peerfilen, skal være installeret; en manglende pakke afslutter opkaldet, før nogen indstilling bliver drøftet.

Aktivér MPPE på den side, der kræver det

Den egentlige beslutning er, hvilken ende der ejer krypteringspolitikken. En klient kan tilbyde MPPE, kræve det eller afvise det, og serveren træffer samme valg. Når begge kræver det, kommer forbindelsen op; når den ene kræver og den anden afviser, slutter LCP.

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

Indlæs modulet med modprobe ppp_mppe før opkald, fordi require-mppe-128 fejler uden det. På Windows er den tilsvarende kontrol sikkerhedsfanen i VPN-posten, hvor klienten skal bedes om at kræve kryptering i stedet for at acceptere, hvad serveren tilbyder. Hvis serveren stadig afbryder LCP, så spørg dens operatør, om MPPE er obligatorisk, valgfrit eller deaktiveret, da en klient ikke kan forhandle beskyttelse, som serveren afviser. At slå kryptering fra for at få meddelelsen til at forsvinde er den forkerte vej: det fjerner den eneste beskyttelse, denne protokol har.

Gem den fungerende peerfil, før du redigerer den. En forkert skrevet require-mppe-linje genskaber den samme generiske LCP-fejl og sender dig tilbage til starten.

Læs pppd’s egen log i stedet for appletten

Skrivebords-appletter viser afbrydelsen og skjuler årsagen, så læs daemonens redegørelse for ét forsøg. På systemd-systemer ender meddelelsen i journalen; ældre opsætninger skriver til de traditionelle logfiler.

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

Søg i et vindue omkring ét opkald i stedet for en hel dags genopkoblinger, så den afviste indstilling er let at se. pppd nævner normalt indstillingen og peerens svar, hvilket fortæller dig, om du skal ændre dit eget forslag eller bede serversiden om at lempe sit krav. Hold forsøgene tidsstemplet, fordi sammenligning af to logge kun er nyttig, når du ved, hvilke linjer der hører til hvilket opkald. Når der slet ikke vises nogen LCP-udveksling, ligger fejlen tidligere i kæden, og MPPE er ikke den mistænkte.

Behold rettelsen gennem genopkoblinger: hook-navne og MTU

Når forbindelsen først holder, afgør to detaljer, om den overlever en genopkobling. Hooks ligger i /etc/ppp/ip-up.d og /etc/network/if-up.d, og begge mapper behandles af run-parts, hvis filnavnsfilter afviser alt med et punktum. Et script med navnet set-pptp.sh springes derfor over, mens set-pptp køres. Tjek navnet, før du fejlretter scriptets indhold, og sæt derefter den mindre MTU inde fra det hook, så hver ny ppp-grænseflade arver den uden en manuel kommando.

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

For at afslutte en session med vilje skal du ramme den pid, pppd har registreret, i stedet for at mønstermatche procesnavne, fordi drab på alt, der indeholder ppp, også river ikke-relaterede forbindelser ned. PPTP er forældet, og MS-CHAPv2 er svag, så behandl disse tjek som vedligeholdelse af en forbindelse, der skal blive ved med at virke, ikke som en grund til at udrulle PPTP nogen nye steder.