Veza prolazi autentifikaciju, klijent javlja da je povezan, a sekundu kasnije dnevnik se zatvara porukom da je LCP prekinut od strane druge strane. Taj red dolazi iz PPP pregovora unutar GRE tunela, dakle transport je već radio, a dvije strane su se razišle oko opcija veze. Lozinke i adrese servera ovdje su obično nedužne. Politika šifrovanja je prva stvar koju treba uporediti, a na Linuxu je pppd datoteka druge strane prvo mjesto za pogledati.

Šta LCP neuspjeh govori o PPP fazi

PPTP umotava PPP u GRE: TCP 1723 kontrolna veza postavlja poziv, GRE nosi sadržaj, a zatim LCP pregovara opcije kao što su protokol autentifikacije, kompresija i MPPE. Druga strana prekida LCP kada joj je obavezna opcija neprihvatljiva. Dnevnik u kojem se CHAP ili MSCHAPv2 razmjena završi i LCP odmah nakon toga okonča je odbijanje politike, a ne neuspjeh dostupnosti. Ako tunel uopšte ne stigne do pregovora, provjerite pppd i njegov dodatak prije čitanja LCP reda.

Dva preduslova se lako propuste. Izvršna datoteka pppd mora postojati, a PPTP dodatak naveden u datoteci druge strane mora biti instaliran; paket koji nedostaje završava poziv prije nego što se bilo koja opcija razmotri.

Omogućite MPPE na strani koja ga zahtijeva

Prava odluka je koja strana posjeduje politiku šifrovanja. Klijent može ponuditi MPPE, zahtijevati ga ili ga odbiti, a server čini isti izbor. Kada ga obje strane zahtijevaju, veza se podiže; kada ga jedna zahtijeva a druga odbija, LCP se završava.

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

Učitajte modul pomoću modprobe ppp_mppe prije pozivanja, jer bez njega require-mppe-128 ne uspijeva. Na Windowsu je ekvivalentna kontrola kartica sigurnosti VPN unosa, gdje klijentu treba narediti da zahtijeva šifrovanje umjesto da prihvati šta god server ponudi. Ako server i dalje prekida LCP, pitajte njegovog operatera je li MPPE obavezan, opcionalan ili onemogućen, jer klijent ne može pregovarati zaštitu koju server odbija. Isključivanje šifrovanja da bi poruka nestala je pogrešan smjer: time se uklanja jedina zaštita koju ovaj protokol ima.

Sačuvajte radnu datoteku druge strane prije nego što je uredite. Pogrešno otkucan red require-mppe reprodukuje isti generički LCP neuspjeh i vraća vas na početak.

Čitajte pppd dnevnik, a ne aplet

Desktop apleti prikazuju prekid i skrivaju razlog, pa pročitajte izvještaj demona o jednom pokušaju. Na systemd sistemima poruka odlazi u dnevnik; starija podešavanja pišu u tradicionalne datoteke dnevnika.

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

Pretražite prozor oko jednog poziva umjesto cijelog dana ponovnih povezivanja, kako bi odbijena opcija bila lako uočljiva. pppd obično navede opciju i odgovor druge strane, što vam kaže da li da promijenite vlastiti predlog ili zamolite serversku stranu da ublaži zahtjev. Vodite pokušaje s vremenskim oznakama, jer je poređenje dva dnevnika korisno samo kada znate koji redovi pripadaju kojem pozivu. Kada se nikakva LCP razmjena ne pojavi, kvar je ranije u lancu i MPPE nije osumnjičeni.

Zadržite popravku kroz ponovna povezivanja: nazivi kuka i MTU

Kada veza ostane stabilna, dva detalja odlučuju hoće li preživjeti ponovno povezivanje. Kuke žive u /etc/ppp/ip-up.d i /etc/network/if-up.d, a oba direktorija obrađuje run-parts, čiji filtar naziva datoteka odbija sve što sadrži tačku. Skripta nazvana set-pptp.sh se zato preskače, dok se set-pptp izvršava. Provjerite naziv prije nego što otklanjate greške u sadržaju skripte, zatim postavite manji MTU unutar te kuke kako bi ga svako novo ppp sučelje naslijedilo bez ručne komande.

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

Da biste namjerno završili sesiju, ciljajte na pid koji je pppd zabilježio umjesto da uparujete imena procesa, jer ubijanje svega što sadrži ppp ruši i nepovezane veze. PPTP je zastario i MS-CHAPv2 je slab, pa ove provjere tretirajte kao održavanje veze koja mora nastaviti raditi, a ne kao razlog da PPTP uvozite bilo gdje novo.

Povezani članci