Bakit ang PPP CHAP lamang ay hindi makakatugon sa pangangailangang MPPE

Ang isang profile ng PPTP na nagpipilit sa pag-encrypt ay karaniwang nabibigo sa parehong lugar: ang PPP ay sumasang-ayon sa isang palitan ng pagpapatunay na hindi kailanman gumagawa ng materyal ng susi na kailangan ng MPPE. Mukhang kalahating buhay ang tunel, tinatanggap ang password, at bumabagsak ang link bago pa man may trapikong dumaan dito. Ang pag-abot sa dropdown ng CHAP hanggang may kumonekta ay nagtatago ng tunay na depekto, at iyon ay isang kontrata sa pagitan ng paraan ng pagpapatunay at ng patakaran sa proteksyon. Ang mga pagsusuri sa ibaba ay inayos upang ang bawat isa ay mag-alis ng mas murang dahilan kaysa sa susunod.

Dalawang negosasyon ang tumatakbo sa loob ng isang koneksyon ng PPTP

Dinadala ng PPTP ang isang normal na sesyon ng PPP sa loob ng tunel na GRE, at magkahiwalay silang nagnegosasyon. Ang panlabas na layer ay nagpapasya kung paano binabalot ang mga pakete at kung aling control channel ang umiiral; ang panloob na sesyon ng PPP ay nagpapasya kung sino ang kapareha at kung anong proteksyon ang nakasakay sa itaas. Kaya ang kahilingan ng password ay nagpapatunay lamang ng isang bagay tungkol sa panloob na layer, at ang isang natapos na panlabas na handshake ay hindi nagpapatunay ng anuman tungkol sa alinman sa dalawa. Nabibigo ang mga profile dito dahil nagde-debug ang mga tao sa tunel habang ang hindi pagkakasundo ay nakaupo sa loob ng PPP.

Ang simpleng CHAP ay ang palitan ng hamon-at-tugon sa RFC 1994, itinayo sa isang pinagsasaluhang lihim at wala nang iba pa. Ang MS-CHAPv2 ay isang ibang palitan na may ibang mga mensahe at ibang output, na na-standardize sa RFC 2759. Ang pinagsasaluhang salita sa dalawang pangalan ay ang tanging bagay na pinagsasaluhan nila sa kawad. Wala sa mga pangalan ang nagsasabi kung ano ang ginagawa ng palitan, at iyon lamang ang mahalagang bahagi.

Kaya ang isang opsyon na may simpleng label na CHAP ay malabo sa isang lumang profile. Kapag hinihiling ng server ang MS-CHAPv2 at nag-aalok ang kliyente ng simpleng CHAP, maaari pa ring matapos ang kontrol ng link at maaari pa ring tanggapin ang password. Dumarating ang pagpalya mamaya, kapag sinubukan ng server na kunin ang mga susi ng proteksyon mula sa isang palitang walang ginawa.

Itugma ang kinakailangang paraan sa mga susi na kaya nitong gawin

Ang mga susi ng MPPE ay hindi katangian ng PPP sa pangkalahatan. Para sa pamilyang Microsoft CHAP ang derivasyon ay tinukoy sa RFC 3079, at ito ay kumukuha bilang input ng output ng palitan ng MS-CHAP kaysa sa isang pinagsasaluhang lihim. Ang mga paraan ng EAP ay nakakarating sa parehong lugar sa ibang ruta, na ibinabalik ng server ng pagpapatunay ang mga susi bilang mga katangiang MS-MPPE-Recv-Key at MS-MPPE-Send-Key. Ang simpleng CHAP ay hindi lumilitaw sa alinman sa dalawang ruta, at iyon ang buong dahilan kung bakit umiiral ang pagkakaibang ito.

Ang isang konfigurasyong nangangailangan ng MPPE habang tinatanggihan ang bawat paraan na makapagbibigay ng mga susi ay panloob na magkasalungat. Nilulutas ng pppd ang kontradiksyong iyon sa pamamagitan ng pagtanggi sa link, hindi sa pag-imbento ng mga susi, kaya ang nakikitang resulta ay isang sesyon na nagpapatunay at pagkatapos ay nagtatapos sa yugto ng network. Ang muling pagsubok sa kliyente ay hindi magbabago nito hangga't tinatanggihan ng server ang tanging mga paraan na nagde-derive ng anuman.

Ang tuntuning sumusunod ay maikli: kung kinakailangan ng profile ang MPPE, ang paraan ay dapat na isang variant ng MS-CHAP o isang paraan ng EAP na ibinabalik ng server ang mga susi. Ang pagtanggi lamang sa MS-CHAPv2 ay hindi nagpapatupad niyon, dahil nagde-derive rin ng mga susi ang MS-CHAPv1 at nananatiling magagamit maliban kung tanggihan ito nang hiwalay; ang pagtanggi sa dalawa ay nag-iiwan ng simpleng CHAP at PAP, na hindi nagde-derive ng anuman at ginagawang hindi matupad ang pangangailangan. Pangalanan ang tinatanggap na paraan nang malinaw kaysa sa ilista ang mga hindi mo gusto. Ang pag-iwan sa pangangailangan ng encryption upang makakonekta ang kliyente ay isang pagbaba, hindi isang pagkukumpuni.

Basahin ang mga opsyon ng server bago mag-edit ng kliyente

Karamihan sa mga pagkakaibang ito ay nakikita sa server sa dalawang file, at ang pagbasa sa mga ito ay mas mura kaysa sa muling pagbuo ng kliyente. Sa isang endpoint ng PPTP sa Linux, ang mga kaugnay na setting ay naninirahan sa file ng mga opsyon ng pppd na ipinapasa ng pptpd. Patakbuhin ito sa server, hindi mula sa screen ng kalagayan ng kliyente. Magsimula sa mga linyang nangangailangan, tumatanggi o nagpapangalan ng isang mode ng proteksyon:

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

Basahin ang output bilang isang kontrata at hindi bilang isang listahan ng mga flag. Ang isang linyang nangangailangan ng MPPE habang tinatanggihan ang dalawang variant ng MS-CHAP ay hindi matutupad ng anumang kliyente, at ang nawawalang pangangailangan para sa isang paraan ng MS-CHAP ay nag-iiwan ng pinto para sa mga palitang hindi nagbibigay ng mga susi. Pagkatapos ay suriin kung sino ang pinapayagang magpatunay, na pinagpapasyahan ng file ng mga lihim:

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

Isulat ang tatlong halaga bago baguhin ang anuman: ang panlabas na protocol, ang paraan ng pagpapatunay na kinakailangan ng server, at kung ang proteksyon ay sapilitan o opsyonal. Ang tatlong iyon ay nagpapasya sa bawat susunod na desisyon, at ang paghula sa mga ito mula sa isang dialog ng kliyente ay ang paraan kung paano nagtatapos ang isang profile na kalahating naka-configure. Panatilihing bukas ang file habang nagtatrabaho, dahil kailangan ng susunod na seksyon ang parehong tatlong halaga.

Hanapin ang pagpalya ayon sa yugto ng PPP

Ang PPP ay nag-uulat ng mga pagpalya sa mga yugto, at sinasabi ng yugto kung aling sugnay ng kontrata ang nabali. Ang isang link na hindi kailanman lumalabas sa kontrol ng link ay may problema sa encapsulation o negosasyon, samantalang ang isang nagpapatunay at pagkatapos ay namamatay ay karaniwang may problema sa patakaran o susi. Ang isang link na nananatiling nakaangat at walang dinadala ay lumipat sa routing, na isang ibang pagsisiyasat.

Ang journal ay nagpapanatili ng mga linya ng yugto, at ang mga ito ay mas kapaki-pakinabang kaysa sa mas mataas na antas ng debug. Humingi ng mga proseso ng PPP at mga mensahe ng proteksyon, pagkatapos ay basahin ang resulta ng pagpapatunay bago ang lahat ng iba pa. Ang mga huling linya ay karaniwang nagpapangalan ng sugnay na tumanggi:

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

Sa output na iyon, hanapin muna ang resulta ng pagpapatunay at pagkatapos ang reklamong kinailangan ng proteksyon ngunit hindi ito naipagkasundo. Ang ikalawang mensahe ay ang pirma ng kontradiksyon sa itaas, at walang dami ng muling pagsubok ang nag-aalis nito hangga't tinatanggihan ng server ang tanging paraan na makagawa ng mga susi. Dalawang patibong ang dapat pangalanan: ang pagtaas ng antas ng debug nang hindi binabasa ang mga linya ng yugto ay gumagawa ng ingay, at ang paghuli sa materyal ng hamon o mga password ay ginagawang pagtagas ng kredensyal ang isang gawain sa konfigurasyon. Itala ang yugtong iyon bago baguhin ang anumang opsyon.

Planoin ang paglabas bago patayin ang lumang endpoint

Ang MPPE ay isang makasaysayang mekanismo ng proteksyon ng link, at ang presensya nito ay hindi ginagawang makatwirang pagpipilian ang PPTP para sa isang bagong deployment. Ang kasalukuyang gabay ng Microsoft ay nagpapayo na laban sa PPTP at laban sa L2TP/IPsec na may paunang pinagsasaluhang susi para sa mga bagong deployment ng remote access. Ang pagpapanatiling buhay ng isang lumang endpoint ay isang desisyon tungkol sa isang umiiral na serbisyo, hindi isang template para sa susunod.

Kapag kailangang manatili ang endpoint, isulat ang kontrata: panlabas na protocol, kinakailangang paraan ng pagpapatunay, sapilitang proteksyon, at ang bersyon ng kliyenteng nakikipagnegosasyon nito. Kapag maaari na itong umalis, piliin ang pagkakakilanlan ng gateway ng kapalit, ang pagpapatunay ng kliyente nito at kung saan maninirahan ang mga kredensyal bago hawakan ang lumang profile. Pagkatapos ay planuhin ang mga ruta, DNS at ang mga mapagkukunang pinahihintulutan ng bawat gumagamit. Patunayan ang nilalayong kliyente laban sa mga pangangailangan ng may-ari at hindi laban sa isang gumaganang koneksyon.

Ang sadyang pagtanggi ay dapat manatiling pagtanggi, dahil ang pagbabalik sa isang mode na walang proteksyon upang makapasa ang isang pagsubok ay ginagawang pagkakalantad ang isang pagpalya ng patakaran. Ang tapos na kalagayan ay isang sinusuportahang, dokumentadong kontrata, hindi ang pinakamaliit na hanay ng mga pagbabagong nagpapagumpay sa isang lumang koneksyon. Iwanan ang lumang profile sa lugar nito, hindi ginagamit at dokumentado, hanggang sa makapasa ang kapalit sa parehong mga pagsusuri.