Përcjellja e TCP 1723 shpesh pastron pjesën e parë të PPTP dhe e lë pjesën tjetër të prishur, ndaj Windows kthen përsëri gabimin 807 në tentativë. Instinkti tjetër është të shtohet një rregull për portën 47, dhe pikërisht ky hap humb një pasdite: GRE është numër protokolli në kokën IP, jo një port që një tabelë përcjelljeje mund të përputhë. Derisa ruteri ta kalojë protokollin 47 dhe ta lidhë me të njëjtën thirrje, tuneli nuk mund të nisë. Seksionet më poshtë i ndajnë dy kanalet, pastaj i provojnë një nga një.

Tabela e portave nuk ka rresht për numrin e protokollit

PPTP përdor dy biseda që dështojnë në mënyra të ndryshme. Ajo në TCP 1723 e nis thirrjen, kalon informacionin e lidhjes dhe e mbyll kur përdoruesi shkëputet. Ana e ngarkesës ecën brenda GRE, të cilin koka IP e etiketon me numrin e protokollit 47, dhe brenda atij tuneli PPP negocion lidhjen ndërsa MS-CHAPv2 verifikon kredencialet.

Meqë GRE nuk mbart kokë transporti, nuk ekspozon porta, ndaj një rregull i shkruar për porta nuk ka me çfarë të përputhet. Një ruter që përcjell 1723 krijon një hartë për atë sesion TCP dhe ndalet aty. Firmware-i që trajton gjysmën e dytë e quan funksionin PPTP passthrough ose PPTP ALG, dhe disa firmware nuk ofrojnë asnjërën dhe nuk e përmendin kurrë boshllëkun. Etiketa në kutinë e zgjedhjes ka më pak rëndësi sesa fakti nëse protokolli 47 njihet fare.

Çfarë raporton Windows kur vdes rruga e të dhënave

Gabimi 807 thotë se lidhja nuk mund të përfundohej, që në praktikë do të thotë se thirrja arriti serverin dhe kanali i të dhënave nuk u ngrit. Është një verdikt për transportin, jo për llogarinë. Gabimi 691 është ai që tregon kredencialet ose një mospërputhje të protokollit të vërtetimit, ndaj të dërgon diku krejt tjetër.

Punoni në transport përpara se të prekni fjalëkalimin. Ndryshimi i kredencialeve për të ndjekur 807 e lë defektin e vërtetë në vend dhe e bën tentativën tjetër më të vështirë për t'u lexuar.

Pse një klient i dytë prish një tunel që punon

Pa porta për t'i dalluar, një pajisje NAT nuk mund të ndajë dy klientë PPTP ashtu siç ndan dy sesione HTTPS. Prandaj shumë pajisje konsumatori lejojnë një thirrje të vetme PPTP dhe e ndjekin sipas adresës burimore. Një laptop që punonte vetëm ndalon së përfunduari kur një makinë e dytë hap linjë, dhe nga ana e klientit dështimi duket i rastësishëm. Ky model i përket firmware-it dhe asnjë ndryshim profili nuk e ndryshon.

Vëzhgo tabelën e lidhjeve ndërsa të dy klientët hapin linjë. Nëse vetëm hosti i parë mban gjithmonë një hartë, ruteri ka arritur kufirin e asaj që mbështet dhe asnjë cilësim nga ana e klientit nuk e lëviz.

Provoni cila gjysmë dështon

Konfirmoni se TCP 1723 arrin përpara se të ndryshoni çfarëdo në ruter, sepse ajo përgjigje vendos cilën gjysmë po provoni. Ekzekutojini nga klienti Windows kundër emrit tuaj të serverit. I pari shtyp nëse porta u përgjigj, dhe i dyti hap linjë pa dialog, gjë që i bën tentativat e përsëritura të krahasueshme.

Test-NetConnection vpn.example.com -Port 1723
rasdial "Work VPN"

Një rezultat i vërtetë në provën e portës do të thotë se kanali i kontrollit është i hapur dhe GRE është i dyshuari i mbetur. Një rezultat i rremë do të thotë se rrugëtimi, një filtër ose përcjellja është prishur, dhe asnjë ndryshim GRE nuk e shpëton. Ana e të dhënave duhet vëzhguar aty ku mund të shihet, në fundin e serverit ose në ruter.

tcpdump -ni any proto 47

Ekuivalenti në Wireshark është filtri i ekranit ip proto 47, i cili është më i lehtë për t'i dhënë dikujt që nuk është i rehatshëm në shell. GRE që arrin ndërsa asgjë nuk del si përgjigje do të thotë se rruga e kthimit duhet rregulluar.

Çfarë e rregullon vërtet gabimin

Aty ku ruteri e ekspozon cilësimin, aktivizoni PPTP passthrough, ose lejoni shprehimisht protokollin 47 në firmware-in që pranon rregulla. Në RouterOS rregulli forward përputh protokollin drejtpërdrejt, gjë që një përcjellje e bazuar në porta nuk mund ta bënte kurrë. Firmware-i i konsumatorit zakonisht e fsheh të njëjtin vendim pas një kutie zgjedhjeje, ndonjëherë nën cilësimet e sigurisë dhe jo nën përcjelljen e portave. Nëse një kontroll i tillë nuk ekziston, asgjë në klient nuk e kompenson.

/ip firewall filter add chain=forward protocol=gre action=accept
/ip firewall filter print where protocol=gre

Zëvendësimi i PPTP është opsioni tjetër dhe shpesh më i liri. Një ruter që e përfundon vetë VPN-in shmang NAT të dyfishtë për klientët hyrës, dhe një protokoll që NAT i bazuar në porta tashmë trajton nuk ka nevojë fare për passthrough: OpenVPN mbi UDP, SSTP mbi TCP 443, ose L2TP/IPsec me NAT-T që e mbështjell ESP në UDP 4500. PPTP varet gjithashtu nga MS-CHAPv2, dobësitë e dokumentuara të të cilit e bëjnë një zgjedhje të dobët për një vendosje të re edhe pasi gabimi të pastrohet.

Shkruani cili rregull bëri diferencën, sepse i njëjti vend do të përballet me të njëjtin kufi kur përdoruesi i dytë kërkon akses. Një rregullim në nivel protokolli i takon shënimeve të rrjetit, ku do të shikojë inxhinieri i ardhshëm.

Artikuj të ngjashëm