Prečo samotný PPP CHAP nemôže splniť požiadavku MPPE

PPTP profil, ktorý trvá na šifrovaní, zvyčajne zlyhá na tom istom mieste: PPP sa dohodne na výmene autentifikácie, ktorá nikdy nevytvorí kľúčový materiál, ktorý MPPE potrebuje. Tunel vyzerá napoly živý, heslo je prijaté a spojenie padne skôr, než ním prejde akákoľvek prevádzka. Siahnutie po rozbaľovacom zozname CHAP, kým sa niečo nepripojí, skrýva skutočnú chybu, a tou je zmluva medzi metódou autentifikácie a politikou ochrany. Kontroly nižšie sú zoradené tak, aby každá vylúčila lacnejšiu príčinu než tá nasledujúca.

V jednom PPTP spojení prebiehajú dve rokovania

PPTP prenáša normálnu reláciu PPP v tuneli GRE a obe rokujú oddelene. Vonkajšia vrstva rozhoduje, ako sa pakety zapuzdrujú a ktorý riadiaci kanál existuje; vnútorná relácia PPP rozhoduje, kto je partner a aká ochrana ide navrchu. Žiadosť o heslo teda dokazuje niečo len o vnútornej vrstve a dokončený vonkajší handshake nedokazuje nič ani o jednej z nich. Profily tu zlyhávajú preto, lebo ľudia ladia tunel, zatiaľ čo nesúlad sedí vnútri PPP.

Obyčajný CHAP je výmena výzvy a odpovede z RFC 1994, postavená na spoločnom tajomstve a ničom inom. MS-CHAPv2 je iná výmena s inými správami a iným výstupom, štandardizovaná v RFC 2759. Spoločné slovo v oboch názvoch je jediné, čo majú na drôte spoločné. Ani jeden názov nehovorí, čo výmena vytvára, a to je jediná časť, na ktorej záleží.

Preto je voľba označená jednoducho CHAP v starom profile nejednoznačná. Keď server chce MS-CHAPv2 a klient ponúka obyčajný CHAP, riadenie spojenia sa ešte môže dokončiť a heslo ešte môže byť prijaté. Zlyhanie prichádza neskôr, keď sa server pokúsi odvodiť ochranné kľúče z výmeny, ktorá nič nevytvorila.

Zlaďte požadovanú metódu s kľúčmi, ktoré dokáže vytvoriť

Kľúče MPPE nie sú všeobecne vlastnosťou PPP. Pre rodinu Microsoft CHAP je odvodzovanie určené v RFC 3079 a ako vstup berie výstup výmeny MS-CHAP, nie spoločné tajomstvo. Metódy EAP sa dostanú na to isté miesto inou cestou, pričom autentifikačný server vracia kľúče ako atribúty MS-MPPE-Recv-Key a MS-MPPE-Send-Key. Obyčajný CHAP sa neobjavuje ani na jednej z ciest, a to je celý dôvod existencie tohto nesúladu.

Konfigurácia, ktorá vyžaduje MPPE a zároveň odmieta každú metódu schopnú dodať kľúče, je vnútorne protirečivá. pppd tento rozpor rieši odmietnutím spojenia, nie vymýšľaním kľúčov, takže viditeľným výsledkom je relácia, ktorá sa autentifikuje a potom sa skončí v sieťovej fáze. Opakované pokusy klienta to nezmenia, kým server odmieta jediné metódy, ktoré niečo odvodzujú.

Pravidlo, ktoré z toho vyplýva, je krátke: ak profil vyžaduje MPPE, metóda musí byť variantom MS-CHAP alebo metódou EAP, ktorej kľúče server vracia. Odmietnutie iba MS-CHAPv2 to nevynucuje, pretože MS-CHAPv1 tiež odvodzuje kľúče a zostáva dostupný, ak sa neodmietne osobitne; odmietnutie oboch ponechá obyčajný CHAP a PAP, ktoré nič neodvodzujú a robia požiadavku nesplniteľnou. Pomenujte prijatú metódu výslovne namiesto vypisovania tých, ktoré nemáte radi. Vzdanie sa požiadavky na šifrovanie, aby sa klient pripojil, je zníženie, nie oprava.

Prečítajte si možnosti servera pred úpravou klienta

Väčšina týchto nesúladov je na serveri viditeľná v dvoch súboroch a ich prečítanie stojí menej než prestavba klienta. Na linuxovom PPTP koncovom bode žijú príslušné nastavenia v súbore možností pppd, ktorý odovzdáva pptpd. Spustite ho na serveri, nie z obrazovky stavu klienta. Začnite riadkami, ktoré vyžadujú, odmietajú alebo pomenúvajú režim ochrany:

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

Čítajte výstup ako zmluvu a nie ako zoznam prepínačov. Riadok, ktorý vyžaduje MPPE a zároveň odmieta oba varianty MS-CHAP, nemôže splniť žiadny klient, a chýbajúca požiadavka na metódu MS-CHAP necháva dvere otvorené výmenám, ktoré nedávajú kľúče. Potom skontrolujte, kto sa vôbec smie autentifikovať, čo určuje súbor tajomstiev:

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

Pred akoukoľvek zmenou si zapíšte tri hodnoty: vonkajší protokol, metódu autentifikácie, ktorú server vyžaduje, a či je ochrana povinná alebo voliteľná. Tieto tri určujú každé ďalšie rozhodnutie a ich hádanie z dialógu klienta je spôsob, akým profil skončí napoly nakonfigurovaný. Nechajte súbor otvorený, kým pracujete, pretože ďalšia časť potrebuje rovnaké tri hodnoty.

Nájdite zlyhanie podľa fázy PPP

PPP hlási zlyhania po fázach a fáza hovorí, ktorá klauzula zmluvy sa porušila. Spojenie, ktoré nikdy neopustí riadenie spojenia, má problém so zapuzdrením alebo rokovaním, kým to, ktoré sa autentifikuje a potom zomrie, má zvyčajne problém s politikou alebo kľúčom. Spojenie, ktoré zostane hore a nič nenesie, prešlo na smerovanie, čo je iné vyšetrovanie.

Journal uchováva riadky fáz a tie sú užitočnejšie než vyššia úroveň ladenia. Vyžiadajte procesy PPP a správy o ochrane a potom prečítajte výsledok autentifikácie pred všetkým ostatným. Posledné riadky zvyčajne pomenujú klauzulu, ktorá odmietla:

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

V tomto výstupe najprv hľadajte výsledok autentifikácie a potom sťažnosť, že ochrana bola požadovaná, ale nebola dohodnutá. Druhá správa je podpisom vyššie uvedeného rozporu a žiadne množstvo opakovaní ju neodstráni, kým server odmieta jedinú metódu, ktorá dokáže vytvoriť kľúče. Dve pasce stoja za pomenovanie: zvyšovanie úrovne ladenia bez čítania riadkov fáz vytvára šum a zachytávanie materiálu výzvy alebo hesiel mení konfiguračnú úlohu na únik prihlasovacích údajov. Zaznamenajte tú fázu, než zmeníte akúkoľvek možnosť.

Naplánujte odchod skôr, než sa starý koncový bod vypne

MPPE je historický mechanizmus ochrany spojenia a jeho prítomnosť nerobí z PPTP rozumnú voľbu pre nové nasadenie. Súčasné usmernenia Microsoftu už odrádzajú od PPTP aj od L2TP/IPsec s vopred zdieľaným kľúčom pre nové nasadenia vzdialeného prístupu. Udržiavať starý koncový bod nažive je rozhodnutie o existujúcej službe, nie šablóna pre tú nasledujúcu.

Keď koncový bod musí zostať, zapíšte zmluvu: vonkajší protokol, požadovanú metódu autentifikácie, povinnú ochranu a verziu klienta, ktorá ju dojednáva. Keď môže odísť, vyberte identitu brány náhrady, jej autentifikáciu klienta a miesto, kde budú žiť prihlasovacie údaje, skôr než sa dotknete starého profilu. Potom naplánujte trasy, DNS a prostriedky, na ktoré je každý používateľ oprávnený. Overte zamýšľaného klienta voči požiadavkám vlastníka, nie voči fungujúcemu spojeniu.

Úmyselné odmietnutie by malo zostať odmietnutím, pretože návrat k nechránenému režimu, aby test prešiel, mení zlyhanie politiky na vystavenie. Hotový stav je podporovaná, zdokumentovaná zmluva, nie najmenšia sada zmien, ktorá umožní jednému starému spojeniu uspieť. Nechajte starý profil na mieste, nepoužívaný a zdokumentovaný, kým náhrada neprejde tými istými kontrolami.