Kial PPP CHAP sola ne povas plenumi postulon pri MPPE

PPTP-profilo, kiu insistas pri ĉifrado, kutime paneas en la sama loko: PPP interkonsentas pri aŭtentikiga interŝanĝo, kiu neniam produktas la ŝlosilmaterialon, kiun MPPE bezonas. La tunelo aspektas duone viva, la pasvorto akceptiĝas, kaj la ligo falas antaŭ ol iu ajn trafiko trapasas ĝin. Ekpreni la CHAP-malplektoliston ĝis io konektiĝas kaŝas la veran difekton, kaj tiu estas kontrakto inter la aŭtentikiga metodo kaj la protekta politiko. La kontroloj sube estas ordigitaj tiel, ke ĉiu ekskludas pli malmultekostan kaŭzon ol la sekva.

Du intertraktadoj okazas ene de unu PPTP-ligo

PPTP portas normalan PPP-sesion ene de GRE-tunelo, kaj ambaŭ intertraktas aparte. La ekstera tavolo decidas kiel pakoj enkapsuliĝas kaj kiu regkanalo ekzistas; la interna PPP-sesio decidas kiu estas la kunulo kaj kiu protekto sidas supre. Pasvorta instigo do pruvas ion nur pri la interna tavolo, kaj finita ekstera manpremo pruvas nenion pri iu el ili. Profiloj paneas ĉi tie ĉar homoj sencimigas la tunelon dum la malkonsento sidas ene de PPP.

Ordinara CHAP estas la defio-responda interŝanĝo en RFC 1994, konstruita sur komuna sekreto kaj nenio alia. MS-CHAPv2 estas alia interŝanĝo kun aliaj mesaĝoj kaj alia eligo, normigita en RFC 2759. La komuna vorto en la du nomoj estas la sola, kion ili havas komunan sur la drato. Neniu el la nomoj diras, kion la interŝanĝo produktas, kaj tio estas la sola parto, kiu gravas.

Tial opcio simple nomata CHAP estas ambigua en malnova profilo. Kiam la servilo volas MS-CHAPv2 kaj la kliento proponas ordinaran CHAP, ligokontrolo ankoraŭ povas finiĝi kaj pasvorto ankoraŭ povas esti akceptita. La paneo alvenas poste, kiam la servilo provas derivi protektajn ŝlosilojn el interŝanĝo, kiu produktis neniun.

Alkongruigu la postulatan metodon kun la ŝlosiloj, kiujn ĝi povas produkti

MPPE-ŝlosiloj ne estas eco de PPP ĝenerale. Por la familio Microsoft CHAP la derivado estas specifita en RFC 3079, kaj ĝi prenas kiel enigon la eligon de MS-CHAP-interŝanĝo anstataŭ komunan sekreton. EAP-metodoj atingas la saman lokon per alia vojo, ĉe kio la aŭtentikiga servilo redonas la ŝlosilojn kiel atributojn MS-MPPE-Recv-Key kaj MS-MPPE-Send-Key. Ordinara CHAP aperas en neniu el la du vojoj, kaj tio estas la tuta kialo, ke la miskongruo ekzistas.

Agordo, kiu postulas MPPE dum ĝi rifuzas ĉiun metodon kapablan liveri ŝlosilojn, estas interne kontraŭdira. pppd solvas tiun kontraŭdiron rifuzante la ligon, ne elpensante ŝlosilojn, do la videbla rezulto estas sesio, kiu aŭtentikiĝas kaj poste finiĝas dum la reta fazo. Ripeti la klienton ne ŝanĝos tion, dum la servilo rifuzas la solajn metodojn, kiuj derivas ion.

La regulo, kiu sekvas, estas mallonga: se la profilo postulas MPPE, la metodo devas esti variaĵo de MS-CHAP aŭ EAP-metodo, kies ŝlosilojn la servilo redonas. Rifuzi nur MS-CHAPv2 ne trudas tion, ĉar MS-CHAPv1 ankaŭ derivas ŝlosilojn kaj restas disponebla krom se ĝi estas aparte rifuzita; rifuzi ambaŭ lasas ordinaran CHAP kaj PAP, kiuj derivas nenion kaj faras la postulon neplenumebla. Nomu la akceptitan metodon eksplicite anstataŭ listigi la malplaĉajn. Forlasi la ĉifran postulon por ke kliento konektiĝu estas malaltigo, ne riparo.

Legu la opciojn de la servilo antaŭ ol redakti klienton

Plej multaj el tiuj miskongruoj videblas sur la servilo en du dosieroj, kaj legi ilin kostas malpli ol rekonstrui klienton. Sur Linux PPTP-fina punkto la koncernaj agordoj loĝas en la pppd-opcia dosiero, kiun pptpd pasigas. Rulu ĝin sur la servilo, ne de klienta statuse krano. Komencu per la linioj, kiuj postulas, rifuzas aŭ nomas protektan reĝimon:

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

Legu la eligon kiel kontrakton anstataŭ kiel liston de flagoj. Linion, kiu postulas MPPE dum ĝi rifuzas ambaŭ MS-CHAP-variaĵojn, neniu kliento povas plenumi, kaj mankanta postulo pri MS-CHAP-metodo lasas la pordon malfermita al interŝanĝoj, kiuj donas neniujn ŝlosilojn. Poste kontrolu, kiu entute rajtas aŭtentikiĝi, kion decidas la sekreta dosiero:

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

Notu tri valorojn antaŭ ol ŝanĝi ion ajn: la eksteran protokolon, la aŭtentikigan metodon, kiun la servilo postulas, kaj ĉu la protekto estas deviga aŭ laŭvola. Tiuj tri determinas ĉiun postan decidon, kaj diveni ilin el klienta dialogo estas la maniero, kiel profilo finiĝas duone agordita. Tenu la dosieron malfermita dum vi laboras, ĉar la sekva sekcio bezonas la samajn tri valorojn.

Trovu la paneon laŭ la PPP-fazo

PPP raportas paneojn laŭ fazoj, kaj la fazo diras, kiu klaŭzo de la kontrakto rompiĝis. Ligo, kiu neniam forlasas ligokontrolon, havas enkapsuligan aŭ intertraktadan problemon, dum tiu, kiu aŭtentikiĝas kaj poste mortas, kutime havas politikan aŭ ŝlosilan problemon. Ligo, kiu restas supre kaj portas nenion, transiris al enkursigado, kio estas alia esploro.

La ĵurnalo konservas la fazajn liniojn, kaj ili estas pli utilaj ol pli alta sencimiga nivelo. Petu la PPP-procezojn kaj la protektajn mesaĝojn, poste legu la aŭtentikigan rezulton antaŭ ĉio alia. La lastaj linioj kutime nomas la klaŭzon, kiu rifuzis:

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

En tiu eligo, serĉu unue la aŭtentikigan rezulton kaj poste plendon, ke protekto estis postulata sed ne intertraktita. La dua mesaĝo estas la subskribo de la supra kontraŭdiro, kaj neniu kvanto da ripetado forigas ĝin, dum la servilo rifuzas la solan metodon, kiu povas produkti ŝlosilojn. Du kaptiloj indas esti nomitaj: altigi la sencimigan nivelon sen legi la fazajn liniojn produktas bruon, kaj kapti defiomaterialon aŭ pasvortojn transformas agordan taskon en likon de akreditaĵoj. Notu tiun fazon antaŭ ol ŝanĝi iun ajn opcion.

Planu la eliron antaŭ ol la malnova fina punkto malŝaltiĝos

MPPE estas historia ligoprotekta mekanismo, kaj ĝia ĉeesto ne faras PPTP prudentan elekton por nova deplojo. La nuna gvidado de Microsoft jam konsilas kontraŭ PPTP kaj kontraŭ L2TP/IPsec kun antaŭe dividita ŝlosilo por novaj deplojoj de fora aliro. Teni malnovan finan punkton viva estas decido pri ekzistanta servo, ne ŝablono por la sekva.

Kiam la fina punkto devas resti, skribu la kontrakton: ekstera protokolo, postulata aŭtentikiga metodo, deviga protekto kaj la klienta versio, kiu intertraktas ĝin. Kiam ĝi povas foriri, elektu la pordegan identecon de la anstataŭaĵo, ĝian klientan aŭtentikigon kaj kie loĝos la akreditaĵoj antaŭ ol tuŝi la malnovan profilon. Poste planu itinerojn, DNS kaj la rimedojn, al kiuj ĉiu uzanto rajtas aliri. Validigu la celatan klienton kontraŭ la postuloj de la posedanto, ne kontraŭ funkcianta konekto.

Intenca rifuzo devus resti rifuzo, ĉar retroiri al neprotektita reĝimo por ke testo pasu transformas politikan paneon en elmeton. La finita stato estas subtenata, dokumentita kontrakto, ne la plej malgranda aro da ŝanĝoj, kiu sukcesigas unu malnovan konekton. Lasu la malnovan profilon surloke, neuzatan kaj dokumentitan, ĝis la anstataŭaĵo trapasos la samajn kontrolojn.