Nega faqat PPP CHAP MPPE talabini qondira olmaydi

Shifrlashni talab qiladigan PPTP profili odatda bir joyda muvaffaqiyatsizlikka uchraydi: PPP MPPE uchun kerak bo‘lgan kalit materialini hech qachon ishlab chiqarmaydigan autentifikatsiya almashinuviga rozi bo‘ladi. Tunnel yarim tirik ko‘rinadi, parol qabul qilinadi va undan hech qanday trafik o‘tmasdan oldin aloqa uziladi. Biror narsa ulanmaguncha CHAP ochiladigan ro‘yxatiga qo‘l cho‘zish haqiqiy nuqsonni yashiradi, va bu autentifikatsiya usuli bilan himoya siyosati o‘rtasidagi shartnoma. Quyidagi tekshiruvlar har biri keyingisidan arzonroq sababni istisno qiladigan tartibda joylashtirilgan.

Bitta PPTP ulanishi ichida ikki muzokara boradi

PPTP GRE tunneli ichida oddiy PPP sessiyasini olib yuradi va ikkisi alohida muzokara qiladi. Tashqi qatlam paketlar qanday inkapsulyatsiya qilinishini va qaysi boshqaruv kanali borligini hal qiladi; ichki PPP sessiyasi kim sherik ekanini va tepada qanday himoya borishini hal qiladi. Shuning uchun parol so‘rovi faqat ichki qatlam haqida biror narsani isbotlaydi, tugallangan tashqi qo‘l berish esa ikkisining hech biri haqida hech narsani isbotlamaydi. Profillar bu yerda muvaffaqiyatsizlikka uchraydi, chunki odamlar tunnel nosozliklarini tuzatishadi, kelishmovchilik esa PPP ichida o‘tiradi.

Oddiy CHAP — RFC 1994dagi chaqiruv-javob almashinuvi, umumiy sir va boshqa hech narsaga qurilgan. MS-CHAPv2 boshqa xabarlar va boshqa chiqishga ega boshqa almashinuv, RFC 2759da standartlashtirilgan. Ikki nomdagi umumiy so‘z simda ularga umumiy bo‘lgan yagona narsa. Hech bir nom almashinuv nima ishlab chiqarishini aytmaydi, va bu yagona muhim qism.

Shuning uchun oddiygina CHAP deb belgilangan variant eski profilda noaniq. Server MS-CHAPv2 xohlasa, klient esa oddiy CHAP taklif qilsa, aloqa boshqaruvi baribir tugallanishi va parol baribir qabul qilinishi mumkin. Muvaffaqiyatsizlik keyinroq, server hech narsa ishlab chiqarmagan almashinuvdan himoya kalitlarini olishga urinayotganda keladi.

Talab qilinadigan usulni u ishlab chiqara oladigan kalitlarga moslang

MPPE kalitlari umuman PPPning xossasi emas. Microsoft CHAP oilasi uchun hosila RFC 3079 hujjatida belgilangan va u kirish sifatida umumiy sirni emas, MS-CHAP almashinuvining chiqishini oladi. EAP usullari xuddi shu joyga boshqa yo‘l bilan yetadi, autentifikatsiya serveri kalitlarni MS-MPPE-Recv-Key va MS-MPPE-Send-Key atributlari sifatida qaytaradi. Oddiy CHAP ikkala yo‘lda ham ko‘rinmaydi, va bu nomuvofiqlikning mavjud bo‘lishining butun sababi.

MPPE talab qilib, kalit bera oladigan har bir usulni rad etuvchi konfiguratsiya ichdan qarama-qarshi. pppd bu qarama-qarshilikni kalitlarni o‘ylab topish bilan emas, aloqani rad etish bilan hal qiladi, shuning uchun ko‘rinadigan natija autentifikatsiyadan o‘tib, keyin tarmoq bosqichida tugaydigan sessiya. Server biror narsa hosil qiladigan yagona usullarni rad etar ekan, klientni qayta urinish buni o‘zgartirmaydi.

Bundan kelib chiqadigan qoida qisqa: agar profil MPPE talab qilsa, usul MS-CHAP varianti yoki server kalitlarini qaytaradigan EAP usuli bo‘lishi kerak. Faqat MS-CHAPv2ni rad etish buni ta’minlamaydi, chunki MS-CHAPv1 ham kalit hosil qiladi va alohida rad etilmasa, mavjud bo‘lib qoladi; ikkisini ham rad etish oddiy CHAP va PAPni qoldiradi, ular hech narsa hosil qilmaydi va talabni bajarib bo‘lmaydigan qiladi. Yoqmaydiganlarini sanab o‘tish o‘rniga qabul qilingan usulni aniq nomlang. Klient ulanishi uchun shifrlash talabidan voz kechish ta’mir emas, pasaytirish.

Klientni tahrirlashdan oldin server parametrlarini o‘qing

Bu nomuvofiqliklarning ko‘pi serverda ikki faylda ko‘rinadi va ularni o‘qish klientni qayta qurishdan arzon. Linux PPTP so‘nggi nuqtasida tegishli sozlamalar pptpd uzatadigan pppd parametrlar faylida yashaydi. Uni serverda ishga tushiring, klient holati ekranidan emas. Himoya rejimini talab qiladigan, rad etadigan yoki nomlaydigan satrlardan boshlang:

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

Chiqishni bayroqlar ro‘yxati emas, shartnoma sifatida o‘qing. MPPE talab qilib, MS-CHAPning ikkala variantini rad etadigan satrni hech bir klient bajara olmaydi, MS-CHAP usuliga talabning yo‘qligi esa kalit bermaydigan almashinuvlarga eshikni ochiq qoldiradi. Keyin kimga autentifikatsiya ruxsat etilganini tekshiring, buni sirli fayl hal qiladi:

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

Biror narsani o‘zgartirishdan oldin uchta qiymatni yozing: tashqi protokol, server talab qiladigan autentifikatsiya usuli va himoyaning majburiy yoki ixtiyoriy ekani. Bu uchtasi har bir keyingi qarorni belgilaydi, ularni klient muloqotidan taxmin qilish esa profilning yarim sozlangan holda qolish yo‘li. Ish paytida faylni ochiq tuting, chunki keyingi bo‘limga xuddi shu uchta qiymat kerak.

Muvaffaqiyatsizlikni PPP bosqichiga ko‘ra toping

PPP muvaffaqiyatsizliklarni bosqichlarda xabar qiladi, bosqich esa shartnomaning qaysi bandi buzilganini aytadi. Aloqa boshqaruvidan hech qachon chiqmaydigan aloqada inkapsulyatsiya yoki muzokara muammosi bor, autentifikatsiyadan o‘tib keyin o‘ladigan aloqada esa odatda siyosat yoki kalit muammosi bo‘ladi. Tepada qolib hech narsa tashimaydigan aloqa marshrutlashga o‘tgan, bu boshqa tekshiruv.

Jurnal bosqich satrlarini saqlaydi va ular yuqoriroq tuzatish darajasidan foydaliroq. PPP jarayonlari va himoya xabarlarini so‘rang, keyin hamma narsadan oldin autentifikatsiya natijasini o‘qing. Oxirgi satrlar odatda rad etgan bandni nomlaydi:

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

O‘sha chiqishda avval autentifikatsiya natijasini, keyin himoya talab qilingan, ammo muzokara qilinmagan degan shikoyatni qidiring. Ikkinchi xabar yuqoridagi qarama-qarshilikning imzosi, va server kalit ishlab chiqara oladigan yagona usulni rad etar ekan, qancha qayta urinsangiz ham uni tozalamaydi. Ikkita tuzoqni nomlash joiz: bosqich satrlarini o‘qimasdan tuzatish darajasini ko‘tarish shovqin tug‘diradi, chaqiruv materialini yoki parollarni ushlash esa sozlash vazifasini hisob ma’lumotlari oqib ketishiga aylantiradi. Har qanday parametrni o‘zgartirishdan oldin o‘sha bosqichni yozib qo‘ying.

Eski so‘nggi nuqta o‘chirilishidan oldin chiqishni rejalashtiring

MPPE — aloqa himoyasining tarixiy mexanizmi, uning mavjudligi PPTPni yangi joylashtirish uchun oqilona tanlovga aylantirmaydi. Microsoftning amaldagi qo‘llanmasi yangi masofaviy kirish joylashtirishlari uchun PPTPga va oldindan umumiy kalitli L2TP/IPsecga qarshi allaqachon maslahat beradi. Eski so‘nggi nuqtani tirik saqlash mavjud xizmat haqidagi qaror, keyingisi uchun namuna emas.

So‘nggi nuqta qolishi kerak bo‘lsa, shartnomani yozing: tashqi protokol, talab qilinadigan autentifikatsiya usuli, majburiy himoya va uni muzokara qiladigan klient versiyasi. U keta olsa, eski profilga tegishdan oldin o‘rinbosarning shlyuz identifikatori, uning klient autentifikatsiyasi va hisob ma’lumotlari yashaydigan joyni tanlang. Keyin marshrutlar, DNS va har bir foydalanuvchi ruxsat olgan resurslarni rejalashtiring. Ko‘zda tutilgan klientni ishlayotgan aloqa bilan emas, egasining talablari bilan solishtirib tekshiring.

Qasddan rad etish rad etish bo‘lib qolishi kerak, chunki sinovdan o‘tish uchun himoyasiz rejimga qaytish siyosat muvaffaqiyatsizligini fosh etishga aylantiradi. Tayyor holat — qo‘llab-quvvatlanadigan, hujjatlashtirilgan shartnoma, bitta eski aloqani muvaffaqiyatli qiladigan eng kichik o‘zgarishlar to‘plami emas. O‘rinbosar xuddi shu tekshiruvlardan o‘tmaguuncha eski profilni joyida, ishlatilmay va hujjatlashtirilgan holda qoldiring.