LCP încheiat de peer pe PPTP: activați mai întâi MPPE

Încheierea LCP de către peer pe un link PPTP este o nepotrivire a politicii PPP. Comparați cerințele MPPE, citiți jurnalul pppd și verificați numele hook-urilor înainte de a atinge credențialele.

Linkul se autentifică, clientul raportează conectat, iar o secundă mai târziu jurnalul se închide cu LCP încheiat de peer. Linia aceea provine din negocierea PPP din interiorul tunelului GRE, deci transportul funcționa deja, iar cele două capete nu cădeau de acord asupra opțiunilor linkului. Parolele și adresele de server sunt de obicei nevinovate aici. Politica de criptare este primul lucru de comparat, iar pe Linux fișierul peer al pppd este primul loc unde trebuie privit.

Ce spune eșecul LCP despre etapa PPP

PPTP împachetează PPP în GRE: conexiunea de control TCP 1723 pregătește apelul, GRE transportă încărcătura, iar apoi LCP negociază opțiuni precum protocolul de autentificare, compresia și MPPE. Peer-ul încheie LCP când o opțiune obligatorie nu este acceptabilă de partea lui. Un jurnal în care schimbul CHAP sau MSCHAPv2 se încheie și LCP se termină imediat după aceea este o respingere de politică, nu o defecțiune de accesibilitate. Dacă tunelul nu ajunge deloc la negociere, verificați pppd și plugin-ul lui înainte de a citi linia LCP.

Două condiții prealabile sunt ușor de ratat. Binarul pppd trebuie să existe, iar plugin-ul PPTP numit în fișierul peer trebuie instalat; un pachet lipsă încheie apelul înainte de a fi discutată vreo opțiune.

Activați MPPE pe partea care îl cere

Adevărata decizie este care capăt deține politica de criptare. Un client poate oferi MPPE, îl poate cere sau refuza, iar serverul face aceeași alegere. Când ambele îl cer, linkul urcă; când unul îl cere și celălalt refuză, LCP se termină.

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

Încărcați modulul cu modprobe ppp_mppe înainte de apel, pentru că require-mppe-128 eșuează fără el. Pe Windows, controlul echivalent este fila de securitate a intrării VPN, unde clientului trebuie să i se ceară să solicite criptarea în loc să accepte ce oferă serverul. Dacă serverul încă încheie LCP, întrebați operatorul dacă MPPE este obligatoriu, opțional sau dezactivat, fiindcă un client nu poate negocia o protecție pe care serverul o refuză. Oprirea criptării ca mesajul să dispară este direcția greșită: elimină singura protecție pe care o are acest protocol.

Salvați fișierul peer funcțional înainte de a-l edita. O linie require-mppe scrisă greșit reproduce aceeași eroare LCP generică și vă trimite înapoi la început.

Citiți jurnalul propriu al pppd, nu applet-ul

Applet-urile de desktop arată deconectarea și ascund motivul, așa că citiți relatarea daemonului despre o singură încercare. Pe sistemele systemd mesajul ajunge în journal; instalările mai vechi scriu în fișierele de jurnal tradiționale.

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

Căutați într-o fereastră din jurul unui singur apel, nu într-o zi întreagă de reconectări, ca opțiunea respinsă să fie ușor de observat. pppd numește de obicei opțiunea și răspunsul peer-ului, ceea ce vă spune dacă să vă schimbați propria propunere sau să cereți părții serverului să relaxeze cerința. Păstrați încercările cu marcaje de timp, fiindcă compararea a două jurnale este utilă doar când știți care linii aparțin cărui apel. Când nu apare niciun schimb LCP, defecțiunea este mai sus în lanț și MPPE nu este suspectul.

Păstrați corecția între reconectări: nume de hook-uri și MTU

Odată ce linkul rămâne stabil, două detalii decid dacă supraviețuiește unei reconectări. Hook-urile stau în /etc/ppp/ip-up.d și /etc/network/if-up.d, iar run-parts procesează ambele directoare, filtrul său de nume de fișiere respingând tot ce conține un punct. De aceea un script numit set-pptp.sh este sărit, în timp ce set-pptp este executat. Verificați numele înainte de a depana conținutul scriptului, apoi setați MTU mai mic din interiorul acelui hook, astfel încât fiecare interfață ppp nouă să-l moștenească fără o comandă manuală.

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

Pentru a încheia intenționat o sesiune, țintiți pid-ul înregistrat de pppd în loc să potriviți numele proceselor, fiindcă uciderea a tot ce conține ppp rupe și linkuri nelegate. PPTP este învechit, iar MS-CHAPv2 este slab, așa că tratați aceste verificări ca întreținere pentru un link care trebuie să continue să funcționeze, nu ca motiv de a implementa PPTP într-un loc nou.

Articole similare