Kwa nini PPP CHAP peke yake haiwezi kutimiza sharti la MPPE

Profaili ya PPTP inayosisitiza usimbaji fiche kwa kawaida hushindwa mahali pale pale: PPP inakubali mabadilishano ya uthibitishaji ambayo hayazalishi kamwe nyenzo za ufunguo ambazo MPPE inahitaji. Handaki huonekana nusu hai, nenosiri hukubaliwa, na kiungo huanguka kabla ya trafiki yoyote kuipita. Kufikia orodha ya kushuka ya CHAP hadi kitu kiunganishwe huficha kasoro halisi, na hiyo ni mkataba kati ya mbinu ya uthibitishaji na sera ya ulinzi. Ukaguzi ulio hapa chini umepangwa ili kila mmoja uondoe sababu iliyo rahisi zaidi kuliko inayofuata.

Mazungumzo mawili hufanyika ndani ya muunganisho mmoja wa PPTP

PPTP hubeba kikao cha kawaida cha PPP ndani ya handaki la GRE, na wote wawili hujadiliana kwa tofauti. Tabaka la nje huamua jinsi pakiti zinavyofungwa na ni kituo gani cha udhibiti kilichopo; kikao cha ndani cha PPP huamua nani ni mwenzake na ni ulinzi gani unaokaa juu. Kwa hiyo ombi la nenosiri huthibitisha kitu kuhusu tabaka la ndani peke yake, na kupeana mikono kwa nje kumekamilika hakuthibitishi kitu kuhusu yeyote wao. Profaili hushindwa hapa kwa sababu watu hurekebisha hitilafu za handaki wakati kutokubaliana kumekaa ndani ya PPP.

CHAP ya kawaida ni mabadilishano ya changamoto na jibu katika RFC 1994, yaliyojengwa juu ya siri inayoshirikiwa na kitu kingine chochote. MS-CHAPv2 ni mabadilishano tofauti yenye ujumbe tofauti na matokeo tofauti, yaliyosawazishwa katika RFC 2759. Neno linaloshirikiwa katika majina yote mawili ni kitu pekee wanachoshirikiana kwenye waya. Hakuna jina linalosema mabadilishano huzalisha nini, na hiyo ndiyo sehemu pekee muhimu.

Ndiyo sababu chaguo lililoandikwa tu CHAP ni gumu kueleweka katika profaili ya zamani. Wakati seva inataka MS-CHAPv2 na mteja anatoa CHAP ya kawaida, udhibiti wa kiungo bado unaweza kukamilika na nenosiri bado linaweza kukubaliwa. Kushindwa huja baadaye, seva inapojaribu kupata funguo za ulinzi kutoka kwa mabadilishano ambayo hayakuzalisha chochote.

Oanisha mbinu inayohitajika na funguo inazoweza kuzalisha

Funguo za MPPE si sifa ya PPP kwa ujumla. Kwa familia ya Microsoft CHAP uasilia umeainishwa katika RFC 3079, na huchukua kama pembejeo matokeo ya mabadilishano ya MS-CHAP badala ya siri inayoshirikiwa. Mbinu za EAP hufikia mahali pale kwa njia nyingine, seva ya uthibitishaji ikirudisha funguo kama sifa za MS-MPPE-Recv-Key na MS-MPPE-Send-Key. CHAP ya kawaida haionekani katika njia yoyote kati ya hizo mbili, na hiyo ndiyo sababu yote ya kutokubaliana huku kuwepo.

Mpangilio unaohitaji MPPE huku ukikataa kila mbinu inayoweza kutoa funguo unajipinga ndani. pppd hutatua mgongano huo kwa kukataa kiungo, si kwa kubuni funguo, kwa hiyo matokeo yanayoonekana ni kikao kinachothibitisha na kisha kuisha katika awamu ya mtandao. Kujaribu tena kwa mteja hakutabadilisha hilo maadamu seva inakataa mbinu pekee zinazozalisha kitu.

Kanuni inayofuata ni fupi: ikiwa profaili inahitaji MPPE, mbinu lazima iwe aina ya MS-CHAP au mbinu ya EAP ambayo seva hurudisha funguo zake. Kukataa MS-CHAPv2 peke yake hakutekelezi hilo, kwa sababu MS-CHAPv1 pia huzalisha funguo na hubaki inapatikana isipokataliwa kando; kukataa zote mbili huacha CHAP ya kawaida na PAP, ambazo hazizalishi chochote na hufanya sharti lisilotimizika. Taja mbinu inayokubaliwa kwa uwazi badala ya kuorodhesha zile usizozipenda. Kuacha sharti la usimbaji fiche ili mteja aunganishwe ni kushuka daraja, si ukarabati.

Soma chaguo za seva kabla ya kuhariri mteja

Wengi wa kutokubaliana huku huonekana kwenye seva katika faili mbili, na kuzisoma hugharimu kidogo kuliko kujenga upya mteja. Kwenye kituo cha mwisho cha PPTP cha Linux mipangilio husika huishi katika faili ya chaguo za pppd ambayo pptpd huipitisha. Iendeshe kwenye seva, si kutoka skrini ya hali ya mteja. Anza na mistari inayohitaji, inayokataa au inayotaja hali ya ulinzi:

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

Soma matokeo kama mkataba na si kama orodha ya bendera. Mstari unaohitaji MPPE huku ukikataa aina zote mbili za MS-CHAP hauwezi kutimizwa na mteja yeyote, na sharti lisilokuwepo kwa mbinu ya MS-CHAP huacha mlango wazi kwa mabadilishano yasiyotoa funguo. Kisha angalia nani anaruhusiwa kuthibitisha hata kidogo, jambo ambalo faili ya siri huamua:

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

Andika thamani tatu kabla ya kubadilisha kitu: itifaki ya nje, mbinu ya uthibitishaji inayohitajwa na seva, na kama ulinzi ni wa lazima au wa hiari. Hizo tatu huamua kila uamuzi unaofuata, na kuzikisia kutoka kwa mazungumzo ya mteja ndiyo njia ambayo profaili huishia ikiwa imesanidiwa nusu. Weka faili wazi unapofanya kazi, kwa sababu sehemu inayofuata inahitaji thamani hizo tatu.

Pata kushindwa kwa awamu ya PPP

PPP huripoti kushindwa kwa awamu, na awamu husema ni kipengele gani cha mkataba kilichovunjika. Kiungo ambacho hakitoki kwenye udhibiti wa kiungo kina tatizo la ufungaji au majadiliano, wakati kile kinachothibitisha na kisha kufa kwa kawaida kina tatizo la sera au ufunguo. Kiungo kinachobaki juu na hakibebi chochote kimepita kwenye uelekezaji, jambo ambalo ni uchunguzi mwingine.

Jarida huhifadhi mistari ya awamu, na hiyo ni muhimu zaidi kuliko kiwango cha juu cha utatuzi. Omba michakato ya PPP na ujumbe wa ulinzi, kisha soma matokeo ya uthibitishaji kabla ya kitu kingine chochote. Mistari ya mwisho kwa kawaida hutaja kipengele kilichokataa:

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

Katika matokeo hayo, tafuta kwanza matokeo ya uthibitishaji kisha malalamiko kwamba ulinzi ulihitajika lakini haukujadiliwa. Ujumbe wa pili ni sahihi ya mgongano ulio juu, na hakuna kiasi cha kujaribu tena kinachoifuta maadamu seva inakataa mbinu pekee inayoweza kuzalisha funguo. Mitego miwili inafaa kutajwa: kuongeza kiwango cha utatuzi bila kusoma mistari ya awamu huzalisha kelele, na kunasa nyenzo za changamoto au manenosiri hubadilisha kazi ya usanidi kuwa uvujaji wa vitambulisho. Rekodi awamu hiyo kabla ya kubadilisha chaguo lolote.

Panga kutoka kabla ya kituo cha mwisho cha zamani kuzimwa

MPPE ni utaratibu wa kihistoria wa ulinzi wa kiungo, na uwepo wake haufanyi PPTP kuwa chaguo la busara kwa usambazaji mpya. Mwongozo wa sasa wa Microsoft tayari unashauri dhidi ya PPTP na dhidi ya L2TP/IPsec yenye ufunguo ulioshirikiwa mapema kwa usambazaji mpya wa ufikiaji wa mbali. Kuweka kituo cha mwisho cha zamani hai ni uamuzi kuhusu huduma iliyopo, si kiolezo cha kinachofuata.

Wakati kituo cha mwisho kinapaswa kubaki, andika mkataba: itifaki ya nje, mbinu ya uthibitishaji inayohitajika, ulinzi wa lazima na toleo la mteja linalojadiliana hilo. Wakati kinaweza kuondoka, chagua utambulisho wa lango la mbadala, uthibitishaji wake wa mteja na mahali vitambulisho vitakapoishi kabla ya kugusa profaili ya zamani. Kisha panga njia, DNS na rasilimali ambazo kila mtumiaji ameidhinishwa kuzifikia. Thibitisha mteja anayekusudiwa kulingana na mahitaji ya mmiliki na si kulingana na muunganisho unaofanya kazi.

Kukataa kwa makusudi kunapaswa kubaki kukataa, kwa sababu kurudi kwenye hali isiyo na ulinzi ili jaribio lipite hubadilisha kushindwa kwa sera kuwa mfiduo. Hali iliyokamilika ni mkataba unaoungwa mkono na ulioandikwa, si seti ndogo zaidi ya mabadiliko inayofanya muunganisho mmoja wa zamani ufaulu. Acha profaili ya zamani mahali pake, bila kutumika na ikiwa imeandikwa, hadi mbadala upite ukaguzi huo huo.