Wêrom PPP CHAP allinnich net oan in MPPE-eask foldwaa kin

In PPTP-profyl dat op fersifering stiet, mislearret meastentiids op itselde plak: PPP komt oerien op in autentikaasje-útwikseling dy’t nea it kaaimateriaal leveret dat MPPE nedich hat. De tunnel liket heal libben, it wachtwurd wurdt akseptearre, en de ferbining falt foardat der ek mar wat ferkear trochhinne giet. Nei it CHAP-útlizzerslist gripe oant der wat ferbynt, ferberget it echte mankement, en dat is in kontrakt tusken de autentikaasjemetoade en it beskermingsbelied. De kontrôles hjirûnder binne sa oardere dat elk in goedkeapere oarsaak útslút as de folgjende.

Twa ûnderhannelingen rinne binnen ien PPTP-ferbining

PPTP draacht in gewoane PPP-sesje binnen in GRE-tunnel, en de beide ûnderhannelje apart. De bûtenste laach beslút hoe’t pakketten ynkapsulearre wurde en hokker kontrôlekanaal bestiet; de binnenste PPP-sesje beslút wa’t de peer is en hokker beskerming der boppe-op leit. In wachtwurd-oanfrege bewiist dus allinnich wat oer de binnenste laach, en in foltôge bûtenste hânskodding bewiist neat oer ien fan beide. Profylen mislearje hjir om’t minsken de tunnel debugge wylst it skeel binnen PPP sit.

Gewoane CHAP is de útdaging-respons-útwikseling yn RFC 1994, boud op in dield geheim en neat oars. MS-CHAPv2 is in oare útwikseling mei oare berjochten en in oare útfier, standerdisearre yn RFC 2759. It dielde wurd yn de beide nammen is it iennichste dat se op de tried mienskiplik hawwe. Gjin fan de nammen fertelt wat de útwikseling produsearret, en dat is it iennichste diel dat fan belang is.

Dêrom is in opsje dy’t gewoan CHAP hjit dûbelsinnich yn in âld profyl. As de tsjinner MS-CHAPv2 wol en de kliïnt gewoane CHAP oanbiedt, kin ferbiningskontrôle noch foltôgje en kin in wachtwurd noch akseptearre wurde. De mislearring komt letter, as de tsjinner besiket beskermingskaaien ôf te lieden fan in útwikseling dy’t gjinien produsearre hat.

Bring de easke metoade yn oerienstimming mei de kaaien dy’t it meitsje kin

MPPE-kaaien binne net in eigenskip fan PPP yn it algemien. Foar de Microsoft CHAP-famylje is de ôflieding beskreaun yn RFC 3079, en dy nimt as ynfier de útfier fan in MS-CHAP-útwikseling yn stee fan in dield geheim. EAP-metoaden berikke itselde plak fia in oare wei, wêrby’t de autentikaasjetsjinner de kaaien weromjout as attributen MS-MPPE-Recv-Key en MS-MPPE-Send-Key. Gewoane CHAP komt yn gjin fan beide wegen foar, en dat is de hiele reden dat de mismatch bestiet.

In konfiguraasje dy’t MPPE easket wylst er elke metoade wegeret dy’t kaaien leverje kin, is yntern tsjinstridich. pppd lost dy tsjinstridichheid op troch de ferbining te wegerjen, net troch kaaien te betinken, sadat it sichtbere resultaat in sesje is dy’t autentisearret en dan yn de netwurkfaze einiget. De kliïnt opnij probearje sil dat net feroarje salang’t de tsjinner de iennichste metoaden wegeret dy’t wat ôfliede.

De regel dy’t dêrop folget is koart: as it profyl MPPE easket, moat de metoade in MS-CHAP-fariant wêze of in EAP-metoade waans kaaien de tsjinner weromjout. Allinnich MS-CHAPv2 wegerje twingt dat net ôf, om’t MS-CHAPv1 ek kaaien ôfliedt en beskikber bliuwt útsein as it apart wegere wurdt; beide wegerje lit gewoane CHAP en PAP oer, dy’t neat ôfliede en de eask ûnferfolber meitsje. Neam de akseptearre metoade eksplisyt yn stee fan dyjingen op te listen dy’t jo net lije meie. De fersiferingsseask falle litte om in kliïnt ferbine te litten is in delgong, gjin reparaasje.

Lês de opsjes fan de tsjinner foardat jo in kliïnt bewurkje

De measte fan dizze mismatches binne op de tsjinner sichtber yn twa bestannen, en se lêze kostet minder as in kliïnt wer opbouwe. Op in Linux-PPTP-einpunt libje de relevante ynstellings yn it pppd-opsjebestân dat pptpd trochjout. Fier it út op de tsjinner, net fan in kliïntstatus-skerm. Begjin mei de rigels dy’t in beskermingsmodus easkje, wegerje of neame:

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

Lês de útfier as in kontrakt yn stee fan in list flaggen. In rigel dy’t MPPE easket wylst er beide MS-CHAP-farianten wegeret, kin troch gjin inkele kliïnt foldien wurde, en in ûntbrekkende eask foar in MS-CHAP-metoade lit de doar iepen foar útwikselings dy’t gjin kaaien jouwe. Kontrolearje dan wa’t überhaupt autentisearje mei, wat it geheimenbestân beslút:

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

Skriuw trije wearden op foardat jo wat feroarje: it bûtenste protokol, de autentikaasjemetoade dy’t de tsjinner easket, en oft beskerming ferplichte of opsjoneel is. Dy trije bepale elk letter beslút, en se riede út in kliïntdialooch is hoe’t in profyl heal konfigurearre einiget. Hâld it bestân iepen wylst jo wurkje, om’t de folgjende seksje deselde trije wearden nedich hat.

Fyn de mislearring oan de hân fan de PPP-faze

PPP rapportearret mislearrings yn fazen, en de faze fertelt hokker klausule fan it kontrakt brutsen is. In ferbining dy’t nea ferbiningskontrôle ferlit hat in ynkapsulaasje- of ûnderhannelingsprobleem, wylst ien dy’t autentisearret en dan stjert meastentiids in belieds- of kaaiprobeem hat. In ferbining dy’t oerein bliuwt en neat draacht is trochgien nei routing, wat in oar ûndersyk is.

It journaal bewarret de faze-rigels, en dy binne nuttiger as in heger debug-nivo. Freegje om de PPP-prosessen en de beskermingsberjochten, en lês dan it autentikaasjeresultaat foar al it oare. De lêste rigels neame meastentiids de klausule dy’t wegere:

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

Sykje yn dy útfier earst it autentikaasjeresultaat en dan in klacht dat beskerming easke wie mar net ûnderhannele. It twadde berjocht is de hantekening fan de tsjinstridichheid hjirboppe, en gjin hoemannichte opnij probearje hellet it fuort salang’t de tsjinner de iennichste metoade wegeret dy’t kaaien meitsje kin. Twa fallen binne it neamen wurdich: it debug-nivo ferheegje sûnder de faze-rigels te lêzen produsearret lûd, en it fangen fan útdagingsmateriaal of wachtwurden feroaret in konfiguraasjetaak yn in lek fan bewiisstikken. Skriuw dy faze op foardat jo in opsje feroarje.

Plan de útgong foardat it âlde einpunt útskeakele wurdt

MPPE is in histoarysk meganisme foar ferbiningsbeskerming, en syn oanwêzigens makket PPTP net in ferstannige kar foar in nije útrôl. De hjoeddeiske Microsoft-rjochtline riedt al ôf fan PPTP en fan L2TP/IPsec mei in foarôf dielde kaai foar nije útrôlen fan fjildtagong. In âld einpunt libben hâlde is in beslút oer in besteande tsjinst, gjin sjabloan foar de folgjende.

As it einpunt bliuwe moat, skriuw it kontrakt op: bûtenste protokol, easke autentikaasjemetoade, ferplichte beskerming, en de kliïntferzje dy’t it ûnderhannelt. As it gean kin, kies dan de gateway-identiteit fan de ferfanging, syn kliïntautentikaasje en wêr’t de bewiisstikken libje sille foardat jo it âlde profyl oanreitsje. Plan dan rûtes, DNS en de boarnen dêr’t elke brûker foech ta hat. Falidearje de bedoelde kliïnt tsjin de easken fan de eigner, net tsjin in wurkjende ferbining.

In bewuste wegering moat in wegering bliuwe, om’t weromfalle nei in ûnbeskerme modus om in test slagje te litten in beliedsfout yn in bleatstelling feroaret. De ôfmakke steat is in stipe, dokumintearre kontrakt, net de lytste set feroarings dy’t ien âlde ferbining slagje lit. Lit it âlde profyl op syn plak, ûnbrûkt en dokumintearre, oant de ferfanging deselde kontrôles slagget.