Savienojums autentificējas, klients ziņo par pieslēgšanos, un sekundi vēlāk žurnāls noslēdzas ar ierakstu, ka LCP pārtrauca partneris. Šī rinda nāk no PPP sarunām GRE tunelī, tātad transports jau darbojās un abi gali nebija vienisprātis par savienojuma opcijām. Paroles un servera adreses šeit parasti ir nevainīgas. Šifrēšanas politika ir pirmā lieta, kas jāsalīdzina, un Linux pppd partnera fails ir pirmā vieta, kur jāskatās.

Ko LCP kļūme saka par PPP posmu

PPTP iesaiņo PPP GRE: TCP 1723 vadības savienojums sagatavo zvanu, GRE pārvadā lietderīgo slodzi, un pēc tam LCP apspriež tādas opcijas kā autentifikācijas protokols, saspiešana un MPPE. Partneris pārtrauc LCP, ja nepieciešamā opcija viņa pusē nav pieņemama. Žurnāls, kurā CHAP vai MSCHAPv2 apmaiņa beidzas un LCP beidzas uzreiz pēc tam, ir politikas noraidījums, nevis sasniedzamības kļūme. Ja tunelis vispār neaizsniedzas līdz sarunām, pirms LCP rindas lasīšanas pārbaudiet pppd un tā spraudni.

Divus priekšnosacījumus viegli palaist garām. pppd binārajam failam jābūt, un partnera failā norādītajam PPTP spraudnim jābūt instalētam; trūkstoša pakotne beidz zvanu pirms jebkuras opcijas apspriešanas.

Iespējojiet MPPE tajā pusē, kas to pieprasa

Īstais lēmums ir, kura puse pārvalda šifrēšanas politiku. Klients var piedāvāt MPPE, pieprasīt to vai atteikties, un serveris izdara tādu pašu izvēli. Kad abi to pieprasa, savienojums paceļas; kad viens pieprasa un otrs atsakās, LCP beidzas.

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

Pirms zvana ielādējiet moduli ar modprobe ppp_mppe, jo bez tā require-mppe-128 neizdodas. Windows atbilstošā vadība ir VPN ieraksta drošības cilne, kur klientam jāpasaka pieprasīt šifrēšanu, nevis pieņemt visu, ko serveris piedāvā. Ja serveris joprojām pārtrauc LCP, jautājiet tā operatoram, vai MPPE ir obligāts, neobligāts vai atspējots, jo klients nevar vienoties par aizsardzību, kuru serveris noraida. Šifrēšanas izslēgšana, lai ziņojums pazustu, ir nepareizais virziens: tā noņem vienīgo aizsardzību, kāda šim protokolam ir.

Pirms rediģēšanas saglabājiet strādājošo partnera failu. Nepareizi ievadīta require-mppe rinda atkārto to pašu vispārīgo LCP kļūmi un aizved jūs atpakaļ uz sākumu.

Lasiet paša pppd žurnālu, nevis sīklietotni

Darbvirsmas sīklietotnes parāda atvienošanos un slēpj iemeslu, tāpēc lasiet dēmona aprakstu par vienu mēģinājumu. systemd sistēmās ziņojums nonāk journal; vecākas konfigurācijas raksta tradicionālajos žurnālfailos.

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

Meklējiet logā ap vienu zvanu, nevis visas dienas atkārtotas pieslēgšanās, lai noraidīto opciju būtu viegli pamanīt. pppd parasti nosauc opciju un partnera atbildi, kas pasaka, vai mainīt savu priekšlikumu, vai lūgt servera pusi mīkstināt prasību. Saglabājiet mēģinājumus ar laikspiedoliem, jo divu žurnālu salīdzināšana ir noderīga tikai tad, ja zināt, kuras rindas pieder kuram zvanam. Ja LCP apmaiņa nemaz neparādās, kļūme ir agrāk ķēdē un MPPE nav aizdomās turamais.

Saglabājiet labojumu atkārtotu pieslēgšanos laikā: hooku nosaukumi un MTU

Kad savienojums noturas, divas detaļas izšķir, vai tas pārdzīvos atkārtotu pieslēgšanos. Hooki atrodas /etc/ppp/ip-up.d un /etc/network/if-up.d, un abas mapes apstrādā run-parts, kura faila nosaukuma filtrs noraida visu, kas satur punktu. Tāpēc skripts ar nosaukumu set-pptp.sh tiek izlaists, bet set-pptp tiek izpildīts. Pirms skripta satura atkļūdošanas pārbaudiet nosaukumu, pēc tam iestatiet mazāko MTU no šī hooka iekšpuses, lai katra jauna ppp saskarne to mantotu bez manuālas komandas.

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

Lai tīši beigtu sesiju, mērķējiet uz pppd ierakstīto pid, nevis salīdziniet procesu nosaukumus pēc parauga, jo nogalinot visu, kas satur ppp, tiek norauti arī nesaistīti savienojumi. PPTP ir novecojis un MS-CHAPv2 ir vājš, tāpēc uzskatiet šīs pārbaudes par savienojuma, kam jāturpina darboties, uzturēšanu, nevis par iemeslu izvietot PPTP kaut kur jaunā vietā.

Saistītie raksti