PPTP-deurlaat ontbreek: herstel Windows VPN-fout 807

Die deurvoer van TCP 1723 maak dikwels die eerste deel van PPTP oop en laat die res stukkend, so Windows gee steeds fout 807 by die poging. Die volgende instink is om ’n reël vir poort 47 by te voeg, en dit is juis die stap wat ’n middag mors: GRE is ’n protokolnommer in die IP-kop, nie ’n poort wat ’n deurvoertabel kan pas nie. Totdat die router protokol 47 deurlaat en dit aan dieselfde oproep koppel, kan die tonnel nie begin nie. Die afdelings hieronder skei die twee kanale en toets hulle dan een vir een.

’n Poorttabel het geen ry vir ’n protokolnommer nie

PPTP gebruik twee gesprekke wat op verskillende maniere faal. Die een op TCP 1723 begin die oproep, gee skakelinligting deur en breek dit af wanneer die gebruiker ontkoppel. Die vragkant loop binne GRE, wat die IP-kop met protokolnommer 47 merk, en binne daardie tonnel onderhandel PPP die skakel terwyl MS-CHAPv2 die geloofsbriewe nagaan.

Omdat GRE geen vervoerkop dra nie, het dit geen poorte nie, so ’n reël wat vir poorte geskryf is, het niks om te pas. ’n Router wat 1723 deurvoer, skep ’n kartering vir daardie TCP-sessie en stop daar. Fermware wat die tweede helfte hanteer, noem die funksie PPTP-deurlaat of ’n PPTP-ALG, en sommige fermware bied nie een van die twee nie en noem die gaping nooit. Die etiket op die merkblokkie maak minder saak as of protokol 47 hoegenaamd erken word.

Wat Windows rapporteer wanneer die datapad sterf

Fout 807 sê die verbinding kon nie voltooi word nie, wat in die praktyk beteken die oproep het die bediener bereik en die datakanaal het nie opgekom nie. Dit is ’n uitspraak oor die vervoer, nie ’n uitspraak oor die rekening nie. Fout 691 is die een wat na geloofsbriewe of na ’n wanaanpassing van die verifikasieprotokol wys, so dit stuur jou heeltemal elders.

Werk aan die vervoer voordat jy aan die wagwoord raak. Om geloofsbriewe te verander om 807 te jaag, laat die werklike fout in plek en maak die volgende poging moeiliker om te lees.

Waarom ’n tweede kliënt ’n werkende tonnel breek

Sonder poorte om hulle te onderskei, kan ’n NAT-toestel nie twee PPTP-kliënte skei soos dit twee HTTPS-sessies skei nie. Baie verbruikerstoestelle laat daarom een PPTP-oproep toe en hou dit by bronadres dop. ’n Skootrekenaar wat alleen gewerk het, hou op om te voltooi sodra ’n tweede masjien uitbel, en van die kliënt se kant lyk die fout willekeurig. Daardie patroon hoort by die fermware, en geen profielverandering sal dit verander nie.

Kyk na die verbindingstabel terwyl albei kliënte uitbel. As net die eerste gasheer ooit ’n kartering hou, het die router die grens van sy vermoë bereik en geen kliëntinstelling sal dit skuif nie.

Bewys watter helfte faal

Bevestig dat TCP 1723 aankom voordat jy enigiets op die router verander, want daardie antwoord bepaal watter helfte jy toets. Voer hierdie opdragte vanaf die Windows-kliënt teen jou eie bedienernaam uit. Die eerste druk of die poort geantwoord het, en die tweede skakel sonder ’n dialoog, wat herhaalde pogings vergelykbaar maak.

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

’n Ware resultaat op die poorttoets beteken die beheerkanaal is oop en GRE is die oorblywende verdagte. ’n Valse resultaat beteken roetering, ’n filter of die deurvoer is stukkend, en geen GRE-verandering sal dit red nie. Die datakant moet dopgehou word waar dit gesien kan word, by die bediener of by die router.

tcpdump -ni any proto 47

Die Wireshark-ekwivalent is die vertoonfilter ip proto 47, wat makliker is om aan iemand te gee wat nie gemaklik met ’n opdragreël is nie. GRE wat aankom sonder dat iets in antwoord uitgaan, beteken die terugpad moet reggemaak word.

Wat die fout werklik regstel

Waar die router die instelling blootstel, aktiveer PPTP-deurlaat, of laat protokol 47 uitdruklik toe op fermware wat reëls aanvaar. Op RouterOS pas die deurvoerreël die protokol direk, wat ’n poortgebaseerde deurvoer nooit kon doen nie. Verbruikerfermware versteek gewoonlik dieselfde besluit agter ’n merkblokkie, soms onder sekuriteitsinstellings eerder as onder poortdeurvoer. As daar geen sulke beheer bestaan nie, sal niks op die kliënt dit vergoed nie.

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

Om PPTP te vervang is die ander opsie en dikwels die goedkoopste. ’n Router wat die VPN self termineer, vermy dubbele NAT vir inkomende kliënte, en ’n protokol wat ’n poortgebaseerde NAT al hanteer, het glad geen deurlaat nodig nie: OpenVPN oor UDP, SSTP oor TCP 443, of L2TP/IPsec met NAT-T wat ESP in UDP 4500 toedraai. PPTP hang ook van MS-CHAPv2 af, en die gedokumenteerde swakhede daarvan maak dit ’n swak keuse vir ’n nuwe ontplooiing, selfs nadat die fout verdwyn het.

Skryf neer watter reël die verskil gemaak het, want dieselfde werf sal dieselfde beperking teëkom wanneer die tweede gebruiker toegang vra. ’n Regstelling op protokolvlak hoort in die netwerknotas, waar die volgende ingenieur sal kyk.