PPTP üzərində LCP qarşı tərəf tərəfindən dayandırıldı: əvvəlcə MPPE-ni aktivləşdirin

Bağlantı autentifikasiyadan keçir, müştəri qoşulduğunu bildirir və bir saniyə sonra jurnal LCP-nin qarşı tərəf tərəfindən dayandırılması ilə bağlanır. Bu sətir GRE tuneli daxilindəki PPP danışıqlarından gəlir, yəni nəqliyyat artıq işləyirdi və iki tərəf bağlantı seçimləri barədə razılaşmadı. Parollar və server ünvanları burada adətən günahsızdır. Şifrələmə siyasəti ilk müqayisə edilməli şeydir və Linux-da pppd-nin qarşı tərəf faylı ilk baxılmalı yerdir.

LCP nasazlığı PPP mərhələsi haqqında nə deyir

PPTP PPP-ni GRE içində bükür: TCP 1723 idarəetmə bağlantısı zəngi qurur, GRE yükü daşıyır, sonra LCP autentifikasiya protokolu, sıxılma və MPPE kimi seçimləri danışır. Tələb olunan seçim qarşı tərəf üçün qəbuledilməz olduqda o, LCP-ni dayandırır. CHAP və ya MSCHAPv2 mübadiləsinin tamamlandığı və dərhal sonra LCP-nin bitdiyi jurnal siyasət rəddidir, əlçatanlıq nasazlığı deyil. Tünel ümumiyyətlə danışığa çatmırsa, LCP sətrini oxumaqdan əvvəl pppd-ni və onun plaginini yoxlayın.

İki ilkin şərt asanlıqla gözdən qaçır. pppd ikili faylı mövcud olmalıdır və qarşı tərəf faylında göstərilən PPTP plagini quraşdırılmalıdır; çatışmayan paket hər hansı seçim müzakirə olunmadan zəngi bitirir.

MPPE-ni onu tələb edən tərəfdə aktivləşdirin

Əsl qərar şifrələmə siyasətinin hansı tərəfə aid olmasıdır. Müştəri MPPE-ni təklif edə, tələb edə və ya rədd edə bilər, server də eyni seçimi edir. Hər ikisi tələb etdikdə bağlantı qalxır; biri tələb edib digəri rədd etdikdə LCP bitir.

pty "pptp vpn.example.net --nolaunchpppd"
name alice
remotename PPTP
require-mppe-128

Zəng etməzdən əvvəl modulu modprobe ppp_mppe ilə yükləyin, çünki onsuz require-mppe-128 uğursuz olur. Windows-da ekvivalent idarəetmə VPN girişinin təhlükəsizlik tabıdır və müştəriyə serverin təklif etdiyini qəbul etmək əvəzinə şifrələməni tələb etmək tapşırılmalıdır. Server hələ də LCP-ni dayandırırsa, onun operatorundan MPPE-nin məcburi, istəyə bağlı yoxsa söndürülmüş olduğunu soruşun, çünki müştəri serverin rədd etdiyi qorumanı danışa bilməz. Mesaj yox olsun deyə şifrələməni söndürmək səhv istiqamətdir: bu, protokolun yeganə qorumasını aradan qaldırır.

İşləyən qarşı tərəf faylını redaktə etməzdən əvvəl saxlayın. Səhv yazılmış require-mppe sətri eyni ümumi LCP nasazlığını təkrar yaradır və sizi başlanğıca qaytarır.

Tətbiq yerinə pppd-nin öz jurnalını oxuyun

Masaüstü tətbiqləri əlaqənin kəsildiyini göstərir, səbəbi gizlədir, ona görə də demonun bir cəhd barədə hesabatını oxuyun. systemd sistemlərində mesaj jurnala düşür; daha köhnə quruluşlar ənənəvi jurnal fayllarına yazır.

journalctl --since "10 min ago" | grep -i -E "pppd|lcp|mppe"
tail -n 50 /var/log/syslog

Bir günlük yenidən qoşulmalar yerinə tək zəng ətrafında bir pəncərəni grep edin ki, rədd edilən seçim asan görünsün. pppd adətən seçimin adını və qarşı tərəfin cavabını göstərir; bu, öz təklifinizi dəyişməli, yoxsa server tərəfindən tələbin yumşaldılmasını xahiş etməli olduğunuzu bildirir. Cəhdləri vaxt damğası ilə saxlayın, çünki iki jurnalı müqayisə etmək yalnız hansı sətrin hansı zəngə aid olduğunu bildikdə faydalıdır. Heç bir LCP mübadiləsi görünmürsə, nasazlıq zəncirdə daha erkən yerdədir və MPPE şübhəli deyil.

Düzəlişi yenidən qoşulmalar boyu saxlayın: qarmaq adları və MTU

Bağlantı sabit qaldıqdan sonra iki detal onun yenidən qoşulmaya davam edib-etməyəcəyini həll edir. Qarmaqlar /etc/ppp/ip-up.d və /etc/network/if-up.d içində yerləşir və hər iki qovluq run-parts tərəfindən emal olunur; onun fayl adı filtri nöqtə olan hər şeyi rədd edir. Buna görə set-pptp.sh adlı skript atlanır, set-pptp isə icra olunur. Skriptin məzmununu sazlamazdan əvvəl adı yoxlayın, sonra kiçik MTU-nu həmin qarmağın içindən təyin edin ki, hər yeni ppp interfeysi onu əl əmri olmadan miras alsın.

run-parts --test /etc/ppp/ip-up.d
ip link set dev ppp0 mtu 1200

Sessiyanı qəsdən bitirmək üçün proses adlarını naxışla uyğunlaşdırmaq yerinə pppd-nin qeyd etdiyi pid-i hədəf alın, çünki ppp olan hər şeyi öldürmək əlaqəsiz bağlantıları da qoparır. PPTP köhnəlmişdir və MS-CHAPv2 zəifdir, ona görə bu yoxlamaları işləməyə davam etməli olan bağlantı üçün texniki xidmət kimi qəbul edin, PPTP-ni hər hansı yeni yerdə yerləşdirmək üçün səbəb kimi yox.