pptpd-də GRE yazma xətaları parol problemi deyil

Logda GRE yazma xətası var və ilk instinkt istifadəçinin parolunu sıfırlamaqdır. Bu instinkt demək olar ki, həmişə yanlışdır. Bu mesajlar etimad yoxlamasını deyil, məlumat yolunu təsvir edir: müştəri uğurla autentifikasiya olub, sonra şəbəkədə qeydiyyatdan keçdiyi mərhələdə dayana bilər. İki fərqli mesaj iki fərqli nasazlığa işarə edir və heç biri yeni parolla həll olunmur.

İki mesaj, iki fərqli nasazlıq

Oxuma xətası GRE paketlərinin heç vaxt demona çatmadığını və ya daxil olan yolda atıldığını bildirir. Nəzarət bağlantısı tamamilə sağlam görünə bilər, halbuki məlumat yolundan heç nə keçmir. Autentifikasiya sübut olunmuş şəkildə işləyən yeganə şeydir.

Yazma xətası adətən sessiyanın nüvənin və ya müştərinin istifadə edə bilmədiyi bir şey üzərində razılaşdığını bildirir. Nəzarət kanalı tamamlandı və həmin mübadilə zamanı razılaşdırılan seçimlər son nöqtələrin həqiqətən edə biləcəkləri ilə uyğun gəlmir. Bu, autentifikasiya hadisəsi deyil, konfiqurasiya fərqidir.

Nəyisə dəyişməzdən əvvəl ikisindən hansının göründüyünü oxuyun. Onlar sizi müxtəlif qatlara yönləndirir və onlara bir simptom kimi baxmaq eyni serverin əlaqəsiz səbəblərdən iki dəfə yamaqlanmasının səbəbidir. Log sətri aldığınız yeganə pulsuz diaqnostikadır.

47 protokolu 47 portu deyil

PPTP zəngi qurmaq üçün TCP 1723, yükü daşımaq üçün GRE istifadə edir. GRE port nömrəsi deyil, IP protokolu 47-dir, buna görə 47 portunu açan firewall qaydası faydalı heç nəyə icazə vermir.

Yoldakı marşrutlaşdırıcıya PPTP passthrough funksiyası və ya açıq GRE icazəsi lazımdır. Bu olmadan TCP handshake tamamlanır və tunel heç vaxt paket daşımır, bu da yuxarıdakı oxuma xətasını tam olaraq yaradır. Firewallda 47 portu qaydaları bu protokolda ən çox boşa gedən günorta saatlarıdır.

Hansı tərəfin trafiki atdığını təxmin etmək əvəzinə serverdə hər iki istiqaməti eyni vaxtda izləyin: tcpdump -ni any port 1723 or proto gre.

Əgər 1723 zəng quruluşunu göstərirsə və GRE səssiz qalırsa, blok hostdan yuxarıdadır. Əgər GRE gəlir və demon hələ də uğursuz olursa, problem lokaldır və seçimlər baxılacaq növbəti yerdir.

GRE-yə hostun həqiqətən yönləndirdiyi yerdə icazə verin

Tunel trafikini yönləndirən hostda GRE üçün forward qaydası əlavə etmək ağlabatan sınaqdır və bu siyasət deyil. Bir protokolun hər şeyini qəbul edən sınaq qaydası dizayn deyil, diaqnostikadır. Bir şey öyrənmək üçün kifayət qədər saxlayın, sonra onu məhdud qayda ilə əvəz edin.

Serverin özünə ünvanlanmış paketlər üçün input qaydası əlavə edin, çünki forward zənciri onları görmür. Sonra qayda sayğaclarına bağlantı cəhdindən əvvəl və sonra baxın, bu paketlərin ümumiyyətlə gəlib-gəlmədiyini bildirir.

Qaydanı hər yenidən başlatmadan sonra yenidən işə salmaq əvəzinə distributivin firewall xidməti vasitəsilə saxlayın. nftables hostunda həm input, həm də forward zəncirində ip protocol gre ilə uyğunlaşdırın.

ppp_generic modulunun da yükləndiyini təsdiqləyin və bağlantı izləmənin qayıdış istiqamətini atıb-atmadığını yoxlayın. Hər ikisi firewall problemi kimi görünən və olmayan nasazlıqlar yaradır. Çatışmayan nüvə modulu yoxlayana qədər bloklanmış protokol kimi görünür.

Seçimləri həqiqətən sahib olduğunuz müştəriyə uyğunlaşdırın

Digər hesabatın düzəlişi /etc/ppp/pptpd-options faylındadır, burada resept PAP, CHAP və MSCHAP-i rədd edir, uyğun require sətirlərini şərhə alır və stateful MPPE saxlayır. Həmin resept bir müştəri qarışığı üçün yazılmışdı və onu kor-koranə kopyalamaq adi halı pozur. Rədd sətirlərini tövsiyə kimi deyil, müəllifin hansı müştəriləri olduğuna dair bəyanat kimi oxuyun.

Windows müştərisi adətən MS-CHAPv2 ilə MPPE-128 tələb edir. Bu tələbləri saxlayın və yalnız müştərinin həqiqətən razılaşa bilmədiyi seçimləri çıxarın.

# keep encryption; drop only what this client cannot negotiate
refuse-pap
refuse-chap
refuse-mschap
mppe-stateful
require-mschap-v2
require-mppe-128

Bağlantının uğurlu olması üçün şifrələməni söndürmək təmir deyil, aşağı salmadır. Belə variantı laboratoriya xəttində sınaqdan keçirin, sonra xidmət real müştərilərlə qarşılaşmazdan əvvəl şifrələməni bərpa edin. Təhlükəsiz işləməyən bağlantı dürüst şəkildə uğursuz olan bağlantıdan pisdir.

Müştərinin xəta nömrəsini oxuyun

Müştərinin rəqəmsal kodu mərhələni server logundan daha sürətli daraldır. Başqa heç nə oxumazdan əvvəl onu oxuyun. 691 etimad məlumatlarının rədd edildiyini, 721 serverin heç vaxt cavab vermədiyini və 619 bağlantının kəsildiyini bildirir. Nömrə ilə iki dəqiqə konfiqurasiya ilə bir saatı qənaət edir.

Hər hansı düzəlişdən əvvəl həmin kodu server logu ilə müqayisə edin və hər dəyişiklikdən sonra eyni müştəri ilə yenidən sınaqdan keçirin. Əks halda ikinci nasazlıq birincinin arxasında gizlənir və düzəliş səmərəsiz görünür.

Giriş uğurlu olduqda və heç bir trafik hərəkət etmədikdə, GRE şübhəli olaraq qalır. Bu, etimad anbarına deyil, tutmağa qayıtmaq anıdır.