Hvers vegna PPP CHAP eitt og sér getur ekki uppfyllt MPPE-kröfu

PPTP-snið sem krefst dulritunar mistekst venjulega á sama stað: PPP samþykkir auðkenningarskipti sem framleiða aldrei það lykilefni sem MPPE þarf. Göngin virka hálf-lifandi, lykilorðið er samþykkt og tengingin fellur áður en nokkur umferð fer yfir hana. Að grípa í CHAP-valmyndina þar til eitthvað tengist hylur raunverulega gallann, og hann er samningur milli auðkenningaraðferðarinnar og verndarstefnunnar. Prófanirnar hér að neðan eru raðað þannig að hver þeirra útilokar ódýrari orsök en sú næsta.

Tvær samningaviðræður fara fram innan einnar PPTP-tengingar

PPTP ber venjulega PPP-lotu innan GRE-ganga, og þær tvær semja sérstaklega. Ytra lagið ákveður hvernig pakkar eru umluktir og hvaða stjórnrás er til; innri PPP-lotan ákveður hver jafninginn er og hvaða vernd liggur ofan á. Lykilorðsbeiðni sannar því aðeins eitthvað um innra lagið, og lokið ytri handaband sannar ekkert um hvort þeirra. Snið mistekst hér vegna þess að fólk villuleitar göngin á meðan ágreiningurinn situr innan PPP.

Venjulegt CHAP er áskorun-og-svar skiptin í RFC 1994, byggð á sameiginlegu leyndarmáli og engu öðru. MS-CHAPv2 er annað skipti með öðrum skilaboðum og annarri úttak, stöðluð í RFC 2759. Sameiginlega orðið í báðum nöfnunum er það eina sem þau eiga sameiginlegt á vírnum. Ekkert nafnið segir hvað skiptin framleiða, og það er eini hlutinn sem skiptir máli.

Þess vegna er valkostur sem einfaldlega heitir CHAP tvíræður í gömlu sniði. Þegar þjónninn vill MS-CHAPv2 og biðlarinn býður venjulegt CHAP getur tengistjórnun samt klárast og lykilorð samt verið samþykkt. Mistökin koma seinna, þegar þjónninn reynir að leiða verndarlykla úr skiptum sem framleiddu enga.

Passaðu kröfðu aðferðina við lyklana sem hún getur framleitt

MPPE-lyklar eru ekki eiginleiki PPP almennt. Fyrir Microsoft CHAP-fjölskylduna er afleiðslan tilgreind í RFC 3079, og hún tekur sem inntak úttak MS-CHAP-skipta frekar en sameiginlegt leyndarmál. EAP-aðferðir ná sama stað á annan hátt, þar sem auðkenningarþjónninn skilar lyklunum sem eigindunum MS-MPPE-Recv-Key og MS-MPPE-Send-Key. Venjulegt CHAP kemur ekki fyrir á hvorugri leiðinni, og það er öll ástæðan fyrir því að misræmið er til.

Stilling sem krefst MPPE en hafnar öllum aðferðum sem geta afhent lykla er innvortis mótsagnakennd. pppd leysir þá mótsögn með því að hafna tengingunni, ekki með því að finna upp lykla, svo sýnilega niðurstaðan er lota sem auðkennir sig og endar svo í netfasanum. Endurtekin tilraun biðlarans breytir því ekki á meðan þjónninn hafnar einu aðferðunum sem leiða eitthvað.

Reglan sem fylgir er stutt: ef sniðið krefst MPPE verður aðferðin að vera afbrigði af MS-CHAP eða EAP-aðferð sem þjónninn skilar lyklum hennar. Að hafna aðeins MS-CHAPv2 framfylgir því ekki, því MS-CHAPv1 leiðir líka lykla og helst aðgengilegt nema hafnað sé sérstaklega; að hafna báðum skilur eftir venjulegt CHAP og PAP, sem leiða ekkert og gera kröfuna óuppfyllanlega. Nefndu samþykktu aðferðina skýrt í stað þess að telja upp þær sem þér líkar ekki. Að sleppa dulritunarkröfunni svo biðlari tengist er lækkun, ekki viðgerð.

Lestu valkosti þjónsins áður en þú breytir biðlara

Flest þessara misræma sjást á þjóninum í tveimur skrám, og að lesa þær kostar minna en að endurbyggja biðlara. Á Linux PPTP-endapunkti lifa viðeigandi stillingar í pppd-valkostaskránni sem pptpd sendir áfram. Keyrðu hana á þjóninum, ekki af stöðuskjá biðlarans. Byrjaðu á línum sem krefjast, hafna eða nefna verndarham:

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

Lestu úttakið sem samning en ekki lista af fánum. Línu sem krefst MPPE en hafnar báðum afbrigðum MS-CHAP getur enginn biðlari uppfyllt, og skortur á kröfu fyrir MS-CHAP-aðferð lætur dyrnar standa opnar fyrir skiptum sem gefa enga lykla. Athugaðu svo hver má auðkenna sig yfirhöfuð, sem leyndarmálaskráin ræður:

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

Skrifaðu niður þrjú gildi áður en þú breytir nokkru: ytra samskiptareglan, auðkenningaraðferðina sem þjónninn krefst, og hvort vernd er skylda eða valfrjáls. Þessi þrjú ráða hverri síðari ákvörðun, og að giska á þau úr biðlaraglugga er hvernig snið endar hálfstillt. Hafðu skrána opna á meðan þú vinnur, því næsti kafli þarf sömu þrjú gildin.

Finndu mistökin eftir PPP-fasa

PPP tilkynnir mistök í fasa, og fasinn segir hvaða skilmáli samningsins brotnaði. Tenging sem fer aldrei út úr tengistjórnun hefur umlukningar- eða samningavandamál, á meðan sú sem auðkennir sig og deyr svo hefur venjulega stefnu- eða lykilvandamál. Tenging sem stendur uppi og ber ekkert hefur færst yfir í leiðslu, sem er önnur rannsókn.

Dagbókin geymir fasalinurnar, og þær eru gagnlegri en hærra villuleitarstig. Biddu um PPP-ferlana og verndarskilaboðin, lestu svo auðkenningarniðurstöðuna fyrir öllu öðru. Síðustu línurnar nefna venjulega skilmálann sem hafnaði:

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

Í því úttaki skaltu fyrst leita að auðkenningarniðurstöðunni og svo að kvörtun um að vernd hafi verið krafist en ekki samið um hana. Seinni skilaboðin eru undirskrift mótsagnarinnar hér að ofan, og engin endurtaka hreinsar hana á meðan þjónninn hafnar einu aðferðinni sem getur framleitt lykla. Tvær gildrur eru þess virði að nefna: að hækka villuleitarstigið án þess að lesa fasalinurnar framleiðir hávaða, og að grípa áskorunarefni eða lykilorð breytir stillingarverkefni í leka á skilríkjum. Skráðu þann fasa áður en þú breytir nokkrum valkosti.

Skipuleggðu brottförina áður en gamli endapunkturinn er slökktur

MPPE er söguleg tengiverndaraðferð, og tilvist hennar gerir PPTP ekki að skynsamlegu vali fyrir nýja uppsetningu. Núverandi leiðbeiningar Microsoft mæla þegar gegn PPTP og gegn L2TP/IPsec með fyrirfram deildum lykli fyrir nýjar fjartengingar. Að halda gömlum endapunkti lifandi er ákvörðun um núverandi þjónustu, ekki sniðmát fyrir þá næstu.

Þegar endapunkturinn verður að vera, skrifaðu samninginn: ytra samskiptareglan, kröfða auðkenningaraðferð, skyldubundna vernd og útgáfu biðlarans sem semur um hana. Þegar hann getur farið skaltu velja auðkenni gáttar staðgengilsins, auðkenningu biðlarans hans og hvar skilríkin munu búa áður en þú snertir gamla sniðið. Skipuleggðu svo leiðir, DNS og auðlindirnar sem hver notandi hefur heimild til að ná. Staðfestu fyrirhugaðan biðlara gegn kröfum eigandans, ekki gegn virkri tengingu.

Viljandi höfnun ætti að vera áfram höfnun, því að falla aftur í óvarið ham til að láta próf standast breytir stefnumistökum í berskjöldun. Fullbúið ástand er studdur, skjalfestur samningur, ekki minnsta breytingasettið sem lætur eina gamla tengingu heppnast. Láttu gamla sniðið vera á sínum stað, ónotað og skjalfest, þar til staðgengillinn stenst sömu prófanir.