Miks üksi PPP CHAP ei suuda MPPE nõuet täita

Krüpteerimist nõudev PPTP profiil ebaõnnestub tavaliselt samas kohas: PPP lepib kokku autentimisvahetuses, mis ei tooda kunagi MPPE-le vajalikku võtmematerjali. Tunnel näib poolenisti elus, parool võetakse vastu ja ühendus katkeb enne, kui sellest läbib mingi liiklus. CHAP-i rippmenüü poole sirutamine, kuni miski ühendub, varjab tegelikku defekti, ja see on leping autentimismeetodi ning kaitsepoliitika vahel. Allpool olevad kontrollid on järjestatud nii, et igaüks välistab odavama põhjuse kui järgmine.

Ühe PPTP-ühenduse sees käib kaks läbirääkimist

PPTP kannab tavalist PPP-sessiooni GRE-tunneli sees ja need kaks peavad läbirääkimisi eraldi. Välimine kiht otsustab, kuidas paketid kapseldatakse ja milline juhtkanal olemas on; sisemine PPP-sessioon otsustab, kes on partner ja milline kaitse selle peal sõidab. Seega parooliküsimus tõestab midagi ainult sisemise kihi kohta ning lõpetatud välimine käepigistus ei tõesta midagi kummagi kohta. Profiilid ebaõnnestuvad siin sellepärast, et inimesed siluvad tunnelit, samal ajal kui lahkarvamus istub PPP sees.

Tavaline CHAP on RFC 1994 väljakutse-vastuse vahetus, üles ehitatud jagatud saladusele ja mitte millelegi muule. MS-CHAPv2 on teistsugune vahetus teistsuguste sõnumite ja teistsuguse väljundiga, standardiseeritud RFC 2759-s. Kahe nime ühine sõna on ainus, mis neil juhtmel ühist on. Kumbki nimi ei ütle, mida vahetus toodab, ja just see on ainus oluline osa.

Seepärast on lihtsalt CHAP-iks märgitud valik vanas profiilis mitmetähenduslik. Kui server tahab MS-CHAPv2-te ja klient pakub tavalist CHAP-i, võib lingi juhtimine ikkagi lõppeda ja parool ikkagi vastu võetud saada. Tõrge saabub hiljem, kui server püüab tuletada kaitsevõtmeid vahetusest, mis ei tootnud midagi.

Sovitage nõutud meetod võtmetega, mida see suudab toota

MPPE võtmed ei ole PPP üldine omadus. Microsofti CHAP-i perekonna jaoks on tuletus määratletud RFC 3079-s ja see võtab sisendiks MS-CHAP-i vahetuse väljundi, mitte jagatud saladuse. EAP-meetodid jõuavad samasse kohta teist teed, kusjuures autentimisserver tagastab võtmed atribuutidena MS-MPPE-Recv-Key ja MS-MPPE-Send-Key. Tavaline CHAP ei esine kummalgi teel, ja see on kogu põhjus, miks see mittevastavus üldse olemas on.

Konfiguratsioon, mis nõuab MPPE-d, kuid keeldub igast võtmeid andmiseks võimelisest meetodist, on sisemiselt vastuoluline. pppd lahendab selle vastuolu ühendusest keeldumisega, mitte võtmete leiutamisega, nii et nähtav tulemus on sessioon, mis autendib ja seejärel võrguetapis lõpeb. Kliendi uuesti proovimine ei muuda seda seni, kuni server keeldub ainsatest meetoditest, mis midagi tuletavad.

Sellest tulenev reegel on lühike: kui profiil nõuab MPPE-d, peab meetod olema MS-CHAP-i variant või EAP-meetod, mille võtmed server tagastab. Ainult MS-CHAPv2-st keeldumine ei taga seda, sest ka MS-CHAPv1 tuletab võtmeid ja jääb kättesaadavaks, kui sellest eraldi ei keeldata; mõlemast keeldumine jätab alles tavalise CHAP-i ja PAP-i, mis ei tuleta midagi ja teevad nõude täitmatuks. Nimetage vastuvõetud meetod selgesõnalisesti, selle asemel et loetleda neid, mis teile ei meeldi. Krüpteerimisnõudest loobumine, et klient ühenduks, on allakäik, mitte parandus.

Lugege serveri valikuid enne kliendi muutmist

Enamik neist mittevastavustest on serveris nähtavad kahes failis ja nende lugemine maksab vähem kui kliendi ümberehitamine. Linuxi PPTP-lõpp-punktis elavad asjakohased seaded pppd valikute failis, mille pptpd edasi annab. Käivitage see serveris, mitte kliendi olekuekraanilt. Alustage ridadest, mis nõuavad, keelduvad või nimetavad kaitsevaimu:

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

Lugege väljundit lepinguna, mitte lippude loendina. Rida, mis nõuab MPPE-d, kuid keeldub mõlemast MS-CHAP-i variandist, ei suuda ükski klient täita, ja puuduv nõue MS-CHAP-i meetodi kohta jätab ukse lahti vahetusteks, mis võtmeid ei anna. Seejärel kontrollige, kellel üldse lubatakse autentida, mida otsustab saladuste fail:

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

Kirjutage üles kolm väärtust enne millegi muutmist: välimine protokoll, serveri nõutav autentimismeetod ja kas kaitse on kohustuslik või valikuline. Need kolm määravad iga hilisema otsuse, ja nende äraarvamine kliendi dialoogist on viis, kuidas profiil jääb pooleldi seadistatuks. Hoidke fail töötamise ajal lahti, sest järgmine osa vajab samu kolme väärtust.

Leidke tõrge PPP-faasi järgi

PPP teatab tõrgetest faaside kaupa ja faas ütleb, milline lepingu punkt katki läks. Ühendusel, mis ei lahku kunagi lingi juhtimisest, on kapseldamise või läbirääkimise probleem, samas kui see, mis autendib ja siis sureb, on tavaliselt poliitika- või võtmeprobleem. Ühendus, mis jääb püsti ega kanna midagi, on liikunud marsruutimise juurde, mis on teine uurimine.

Journal hoiab faasiread alles ja need on kasulikumad kui kõrgem silumistase. Küsige PPP protsessid ja kaitse sõnumid, seejärel lugege autentimistulemus enne kõike muud. Viimased read nimetavad tavaliselt punkti, mis keeldus:

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

Selles väljundis otsige kõigepealt autentimistulemust ja seejärel kaebust, et kaitset nõuti, kuid seda ei peetud läbirääkimisi. Teine sõnum on ülaltoodud vastuolu allkiri ja ükski korduskatsete hulk ei puhasta seda seni, kuni server keeldub ainsast meetodist, mis suudab võtmeid toota. Kaht lõksu tasub nimetada: silumistaseme tõstmine ilma faasiridu lugemata tekitab müra, ning väljakutse materjali või paroolide püüdmine muudab seadistusülesande volituste lekkimiseks. Kirjutage see faas üles enne mis tahes valiku muutmist.

Planeerige väljumine enne vana lõpp-punkti väljalülitamist

MPPE on ajalooline lingi kaitse mehhanism ja selle olemasolu ei tee PPTP-st uue juurutuse jaoks mõistlikku valikut. Microsofti praegused juhised soovitavad juba PPTP vastu ja ka L2TP/IPsec-i vastu eeljagatud võtmega uute kaugjuurdepääsu juurutuste jaoks. Vana lõpp-punkti elus hoidmine on otsus olemasoleva teenuse kohta, mitte mall järgmise jaoks.

Kui lõpp-punkt peab jääma, kirjutage leping üles: välimine protokoll, nõutav autentimismeetod, kohustuslik kaitse ja kliendi versioon, mis seda läbirääkimistel käsitleb. Kui see võib lahkuda, valige asendaja lüüsi identiteet, selle kliendi autentimine ja koht, kus volitused elavad, enne kui vana profiili puudutate. Seejärel planeerige marsruudid, DNS ja ressursid, millele igal kasutajal on lubatud pääseda. Valideerige kavandatud klient omaniku nõuete vastu, mitte töötava ühenduse vastu.

Tahtlik keeldumine peaks jääma keeldumiseks, sest kaitsmata režiimi taganemine testi läbimiseks muudab poliitika tõrke paljastumiseks. Lõppseisund on toetatud, dokumenteeritud leping, mitte väikseim muudatuste kogum, mis ühe vana ühenduse õnnestuma paneb. Jätke vana profiil paigale, kasutamata ja dokumenteerituna, kuni asendaja läbib samad kontrollid.