Zakaj sam PPP CHAP ne more izpolniti zahteve MPPE

Profil PPTP, ki vztraja pri šifriranju, običajno odpove na istem mestu: PPP se dogovori o izmenjavi preverjanja pristnosti, ki nikoli ne ustvari ključnega gradiva, ki ga MPPE potrebuje. Tunel je videti napol živ, geslo je sprejeto, povezava pa pade, preden jo prečka kakšen promet. Seganje po spustnem seznamu CHAP, dokler se kaj ne poveže, skriva pravo napako, ta napaka pa je pogodba med metodo preverjanja pristnosti in politiko zaščite. Spodnja preverjanja so urejena tako, da vsako izloči cenejši vzrok od naslednjega.

V eni povezavi PPTP potekata dve pogajanji

PPTP prenaša običajno sejo PPP znotraj tunela GRE in oba se pogajata ločeno. Zunanji sloj odloča, kako so paketi zapakirani in kateri krmilni kanal obstaja; notranja seja PPP odloča, kdo je partner in kakšna zaščita je na vrhu. Zato poziv za geslo dokazuje nekaj le o notranjem sloju, dokončan zunanji rokovanje pa ne dokazuje ničesar o nobenem od njiju. Profili tu odpovejo zato, ker ljudje razhroščujejo tunel, medtem ko nesoglasje sedi znotraj PPP.

Običajni CHAP je izmenjava izziva in odgovora iz RFC 1994, zgrajena na skupni skrivnosti in ničemer drugem. MS-CHAPv2 je druga izmenjava z drugimi sporočili in drugačnim izhodom, standardizirana v RFC 2759. Skupna beseda v obeh imenih je edino, kar imata skupnega na žici. Nobeno ime ne pove, kaj izmenjava ustvari, in to je edini del, ki šteje.

Zato je možnost z oznako preprosto CHAP v starem profilu dvoumna. Ko strežnik želi MS-CHAPv2, odjemalec pa ponuja običajni CHAP, se nadzor povezave lahko še vedno zaključi in geslo se lahko še vedno sprejme. Napaka pride pozneje, ko strežnik poskuša izpeljati zaščitne ključe iz izmenjave, ki ni ustvarila ničesar.

Uskladite zahtevano metodo s ključi, ki jih lahko ustvari

Ključi MPPE niso splošna lastnost PPP. Za družino Microsoft CHAP je izpeljava določena v RFC 3079 in kot vhod vzame izhod izmenjave MS-CHAP, ne skupne skrivnosti. Metode EAP dosežejo isto mesto po drugi poti, pri čemer strežnik za preverjanje pristnosti vrne ključe kot atributa MS-MPPE-Recv-Key in MS-MPPE-Send-Key. Običajni CHAP se ne pojavi na nobeni od obeh poti in to je ves razlog za obstoj tega neskladja.

Konfiguracija, ki zahteva MPPE in hkrati zavrača vsako metodo, ki lahko dobavi ključe, je notranje protislovna. pppd to protislovje razreši z zavrnitvijo povezave, ne z izmišljanjem ključev, zato je viden rezultat seja, ki se preveri in nato konča v omrežni fazi. Ponovno poskušanje odjemalca tega ne bo spremenilo, dokler strežnik zavrača edine metode, ki kaj izpeljejo.

Pravilo, ki iz tega sledi, je kratko: če profil zahteva MPPE, mora biti metoda različica MS-CHAP ali metoda EAP, katere ključe strežnik vrne. Zavrnitev samo MS-CHAPv2 tega ne vsili, ker tudi MS-CHAPv1 izpeljuje ključe in ostane na voljo, razen če se zavrne ločeno; zavrnitev obeh pusti običajni CHAP in PAP, ki ničesar ne izpeljeta in zahtevo naredita neizpolnljivo. Izrecno navedite sprejeto metodo, namesto da naštevate tiste, ki vam niso všeč. Opustitev zahteve po šifriranju, da bi se odjemalec povezal, je znižanje, ne popravilo.

Preberite možnosti strežnika, preden urejate odjemalca

Večina teh neskladij je na strežniku vidnih v dveh datotekah, njihovo branje pa stane manj kot ponovna gradnja odjemalca. Na končni točki PPTP v Linuxu ustrezne nastavitve živijo v datoteki možnosti pppd, ki jo posreduje pptpd. Zaženite jo na strežniku, ne z zaslona stanja odjemalca. Začnite z vrsticami, ki zahtevajo, zavračajo ali poimenujejo način zaščite:

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

Izhod berite kot pogodbo in ne kot seznam zastavic. Vrstice, ki zahteva MPPE in hkrati zavrača obe različici MS-CHAP, ne more izpolniti noben odjemalec, manjkajoča zahteva za metodo MS-CHAP pa pušča vrata odprta izmenjavam, ki ne dajo ključev. Nato preverite, komu je sploh dovoljeno preverjanje pristnosti, kar odloči datoteka skrivnosti:

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

Preden karkoli spremenite, zapišite tri vrednosti: zunanji protokol, metodo preverjanja pristnosti, ki jo zahteva strežnik, in ali je zaščita obvezna ali neobvezna. Te tri določajo vsako poznejšo odločitev, njihovo ugibanje iz odjemalčevega pogovornega okna pa je pot, po kateri profil ostane napol konfiguriran. Med delom imejte datoteko odprto, ker naslednji razdelek potrebuje iste tri vrednosti.

Poiščite napako po fazi PPP

PPP poroča o napakah po fazah, faza pa pove, katera klavzula pogodbe se je zlomila. Povezava, ki nikoli ne zapusti nadzora povezave, ima težavo z zapakiranjem ali pogajanji, medtem ko ima tista, ki se preveri in nato umre, običajno težavo s politiko ali ključem. Povezava, ki ostane pokonci in ne prenaša ničesar, je prešla na usmerjanje, kar je druga preiskava.

Dnevnik hrani vrstice faz in te so uporabnejše od višje ravni razhroščevanja. Zahtevajte procese PPP in sporočila o zaščiti, nato preberite izid preverjanja pristnosti pred vsem drugim. Zadnje vrstice običajno poimenujejo klavzulo, ki je zavrnila:

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

V tem izhodu najprej poiščite izid preverjanja pristnosti in nato pritožbo, da je bila zaščita zahtevana, a ni bila dogovorjena. Drugo sporočilo je podpis zgornjega protislovja in nobena količina ponovnih poskusov ga ne odstrani, dokler strežnik zavrača edino metodo, ki lahko ustvari ključe. Vredno je poimenovati dve pasti: dvigovanje ravni razhroščevanja brez branja vrstic faz ustvarja šum, zajemanje gradiva izziva ali gesel pa spremeni konfiguracijsko nalogo v uhajanje poverilnic. Zabeležite to fazo, preden spremenite katero koli možnost.

Načrtujte izhod, preden se stara končna točka izklopi

MPPE je zgodovinski mehanizem zaščite povezave in njegova prisotnost ne naredi PPTP razumne izbire za novo uvajanje. Sedanje Microsoftove smernice že odsvetujejo PPTP in L2TP/IPsec s vnaprej skupnim ključem za nove uvajanje oddaljenega dostopa. Ohranjati staro končno točko pri življenju je odločitev o obstoječi storitvi, ne predloga za naslednjo.

Ko mora končna točka ostati, zapišite pogodbo: zunanji protokol, zahtevana metoda preverjanja pristnosti, obvezna zaščita in različica odjemalca, ki jo pogaja. Ko lahko odide, izberite identiteto prehoda zamenjave, njeno preverjanje pristnosti odjemalca in mesto, kjer bodo živele poverilnice, preden se dotaknete starega profila. Nato načrtujte poti, DNS in vire, do katerih je vsak uporabnik pooblaščen. Preverite predvidenega odjemalca glede na zahteve lastnika in ne glede na delujočo povezavo.

Namerna zavrnitev naj ostane zavrnitev, ker vrnitev v nezaščiten način, da test uspe, spremeni neuspeh politike v izpostavljenost. Končno stanje je podprta, dokumentirana pogodba, ne najmanjši nabor sprememb, ki omogoči eni stari povezavi uspeh. Pustite stari profil na mestu, neuporabljen in dokumentiran, dokler zamenjava ne prestane istih preverjanj.