LCP ukončen protistranou u PPTP: nejdřív zapněte MPPE

Spojení projde autentizací, klient hlásí připojení a o sekundu později se log uzavře hláškou LCP ukončeno protistranou. Tento řádek pochází z vyjednávání PPP uvnitř tunelu GRE, takže transport už fungoval a obě strany se rozešly v názoru na volby spoje. Hesla a adresy serveru zde obvykle nemají vinu. Politika šifrování je první věc k porovnání a v Linuxu je prvním místem k pohledu soubor protistrany pppd.

Co selhání LCP říká o fázi PPP

PPTP zabaluje PPP do GRE: řídicí spojení TCP 1723 připraví volání, GRE nese užitečné zatížení a poté LCP vyjednává volby, jako jsou autentizační protokol, komprese a MPPE. Protistrana ukončí LCP, když je požadovaná volba na její straně nepřijatelná. Log, ve kterém výměna CHAP nebo MSCHAPv2 skončí a LCP hned poté skončí, je odmítnutí politiky, nikoli selhání dosažitelnosti. Pokud se tunel vůbec nedostane k vyjednávání, zkontrolujte pppd a jeho plugin dřív, než začnete číst řádek LCP.

Dvě předpoklady se snadno přehlédnou. Binárka pppd musí existovat a plugin PPTP uvedený v souboru protistrany musí být nainstalovaný; chybějící balíček ukončí vytáčení dřív, než se probere jakákoli volba.

Zapněte MPPE na straně, která ho vyžaduje

Skutečné rozhodnutí je, který konec vlastní politiku šifrování. Klient může MPPE nabídnout, vyžadovat nebo odmítnout a server volí stejně. Když ho vyžadují obě strany, linka se zvedne; když jedna vyžaduje a druhá odmítá, LCP skončí.

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

Před vytáčením načtěte modul pomocí modprobe ppp_mppe, protože bez něj require-mppe-128 selže. Ve Windows je ekvivalentem karta zabezpečení záznamu VPN, kde je třeba klientovi nařídit, aby šifrování vyžadoval, místo aby přijal, co server nabídne. Pokud server LCP stále ukončuje, zeptejte se jeho provozovatele, zda je MPPE povinné, volitelné, nebo vypnuté, protože klient nemůže vyjednat ochranu, kterou server odmítá. Vypnout šifrování, aby zpráva zmizela, je špatný směr: odstraňuje jedinou ochranu, kterou tento protokol má.

Než soubor protistrany upravíte, uložte funkční verzi. Špatně napsaný řádek require-mppe reprodukuje stejné obecné selhání LCP a vrátí vás na začátek.

Čtěte vlastní log pppd, ne applet

Desktopové applety ukazují odpojení a skrývají důvod, proto si přečtěte záznam démona o jednom pokusu. V systémech se systemd zpráva skončí v journalu; starší nastavení zapisují do tradičních logovacích souborů.

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

Prohledejte okno kolem jediného vytáčení místo celého dne opětovných připojení, aby byla odmítnutá volba snadno k vidění. pppd obvykle uvede volbu i odpověď protistrany, což vám řekne, zda změnit vlastní návrh, nebo požádat stranu serveru o zmírnění požadavku. Uchovávejte pokusy s časovými značkami, protože porovnávat dva logy má smysl jen tehdy, když víte, které řádky patří ke kterému volání. Když se neobjeví žádná výměna LCP, závada je dřív v řetězu a MPPE není podezřelý.

Udržte opravu i při opětovném připojení: názvy hooků a MTU

Jakmile linka zůstane stát, rozhodují o tom, zda přežije opětovné připojení, dva detaily. Hooky žijí v /etc/ppp/ip-up.d a /etc/network/if-up.d a oba adresáře zpracovává run-parts, jehož filtr názvů souborů odmítá cokoli s tečkou. Skript jménem set-pptp.sh se proto přeskočí, zatímco set-pptp se spustí. Ověřte název, než začnete ladit obsah skriptu, a potom v tomto hooku nastavte menší MTU, aby ho každé nové rozhraní ppp zdědilo bez ručního příkazu.

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

Chcete-li relaci ukončit záměrně, ciťte na pid zaznamenaný pppd, místo abyste porovnávali názvy procesů, protože zabití všeho, co obsahuje ppp, strhne i nesouvisející linky. PPTP je zastaralé a MS-CHAPv2 je slabé, takže tyto kontroly berte jako údržbu linky, která musí dál fungovat, ne jako důvod nasazovat PPTP kdekoli nově.