De ce PPP CHAP singur nu poate satisface o cerință MPPE

Un profil PPTP care insistă asupra criptării eșuează de obicei în același loc: PPP cade de acord asupra unui schimb de autentificare care nu produce niciodată materialul de cheie de care are nevoie MPPE. Tunelul pare pe jumătate viu, parola este acceptată, iar legătura cade înainte ca vreun trafic să o traverseze. A apela la lista derulantă CHAP până când ceva se conectează ascunde defectul real, iar acesta este un contract între metoda de autentificare și politica de protecție. Verificările de mai jos sunt ordonate astfel încât fiecare să elimine o cauză mai ieftină decât următoarea.

Două negocieri se desfășoară într-o singură conexiune PPTP

PPTP transportă o sesiune PPP normală într-un tunel GRE, iar cele două negociază separat. Stratul exterior decide cum sunt încapsulate pachetele și ce canal de control există; sesiunea PPP interioară decide cine este partenerul și ce protecție stă deasupra. O solicitare de parolă dovedește deci ceva doar despre stratul interior, iar un handshake exterior finalizat nu dovedește nimic despre niciunul dintre ele. Profilurile eșuează aici pentru că oamenii depanează tunelul în timp ce dezacordul stă în interiorul PPP.

CHAP simplu este schimbul provocare-răspuns din RFC 1994, construit pe un secret partajat și nimic altceva. MS-CHAPv2 este un alt schimb, cu alte mesaje și o altă ieșire, standardizat în RFC 2759. Cuvântul comun din cele două nume este singurul lucru pe care îl au în comun pe fir. Niciunul dintre nume nu spune ce produce schimbul, și aceasta este singura parte care contează.

De aceea o opțiune etichetată pur și simplu CHAP este ambiguă într-un profil vechi. Când serverul vrea MS-CHAPv2 și clientul oferă CHAP simplu, controlul legăturii poate totuși să se finalizeze și o parolă poate totuși să fie acceptată. Eșecul vine mai târziu, când serverul încearcă să derive chei de protecție dintr-un schimb care nu a produs niciuna.

Potriviți metoda cerută cu cheile pe care le poate produce

Cheile MPPE nu sunt o proprietate a PPP în general. Pentru familia Microsoft CHAP derivarea este specificată în RFC 3079, iar aceasta ia ca intrare ieșirea unui schimb MS-CHAP în locul unui secret partajat. Metodele EAP ajung în același loc pe altă cale, serverul de autentificare returnând cheile ca atribute MS-MPPE-Recv-Key și MS-MPPE-Send-Key. CHAP simplu nu apare pe niciuna dintre cele două căi, și acesta este întregul motiv pentru care nepotrivirea există.

O configurație care cere MPPE dar refuză orice metodă capabilă să furnizeze chei este intern contradictorie. pppd rezolvă această contradicție refuzând legătura, nu inventând chei, așa că rezultatul vizibil este o sesiune care se autentifică și apoi se termină în faza de rețea. Reîncercarea clientului nu va schimba asta cât timp serverul refuză singurele metode care derivă ceva.

Regula care urmează este scurtă: dacă profilul cere MPPE, metoda trebuie să fie o variantă MS-CHAP sau o metodă EAP ale cărei chei serverul le returnează. Refuzul doar al MS-CHAPv2 nu impune asta, pentru că și MS-CHAPv1 derivă chei și rămâne disponibil dacă nu este refuzat separat; refuzul ambelor lasă CHAP simplu și PAP, care nu derivă nimic și fac cerința imposibil de îndeplinit. Numiți explicit metoda acceptată în loc să le enumerați pe cele care nu vă plac. Renunțarea la cerința de criptare pentru ca un client să se conecteze este o degradare, nu o reparație.

Citiți opțiunile serverului înainte de a edita un client

Majoritatea acestor nepotriviri sunt vizibile pe server în două fișiere, iar citirea lor costă mai puțin decât reconstruirea unui client. Pe un punct final PPTP Linux, setările relevante trăiesc în fișierul de opțiuni pppd pe care îl transmite pptpd. Rulați-l pe server, nu de pe un ecran de stare al clientului. Începeți cu liniile care cer, refuză sau numesc un mod de protecție:

sudo grep -nE 'require-|refuse-|mppe|mschap' /etc/ppp/options.pptpd

Citiți ieșirea ca pe un contract și nu ca pe o listă de steaguri. O linie care cere MPPE dar refuză ambele variante MS-CHAP nu poate fi satisfăcută de niciun client, iar lipsa unei cerințe pentru o metodă MS-CHAP lasă ușa deschisă schimburilor care nu dau chei. Apoi verificați cine are voie să se autentifice deloc, ceea ce decide fișierul de secrete:

sudo sed -n '1,20p' /etc/ppp/chap-secrets
sudo pppd --version

Notați trei valori înainte de a schimba ceva: protocolul exterior, metoda de autentificare cerută de server și dacă protecția este obligatorie sau opțională. Acestea trei determină fiecare decizie ulterioară, iar ghicirea lor dintr-un dialog de client este felul în care un profil ajunge pe jumătate configurat. Țineți fișierul deschis în timp ce lucrați, pentru că secțiunea următoare are nevoie de aceleași trei valori.

Localizați eșecul după faza PPP

PPP raportează eșecurile pe faze, iar faza spune care clauză a contractului s-a rupt. O legătură care nu părăsește niciodată controlul legăturii are o problemă de încapsulare sau de negociere, în timp ce una care se autentifică și apoi moare are de obicei o problemă de politică sau de cheie. O legătură care rămâne sus și nu transportă nimic a trecut la rutare, ceea ce este o altă investigație.

Jurnalul păstrează liniile de fază, iar acestea sunt mai utile decât un nivel de depanare mai ridicat. Cereți procesele PPP și mesajele de protecție, apoi citiți rezultatul autentificării înainte de orice altceva. Ultimele linii numesc de obicei clauza care a refuzat:

sudo journalctl -b --no-pager | grep -iE 'pppd|pptpd|mppe|chap' | tail -40

În acea ieșire, căutați mai întâi rezultatul autentificării și apoi o plângere că protecția a fost cerută dar nu a fost negociată. Al doilea mesaj este semnătura contradicției de mai sus, iar nicio cantitate de reîncercări nu îl șterge cât timp serverul refuză singura metodă care poate produce chei. Merită numite două capcane: ridicarea nivelului de depanare fără citirea liniilor de fază produce zgomot, iar capturarea materialului de provocare sau a parolelor transformă o sarcină de configurare într-o scurgere de acreditări. Înregistrați acea fază înainte de a schimba orice opțiune.

Planificați ieșirea înainte ca punctul final vechi să fie oprit

MPPE este un mecanism istoric de protecție a legăturii, iar prezența lui nu face din PPTP o alegere rezonabilă pentru o implementare nouă. Ghidul actual al Microsoft descurajează deja PPTP și L2TP/IPsec cu cheie pre-partajată pentru implementările noi de acces la distanță. Menținerea în viață a unui punct final vechi este o decizie despre un serviciu existent, nu un șablon pentru următorul.

Când punctul final trebuie să rămână, scrieți contractul: protocol exterior, metodă de autentificare cerută, protecție obligatorie și versiunea de client care o negociază. Când poate pleca, alegeți identitatea de gateway a înlocuitorului, autentificarea sa de client și locul unde vor trăi acreditările înainte de a atinge profilul vechi. Apoi planificați rutele, DNS-ul și resursele la care fiecare utilizator este autorizat. Validați clientul prevăzut față de cerințele proprietarului, nu față de o conexiune funcțională.

Un refuz deliberat ar trebui să rămână un refuz, pentru că revenirea la un mod neprotejat ca un test să treacă transformă un eșec de politică într-o expunere. Starea finală este un contract susținut și documentat, nu cel mai mic set de modificări care face o conexiune veche să reușească. Lăsați profilul vechi la locul lui, nefolosit și documentat, până când înlocuitorul trece aceleași verificări.