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

PPTP profil koji insistira na šifriranju obično pada na istom mjestu: PPP se dogovori oko razmjene autentifikacije koja nikada ne proizvede ključni materijal koji MPPE traži. Tunel izgleda poluživ, lozinka se prihvata, a veza puca prije 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. Provjere ispod su poredane tako da svaka isključuje jeftiniji uzrok od sljedeće.

Dvije pregovaranja teku unutar jedne PPTP veze

PPTP nosi normalnu PPP sesiju unutar GRE tunela, a njih dvoje pregovaraju odvojeno. Vanjski 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. Zahtjev za lozinkom stoga dokazuje nešto samo o unutrašnjem sloju, a završeno vanjsko rukovanje ne dokazuje ništa ni o jednom od njih. Profili ovdje padaju jer ljudi otklanjaju greške na tunelu dok neslaganje sjedi unutar PPP-a.

Obični CHAP je razmjena izazova i odgovora u RFC 1994, izgrađena na zajedničkoj tajni i ničemu drugom. MS-CHAPv2 je druga razmjena s drugačijim porukama i drugačijim izlazom, standardizovana u RFC 2759. Zajednička riječ u dva imena jedino je što im je zajedničko na žici. Nijedno ime ne kaže šta razmjena proizvodi, a to je jedini dio 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. Neuspjeh dolazi kasnije, kada server pokuša izvesti ključeve zaštite iz razmjene 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 razmjene, a ne zajedničku tajnu. EAP metodi dolaze do istog mjesta 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 cijeli razlog postojanja nesklada.

Konfiguracija koja traži MPPE, a odbija svaki metod sposoban da isporuči ključeve, unutrašnje je protivrječna. pppd rješava tu protivrječ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 promijeniti dok server odbija jedine metode koje nešto izvode.

Pravilo koje slijedi 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 zahtjev neispunjivim. Imenujte prihvaćeni metod izričito umjesto da nabrajate one koje ne volite. Odustajanje od zahtjeva za šifriranjem da bi se klijent povezao je degradacija, a ne popravka.

Pročitajte serverske opcije prije uređivanja klijenta

Većina ovih nesklada vidljiva je na serveru u dvije 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 prosljeđ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 obje varijante MS-CHAP-a, ne može ispuniti nijedan klijent, a nedostajući zahtjev za MS-CHAP metod ostavlja vrata otvorena razmjenama koje ne daju ključeve. Zatim provjerite 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 vrijednosti prije nego što bilo šta promijenite: vanjski protokol, metod autentifikacije koji server traži, i je li 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 sljedeći odjeljak treba iste tri vrijednosti.

Locirate 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 prije svega ostalog. Posljednji redovi obično imenuju klauzulu koja je odbila:

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

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

Isplanirajte izlaz prije 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. Aktualne Microsoftove smjernice već savjetuju protiv PPTP-a i protiv L2TP/IPsec-a s unaprijed dijeljenim 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 sljedeću.

Kada krajnja točka mora ostati, zapišite ugovor: vanjski protokol, traženi metod autentifikacije, obaveznu zaštitu i verziju klijenta koja to pregovara. Kada može otići, odaberite identitet pristupnika zamjene, njegovu autentifikaciju klijenta i mjesto gdje će akreditivi živjeti prije nego što dotaknete stari profil. Zatim isplanirajte rute, DNS i resurse do kojih svaki korisnik ima ovlaštenje. Provjerite predviđeni klijent prema zahtjevima vlasnika, a ne prema radnoj vezi.

Namjerno odbijanje treba ostati odbijanje, jer vraćanje na nezaštićeni način da bi test prošao pretvara neuspjeh politike u izlaganje. Završeno stanje je podržan, dokumentovan ugovor, a ne najmanji skup izmjena koji čini da jedna stara veza uspije. Ostavite stari profil na mjestu, neiskorišten i dokumentovan, dok zamjena ne prođe iste provjere.