Niyə tək PPP CHAP MPPE tələbini ödəyə bilmir

Şifrələmədə israr edən PPTP profili adətən eyni yerdə uğursuz olur: PPP heç vaxt MPPE-nin ehtiyac duyduğu açar materialını istehsal etməyən autentifikasiya mübadiləsi üzərində razılaşır. Tunel yarı canlı görünür, parol qəbul edilir və hər hansı trafik ondan keçməmişdən əvvəl bağlantı qopur. Nə isə qoşulana qədər CHAP açılan siyahısına uzanmaq əsl qüsuru gizlədir, bu qüsur autentifikasiya üsulu ilə mühafizə siyasəti arasındakı müqavilədir. Aşağıdakı yoxlamalar elə sıralanıb ki, hər biri növbətindən daha ucuz bir səbəbi istisna edir.

Bir PPTP bağlantısı daxilində iki danışıq gedir

PPTP GRE tuneli daxilində normal PPP sessiyası daşıyır və ikisi ayrı-ayrılıqda danışıq aparır. Xarici qat paketlərin necə inkapsulyasiya olunduğunu və hansı idarəetmə kanalının mövcud olduğunu müəyyən edir; daxili PPP sessiyası həmsöhbətin kim olduğunu və üstdə hansı mühafizənin getdiyini müəyyən edir. Buna görə parol sorğusu yalnız daxili qat haqqında nəsə sübut edir, tamamlanmış xarici handshake isə ikisindən heç biri haqqında heç nə sübut etmir. Profillər burada uğursuz olur, çünki insanlar tuneli sazlayarkən fikir ayrılığı PPP-nin içində oturur.

Adi CHAP RFC 1994-dəki çağırış-cavab mübadiləsidir, yalnız ortaq sirr üzərində qurulub. MS-CHAPv2 fərqli mesajları və fərqli çıxışı olan başqa mübadilədir, RFC 2759-da standartlaşdırılıb. İki addakı ortaq söz onların naqildə ortaq olduğu yeganə şeydir. Adların heç biri mübadilənin nə istehsal etdiyini demir, halbuki əhəmiyyətli olan yalnız bu hissədir.

Buna görə sadəcə CHAP adlandırılmış seçim köhnə profildə qeyri-müəyyəndir. Server MS-CHAPv2 istəyəndə və müştəri adi CHAP təklif edəndə, bağlantı nəzarəti yenə də tamamlana bilər və parol yenə də qəbul oluna bilər. Uğursuzluq sonra gəlir, server heç nə istehsal etməyən mübadilədən mühafizə açarları çıxarmağa çalışanda.

Tələb olunan üsulu istehsal edə biləcəyi açarlarla uyğunlaşdırın

MPPE açarları ümumilikdə PPP-nin xassəsi deyil. Microsoft CHAP ailəsi üçün törəmə RFC 3079-da müəyyən edilib və o, giriş kimi ortaq sirri deyil, MS-CHAP mübadiləsinin çıxışını götürür. EAP üsulları fərqli yolla eyni yerə çatır, autentifikasiya serveri açarları MS-MPPE-Recv-Key və MS-MPPE-Send-Key atributları kimi qaytarır. Adi CHAP iki yoldan heç birində görünmür, uyğunsuzluğun bütün səbəbi budur.

Açar təmin edə bilən hər üsulu rədd edərkən MPPE tələb edən konfiqurasiya daxilən ziddiyyətlidir. pppd bu ziddiyyəti açarlar uydurmaqla deyil, bağlantını rədd etməklə həll edir, ona görə görünən nəticə autentifikasiyadan keçib şəbəkə mərhələsində sonlanan sessiyadır. Server hər hansı açar törədən yeganə üsulları rədd etdikcə müştərini yenidən sınamaq bunu dəyişməyəcək.

Bundan çıxan qayda qısadır: profil MPPE tələb edirsə, üsul MS-CHAP variantı və ya serverin açarlarını qaytardığı EAP üsulu olmalıdır. Yalnız MS-CHAPv2-ni rədd etmək bunu təmin etmir, çünki MS-CHAPv1 də açar törədir və ayrıca rədd edilmədikcə mövcud qalır; ikisini də rədd etmək adi CHAP və PAP-ı qoyur, onlar heç nə törətmür və tələbi yerinə yetirilməz edir. Bəyənmədiklərinizi sadalamaq əvəzinə qəbul edilən üsulu açıq şəkildə adlandırın. Müştəri qoşulsun deyə şifrələmə tələbini atmaq təmir deyil, aşağı salmadır.

Müştərini redaktə etməzdən əvvəl serverin seçimlərini oxuyun

Bu uyğunsuzluqların çoxu serverdə iki faylda görünür və onları oxumaq müştərini yenidən qurmaqdan daha az başa gəlir. Linux PPTP son nöqtəsində aid parametrlər pptpd-nin ötürdüyü pppd seçimlər faylında yaşayır. Onu serverdə işə salın, müştəri status ekranından deyil. Mühafizə rejimini tələb edən, rədd edən və ya adlandıran sətirlərlə başlayın:

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

Çıxışı bayraqlar siyahısı kimi deyil, müqavilə kimi oxuyun. MPPE tələb edərkən hər iki MS-CHAP variantını rədd edən sətri heç bir müştəri ödəyə bilməz və MS-CHAP üsulu üçün tələbin olmaması açar verməyən mübadilələrə qapını açıq qoyur. Sonra ümumiyyətlə kimin autentifikasiya edə biləcəyini yoxlayın, bunu sirrlər faylı həll edir:

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

Hər hansı dəyişiklik etməzdən əvvəl üç dəyəri yazın: xarici protokol, serverin tələb etdiyi autentifikasiya üsulu və mühafizənin məcburi və ya istəyə bağlı olması. Bu üçü bütün sonrakı qərarları müəyyən edir və onları müştəri dialoqundan təxmin etmək profilin yarımkonfiqurasiya ilə bitməsinin yoludur. İşləyərkən faylı açıq saxlayın, çünki növbəti bölmə eyni üç dəyərə ehtiyac duyur.

Uğursuzluğu PPP mərhələsinə görə tapın

PPP uğursuzluqları mərhələlərlə bildirir və mərhələ müqavilənin hansı bəndinin pozulduğunu deyir. Bağlantı nəzarətini heç tərk etməyən bağlantıda inkapsulyasiya və ya danışıq problemi var, autentifikasiyadan keçib sonra ölən bağlantıda isə adətən siyasət və ya açar problemi olur. Ayaqda qalıb heç nə daşımayan bağlantı marşrutlaşdırmaya keçib, bu başqa araşdırmadır.

Jurnal mərhələ sətirlərini saxlayır və onlar daha yüksək sazlama səviyyəsindən daha faydalıdır. PPP proseslərini və mühafizə mesajlarını soruşun, sonra hər şeydən əvvəl autentifikasiya nəticəsini oxuyun. Son sətirlər adətən rədd edən bəndi adlandırır:

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

Həmin çıxışda əvvəlcə autentifikasiya nəticəsini, sonra mühafizənin tələb olunduğu amma razılaşdırılmadığı şikayətini axtarın. İkinci mesaj yuxarıdakı ziddiyyətin imzasıdır və server açar istehsal edə bilən yeganə üsulu rədd etdikcə nə qədər təkrar cəhd etsəniz də onu təmizləmir. İki tələni adlandırmağa dəyər: mərhələ sətirlərini oxumadan sazlama səviyyəsini qaldırmaq səs-küy yaradır, çağırış materialını və ya parolları tutmaq isə konfiqurasiya tapşırığını etimad məlumatı sızmasına çevirir. Hər hansı seçimi dəyişməzdən əvvəl o mərhələni qeyd edin.

Köhnə son nöqtə söndürülməzdən əvvəl çıxışı planlaşdırın

MPPE tarixi bir bağlantı mühafizə mexanizmidir və onun mövcudluğu PPTP-ni yeni yerləşdirmə üçün məntiqli seçim etmir. Cari Microsoft təlimatı artıq PPTP-ə və yeni uzaq giriş yerləşdirmələri üçün əvvəlcədən paylaşılan açarlı L2TP/IPsec-ə qarşı tövsiyə edir. Köhnə son nöqtəni canlı saxlamaq mövcud xidmət haqqında qərardır, növbətisi üçün şablon deyil.

Son nöqtə qalmalı olduqda müqaviləni yazın: xarici protokol, tələb olunan autentifikasiya üsulu, məcburi mühafizə və onu razılaşdıran müştəri versiyası. Gedə bildikdə isə köhnə profilə toxunmazdan əvvəl əvəzedicinin şlüz kimliyini, onun müştəri autentifikasiyasını və etimad məlumatlarının harada yaşayacağını seçin. Sonra marşrutları, DNS-i və hər istifadəçinin giriş icazəsi olan resursları planlaşdırın. Nəzərdə tutulan müştərini işləyən bağlantıya görə deyil, sahibin tələblərinə görə yoxlayın.

Qəsdən edilən rədd rədd olaraq qalmalıdır, çünki testin keçməsi üçün mühafizəsiz rejimə geri çəkilmək siyasət uğursuzluğunu məruz qalmaya çevirir. Tamamlanmış vəziyyət dəstəklənən, sənədləşdirilmiş müqavilədir, bir köhnə bağlantını uğurla edən ən kiçik dəyişikliklər toplusu deyil. Köhnə profili yerində, istifadəsiz və sənədləşdirilmiş şəkildə saxlayın, əvəzedici eyni yoxlamalardan keçənə qədər.