LCP tinapos ng peer sa PPTP: i-enable muna ang MPPE

Nagpapatotoo ang link, nag-uulat ang kliyente na konektado, at makalipas ang isang segundo nagsasara ang log na may LCP na tinapos ng peer. Ang linyang iyon ay galing sa negosasyon ng PPP sa loob ng GRE tunnel, kaya gumagana na ang transport at hindi nagkasundo ang dalawang dulo sa mga opsyon ng link. Ang mga password at address ng server ay karaniwang walang kasalanan dito. Ang patakaran sa encryption ang unang dapat ihambing, at sa Linux ang peer file ng pppd ang unang lugar na titingnan.

Ano ang sinasabi ng pagkabigo ng LCP tungkol sa yugto ng PPP

Binabalot ng PPTP ang PPP sa loob ng GRE: inihahanda ng TCP 1723 control connection ang tawag, dinadala ng GRE ang payload, at pagkatapos ay nakikipagnegosasyon ang LCP sa mga opsyon tulad ng authentication protocol, compression at MPPE. Tinatapos ng peer ang LCP kapag hindi katanggap-tanggap sa kaniyang panig ang isang kinakailangang opsyon. Ang log kung saan natatapos ang palitan ng CHAP o MSCHAPv2 at agad na nagtatapos ang LCP pagkatapos ay pagtanggi sa patakaran, hindi pagkabigo sa maabot. Kung hindi man lang umabot ang tunnel sa negosasyon, suriin ang pppd at ang plugin nito bago basahin ang linya ng LCP.

Dalawang paunang kondisyon ang madaling makaligtaan. Dapat mayroong pppd binary, at ang PPTP plugin na binanggit sa peer file ay dapat nakainstall; ang kulang na package ay nagtatapos sa tawag bago pa mapag-usapan ang anumang opsyon.

I-enable ang MPPE sa panig na nangangailangan nito

Ang tunay na desisyon ay kung aling dulo ang may-ari ng patakaran sa encryption. Maaaring mag-alok, mangailangan o tumanggi ang kliyente sa MPPE, at ganoon din ang pinipili ng server. Kapag pareho silang nangangailangan, bumabangon ang link; kapag ang isa ay nangangailangan at ang isa ay tumatanggi, nagtatapos ang LCP.

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

I-load ang module gamit ang modprobe ppp_mppe bago tumawag, dahil nabibigo ang require-mppe-128 kung wala ito. Sa Windows, ang katumbas na kontrol ay ang security tab ng VPN entry, kung saan dapat sabihin sa kliyente na hingin ang encryption sa halip na tanggapin ang iniaalok ng server. Kung tinatapos pa rin ng server ang LCP, tanungin ang operator nito kung ang MPPE ay sapilitan, opsyonal o naka-disable, dahil hindi makipagnegosasyon ang kliyente sa proteksyong tinatanggihan ng server. Ang patayin ang encryption para mawala ang mensahe ay maling direksyon: inaalis nito ang tanging proteksyon na mayroon ang protocol na ito.

I-save ang gumaganang peer file bago ito i-edit. Ang maling na-type na require-mppe na linya ay muling gumagawa ng parehong pangkalahatang pagkabigo ng LCP at ibinabalik ka sa simula.

Basahin ang sariling log ng pppd, hindi ang applet

Ipinapakita ng mga desktop applet ang pagdiskonekta at itinatago ang dahilan, kaya basahin ang salaysay ng daemon tungkol sa isang pagtatangka. Sa mga systemd system, napupunta ang mensahe sa journal; ang mas lumang setup ay nagsusulat sa tradisyonal na mga log file.

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

Maghanap sa isang window sa paligid ng isang tawag lamang sa halip na isang buong araw ng mga muling pagkonekta, para madaling makita ang tinanggihang opsyon. Karaniwang binabanggit ng pppd ang opsyon at ang sagot ng peer, na nagsasabi kung babaguhin mo ang sarili mong panukala o hihilingin sa panig ng server na luwagan ang kinakailangan. Panatilihing may timestamp ang mga pagtatangka, dahil makabuluhan lamang ang paghahambing ng dalawang log kapag alam mo kung aling mga linya ang kabilang sa aling tawag. Kapag wala talagang lumabas na palitan ng LCP, mas maaga sa kadena ang depekto at hindi suspect ang MPPE.

Panatilihin ang pagwawasto sa mga muling pagkonekta: mga pangalan ng hook at MTU

Kapag nanatili ang link, dalawang detalye ang nagpapasya kung malalampasan nito ang muling pagkonekta. Nasa /etc/ppp/ip-up.d at /etc/network/if-up.d ang mga hook, at pinoproseso ng run-parts ang dalawang direktoryo, na ang filter sa pangalan ng file ay tumatanggi sa anumang may tuldok. Kaya nilalaktawan ang script na tinatawag na set-pptp.sh, habang pinapatakbo ang set-pptp. Suriin ang pangalan bago i-debug ang nilalaman ng script, pagkatapos ay itakda ang mas maliit na MTU mula sa loob ng hook na iyon upang manahin ito ng bawat bagong ppp interface nang walang manwal na utos.

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

Para sadyang tapusin ang isang session, i-target ang pid na naitala ng pppd sa halip na itugma ang mga pangalan ng proseso, dahil ang pagpatay sa lahat ng may ppp ay pumuputol din ng mga hindi kaugnay na link. Luma na ang PPTP at mahina ang MS-CHAPv2, kaya ituring ang mga pagsusuring ito bilang maintenance ng link na dapat magpatuloy sa paggana, hindi bilang dahilan para mag-deploy ng PPTP sa anumang bagong lugar.