Lidhja autentikohet, klienti raporton i lidhur dhe një sekondë më vonë logu mbyllet me LCP u ndërpre nga partneri. Ai rresht vjen nga negociimi PPP brenda tunelit GRE, pra transporti funksiononte tashmë dhe dy skajet nuk binin dakord për opsionet e lidhjes. Fjalëkalimet dhe adresat e serverit zakonisht janë të pafajshme këtu. Politika e kriptimit është gjëja e parë për t'u krahasuar dhe në Linux skedari i partnerit i pppd është vendi i parë për t'u shikuar.

Çfarë thotë dështimi i LCP për fazën PPP

PPTP e mbështjell PPP brenda GRE: lidhja e kontrollit TCP 1723 përgatit thirrjen, GRE mbart ngarkesën dhe më pas LCP negocion opsione si protokolli i autentikimit, kompresimi dhe MPPE. Partneri e ndërpret LCP kur një opsion i detyrueshëm nuk është i pranueshëm nga ana e tij. Një log ku shkëmbimi CHAP ose MSCHAPv2 përfundon dhe LCP mbaron menjëherë pas kësaj është refuzim politike, jo dështim arritshmërie. Nëse tuneli nuk arrin fare në negociim, kontrolloni pppd dhe shtojcën e tij para se të lexoni rreshtin e LCP.

Dy parakushte humbin lehtë. Binari pppd duhet të ekzistojë dhe shtojca PPTP e përmendur në skedarin e partnerit duhet të jetë e instaluar; një paketë që mungon e përfundon thirrjen para se të diskutohet ndonjë opsion.

Aktivizoni MPPE në anën që e kërkon

Vendimi i vërtetë është cili skaj zotëron politikën e kriptimit. Klienti mund të ofrojë MPPE, ta kërkojë ose ta refuzojë, dhe serveri bën të njëjtën zgjedhje. Kur të dy e kërkojnë lidhja ngrihet; kur njëri e kërkon dhe tjetri e refuzon, LCP mbaron.

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

Ngarkoni modulin me modprobe ppp_mppe para se të telefononi, sepse pa të require-mppe-128 dështon. Në Windows kontrolli ekuivalent është skeda e sigurisë e zërit VPN, ku klientit duhet t'i thuhet të kërkojë kriptim në vend që të pranojë çfarëdo që ofron serveri. Nëse serveri vazhdon të ndërpresë LCP, pyesni operatorin e tij nëse MPPE është i detyrueshëm, opsional ose i çaktivizuar, sepse klienti nuk mund të negociojë një mbrojtje që serveri e refuzon. Fikja e kriptimit që mesazhi të zhduket është drejtimi i gabuar: heq të vetmen mbrojtje që ka ky protokoll.

Ruani skedarin e partnerit që funksionon para se ta redaktoni. Një rresht require-mppe i shtypur gabim riprodhon të njëjtin dështim gjenerik të LCP dhe ju kthen në fillim.

Lexoni logun e vetë pppd, jo appletin

Appletët e desktopit tregojnë shkëputjen dhe fshehin arsyen, prandaj lexoni rrëfimin e daemonit për një provë. Në sistemet systemd mesazhi shkon në journal; konfigurimet më të vjetra shkruajnë në skedarët tradicionalë të logut.

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

Kërkoni në një dritare rreth një telefonate të vetme në vend të një dite të tërë rilidhjesh, që opsioni i refuzuar të dallohet lehtë. pppd zakonisht emërton opsionin dhe përgjigjen e partnerit, gjë që ju tregon nëse duhet të ndryshoni propozimin tuaj ose t'i kërkoni anës së serverit të lehtësojë kërkesën. Mbani provat me vulë kohe, sepse krahasimi i dy logove është i dobishëm vetëm kur e dini cilat rreshta i përkasin cilës thirrje. Kur nuk shfaqet fare shkëmbim LCP, defekti është më lart në zinxhir dhe MPPE nuk është i dyshuari.

Ruani rregullimin përgjatë rilidhjeve: emrat e grepa dhe MTU

Pasi lidhja qëndron, dy detaje vendosin nëse i mbijeton një rilidhjeje. Grepat jetojnë në /etc/ppp/ip-up.d dhe /etc/network/if-up.d, dhe run-parts përpunon të dy drejtoritë, me një filtër emrash skedarësh që refuzon çdo gjë me pikë. Prandaj një skript i quajtur set-pptp.sh anashkalohet, ndërsa set-pptp ekzekutohet. Kontrolloni emrin para se të korrigjoni përmbajtjen e skriptit, më pas vendosni MTU më të vogël brenda atij grep, që çdo ndërfaqe e re ppp ta trashëgojë pa një komandë manuale.

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

Për ta përfunduar një sesion me qëllim, synoni pid-in e regjistruar nga pppd në vend që të përputhni emrat e proceseve, sepse vrasja e gjithçkaje që përmban ppp rrëzon edhe lidhje të palidhura. PPTP është i vjetëruar dhe MS-CHAPv2 është i dobët, prandaj këto kontrolle trajtojini si mirëmbajtje për një lidhje që duhet të vazhdojë të funksionojë, jo si arsye për të vendosur PPTP në ndonjë vend të ri.

Artikuj të ngjashëm