Zergatik PPP CHAP bakarrik ez den gai MPPE baldintza betetzeko

Zifratzean tematzen den PPTP profil batek normalean leku berean huts egiten du: PPPk inoiz MPPEk behar duen gako materiala sortzen ez duen autentifikazio truke bat adosten du. Tunela erdi bizirik dirudi, pasahitza onartzen da eta esteka erortzen da trafikorik zeharkatu aurretik. CHAP goitibeherako zerrendara jotzea zerbait konektatu arte akats erreala ezkutatzen du, eta hori autentifikazio metodoaren eta babes politikaren arteko kontratua da. Beheko egiaztapenak ordenatuta daude, bakoitzak hurrengoa baino arrazoi merkeagoa bazter dezan.

PPTP konexio bakarrean bi negoziazio gertatzen dira

PPTPk PPP saio arrunta eramaten du GRE tunel baten barruan, eta biek bereiz negoziatzen dute. Kanpoko geruzak erabakitzen du paketeak nola kapsulatzen diren eta zein kontrol kanal dagoen; barneko PPP saioak erabakitzen du nor den parekoa eta zein babes doan gainean. Beraz, pasahitz eskaera batek barneko geruzari buruz soilik frogatzen du zerbait, eta kanpoko esku-emate osatu batek ez du ezer frogatzen bien arteko inori buruz. Profilek hemen huts egiten dute jendeak tunela arazten duelako, desadostasuna PPPren barruan dagoen bitartean.

CHAP soila RFC 1994ko erronka-erantzun trukea da, partekatutako sekretu batean eta besterik ez eraikia. MS-CHAPv2 mezu ezberdinekin eta irteera ezberdinarekin beste truke bat da, RFC 2759n estandarizatua. Bi izenetan partekatzen den hitza da kablean komunean duten gauza bakarra. Izen batek ere ez du esaten trukeak zer sortzen duen, eta hori da axola duen atal bakarra.

Horregatik, CHAP soilik deituriko aukera anbiguoa da profil zahar batean. Zerbitzariak MS-CHAPv2 nahi duenean eta bezeroak CHAP soila eskaintzen duenean, estekaren kontrolak oraindik osa daiteke eta pasahitza oraindik onar daiteke. Hutsegitea geroago iristen da, zerbitzariak ezer sortu ez zuen truke batetik babes gakoak eratorri nahi dituenean.

Egokitu eskatutako metodoa sor ditzakeen gakoei

MPPE gakoak ez dira PPPren propietatea oro har. Microsoft CHAP familiarentzat eratorpena RFC 3079 izeneko agirian zehazten da, eta sarrera gisa MS-CHAP truke baten irteera hartzen du, ez partekatutako sekretua. EAP metodoek toki berera beste bide batetik iristen dira, autentifikazio zerbitzariak gakoak MS-MPPE-Recv-Key eta MS-MPPE-Send-Key atributu gisa itzultzen dituelarik. CHAP soila ez da bi bideetan agertzen, eta hori da desdoitzearen existentziaren arrazoi osoa.

MPPE eskatzen duen eta gakoak eman ditzakeen metodo oro ukatzen duen konfigurazioa barnean kontraesankorra da. pppdk kontraesan hori esteka ukatuz konpontzen du, ez gakoak asmatuz, beraz emaitza ikusgai sesio bat da, autentifikatu eta gero sare fasean amaitzen dena. Bezeroa berriz saiatzeak ez du hori aldatuko zerbitzariak ezer eratorritzen duten metodo bakarrak ukatzen dituen bitartean.

Ondorioz datorren araua laburra da: profileak MPPE eskatzen badu, metodoak MS-CHAP aldaera bat edo zerbitzariak gakoak itzultzen dizkion EAP metodo bat izan behar du. MS-CHAPv2 soilik ukatzeak ez du hori behartzen, MS-CHAPv1ek ere gakoak eratorritzen baititu eta eskuragarri jarraitzen baitu bereiz ukatzen ez bada; biak ukatzeak CHAP soila eta PAP uzten ditu, horiek ezer eratorritzen ez dute eta baldintza bete ezina egiten dute. Izenda ezazu onartutako metodoa modu esplizituan, gustuko ez dituzunak zerrendatu beharrean. Zifratze baldintza uztea bezero bat konekta dadin degradazioa da, ez konponketa.

Irakurri zerbitzariaren aukerak bezeroa editatu aurretik

Desdoitze hauetako gehienak zerbitzarian ikusgai daude bi fitxategitan, eta horiek irakurtzeak bezeroa berreraikitzeak baino gutxiago kostatzen du. Linux PPTP amaiera puntu batean ezarpen garrantzitsuak pptpdk pasatzen duen pppd aukera fitxategian bizi dira. Exekuta ezazu zerbitzarian, ez bezeroaren egoera pantailatik. Hasi babes modu bat eskatzen, ukatzen edo izendatzen duten lerroekin:

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

Irakurri irteera kontratu gisa, ez bandera zerrenda gisa. MPPE eskatzen duen eta MS-CHAP aldaera biak ukatzen dituen lerroa ezin du inongo bezerok bete, eta MS-CHAP metodo baterako baldintzarik ez egoteak gakorik ematen ez duten trukeetarako atea irekita uzten du. Gero egiaztatu nork autentifika dezakeen batere, sekretu fitxategiak erabakitzen duena:

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

Idatzi hiru balio ezer aldatu aurretik: kanpoko protokoloa, zerbitzariak eskatzen duen autentifikazio metodoa eta babesa derrigorrezkoa ala hautazkoa den. Hirurek erabakitzen dute geroagoko erabaki oro, eta bezeroaren elkarrizketa batetik asmatzeak profila erdi konfiguratuta uzteko modua da. Eduki fitxategia irekita lan egiten duzun bitartean, hurrengo atalak hiru balio berak behar baititu.

Kokatu hutsegitea PPP faseari jarraituz

PPPk hutsegiteak faseka jakinarazten ditu, eta faseak esaten du kontratuaren zein klausula hautsi den. Estekaren kontrola inoiz uzten ez duen esteka batek kapsulatze edo negoziazio arazo bat du, eta autentifikatu eta gero hiltzen denak normalean politika edo gako arazo bat du. Zutik jarraitzen duen eta ezer eramaten ez duen esteka bideratzeetara pasa da, eta hori beste ikerketa bat da.

Egunkariak fase lerroak gordetzen ditu, eta maila altuagoko arazketa baino erabilgarriagoak dira. Eskatu PPP prozesuak eta babes mezuak, eta gero irakurri autentifikazio emaitza beste ezer baino lehen. Azken lerroek normalean ukatu zuen klausula izendatzen dute:

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

Irteera horretan, bilatu lehenengo autentifikazio emaitza eta gero babesa eskatu baina negoziatu ez zela dioen kexa bat. Bigarren mezua goiko kontraesanaren sinadura da, eta ez du berriz saiatze kopuruak garbitzen zerbitzariak gakoak sor ditzakeen metodo bakarra ukatzen duen bitartean. Bi tranpa merezi dute aipatzea: arazketa maila igotzeak fase lerroak irakurri gabe zarata sortzen du, eta erronka materiala edo pasahitzak harrapatzeak konfigurazio zeregina kredentzialen ihes bihurtzen du. Erregistra ezazu fase hori edozein aukera aldatu aurretik.

Planifikatu irteera amaiera puntu zaharra itzali aurretik

MPPE esteken babes mekanismo historikoa da, eta haren presentziak ez du PPTP aukera zentzuzkoa egiten hedapen berri baterako. Microsoften egungo gidalerroek jada PPTPren eta aurrez partekatutako gakoa duen L2TP/IPsec-en aurka gomendatzen dute urruneko sarbide hedapen berrietarako. Amaiera puntu zaharra bizirik mantentzea lehendik dagoen zerbitzu bati buruzko erabakia da, ez hurrengoarentzako txantiloia.

Amaiera puntuak geratu behar duenean, idatzi kontratua: kanpoko protokoloa, eskatutako autentifikazio metodoa, derrigorrezko babesa eta negoziatzen duen bezeroaren bertsioa. Joan daitekeenean, aukeratu ordezkoaren atebide identitatea, haren bezero autentifikazioa eta kredentzialak non bizi diren profil zaharra ukitu aurretik. Gero planifikatu ibilbideak, DNS eta erabiltzaile bakoitzak sarbide baimena duen baliabideak. Balioztatu aurreikusitako bezeroa jabearen baldintzen aurka, ez funtzionatzen duen konexio baten aurka.

Berezko ukoak uko izaten jarraitu behar du, proba bat gaindi dadin babesik gabeko modura atzeratzeak politika hutsegitea esposizio bihurtzen baitu. Amaitutako egoera kontratu onartu eta dokumentatua da, konexio zahar bat arrakastatsu egiten duen aldaketen multzo txikiena ez. Utzi profil zaharra lekuan, erabili gabe eta dokumentatuta, ordezkoak egiaztapen berak gainditu arte.