LCP ukončené partnerom na PPTP: najprv zapnite MPPE

Spojenie prejde autentizáciou, klient hlási pripojenie a o sekundu neskôr sa log uzavrie hláškou LCP ukončené partnerom. Tento riadok pochádza z vyjednávania PPP vnútri tunela GRE, takže transport už fungoval a obe strany sa nezhodli na možnostiach spojenia. Heslá a adresy servera tu zvyčajne nemajú vinu. Politika šifrovania je prvá vec na porovnanie a v Linuxe je prvým miestom na pohľad súbor partnera pppd.

Čo zlyhanie LCP hovorí o fáze PPP

PPTP zabalí PPP do GRE: riadiace spojenie TCP 1723 pripraví volanie, GRE nesie užitočné zaťaženie a potom LCP vyjednáva možnosti, ako sú autentizačný protokol, kompresia a MPPE. Partner ukončí LCP, keď je požadovaná možnosť na jeho strane neprijateľná. Log, v ktorom sa výmena CHAP alebo MSCHAPv2 dokončí a LCP sa hneď potom skončí, je odmietnutie politiky, nie zlyhanie dostupnosti. Ak sa tunel vôbec nedostane k vyjednávaniu, skontrolujte pppd a jeho plugin, skôr než začnete čítať riadok LCP.

Dve predpoklady sa ľahko prehliadnu. Binárka pppd musí existovať a plugin PPTP uvedený v súbore partnera musí byť nainštalovaný; chýbajúci balík ukončí volanie skôr, než sa preberie akákoľvek možnosť.

Zapnite MPPE na strane, ktorá ho vyžaduje

Skutočné rozhodnutie je, ktorá strana vlastní politiku šifrovania. Klient môže MPPE ponúknuť, vyžadovať alebo odmietnuť a server robí rovnakú voľbu. Keď ho vyžadujú obe strany, linka sa zdvihne; keď jedna vyžaduje a druhá odmieta, LCP sa skončí.

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

Pred vytáčaním načítajte modul pomocou modprobe ppp_mppe, pretože bez neho require-mppe-128 zlyhá. Vo Windows je ekvivalentom karta zabezpečenia záznamu VPN, kde treba klientovi prikázať, aby šifrovanie vyžadoval, namiesto toho, aby prijal, čo ponúkne server. Ak server LCP stále ukončuje, opýtajte sa jeho prevádzkovateľa, či je MPPE povinné, voliteľné alebo vypnuté, keďže klient nemôže vyjednať ochranu, ktorú server odmieta. Vypnutie šifrovania, aby správa zmizla, je nesprávny smer: odstraňuje jedinú ochranu, ktorú tento protokol má.

Pred úpravou si uložte funkčný súbor partnera. Nesprávne napísaný riadok require-mppe reprodukuje to isté všeobecné zlyhanie LCP a vráti vás na začiatok.

Čítajte vlastný log pppd, nie applet

Desktopové applety zobrazujú odpojenie a skrývajú dôvod, preto si prečítajte správu démona o jednom pokuse. V systémoch so systemd sa správa dostane do journalu; staršie nastavenia píšu do tradičných logovacích súborov.

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

Hľadajte v okne okolo jedného volania namiesto celého dňa opätovných pripojení, aby bola odmietnutá možnosť ľahko viditeľná. pppd zvyčajne uvedie možnosť a odpoveď partnera, čo vám povie, či zmeniť vlastný návrh alebo požiadať stranu servera o zmiernenie požiadavky. Uchovávajte pokusy s časovými značkami, pretože porovnávať dva logy má zmysel len vtedy, keď viete, ktoré riadky patria ktorému volaniu. Keď sa neobjaví žiadna výmena LCP, porucha je skôr v reťazci a MPPE nie je podozrivý.

Udržte opravu pri opätovných pripojeniach: názvy hookov a MTU

Keď linka vydrží, dva detaily rozhodujú, či prežije opätovné pripojenie. Hooky žijú v /etc/ppp/ip-up.d a /etc/network/if-up.d a oba adresáre spracúva run-parts, ktorého filter názvov súborov odmieta všetko s bodkou. Skript s názvom set-pptp.sh sa preto preskočí, zatiaľ čo set-pptp sa spustí. Overte názov, skôr než začnete ladiť obsah skriptu, a potom v tomto hooku nastavte menšie MTU, aby ho každé nové rozhranie ppp zdedilo bez ručného príkazu.

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

Ak chcete reláciu ukončiť zámerne, cielite na pid zaznamenaný pppd, namiesto porovnávania názvov procesov, pretože zabitie všetkého, čo obsahuje ppp, strhne aj nesúvisiace linky. PPTP je zastarané a MS-CHAPv2 je slabé, takže tieto kontroly berte ako údržbu linky, ktorá musí ďalej fungovať, nie ako dôvod nasadzovať PPTP na novom mieste.