Kāpēc viens PPP CHAP nevar izpildīt MPPE prasību

PPTP profils, kas uzstāj uz šifrēšanu, parasti sabrūk tajā pašā vietā: PPP vienojas par autentifikācijas apmaiņu, kas nekad neizstrādā MPPE vajadzīgo atslēgu materiālu. Tunelis izskatās puszīvs, parole tiek pieņemta, un saite pārtrūkst, pirms pa to pāriet jebkurš trafiks. Ķeršanās pie CHAP nolaižamās izvēlnes, līdz kaut kas pieslēdzas, slēpj īsto defektu, un tas ir līgums starp autentifikācijas metodi un aizsardzības politiku. Zemāk minētās pārbaudes ir sakārtotas tā, lai katra izslēgtu lētāku cēloni nekā nākamā.

Vienā PPTP savienojumā notiek divas sarunas

PPTP GRE tunelī pārvadā parastu PPP sesiju, un abas sarunājas atsevišķi. Ārējais slānis izlemj, kā paketes tiek iekapsulētas un kurš vadības kanāls pastāv; iekšējā PPP sesija izlemj, kas ir partneris un kāda aizsardzība atrodas virsū. Tāpēc paroles uzvedne pierāda kaut ko tikai par iekšējo slāni, un pabeigta ārējā rokasspiediena pierāda neko par nevienu no abiem. Profili šeit sabrūk tāpēc, ka cilvēki atkļūdo tuneli, kamēr domstarpības sēž PPP iekšienē.

Vienkāršais CHAP ir izaicinājuma-atbildes apmaiņa RFC 1994, veidota uz kopīga noslēpuma un nekas cits. MS-CHAPv2 ir cita apmaiņa ar citiem ziņojumiem un citu izvadi, standartizēta RFC 2759. Kopīgais vārds abos nosaukumos ir vienīgais, kas tiem ir kopīgs uz vada. Neviens nosaukums nepasaka, ko apmaiņa izstrādā, un tieši tā ir vienīgā svarīgā daļa.

Tāpēc opcija, kas marķēta vienkārši kā CHAP, vecā profilā ir divdomīga. Kad serveris grib MS-CHAPv2 un klients piedāvā vienkāršo CHAP, saites vadība joprojām var pabeigties un parole joprojām var tikt pieņemta. Kļūme nāk vēlāk, kad serveris mēģina atvasināt aizsardzības atslēgas no apmaiņas, kas neko neizstrādāja.

Saskaņojiet pieprasīto metodi ar atslēgām, ko tā var izstrādāt

MPPE atslēgas nav vispārēja PPP īpašība. Microsoft CHAP saimei atvasināšana ir noteikta RFC 3079, un tā kā ievadi ņem MS-CHAP apmaiņas izvadi, nevis kopīgu noslēpumu. EAP metodes sasniedz to pašu vietu citā ceļā, un autentifikācijas serveris atgriež atslēgas kā atribūtus MS-MPPE-Recv-Key un MS-MPPE-Send-Key. Vienkāršais CHAP neparādās nevienā no abiem ceļiem, un tas ir viss iemesls, kāpēc šī neatbilstība pastāv.

Konfigurācija, kas pieprasa MPPE, bet noraida katru metodi, kas spēj piegādāt atslēgas, ir iekšēji pretrunīga. pppd šo pretrunu atrisina, noraidot saiti, nevis izgudrojot atslēgas, tāpēc redzamais rezultāts ir sesija, kas autentificējas un pēc tam beidzas tīkla fāzē. Klienta atkārtota mēģināšana to nemainīs, kamēr serveris noraida vienīgās metodes, kas kaut ko atvasina.

No tā izrietošais noteikums ir īss: ja profils pieprasa MPPE, metodei jābūt MS-CHAP variantam vai EAP metodei, kuras atslēgas serveris atgriež. Noraidīt tikai MS-CHAPv2 to nepanāk, jo MS-CHAPv1 arī atvasina atslēgas un paliek pieejams, ja vien to nenoraida atsevišķi; noraidot abus, paliek vienkāršais CHAP un PAP, kas neko neatvasina un padara prasību neizpildāmu. Nosauciet pieņemto metodi skaidri, nevis uzskaitiet tās, kas jums nepatīk. Šifrēšanas prasības atmešana, lai klients pievienotos, ir pazeminājums, nevis remonts.

Izlasiet servera opcijas pirms klienta rediģēšanas

Lielākā daļa šo neatbilstību ir redzamas serverī divos failos, un to lasīšana maksā mazāk nekā klienta pārbūve. Linux PPTP galapunktā attiecīgie iestatījumi dzīvo pppd opciju failā, ko pptpd nodod tālāk. Palaidiet to serverī, nevis klienta statusa ekrānā. Sāciet ar rindām, kas pieprasa, noraida vai nosauc aizsardzības režīmu:

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

Lasiet izvadi kā līgumu, nevis kā karodziņu sarakstu. Rindu, kas pieprasa MPPE, bet noraida abus MS-CHAP variantus, nevar izpildīt neviens klients, un trūkstoša prasība MS-CHAP metodei atstāj durvis vaļā apmaiņām, kas nedod atslēgas. Pēc tam pārbaudiet, kam vispār ir atļauts autentificēties, ko nosaka noslēpumu fails:

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

Pierakstiet trīs vērtības pirms kaut kā maiņas: ārējo protokolu, servera pieprasīto autentifikācijas metodi un to, vai aizsardzība ir obligāta vai neobligāta. Šīs trīs nosaka katru vēlāko lēmumu, un to minēšana no klienta dialoga ir ceļš, kā profils paliek puslīdz konfigurēts. Turiet failu atvērtu, kamēr strādājat, jo nākamajai sadaļai vajadzīgas tās pašas trīs vērtības.

Atrodiet kļūmi pēc PPP fāzes

PPP ziņo par kļūmēm fāzēs, un fāze pasaka, kura līguma klauzula tika pārkāpta. Saitei, kas nekad neiziet no saites vadības, ir iekapsulēšanas vai sarunu problēma, bet tai, kas autentificējas un pēc tam mirst, parasti ir politikas vai atslēgas problēma. Saite, kas paliek augšā un neko nenes, ir pārgājusi uz maršrutēšanu, kas ir cits izmeklēšanas virziens.

Žurnāls glabā fāžu rindas, un tās ir noderīgākas par augstāku atkļūdošanas līmeni. Pieprasiet PPP procesus un aizsardzības ziņojumus, tad izlasiet autentifikācijas rezultātu pirms visa cita. Pēdējās rindas parasti nosauc klauzulu, kas noraidīja:

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

Šajā izvadē vispirms meklējiet autentifikācijas rezultātu un pēc tam sūdzību, ka aizsardzība tika pieprasīta, bet netika saskaņota. Otrais ziņojums ir iepriekš aprakstītās pretrunas paraksts, un nekāds atkārtojumu daudzums to neizdzēš, kamēr serveris noraida vienīgo metodi, kas spēj izstrādāt atslēgas. Ir vērts nosaukt divus slazdus: atkļūdošanas līmeņa celšana, nelasot fāžu rindas, rada troksni, un izaicinājuma materiāla vai paroļu tveršana konfigurācijas uzdevumu pārvērš akreditācijas datu noplūdē. Pierakstiet šo fāzi pirms jebkuras opcijas maiņas.

Plānojiet izeju, pirms vecais galapunkts tiek izslēgts

MPPE ir vēsturisks saites aizsardzības mehānisms, un tā klātbūtne nepadara PPTP par saprātīgu izvēli jaunai ieviešanai. Pašreizējās Microsoft vadlīnijas jau iesaka pret PPTP un pret L2TP/IPsec ar iepriekš kopīgu atslēgu jaunām attālinātās piekļuves ieviešanām. Vecā galapunkta uzturēšana dzīvē ir lēmums par esošu pakalpojumu, nevis veidne nākamajam.

Kad galapunktam jāpaliek, pierakstiet līgumu: ārējais protokols, pieprasītā autentifikācijas metode, obligātā aizsardzība un klienta versija, kas par to vienojas. Kad tas var aiziet, pirms vecā profila aizskaršanas izvēlieties aizstājēja vārtejas identitāti, tā klienta autentifikāciju un vietu, kur dzīvos akreditācijas dati. Pēc tam plānojiet maršrutus, DNS un resursus, kuriem katram lietotājam ir atļauts piekļūt. Validējiet paredzēto klientu pret īpašnieka prasībām, nevis pret strādājošu savienojumu.

Apzinātai noraidīšanai jāpaliek noraidīšanai, jo atkāpšanās neaizsargātā režīmā, lai tests izietu, politikas kļūmi pārvērš pakļautībā. Gatavais stāvoklis ir atbalstīts, dokumentēts līgums, nevis mazākais izmaiņu kopums, kas ļauj vienam vecam savienojumam izdoties. Atstājiet veco profilu savā vietā, neizmantotu un dokumentētu, līdz aizstājējs iztur tās pašas pārbaudes.