Яагаад зөвхөн PPP CHAP нь MPPE-ийн шаардлагыг хангаж чадахгүй вэ

Шифрлэлтийг шаарддаг PPTP профайл ихэвчлэн нэг л газарт бүтэлгүйтдэг: PPP нь MPPE-д хэрэгтэй түлхүүрийн материалыг хэзээ ч үйлдвэрлэдэггүй баталгаажуулалтын солилцоонд санал нэгддэг. Туннель хагас амьд мэт харагдаж, нууц үг хүлээн авагдаж, ямар ч трафик түүгээр гарахаас өмнө холбоос тасардаг. Ямар нэг зүйл холбогдох хүртэл CHAP-ын унадаг цэс рүү тэмүүлэх нь жинхэнэ алдааг нуудаг, тэр нь баталгаажуулалтын арга ба хамгаалалтын бодлогын хоорондын гэрээ юм. Доорх шалгалтууд нь дараагийнхаас хямд шалтгааныг тус бүр нь хасахаар эрэмбэлэгдсэн.

Нэг PPTP холболтын дотор хоёр хэлэлцээр явагдана

PPTP нь GRE туннелийн дотор энгийн PPP сессийг зөөдөг бөгөөд хоёулаа тусдаа хэлэлцээр хийдэг. Гадаад давхарга нь пакетууд хэрхэн капсуллагдах, ямар удирдлагын суваг байгааг шийддэг; дотоод PPP сесс нь хэн түнш, дээр нь ямар хамгаалалт явж байгааг шийддэг. Тиймээс нууц үгийн асуулт зөвхөн дотоод давхаргын тухай ямар нэг зүйлийг нотолж, дууссан гадаад гар барилт нь хоёулангийн аль нэгний тухай юу ч нотолдоггүй. Профайлууд энд бүтэлгүйтдэг, учир нь хүмүүс туннелийг дибаг хийж байхад санал зөрөлдөөн PPP-ийн дотор сууж байдаг.

Энгийн CHAP нь RFC 1994-ийн сорилт-хариултын солилцоо бөгөөд хуваалцсан нууц болон өөр юун дээр ч биш дээр баригдсан. MS-CHAPv2 нь өөр мессеж, өөр гаралттай өөр солилцоо бөгөөд RFC 2759-д стандартлагдсан. Хоёр нэр дэх нийтлэг үг нь утсан дээр тэдний цорын ганц нийтлэг зүйл юм. Аль ч нэр нь солилцоо юу үйлдвэрлэдэгийг хэлэхгүй бөгөөд энэ нь цорын ганц чухал хэсэг юм.

Тиймээс зүгээр CHAP гэж шошголсон сонголт хуучин профайлд хоёрдмол утгатай. Сервер MS-CHAPv2 хүсч, клиент энгийн CHAP санал болгоход холбоосын удирдлага бүрэн болж, нууц үг хүлээн авагдаж болно. Алдаа нь дараа нь, сервер юу ч үйлдвэрлээгүй солилцооноос хамгаалалтын түлхүүр гаргахыг оролдоход ирдэг.

Шаардлагатай аргыг түүний үйлдвэрлэж чадах түлхүүртэй тааруул

MPPE-ийн түлхүүрүүд ерөнхийдөө PPP-ийн шинж чанар биш. Microsoft CHAP гэр бүлийн хувьд үүсмэл нь RFC 3079-д тодорхойлогдсон бөгөөд оролт болгон хуваалцсан нууцыг биш, MS-CHAP солилцооны гаралтыг авдаг. EAP аргууд өөр замаар ижил газарт хүрдэг бөгөөд баталгаажуулалтын сервер түлхүүрүүдийг MS-MPPE-Recv-Key болон MS-MPPE-Send-Key шинж чанарууд хэлбэрээр буцаадаг. Энгийн CHAP хоёр замын аль нэгэнд ч харагдахгүй бөгөөд энэ зөрүү байх бүх шалтгаан нь тэр юм.

Түлхүүр өгч чадах бүх аргыг үгүйсгэж байхдаа MPPE шаарддаг тохиргоо дотооддоо зөрчилтэй. pppd энэ зөрчлийг түлхүүр зохиох замаар биш, холбоосыг үгүйсгэх замаар шийддэг тул харагдах үр дүн нь баталгаажуулагдаж, дараа нь сүлжээний үе шатанд төгсдөг сесс юм. Сервер ямар нэг юм үүсмэл болгодог цорын ганц аргуудыг үгүйсгэж байгаа цагт клиентийг дахин оролдох нь үүнийг өөрчлөхгүй.

Үүнээс гарах дүрэм богино: профайл MPPE шаарддаг бол арга нь MS-CHAP-ийн хувилбар эсвэл сервер түлхүүрийг буцаадаг EAP арга байх ёстой. Зөвхөн MS-CHAPv2-ийг үгүйсгэх нь үүнийг албаддаггүй, учир нь MS-CHAPv1 ч түлхүүр гаргадаг бөгөөд тусад нь үгүйсгэхгүй бол боломжтой хэвээр байдаг; хоёуланг нь үгүйсгэвэл энгийн CHAP болон PAP үлдэж, тэд юу ч гаргахгүй бөгөөд шаардлагыг биелүүлэх боломжгүй болгодог. Дургүй аргуудыг жагсаахын оронд хүлээн зөвшөөрсөн аргыг тодорхой нэрлэнэ үү. Клиент холбогдохын тулд шифрлэлтийн шаардлагыг орхих нь засвар биш, доошлуулалт юм.

Клиентийг засахаас өмнө серверийн тохиргоог уншина уу

Эдгээр зөрүүний ихэнх нь сервер дээр хоёр файлд харагддаг бөгөөд тэдгээрийг унших нь клиентийг дахин барихаас хямд. Linux PPTP төгсгөлийн цэг дээр холбогдох тохиргоо нь pptpd дамжуулдаг pppd тохиргооны файлд амьдардаг. Үүнийг сервер дээр ажиллуулна уу, клиентийн төлөвийн дэлгэцээс биш. Хамгаалалтын горимыг шаарддаг, үгүйсгэдэг эсвэл нэрлэдэг мөрүүдээс эхэлнэ үү:

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

Гаралтыг тугны жагсаалт биш, гэрээ гэж уншина уу. MPPE шаардаж байхдаа MS-CHAP-ийн хоёр хувилбарыг үгүйсгэдэг мөрийг ямар ч клиент биелүүлж чадахгүй бөгөөд MS-CHAP аргын шаардлага байхгүй нь түлхүүр өгдөггүй солилцоонд хаалгыг нээлттэй үлдээдэг. Дараа нь хэнд баталгаажуулалт хийхийг зөвшөөрснийг шалгана уу, үүнийг нууцын файл шийддэг:

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

Ямар нэг юм өөрчлөхөөс өмнө гурван утгыг бичнэ үү: гадаад протокол, серверийн шаарддаг баталгаажуулалтын арга, хамгаалалт заавал эсвэл сонголтоор байх эсэх. Эдгээр гурав нь дараагийн бүх шийдвэрийг тодорхойлдог бөгөөд тэдгээрийг клиентийн харилцааны цонхноос таамаглах нь профайлыг хагас тохируулсан байлгах зам юм. Ажиллахдаа файлыг нээлттэй байлгаарай, учир нь дараагийн хэсэгт мөнөөх гурван утга хэрэгтэй.

Алдааг PPP-ийн үе шатаар ол

PPP алдааг үе шатаар мэдээлдэг бөгөөд үе шат нь гэрээний аль заалт зөрчигдсөнийг хэлдэг. Холбоосын удирдлагаас хэзээ ч гарахгүй холбоос капсулчлал эсвэл хэлэлцээрийн асуудалтай, харин баталгаажуулагдаж дараа нь үхдэг холбоос ихэвчлэн бодлого эсвэл түлхүүрийн асуудалтай байдаг. Дээрээ үлдэж, юу ч зөөдөггүй холбоос маршрутлалт руу шилжсэн бөгөөд энэ нь өөр мөрдөн шалгалт юм.

Сэтгүүл үе шатын мөрүүдийг хадгалдаг бөгөөд тэдгээр нь илүү өндөр дибаг түвшнээс илүү ашигтай. PPP процессууд болон хамгаалалтын мессежүүдийг асуугаад, дараа нь бусад бүхнээс өмнө баталгаажуулалтын үр дүнг уншина уу. Сүүлийн мөрүүд ихэвчлэн үгүйсгэсэн заалтыг нэрлэдэг:

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

Тэр гаралтаас эхлээд баталгаажуулалтын үр дүнг, дараа нь хамгаалалт шаардагдсан боловч хэлэлцэгдээгүй гэсэн гомдлыг хайна уу. Хоёр дахь мессеж нь дээрх зөрчлийн гарын үсэг бөгөөд сервер түлхүүр үйлдвэрлэж чадах цорын ганц аргыг үгүйсгэж байгаа цагт хичнээн дахин оролдсон ч үүнийг арилгахгүй. Хоёр урхийг нэрлэх нь зүйтэй: үе шатын мөрүүдийг уншихгүйгээр дибаг түвшнийг өсгөх нь шуугиан үүсгэдэг, сорилтын материал эсвэл нууц үгийг барих нь тохиргооны ажлыг итгэмжлэлийн алдагдал болгоно. Аль ч тохиргоог өөрчлөхөөс өмнө тэр үе шатыг тэмдэглэ.

Хуучин төгсгөлийн цэгийг унтраахаас өмнө гарах замаа төлөвлө

MPPE бол холбоосын хамгаалалтын түүхэн механизм бөгөөд түүний оршихуй нь PPTP-г шинэ байршуулалтад ухаалаг сонголт болгодоггүй. Microsoft-ын одоогийн заавар нь шинэ алсын хандалтын байршуулалтад PPTP болон урьдчилан хуваалцсан түлхүүртэй L2TP/IPsec-ийн эсрэг зөвлөдөг. Хуучин төгсгөлийн цэгийг амьд байлгах нь одоо байгаа үйлчилгээний тухай шийдвэр бөгөөд дараагийнхны загвар биш.

Төгсгөлийн цэг үлдэх ёстой бол гэрээг бичнэ үү: гадаад протокол, шаардлагатай баталгаажуулалтын арга, заавал хамгаалалт, түүнийг хэлэлцдэг клиентийн хувилбар. Энэ нь явж чадвал хуучин профайлд хүрэхээс өмнө орлуулагчийн гарцын таних тэмдэг, түүний клиентийн баталгаажуулалт, итгэмжлэл хаана амьдрахыг сонгоно уу. Дараа нь маршрут, DNS болон хэрэглэгч бүрт хандах эрхтэй нөөцүүдийг төлөвлө. Зорилгосон клиентийг ажиллаж байгаа холболттой биш, эзэмшигчийн шаардлагатай харьцуулан баталгаажуул.

Санамсаргүй үгүйсгэл үгүйсгэл хэвээр байх ёстой, учир нь шалгалтыг давахын тулд хамгаалалтгүй горимд буцах нь бодлогын бүтэлгүйтлийг илрэл болгоно. Дууссан төлөв нь дэмжигдсэн, баримтжуулсан гэрээ бөгөөд нэг хуучин холболтыг амжилттай болгодог хамгийн бага өөрчлөлтийн багц биш. Орлуулагч мөнөөх шалгалтуудыг давах хүртэл хуучин профайлыг байранд нь, ашиглагдаагүй, баримтжуулсан байдлаар үлдээ.