LCP prekinil partner na PPTP: najprej omogočite MPPE

Povezava se overi, odjemalec sporoči povezavo in sekundo pozneje se dnevnik zapre z LCP prekinil partner. Ta vrstica prihaja iz pogajanj PPP znotraj tunela GRE, torej je transport že deloval in oba konca se nista strinjala glede možnosti povezave. Gesla in naslovi strežnika tu običajno niso krivi. Politika šifriranja je prva stvar za primerjavo, v Linuxu pa je datoteka partnerja pppd prvo mesto, kamor je treba pogledati.

Kaj odpoved LCP pove o fazi PPP

PPTP ovije PPP v GRE: krmilna povezava TCP 1723 pripravi klic, GRE prenaša tovor, nato pa LCP pogaja možnosti, kot so protokol overjanja, stiskanje in MPPE. Partner prekine LCP, ko zahtevana možnost na njegovi strani ni sprejemljiva. Dnevnik, v katerem se izmenjava CHAP ali MSCHAPv2 zaključi in LCP takoj zatem konča, je zavrnitev politike, ne odpoved dosegljivosti. Če tunel sploh ne doseže pogajanj, preverite pppd in njegov vtičnik, preden preberete vrstico LCP.

Dva pogoja zlahka spregledate. Binarna datoteka pppd mora obstajati, vtičnik PPTP, naveden v datoteki partnerja, pa mora biti nameščen; manjkajoči paket konča klic, preden se pogovorijo o kateri koli možnosti.

Omogočite MPPE na strani, ki ga zahteva

Prava odločitev je, kateri konec ima politiko šifriranja. Odjemalec lahko MPPE ponudi, zahteva ali zavrne, strežnik pa naredi enako izbiro. Ko ga zahtevata oba, se povezava dvigne; ko eden zahteva in drugi zavrne, se LCP konča.

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

Pred klicanjem naložite modul z modprobe ppp_mppe, ker brez njega require-mppe-128 odpove. V Windowsu je enakovredna nastavitev zavihek varnosti vnosa VPN, kjer je treba odjemalcu naročiti, naj zahteva šifriranje, namesto da sprejme, kar ponudi strežnik. Če strežnik še vedno prekine LCP, vprašajte njegovega upravljavca, ali je MPPE obvezen, neobvezen ali onemogočen, saj se odjemalec ne more pogajati o zaščiti, ki jo strežnik zavrača. Izklop šifriranja, da bi sporočilo izginilo, je napačna smer: odstrani edino zaščito, ki jo ima ta protokol.

Pred urejanjem shranite delujočo datoteko partnerja. Napačno vtipkana vrstica require-mppe ponovi isto splošno odpoved LCP in vas vrne na začetek.

Berite dnevnik pppd samega, ne apleta

Namizni apleti prikažejo prekinitev in skrijejo razlog, zato preberite poročilo demona o enem poskusu. V sistemih systemd sporočilo pride v journal; starejše nastavitve pišejo v tradicionalne dnevniške datoteke.

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

Iščite v oknu okoli enega klica namesto celega dneva ponovnih povezav, da bo zavrnjena možnost zlahka opazna. pppd običajno navede možnost in odgovor partnerja, kar vam pove, ali spremeniti svoj predlog ali prositi stran strežnika za omilitev zahteve. Poskuse hranite s časovnimi žigi, ker je primerjanje dveh dnevnikov koristno le, ko veste, katere vrstice pripadajo kateremu klicu. Ko se ne pojavi nobena izmenjava LCP, je napaka prej v verigi in MPPE ni osumljenec.

Ohranite popravek med ponovnimi povezavami: imena hookov in MTU

Ko povezava ostane stabilna, dve podrobnosti odločita, ali bo preživela ponovno povezavo. Hooki živijo v /etc/ppp/ip-up.d in /etc/network/if-up.d, oba imenika pa obdela run-parts, katerega filter imen datotek zavrne vse s piko. Skript z imenom set-pptp.sh se zato preskoči, medtem ko se set-pptp izvede. Preverite ime, preden začnete razhroščevati vsebino skripta, nato v tem hooku nastavite manjši MTU, da ga bo vsak nov vmesnik ppp podedoval brez ročnega ukaza.

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

Če želite sejo namerno končati, ciljajte na pid, ki ga je zabeležil pppd, namesto da bi ujemali imena procesov, ker ubijanje vsega, kar vsebuje ppp, podre tudi nepovezane povezave. PPTP je zastarel in MS-CHAPv2 je šibek, zato te preverbe obravnavajte kot vzdrževanje povezave, ki mora delovati naprej, ne kot razlog za uvajanje PPTP na novem mestu.