Proč samotný PPP CHAP nesplní požadavek na MPPE

PPTP profil, který trvá na šifrování, obvykle selhává na stejném místě: PPP se dohodne na výměně autentizace, která nikdy nevytvoří klíčový materiál, jenž MPPE potřebuje. Tunel vypadá napůl živý, heslo je přijato a spojení spadne dřív, než přes něj přejde jakýkoli provoz. Sáhnutí po rozevíracím seznamu CHAP, dokud se něco nepřipojí, skrývá skutečnou vadu, a tou je smlouva mezi metodou autentizace a politikou ochrany. Kontroly níže jsou seřazeny tak, aby každá vyloučila levnější příčinu než ta následující.

Uvnitř jednoho PPTP spojení probíhají dvě vyjednávání

PPTP nese normální PPP relaci uvnitř tunelu GRE a obě vyjednávají odděleně. Vnější vrstva rozhoduje o tom, jak se pakety zapouzdřují a který řídicí kanál existuje; vnitřní PPP relace rozhoduje o tom, kdo je protějšek a jaká ochrana jde navrch. Výzva k zadání hesla tedy dokazuje něco jen o vnitřní vrstvě a dokončený vnější handshake nedokazuje nic ani o jedné z nich. Profily zde selhávají proto, že lidé ladí tunel, zatímco nesoulad sedí uvnitř PPP.

Obyčejný CHAP je výměna výzvy a odpovědi z RFC 1994, postavená na sdíleném tajemství a ničem jiném. MS-CHAPv2 je jiná výměna s jinými zprávami a jiným výstupem, standardizovaná v RFC 2759. Sdílené slovo ve dvou názvech je jediné, co mají na drátě společné. Ani jeden název neříká, co výměna vytvoří, a to je jediná část, na které záleží.

Proto je volba označená prostě CHAP ve starém profilu nejednoznačná. Když server chce MS-CHAPv2 a klient nabízí obyčejný CHAP, řízení spojení může stále dokončit a heslo může být stále přijato. Selhání přijde později, když se server pokusí odvodit ochranné klíče z výměny, která nic nevytvořila.

Slaďte požadovanou metodu s klíči, které může vytvořit

Klíče MPPE nejsou obecně vlastností PPP. Pro rodinu Microsoft CHAP je odvození určeno v RFC 3079 a jako vstup bere výstup výměny MS-CHAP, nikoli sdílené tajemství. Metody EAP se na stejné místo dostanou jinou cestou, přičemž autentizační server vrací klíče jako atributy MS-MPPE-Recv-Key a MS-MPPE-Send-Key. Obyčejný CHAP se neobjevuje ani na jedné cestě, a to je celý důvod, proč nesoulad existuje.

Konfigurace, která vyžaduje MPPE a zároveň odmítá každou metodu schopnou dodat klíče, je vnitřně rozporná. pppd tento rozpor řeší odmítnutím spojení, ne vymýšlením klíčů, takže viditelným výsledkem je relace, která se autentizuje a poté skončí během síťové fáze. Opakované pokusy klienta to nezmění, dokud server odmítá jediné metody, které něco odvozují.

Pravidlo, které z toho plyne, je krátké: pokud profil vyžaduje MPPE, musí být metoda variantou MS-CHAP nebo metodou EAP, jejíž klíče server vrací. Odmítnutí pouze MS-CHAPv2 to nevynutí, protože MS-CHAPv1 také odvozuje klíče a zůstává dostupný, dokud není odmítnut zvlášť; odmítnutí obou ponechá obyčejný CHAP a PAP, které nic neodvozují a činí požadavek nesplnitelným. Pojmenujte přijatou metodu výslovně místo vypisování těch, které nemáte rádi. Zrušení požadavku na šifrování, aby se klient připojil, je degradace, ne oprava.

Přečtěte si volby serveru dřív, než upravíte klienta

Většina těchto nesouladů je na serveru vidět ve dvou souborech a jejich přečtení stojí méně než přestavba klienta. Na linuxovém PPTP koncovém bodu žijí příslušná nastavení v souboru voleb pppd, který pptpd předává. Spusťte ho na serveru, ne z obrazovky stavu klienta. Začněte řádky, které vyžadují, odmítají nebo pojmenovávají režim ochrany:

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

Čtěte výstup jako smlouvu, ne jako seznam přepínačů. Řádek, který vyžaduje MPPE a zároveň odmítá obě varianty MS-CHAP, nemůže splnit žádný klient, a chybějící požadavek na metodu MS-CHAP nechává dveře otevřené výměnám, které nedávají klíče. Potom zkontrolujte, kdo se vůbec smí autentizovat, což určuje soubor tajemství:

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

Než cokoli změníte, zapište tři hodnoty: vnější protokol, metodu autentizace, kterou server vyžaduje, a zda je ochrana povinná, nebo volitelná. Tyto tři určují každé další rozhodnutí a jejich hádání z dialogu klienta je způsob, jak skončí profil napůl nakonfigurovaný. Nechte soubor otevřený, protože další část potřebuje stejné tři hodnoty.

Najděte selhání podle fáze PPP

PPP hlásí selhání po fázích a fáze říká, která klauzule smlouvy se porušila. Spojení, které nikdy neopustí řízení spojení, má problém se zapouzdřením nebo vyjednáváním, zatímco to, které se autentizuje a pak umře, má obvykle problém s politikou nebo klíčem. Spojení, které zůstane nahoru a nic nenese, přešlo na směrování, což je jiné vyšetřování.

Journal uchovává řádky fází a ty jsou užitečnější než vyšší úroveň ladění. Vyžádejte si procesy PPP a zprávy o ochraně a potom přečtěte výsledek autentizace dřív než cokoli jiného. Poslední řádky obvykle pojmenují klauzuli, která odmítla:

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

V tomto výstupu hledejte nejprve výsledek autentizace a potom stížnost, že ochrana byla vyžadována, ale nebyla vyjednána. Druhá zpráva je podpisem výše uvedeného rozporu a žádné opakování ji neodstraní, dokud server odmítá jedinou metodu, která může vytvořit klíče. Dvě pasti stojí za pojmenování: zvyšování úrovně ladění bez čtení řádků fází vytváří šum a zachycování materiálu výzvy nebo hesel mění konfigurační úlohu v únik přihlašovacích údajů. Zaznamenejte tu fázi, než změníte jakoukoli volbu.

Naplánujte odchod dřív, než se starý koncový bod vypne

MPPE je historický mechanismus ochrany spojení a jeho přítomnost nedělá z PPTP rozumnou volbu pro nové nasazení. Současné pokyny Microsoftu už nedoporučují PPTP ani L2TP/IPsec s předem sdíleným klíčem pro nová nasazení vzdáleného přístupu. Udržovat starý koncový bod naživu je rozhodnutí o existující službě, ne šablona pro tu následující.

Když koncový bod musí zůstat, zapište smlouvu: vnější protokol, požadovanou metodu autentizace, povinnou ochranu a verzi klienta, která ji vyjednává. Když může odejít, zvolte identitu brány náhrady, její autentizaci klienta a místo, kde budou žít přihlašovací údaje, dřív než se dotknete starého profilu. Potom naplánujte trasy, DNS a prostředky, ke kterým je každý uživatel oprávněn. Ověřte zamýšleného klienta proti požadavkům vlastníka, ne proti fungujícímu spojení.

Záměrné odmítnutí má zůstat odmítnutím, protože návrat k nechráněnému režimu, aby test prošel, mění selhání politiky v vystavení. Hotový stav je podporovaná, zdokumentovaná smlouva, ne nejmenší sada změn, která umožní jednomu starému spojení uspět. Nechte starý profil na místě, nepoužívaný a zdokumentovaný, dokud náhrada neprojde stejnými kontrolami.