Gabimi PPTP 800 kundrejt 812 dhe shkëputjet pas një minute

Tre mesazhe gabimi nga një klient PPTP zakonisht përshkruajnë tre defekte të ndryshme. Gabimi 800 do të thotë që tuneli nuk u formua kurrë, gabimi 812 do të thotë që serveri refuzoi metodën e vërtetimit, dhe një shkëputje pas një minute është një kohëmatës keepalive që vendos se një partner i shëndetshëm është larguar. Çdo fazë dështon për arsyen e vet, prandaj secila kërkon kontrollin e vet.

Gabimi 800 do të thotë që tuneli nuk u formua kurrë

Windows nxjerr gabimin 800 kur nuk mund ta ndërtojë tunelin fare, dhe teksti për një server të paarritshëm ose parametra sigurie të papërshtatshëm është përmbledhje, jo diagnozë. PPTP kërkon dy gjëra të ndara nga rrjeti përpara se të ekzaminohet ndonjë kredencial. TCP 1723 mban kanalin e kontrollit, dhe protokolli IP 47, GRE, mban ngarkesën e inkapsuluar.

Testojeni atë rrugë të jashtme nga jashtë LAN-it tuaj, sepse një lidhje që funksionon në zyrë nuk provon asgjë për skajin:

$ nc -vz vpn.example.net 1723
Connection to vpn.example.net 1723 port [tcp/*] succeeded!
$ sudo tcpdump -ni eth0 proto gre
tcpdump: listening on eth0, link-type EN10MB

Nëse 1723 përgjigjet dhe kapja mbetet bosh ndërsa klienti përpiqet të lidhet, rruga po hedh poshtë protokollin 47. Një ruter me 1723 të përcjellë por passthrough PPTP të fikur prodhon pikërisht atë model: shtrëngimi i dorës TCP përfundon, pastaj paketat GRE zhduken, kështu që dështimi duket si problem kredencialesh edhe pse nuk u provua asnjë hyrje.

Drejtojeni përcjelljen te adresa aktuale LAN e serverit, aktivizoni passthrough PPTP aty ku ruteri e ofron, dhe provoni përsëri nga i njëjti pikë e jashtme. Kur GRE filtrohet më lart dhe nuk mund ta ndryshoni, SSTP mbi TCP 443 ose L2TP/IPsec mbi UDP 500 dhe 4500 ka shanse më të mira se çdo ndryshim që mund të bëni në anën e Windows.

Gabimi 812 është serveri që refuzon metodën tuaj të vërtetimit

Gabimi 812 kthehet pasi tuneli është lart, prandaj ndihet si problem fjalëkalimi. Serveri refuzon metodën e vërtetimit të negociuar për lidhjen, jo domosdoshmërisht vetë fjalëkalimin. Në klient, hapni zërin VPN, shkoni te skeda e sigurisë, vendosni llojin në Point-to-Point Tunneling Protocol, zgjidhni listën e qartë të protokolleve dhe shënoni Microsoft CHAP versioni 2.

Mund ta lexoni cilësimin aktual pa klikuar nëpër dialog:

$ Get-VpnConnection -Name "Office" | Select-Object -ExpandProperty AuthenticationMethod
MsChapv2

Një server që kërkon MS-CHAP v2 refuzon një klient të lënë në PAP ose në një lloj automatik që negocion diçka më të dobët, dhe gabimi vjen përpara se të vlerësohet ndonjë fjalëkalim përdoruesi. Formati i llogarisë është gjysma tjetër e të njëjtit refuzim. Në një rast Windows dërgoi një identitet llogarie Microsoft në formën MicrosoftAccount\[email protected] ndërsa serveri donte një llogari lokale ose domaini. Shtypja e SERVERNAME\username i tha Windows-it cilën depo llogarish të konsultojë dhe e hoqi gabimin. Shkruani emrin me dorë në vend që një kredencial i ruajtur të përsëritë një format të mëparshëm.

Shkëputjet pas një minute janë një vendim keepalive

Kur tuneli lidhet, kalon pak trafik dhe pastaj shkëputet, shikoni sjelljen e eko LCP të serverit përpara se të prekni klientin. Demon periodikisht i kërkon partnerit të konfirmojë se është ende aty. Nëse brenda buxhetit të konfiguruar vijnë shumë pak përgjigje, sesioni rrëzohet edhe pse përdoruesi ka ende një lidhje funksionale.

Në një server Linux pptpd ato vlera jetojnë në /etc/ppp/options.pptpd, dhe riparimi i zakonshëm është të zgjerohet buxheti, jo të shkurtohet intervali:

# /etc/ppp/options.pptpd
lcp-echo-failure 30
lcp-echo-interval 5
# then
sudo systemctl restart pptpd

Tridhjetë humbje në një interval prej pesë sekondash falin një ndalesë të shkurtër në vend që të shpallin partnerin larguar. Ulja e numrit në një ose dy e kthen dridhjen e zakonshme në një rrugë të përkthyer në shkëputje afërsisht çdo minutë. Nëse serveri juaj është Windows RRAS dhe jo pptpd, shikoni në vend të kësaj afatin e sesionit PPP dhe politikën e shkëputjes në papunësi. Ato jetojnë diku tjetër, dhe redaktimi i një skedari pppd që nuk ekziston nuk do të ndryshojë asgjë.

Nënrrjetat e mbivendosura prishin rrugën e të dhënave

Një tunel PPTP mund të vërtetohet pastër dhe gjithsesi të mos arrijë askund kur të dy vendet përdorin të njëjtin interval privat, për shembull 192.168.1.0/24 në zyrë dhe në shtëpi. Klienti nuk mund të thotë se cilit host i referohet një adresë e caktuar, dhe disa stiva refuzojnë të instalojnë fare rrugën në vend që të zgjedhin një.

Trajtojeni atë si defekt projektimi dhe rinumeroni njërën anë, ose jepini klientit një interval aksesi të përkthyer qëllimisht. Debugimi i klientit PPTP nuk mund të rregullojë një hapësirë adresash që ekziston dy herë, dhe simptoma do të vazhdojë të duket si një shkëputje e rastësishme.

Filloni me fazën që dështoi: GRE për 800, metoda dhe vargu i llogarisë për 812, cilësimet e ekos për një tunel që vdes sipas orarit.