pptpd-ko GRE idazketa-hutsegiteak ez dira pasahitz arazoa

GRE idazketa-hutsegitea erregistroan, eta lehen bulkada erabiltzailearen pasahitza berrezartzea da. Bulkada hori ia beti okerra da. Mezu hauek datu-bidea deskribatzen dute, ez kredentzialen egiaztapena: baliteke bezeroak behar bezala autentifikatu izana eta gero sarean erregistratzen den fasean trabatuta geratu izana. Bi mezu desberdinek bi hutsegite desberdin adierazten dituzte, eta bat ere ez da pasahitz berri batekin konpontzen.

Bi mezu, bi hutsegite desberdin

Irakurketa-hutsegiteak esan nahi du GRE paketeak ez direla sekula daemonera iristen, edo sarreran botatzen direla. Kontrol-konexioak guztiz osasuntsu dirudi, datu-bideak ezer zeharkatzen ez duen bitartean. Autentifikazioa frogagarriki funtzionatu zuen gauza bakarra da.

Idazketa-hutsegiteak normalean esan nahi du saioak kernelak edo bezeroak erabili ezin duen zerbait negoziatu duela. Kontrol-kanala osatu zen, eta truke horretan adostutako aukerak ez datoz bat muturrek benetan egin dezaketenarekin. Konfigurazio-desadostasuna da, ez autentifikazio-gertaera.

Irakurri bietako zein agertzen den ezer aldatu aurretik. Geruza desberdinetara bidaltzen zaituzte, eta sintoma bakar gisa tratatzea da zerbitzari bera bi aldiz adabaki izatearen arrazoia, zerikusirik ez duten arrazoiengatik. Erregistro-lerroa lortzen duzun diagnostiko doako bakarra da.

47 protokoloa ez da 47 ataka

PPTPk TCP 1723 erabiltzen du deia ezartzeko eta GRE karga eramateko. GRE IP protokolo 47 da, ez ataka-zenbaki, beraz 47 ataka irekitzen duen suebaki-arauak ez du ezer baliagarririk baimenduko.

Bideko bideratzaileak PPTP passthrough funtzioa edo GRE baimen esplizitua behar du. Hori gabe, TCP esku-ukipena osatzen da eta tuneleak ez du sekula paketerik eramaten, eta horrek goiko irakurketa-hutsegitea sortzen du zehazki. Suebaki bateko 47 atakako arauak protokolo honetako arratsalde galduena dira.

Behaketu bi norabideak aldi berean zerbitzarian, zein alde ari den trafikoa botatzen asmatu beharrean: tcpdump -ni any port 1723 or proto gre.

1723k deia ezartzen duela erakusten badu eta GRE isilik badago, blokeoa ostalaritik gora dago. GRE iristen bada eta daemonak huts egiten badu oraindik, arazoa lokala da eta aukerak hurrengo begiratzeko tokia dira.

Baimendu GRE ostalariak benetan birbidaltzen duen tokian

GRE-rako forward arau bat sartzea proba arrazoizkoa da tuneleko trafikoa birbidaltzen duen ostalari batean, eta ez da politika. Protokolo baten guztia onartzen duen proba-araua diagnostikoa da, ez diseinua. Utzi nahikoa denbora zerbait ikasteko, eta ordeztu gero arau mugatu batekin.

Gehitu input arau bat zerbitzariari berari zuzendutako paketeetarako, forward kateak ez baititu ikusten. Gero begiratu arauaren kontagailuak konexio-saiakera baten aurretik eta ondoren, eta horrek esango dizu paketeak iristen diren ala ez.

Egin araua iraunkorra banaketaren suebaki-zerbitzuaren bidez, berrabiarazte bakoitzaren ondoren berriro exekutatu beharrean. nftables ostalari batean, egin bat ip protocol gre input eta forward kateetan.

Egiaztatu ppp_generic modulua ere kargatuta dagoela, eta egiaztatu konexioen jarraipenak itzulerako norabidea botatzen duen. Biek suebaki-arazo itxura duten hutsegiteak sortzen dituzte, eta ez dira. Falta den kernel modulu bat protokolo blokeatu baten itxura du zehazki egiaztatu arte.

Egokitu aukerak benetan duzun bezeroari

Beste txostenaren konponketa /etc/ppp/pptpd-options fitxategian dago, non errezetak PAP, CHAP eta MSCHAP ukatzen dituen, dagozkion require lerroak iruzkintzen dituen eta egoera duen MPPE mantentzen duen. Errezeta hori bezero-nahaste batetarako idatzi zen, eta itsu kopiatzeak ohiko kasua hausten du. Irakurri ukapen-lerroak egileak zein bezero zituen adierazpen gisa, ez gomendio gisa.

Windows bezero batek normalean MS-CHAPv2 behar du MPPE-128-rekin. Mantendu baldintza horiek eta kendu soilik bezeroak benetan negozia ezin dituen aukerak.

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

Konexio bat lortzeko zifratzea desaktibatzea beherapena da, ez konponketa. Probatu halako aldaera bat laborategiko loturan, eta gero leheneratu zifratzea zerbitzuak bezero errealekin topo egin aurretik. Modu ez-seguruan funtzionatzen duen konexioa okerragoa da zintzotasunez huts egiten duena baino.

Irakurri bezeroaren errore-zenbakia

Bezeroaren kode numerikoak fasea azkarrago murrizten du zerbitzariaren erregistroak baino. Irakurri ezazu beste ezer irakurri aurretik. 691 zenbakiak esan nahi du kredentzialak baztertu zirela, 721 zenbakiak zerbitzariak inoiz erantzun ez zuela, eta 619 zenbakiak konexioa eten zela. Zenbakiarekin bi minutuk ordu bat aurreztetzen dute konfigurazioarekin.

Konparatu kode hori zerbitzariaren erregistroarekin ezer editatu aurretik, eta probatu berriro bezero berarekin aldaketa bakoitzaren ondoren. Bestela bigarren hutsegitea lehenaren atzean ezkutatzen da eta konponketa eraginkorra ez dela dirudi.

Saio-hasiera arrakastatsua denean eta trafikorik mugitzen ez denean, GRE susmoa izaten jarraitzen du. Hori da kapturara itzultzeko unea, kredentzial biltegira ez.