Dështimet e shkrimit GRE në pptpd nuk janë problem fjalëkalimi

Dështim shkrimi GRE në log, dhe instinkti i parë është të rivendosësh fjalëkalimin e përdoruesit. Ky instinkt është pothuajse gjithmonë i gabuar. Këto mesazhe përshkruajnë rrugën e të dhënave, jo kontrollin e kredencialeve: klienti mund të jetë autentikuar me sukses dhe më pas të jetë bllokuar në fazën kur regjistrohet në rrjet. Dy mesazhe të ndryshme tregojnë dy defekte të ndryshme, dhe asnjëri nuk zgjidhet me një fjalëkalim të ri.

Dy mesazhe, dy defekte të ndryshme

Një dështim leximi do të thotë që paketat GRE nuk arrijnë kurrë te daemoni, ose hidhen poshtë gjatë hyrjes. Lidhja e kontrollit mund të duket plotësisht e shëndetshme ndërkohë që asgjë nuk kalon nëpër rrugën e të dhënave. Autentikimi është e vetmja gjë që funksionoi në mënyrë të provueshme.

Një dështim shkrimi zakonisht do të thotë që sesioni negocioi diçka që kernel-i ose klienti nuk mund ta përdorë. Kanali i kontrollit përfundoi, dhe opsionet e rregulluara gjatë atij shkëmbimi nuk përputhen me atë që pikat fundore mund të bëjnë në të vërtetë. Ky është një mospërputhje konfigurimi, jo një ngjarje autentikimi.

Lexoni cila nga të dyja shfaqet përpara se të ndryshoni ndonjë gjë. Ato ju çojnë në shtresa të ndryshme, dhe trajtimi i tyre si një simptom i vetëm është arsyeja pse i njëjti server rregullohet dy herë për arsye të palidhura. Rreshti i log-ut është diagnostikimi i vetëm falas që merrni.

Protokolli 47 nuk është porti 47

PPTP përdor TCP 1723 për të vendosur thirrjen dhe GRE për të transportuar ngarkesën. GRE është protokolli IP 47, jo një numër porti, kështu që një rregull firewall që hap portin 47 nuk lejon asgjë të dobishme.

Një router në rrugë ka nevojë për funksion passthrough PPTP ose një leje të shprehur për GRE. Pa të, shtrëngimi i duarve TCP përfundon dhe tuneli nuk transporton kurrë një paketë, gjë që prodhon pikërisht dështimin e leximit më sipër. Rregullat për portin 47 në një firewall janë pasdreja më e shpeshtë e humbur në këtë protokoll.

Vëzhgoni të dy drejtimet njëkohësisht në server në vend që të hamendësoni cila anë i hedh poshtë trafikut: tcpdump -ni any port 1723 or proto gre.

Nëse 1723 tregon vendosjen e thirrjes ndërsa GRE mbetet i heshtur, bllokimi është mbi hostin. Nëse GRE arrin dhe daemoni ende dështon, problemi është lokal dhe opsionet janë vendi tjetër për të parë.

Lejoni GRE aty ku hosti përcjell vërtet

Futja e një rregulli forward për GRE është një provë e arsyeshme në një host që përcjell trafik tuneli, dhe nuk është politikë. Një rregull prove që pranon gjithçka të një protokolli është diagnostikim, jo dizajn. Lëreni mjaftueshëm gjatë për të mësuar diçka, pastaj zëvendësojeni me një rregull të kufizuar.

Shtoni një rregull input për paketat e adresuara vetë serverit, sepse zinxhiri forward nuk i sheh ato. Pastaj shikoni numëruesit e rregullit përpara dhe pas një përpjekjeje lidhjeje, gjë që ju tregon nëse paketat arrijnë fare.

Bëjeni rregullin të përhershëm përmes shërbimit të firewall-it të shpërndarjes në vend që ta ekzekutoni përsëri pas çdo rindezjeje. Në një host nftables, përputhni ip protocol gre si në zinxhirin input ashtu edhe në atë forward.

Konfirmoni që edhe moduli ppp_generic është i ngarkuar, dhe kontrolloni nëse gjurmimi i lidhjeve e hedh poshtë drejtimin e kthimit. Të dyja prodhojnë dështime që duken si problem firewall dhe nuk janë. Një modul kernel që mungon duket pikërisht si një protokoll i bllokuar derisa ta kontrolloni.

Përshtatni opsionet me klientin që keni vërtet

Korrigjimi nga raporti tjetër është në /etc/ppp/pptpd-options, ku receta refuzon PAP, CHAP dhe MSCHAP, komenton rreshtat require përkatës dhe mban MPPE me gjendje. Ajo recetë u shkrua për një përzierje të vetme klientësh, dhe kopjimi i verbër prish rastin e zakonshëm. Lexoni rreshtat e refuzimit si një deklaratë për klientët që autori kishte, jo si një rekomandim.

Një klient Windows zakonisht ka nevojë për MS-CHAPv2 me MPPE-128. Mbani ato kërkesa dhe hiqni vetëm opsionet që klienti vërtet nuk mund t'i negociojë.

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

Çaktivizimi i kriptimit për të bërë një lidhje të funksionojë është një degradim, jo një riparim. Provoni një variant të tillë në një lidhje laboratori, pastaj rikthejeni kriptimin përpara se shërbimi të përballet me klientë të vërtetë. Lidhja që funksionon në mënyrë të pasigurt është më e keqe se ajo që dështon me ndershmëri.

Lexoni numrin e gabimit të klientit

Kodi numerik i klientit e ngushton fazën më shpejt se log-u i serverit. Lexojeni përpara se të lexoni çdo gjë tjetër. 691 do të thotë që kredencialet u refuzuan, 721 do të thotë që serveri nuk u përgjigj kurrë, dhe 619 do të thotë që lidhja ra. Dy minuta me numrin kursejnë një orë me konfigurimin.

Krahasoni atë kod me log-un e serverit përpara se të modifikoni ndonjë gjë, dhe ritestoni me të njëjtin klient pas çdo ndryshimi. Përndryshe një defekt i dytë fshihet pas të parit dhe korrigjimi duket i paefektshëm.

Kur hyrja ka sukses dhe asnjë trafik nuk lëviz, GRE mbetet i dyshuari. Ky është momenti për t'u kthyer te kapja, jo te depoja e kredencialeve.