Zašto samo PPP CHAP ne može ispuniti zahtev za MPPE

PPTP profil koji insistira na šifriranju obično pada na istom mestu: PPP se dogovori oko razmene autentifikacije koja nikada ne proizvede ključni materijal koji MPPE traži. Tunel izgleda poluživ, lozinka se prihvata, a veza puca pre nego što je preko nje prešao ikakav saobraćaj. Posezanje za CHAP padajućim menijem dok se nešto ne poveže skriva pravi defekt, a to je ugovor između metoda autentifikacije i politike zaštite. Provere ispod su poređane tako da svaka isključuje jeftiniji uzrok od sledeće.

Dva pregovaranja teku unutar jedne PPTP veze

PPTP nosi normalnu PPP sesiju unutar GRE tunela, a njih dvoje pregovaraju odvojeno. Spoljni sloj odlučuje kako se paketi inkapsuliraju i koji kontrolni kanal postoji; unutrašnja PPP sesija odlučuje ko je sagovornik i kakva zaštita ide povrh. Zahtev za lozinkom stoga dokazuje nešto samo o unutrašnjem sloju, a završeno spoljno rukovanje ne dokazuje ništa ni o jednom od njih. Profili ovde padaju jer ljudi otklanjaju greške na tunelu dok neslaganje sedi unutar PPP-a.

Obični CHAP je razmena izazova i odgovora u RFC 1994, izgrađena na zajedničkoj tajni i ničemu drugom. MS-CHAPv2 je druga razmena sa drugačijim porukama i drugačijim izlazom, standardizovana u RFC 2759. Zajednička reč u dva imena jedino je što im je zajedničko na žici. Nijedno ime ne kaže šta razmena proizvodi, a to je jedini deo koji je važan.

Zato je opcija označena samo kao CHAP dvosmislena u starom profilu. Kada server želi MS-CHAPv2, a klijent nudi obični CHAP, kontrola veze ipak može završiti i lozinka ipak može biti prihvaćena. Neuspeh dolazi kasnije, kada server pokuša izvesti ključeve zaštite iz razmene koja nije proizvela ništa.

Uskladite traženi metod s ključevima koje može proizvesti

MPPE ključevi nisu svojstvo PPP-a uopšte. Za porodicu Microsoft CHAP izvođenje je propisano u RFC 3079, a kao ulaz uzima izlaz MS-CHAP razmene, a ne zajedničku tajnu. EAP metodi dolaze do istog mesta drugim putem, pri čemu server za autentifikaciju vraća ključeve kao atribute MS-MPPE-Recv-Key i MS-MPPE-Send-Key. Obični CHAP se ne pojavljuje ni na jednom putu, i to je ceo razlog postojanja nesklada.

Konfiguracija koja traži MPPE, a odbija svaki metod sposoban da isporuči ključeve, unutrašnje je protivrečna. pppd rešava tu protivrečnost odbijanjem veze, a ne izmišljanjem ključeva, pa je vidljiv rezultat sesija koja se autentifikuje i zatim završava tokom mrežne faze. Ponovni pokušaji klijenta to neće promeniti dok server odbija jedine metode koje nešto izvode.

Pravilo koje sledi je kratko: ako profil traži MPPE, metod mora biti varijanta MS-CHAP-a ili EAP metod čije ključeve server vraća. Odbijanje samo MS-CHAPv2 to ne sprovodi, jer MS-CHAPv1 takođe izvodi ključeve i ostaje dostupan osim ako se odbije zasebno; odbijanje oba ostavlja obični CHAP i PAP, koji ne izvode ništa i čine zahtev neispunjivim. Imenujte prihvaćeni metod izričito umesto da nabrajate one koje ne volite. Odustajanje od zahteva za šifriranjem da bi se klijent povezao je degradacija, a ne popravka.

Pročitajte serverske opcije pre uređivanja klijenta

Većina ovih nesklada vidljiva je na serveru u dve datoteke, a njihovo čitanje košta manje od ponovne izgradnje klijenta. Na Linux PPTP krajnjoj točki relevantne postavke žive u pppd datoteci opcija koju pptpd prosleđuje. Pokrenite je na serveru, a ne s ekrana statusa klijenta. Počnite s redovima koji traže, odbijaju ili imenuju način zaštite:

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

Čitajte izlaz kao ugovor, a ne kao popis zastavica. Red koji traži MPPE, a odbija obe varijante MS-CHAP-a, ne može ispuniti nijedan klijent, a nedostajući zahtev za MS-CHAP metod ostavlja vrata otvorena razmenama koje ne daju ključeve. Zatim proverite kome je uopšte dopuštena autentifikacija, što odlučuje datoteka tajni:

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

Zapišite tri vrednosti pre nego što bilo šta promenite: spoljni protokol, metod autentifikacije koji server traži, i da li je zaštita obavezna ili opciona. Te tri određuju svaku kasniju odluku, a nagađanje o njima iz klijentskog dijaloga je način na koji profil završi napola konfigurisan. Držite datoteku otvorenom dok radite, jer sledeći odeljak treba iste tri vrednosti.

Locirajte kvar po PPP fazi

PPP prijavljuje kvarove po fazama, a faza kaže koja je klauzula ugovora prekršena. Veza koja nikada ne napusti kontrolu veze ima problem s inkapsulacijom ili pregovaranjem, dok ona koja se autentifikuje i zatim umre obično ima problem s politikom ili ključem. Veza koja ostane podignuta i ne nosi ništa prešla je na rutiranje, što je druga istraga.

Dnevnik čuva redove faza, i oni su korisniji od višeg nivoa otklanjanja grešaka. Zatražite PPP procese i poruke zaštite, pa pročitajte rezultat autentifikacije pre svega ostalog. Poslednji redovi obično imenuju klauzulu koja je odbila:

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

U tom izlazu najpre tražite rezultat autentifikacije, a zatim pritužbu da je zaštita bila tražena ali nije pregovarana. Druga poruka je potpis gornje protivrečnosti, i nikakvo ponavljanje je ne uklanja dok server odbija jedini metod koji može proizvesti ključeve. Dve zamke vredi imenovati: podizanje nivoa otklanjanja grešaka bez čitanja redova faza proizvodi šum, a hvatanje materijala izazova ili lozinki pretvara konfiguracijski zadatak u curenje akreditiva. Zabeležite tu fazu pre nego što promenite bilo koju opciju.

Isplanirajte izlaz pre nego što se stara krajnja točka isključi

MPPE je istorijski mehanizam zaštite veze, a njegovo prisustvo ne čini PPTP razumnim izborom za novo postavljanje. Aktuelne Microsoftove smernice već savetuju protiv PPTP-a i protiv L2TP/IPsec-a s unapred deljenim ključem za nova postavljanja daljinskog pristupa. Održavanje stare krajnje točke na životu odluka je o postojećoj usluzi, a ne predložak za sledeću.

Kada krajnja točka mora ostati, zapišite ugovor: spoljni protokol, traženi metod autentifikacije, obaveznu zaštitu i verziju klijenta koja to pregovara. Kada može otići, odaberite identitet pristupnika zamene, njegovu autentifikaciju klijenta i mesto gde će akreditivi živeti pre nego što dotaknete stari profil. Zatim isplanirajte rute, DNS i resurse do kojih svaki korisnik ima ovlaštenje. Proverite predviđeni klijent prema zahtevima vlasnika, a ne prema radnoj vezi.

Namerno odbijanje treba ostati odbijanje, jer vraćanje na nezaštićeni način da bi test prošao pretvara neuspeh politike u izlaganje. Završeno stanje je podržan, dokumentovan ugovor, a ne najmanji skup izmena koji čini da jedna stara veza uspe. Ostavite stari profil na mestu, neiskorišten i dokumentovan, dok zamena ne prođe iste provere.