Pse PPP CHAP i vetëm nuk mund të plotësojë një kërkesë MPPE

Një profil PPTP që këmbëngul për kriptim zakonisht dështon në të njëjtin vend: PPP bie dakord për një shkëmbim vërtetimi që nuk prodhon kurrë materialin e çelësit që MPPE ka nevojë. Tuneli duket gjysmë i gjallë, fjalëkalimi pranohet dhe lidhja bie përpara se ndonjë trafik ta kalojë atë. Të shtrish drejt listës rënëse të CHAP derisa diçka të lidhet fsheh defektin e vërtetë, dhe ai është një kontratë midis metodës së vërtetimit dhe politikës së mbrojtjes. Kontrollet më poshtë janë renditur që secila të përjashtojë një shkak më të lirë se tjetri.

Dy negociata zhvillohen brenda një lidhjeje PPTP

PPTP transporton një sesion normal PPP brenda një tuneli GRE, dhe të dyja negociojnë veçmas. Shtresa e jashtme vendos si kapsulohen paketat dhe cili kanal kontrolli ekziston; sesioni i brendshëm PPP vendos kush është pala dhe çfarë mbrojtje qëndron sipër. Prandaj një kërkesë fjalëkalimi provon diçka vetëm për shtresën e brendshme, dhe një shtrëngim duarsh i jashtëm i përfunduar nuk provon asgjë për asnjërën. Profilet dështojnë këtu sepse njerëzit korrigjojnë tunelin ndërsa mospajtimi qëndron brenda PPP.

CHAP i thjeshtë është shkëmbimi sfidë-përgjigje në RFC 1994, ndërtuar mbi një sekret të përbashkët dhe asgjë tjetër. MS-CHAPv2 është një shkëmbim tjetër me mesazhe të tjera dhe një dalje tjetër, i standardizuar në RFC 2759. Fjala e përbashkët në dy emrat është e vetmja gjë që kanë të përbashkët në tel. Asnjë emër nuk thotë çfarë prodhon shkëmbimi, dhe kjo është pjesa e vetme që ka rëndësi.

Kjo është arsyeja pse një opsion i etiketuar thjesht CHAP është i paqartë në një profil të vjetër. Kur serveri dëshiron MS-CHAPv2 dhe klienti ofron CHAP të thjeshtë, kontrolli i lidhjes ende mund të përfundojë dhe një fjalëkalim ende mund të pranohet. Dështimi vjen më vonë, kur serveri përpiqet të nxjerrë çelësa mbrojtjeje nga një shkëmbim që nuk prodhoi asnjë.

Përputhni metodën e kërkuar me çelësat që mund të prodhojë

Çelësat MPPE nuk janë një veti e PPP në përgjithësi. Për familjen Microsoft CHAP derivimi është specifikuar në RFC 3079, dhe merr si hyrje daljen e një shkëmbimi MS-CHAP në vend të një sekreti të përbashkët. Metodat EAP arrijnë në të njëjtin vend në një rrugë tjetër, me serverin e vërtetimit që kthen çelësat si atribute MS-MPPE-Recv-Key dhe MS-MPPE-Send-Key. CHAP i thjeshtë nuk shfaqet në asnjërën rrugë, dhe kjo është e gjithë arsyeja pse ekziston mospërputhja.

Një konfigurim që kërkon MPPE ndërsa refuzon çdo metodë të aftë të furnizojë çelësa është brendësisht kontradiktor. pppd e zgjidh atë kontradiktë duke refuzuar lidhjen, jo duke shpikur çelësa, kështu që rezultati i dukshëm është një sesion që vërtetohet dhe pastaj përfundon në fazën e rrjetit. Riprovimi i klientit nuk do ta ndryshojë këtë për sa kohë serveri refuzon metodat e vetme që nxjerrin diçka.

Rregulli që rrjedh është i shkurtër: nëse profili kërkon MPPE, metoda duhet të jetë një variant i MS-CHAP ose një metodë EAP, çelësat e së cilës serveri i kthen. Refuzimi vetëm i MS-CHAPv2 nuk e imponon këtë, sepse edhe MS-CHAPv1 nxjerr çelësa dhe mbetet i disponueshëm nëse nuk refuzohet veçmas; refuzimi i të dyjave lë CHAP të thjeshtë dhe PAP, të cilat nuk nxjerrin asgjë dhe e bëjnë kërkesën të paplotësueshme. Emërtoni shprehimisht metodën e pranuar në vend që të listoni ato që nuk ju pëlqejnë. Heqja dorë nga kërkesa e kriptimit që një klient të lidhet është një ulje, jo një riparim.

Lexoni opsionet e serverit përpara se të modifikoni një klient

Shumica e këtyre mospërputhjeve janë të dukshme në server në dy skedarë, dhe leximi i tyre kushton më pak se rindërtimi i një klienti. Në një pikë fundore PPTP Linux cilësimet përkatëse jetojnë në skedarin e opsioneve të pppd që pptpd kalon. Ekzekutojeni në server, jo nga një ekran statusi i klientit. Filloni me rreshtat që kërkojnë, refuzojnë ose emërtojnë një mënyrë mbrojtjeje:

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

Lexoni daljen si një kontratë dhe jo si një listë flamujsh. Një rresht që kërkon MPPE ndërsa refuzon të dy variantet MS-CHAP nuk mund të plotësohet nga asnjë klient, dhe mungesa e një kërkese për një metodë MS-CHAP lë derën hapur për shkëmbime që nuk japin çelësa. Më pas kontrolloni kush lejohet të vërtetohet fare, çka vendos skedari i sekreteve:

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

Shkruani tre vlera përpara se të ndryshoni diçka: protokolli i jashtëm, metoda e vërtetimit që kërkon serveri dhe nëse mbrojtja është e detyrueshme ose fakultative. Këto të treja përcaktojnë çdo vendim të mëvonshëm, dhe hamendësimi i tyre nga një dialog klienti është mënyra se si një profil përfundon gjysmë i konfiguruar. Mbajeni skedarin hapur ndërsa punoni, sepse seksioni tjetër ka nevojë për të njëjtat tre vlera.

Lokalisojeni dështimin sipas fazës PPP

PPP raporton dështimet në faza, dhe faza thotë cila klauzolë e kontratës u thye. Një lidhje që nuk e lë kurrë kontrollin e lidhjes ka një problem kapsulimi ose negociatash, ndërsa ajo që vërtetohet dhe pastaj vdes zakonisht ka një problem politike ose çelësi. Një lidhje që qëndron lart dhe nuk transporton asgjë ka kaluar në rrugëzim, çka është një hetim tjetër.

Regjistri mban rreshtat e fazës, dhe ata janë më të dobishëm se një nivel më i lartë korrigjimi. Kërkoni proceset PPP dhe mesazhet e mbrojtjes, pastaj lexoni rezultatin e vërtetimit përpara çdo gjëje tjetër. Rreshtat e fundit zakonisht emërtojnë klauzolën që refuzoi:

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

Në atë dalje, kërkoni fillimisht rezultatin e vërtetimit dhe pastaj një ankesë se mbrojtja u kërkua por nuk u negociua. Mesazhi i dytë është firma e kontradiktës më sipër, dhe asnjë sasi ripërpjekjesh nuk e fshin atë për sa kohë serveri refuzon metodën e vetme që mund të prodhojë çelësa. Vlen të emërtohen dy kurthe: ngritja e nivelit të korrigjimit pa lexuar rreshtat e fazës prodhon zhurmë, dhe kapja e materialit të sfidës ose fjalëkalimeve e shndërron një detyrë konfigurimi në rrjedhje kredencialesh. Regjistroni atë fazë përpara se të ndryshoni ndonjë opsion.

Planifikoni daljen përpara se pika fundore e vjetër të fiket

MPPE është një mekanizëm historik i mbrojtjes së lidhjes, dhe prania e tij nuk e bën PPTP një zgjedhje të arsyeshme për një vendosje të re. Udhëzimet aktuale të Microsoft këshillojnë tashmë kundër PPTP dhe kundër L2TP/IPsec me çelës të ndarë paraprakisht për vendosjet e reja të aksesit në distancë. Mbajtja gjallë e një pike fundore të vjetër është një vendim për një shërbim ekzistues, jo një shabllon për të tjetrin.

Kur pika fundore duhet të mbetet, shkruani kontratën: protokoll i jashtëm, metodë e vërtetimit e kërkuar, mbrojtje e detyrueshme dhe versioni i klientit që e negocion. Kur mund të largohet, zgjidhni identitetin e portës së zëvendësuesit, vërtetimin e klientit të tij dhe vendin ku do të jetojnë kredencialet përpara se të prekni profilin e vjetër. Pastaj planifikoni rrugët, DNS dhe burimet për të cilat çdo përdorues është i autorizuar. Vlerësoni klientin e synuar kundrejt kërkesave të pronarit dhe jo kundrejt një lidhjeje që funksionon.

Një refuzim i qëllimshëm duhet të mbetet refuzim, sepse kthimi në një mënyrë të pambrojtur që një test të kalojë e shndërron një dështim politike në ekspozim. Gjendja e përfunduar është një kontratë e mbështetur dhe e dokumentuar, jo grupi më i vogël i ndryshimeve që bën një lidhje të vjetër të ketë sukses. Lëreni profilin e vjetër në vendin e tij, të papërdorur dhe të dokumentuar, derisa zëvendësuesi të kalojë të njëjtat kontrolle.