Kodėl vien PPP CHAP negali įvykdyti MPPE reikalavimo

PPTP profilis, reikalaujantis šifravimo, dažniausiai sugenda toje pačioje vietoje: PPP susitaria dėl autentifikavimo mainų, kurie niekada nesukuria MPPE reikalingos raktų medžiagos. Tunelis atrodo pusgyvis, slaptažodis priimamas, o ryšys nutrūksta prieš jam pereinant bet kokiam srautui. Siekiant CHAP išskleidžiamojo sąrašo tol, kol kas nors prisijungs, paslepiamas tikrasis defektas, o tai yra sutartis tarp autentifikavimo metodo ir apsaugos politikos. Toliau pateikti patikrinimai išdėstyti taip, kad kiekvienas atmeta pigesnę priežastį nei kitas.

Vienoje PPTP jungtyje vyksta dvi derybos

PPTP perduoda įprastą PPP sesiją GRE tunelio viduje, ir abi derasi atskirai. Išorinis sluoksnis nusprendžia, kaip paketai inkapsuliuojami ir koks valdymo kanalas egzistuoja; vidinė PPP sesija nusprendžia, kas yra partneris ir kokia apsauga yra viršuje. Todėl slaptažodžio užklausa įrodo ką nors tik apie vidinį sluoksnį, o baigtas išorinis rankos paspaudimas neįrodo nieko apie nė vieną iš jų. Profiliai čia sugenda todėl, kad žmonės derina tunelį, o nesutarimas glūdi PPP viduje.

Paprastas CHAP yra iššūkio-atsakymo mainai pagal RFC 1994, sukurti bendros paslapties ir nieko daugiau pagrindu. MS-CHAPv2 yra kiti mainai su kitomis žinutėmis ir kita išvestimi, standartizuoti RFC 2759. Bendras žodis abiejuose pavadinimuose yra vienintelis dalykas, kurį jie turi bendro laidu. Nė vienas pavadinimas nesako, ką mainai sukuria, ir būtent tai yra vienintelė svarbi dalis.

Štai kodėl parinktis, pažymėta tiesiog CHAP, sename profilyje yra dviprasmė. Kai serveris nori MS-CHAPv2, o klientas siūlo paprastą CHAP, ryšio valdymas vis tiek gali baigtis ir slaptažodis vis tiek gali būti priimtas. Gedimas ateina vėliau, kai serveris bando išvesti apsaugos raktus iš mainų, kurie nieko nesukūrė.

Suderinkite reikalaujamą metodą su raktais, kuriuos jis gali sukurti

MPPE raktai nėra bendra PPP savybė. Microsoft CHAP šeimai išvedimas nurodytas RFC 3079, ir jis kaip įvestį ima MS-CHAP mainų išvestį, o ne bendrą paslaptį. EAP metodai pasiekia tą pačią vietą kitu keliu, kai autentifikavimo serveris grąžina raktus kaip atributus MS-MPPE-Recv-Key ir MS-MPPE-Send-Key. Paprastas CHAP neatsiranda nė viename kelyje, ir tai yra visa priežastis, kodėl šis neatitikimas egzistuoja.

Konfigūracija, kuri reikalauja MPPE ir kartu atmeta kiekvieną metodą, galintį tiekti raktus, yra vidujai prieštaringa. pppd šį prieštaravimą sprendžia atmesdamas ryšį, o ne išgalvodamas raktus, todėl matomas rezultatas yra sesija, kuri autentifikuojasi ir tada baigiasi tinklo fazėje. Kliento bandymas iš naujo to nepakeis, kol serveris atmeta vienintelius metodus, kurie ką nors išveda.

Iš to kylanti taisyklė trumpa: jei profilis reikalauja MPPE, metodas turi būti MS-CHAP variantas arba EAP metodas, kurio raktus serveris grąžina. Atmesti tik MS-CHAPv2 to nepakanka, nes MS-CHAPv1 taip pat išveda raktus ir lieka prieinamas, nebent jis atmetamas atskirai; atmetus abu lieka paprastas CHAP ir PAP, kurie nieko neišveda ir padaro reikalavimą neįvykdomu. Įvardykite priimtą metodą aiškiai, o ne išvardykite tuos, kurie jums nepatinka. Šifravimo reikalavimo atsisakymas, kad klientas prisijungtų, yra nuosmukis, o ne taisymas.

Perskaitykite serverio parinktis prieš redaguodami klientą

Dauguma šių neatitikimų matomi serveryje dviejuose failuose, o juos perskaityti pigiau nei perstatyti klientą. Linux PPTP galiniame taške atitinkami nustatymai gyvena pppd parinkčių faile, kurį perduoda pptpd. Vykdykite jį serveryje, o ne kliento būsenos ekrane. Pradėkite nuo eilučių, kurios reikalauja, atmeta arba įvardija apsaugos režimą:

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

Skaitykite išvestį kaip sutartį, o ne kaip vėliavėlių sąrašą. Eilutės, kuri reikalauja MPPE ir kartu atmeta abu MS-CHAP variantus, negali įvykdyti joks klientas, o trūkstamas reikalavimas MS-CHAP metodui palieka duris atviras mainams, kurie neduoda raktų. Tada patikrinkite, kam apskritai leidžiama autentifikuotis, ką nusprendžia paslapčių failas:

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

Užrašykite tris reikšmes prieš ką nors keisdami: išorinį protokolą, serverio reikalaujamą autentifikavimo metodą ir ar apsauga yra privaloma, ar neprivaloma. Šie trys nulemia kiekvieną vėlesnį sprendimą, o jų spėliojimas iš kliento dialogo yra kelias, kuriuo profilis lieka pusiau sukonfigūruotas. Laikykite failą atidarytą dirbdami, nes kitam skyriui reikia tų pačių trijų reikšmių.

Raskite gedimą pagal PPP fazę

PPP praneša apie gedimus fazėmis, o fazė pasako, kuri sutarties sąlyga buvo pažeista. Ryšys, kuris niekada nepalieka ryšio valdymo, turi inkapsuliavimo arba derybų problemą, o tas, kuris autentifikuojasi ir tada miršta, dažniausiai turi politikos arba rakto problemą. Ryšys, kuris lieka pakeltas ir nieko neneša, perėjo prie maršrutizavimo, o tai yra kitas tyrimas.

Žurnalas saugo fazių eilutes, ir jos naudingesnės nei aukštesnis derinimo lygis. Paprašykite PPP procesų ir apsaugos pranešimų, tada perskaitykite autentifikavimo rezultatą prieš visa kita. Paskutinės eilutės dažniausiai įvardija sąlygą, kuri atmetė:

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

Toje išvestyje pirmiausia ieškokite autentifikavimo rezultato, o tada skundo, kad apsauga buvo reikalaujama, bet nebuvo suderėta. Antrasis pranešimas yra aukščiau aprašyto prieštaravimo parašas, ir joks pakartojimų kiekis jo nepašalina, kol serveris atmeta vienintelį metodą, galintį sukurti raktus. Verta įvardyti dvi spąstus: derinimo lygio kėlimas neskaitant fazių eilučių sukuria triukšmą, o iššūkio medžiagos ar slaptažodžių fiksavimas konfigūravimo užduotį paverčia prisijungimo duomenų nutekėjimu. Užrašykite tą fazę prieš keisdami bet kurią parinktį.

Suplanuokite išėjimą prieš išjungiant senąjį galinį tašką

MPPE yra istorinis ryšio apsaugos mechanizmas, ir jo buvimas nepadaro PPTP protingu pasirinkimu naujam diegimui. Dabartinės Microsoft gairės jau rekomenduoja prieš PPTP ir prieš L2TP/IPsec su iš anksto bendru raktu naujiems nuotolinės prieigos diegimams. Seno galinio taško palaikymas gyvo yra sprendimas dėl esamos paslaugos, o ne šablonas kitai.

Kai galinis taškas turi likti, užrašykite sutartį: išorinis protokolas, reikalaujamas autentifikavimo metodas, privaloma apsauga ir kliento versija, kuri ją derasi. Kai jis gali išeiti, prieš liesdami seną profilį pasirinkite pakaitalo tinklų sietuvos tapatybę, jo kliento autentifikavimą ir vietą, kur gyvens prisijungimo duomenys. Tada suplanuokite maršrutus, DNS ir išteklius, kuriuos kiekvienas naudotojas turi teisę pasiekti. Patikrinkite numatomą klientą pagal savininko reikalavimus, o ne pagal veikiantį ryšį.

Tyčinis atmetimas turėtų likti atmetimu, nes grįžimas į neapsaugotą režimą, kad testas praeitų, politikos gedimą paverčia pavojumi. Galutinė būsena yra palaikoma, dokumentuota sutartis, o ne mažiausias pakeitimų rinkinys, leidžiantis vienam senam ryšiui pasisekti. Palikite seną profilį jo vietoje, nenaudojamą ir dokumentuotą, kol pakaitalas praeis tuos pačius patikrinimus.