LCP lõpetas partner PPTP-l: lubage esmalt MPPE

Lüli autendib, klient teatab ühendusest ja sekund hiljem sulgub logi kirjega LCP lõpetas partner. See rida pärineb PPP läbirääkimistest GRE-tunneli sees, seega transport juba töötas ja kaks otsa ei olnud lüli valikute osas ühel nõul. Paroolid ja serveri aadressid on siin tavaliselt süütud. Krüpteerimispoliitika on esimene asi, mida võrrelda, ja Linuxis on pppd partnerfail esimene koht, kuhu vaadata.

Mida LCP tõrge PPP-etapi kohta ütleb

PPTP mähkib PPP GRE sisse: TCP 1723 juhtühendus seab kõne üles, GRE kannab koormust ja seejärel läbiräägib LCP selliseid valikuid nagu autentimisprotokoll, tihendamine ja MPPE. Partner lõpetab LCP, kui nõutav valik ei ole tema poolel vastuvõetav. Logi, kus CHAP või MSCHAPv2 vahetus lõpeb ja LCP lõpeb kohe pärast seda, on poliitika tagasilükkamine, mitte kättesaadavuse tõrge. Kui tunnel ei jõua üldse läbirääkimisteni, kontrollige pppd-d ja selle pluginat enne LCP rea lugemist.

Kaks eeldust jäävad kergesti märkamata. pppd binaarfail peab olemas olema ja partnerfailis nimetatud PPTP plugina peab olema paigaldatud; puuduv pakett lõpetab kõne enne, kui ühtegi valikut arutatakse.

Lubage MPPE sellel poolel, kes seda nõuab

Tegelik otsus on, kummale poolele krüpteerimispoliitika kuulub. Klient võib MPPE-d pakkuda, nõuda või keelduda ja server teeb sama valiku. Kui mõlemad seda nõuavad, tõuseb lüli üles; kui üks nõuab ja teine keeldub, lõpeb LCP.

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

Laadige moodul modprobe ppp_mppe abil enne valimist, sest ilma selleta ebaõnnestub require-mppe-128. Windowsis on samaväärne juhtelement VPN-kirje turbevahekaart, kus kliendile tuleb öelda, et ta nõuaks krüpteerimist, mitte ei aktsepteeriks seda, mida server pakub. Kui server ikka LCP lõpetab, küsige selle operaatorilt, kas MPPE on kohustuslik, valikuline või välja lülitatud, sest klient ei saa läbi rääkida kaitset, millest server keeldub. Krüpteerimise väljalülitamine, et teade kaoks, on vale suund: see eemaldab ainsa kaitse, mis sellel protokollil on.

Salvestage töötav partnerfail enne selle muutmist. Valesti trükitud require-mppe rida taastoodab sama üldise LCP tõrke ja saadab teid tagasi algusesse.

Lugege pppd enda logi, mitte rakendust

Töölaua rakendused näitavad katkestust ja varjavad põhjust, seega lugege deemoni raportit ühe katse kohta. systemd süsteemides jõuab teade journalisse; vanemad seadistused kirjutavad traditsioonilistesse logifailidesse.

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

Otsige aknas ühe kõne ümber, mitte terve päeva taasühenduste hulgast, et tagasilükatud valik oleks kergesti märgatav. pppd nimetab tavaliselt valiku ja partneri vastuse, mis ütleb, kas muuta oma pakkumist või paluda serveripoolel oma nõuet leevendada. Hoidke katsed ajatemplitega, sest kahe logi võrdlemine on kasulik ainult siis, kui teate, millised read kuuluvad millisesse kõnesse. Kui LCP vahetust ei ilmugi, asub viga ahelas varem ja MPPE ei ole kahtlusalune.

Hoidke parandus üle taasühenduste: konksude nimed ja MTU

Kui lüli püsib, otsustavad kaks detaili, kas see elab taasühenduse üle. Konksud asuvad kaustades /etc/ppp/ip-up.d ja /etc/network/if-up.d ning mõlemat kausta töötleb run-parts, mille failinime filter lükkab tagasi kõik punkti sisaldava. Nii jäetakse vahele skript nimega set-pptp.sh, samal ajal kui set-pptp käivitatakse. Kontrollige nime enne skripti sisu silumist, seejärel seadke väiksem MTU selle konksu seest, et iga uus ppp-liides päriks selle ilma käsitsi käsuta.

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

Seansi meelega lõpetamiseks sihtige pppd poolt kirja pandud pid-i, selle asemel et sobitada protsessinimesid mustriga, sest kõige ppp-d sisaldava tapmine rebib maha ka mitteseotud lülid. PPTP on iganenud ja MS-CHAPv2 on nõrk, seega käsitlege neid kontrolle hooldusena lülile, mis peab edasi töötama, mitte põhjusena PPTP-d kuhugi uude kohta juurutada.