Chybí průchod PPTP: oprava chyby 807 ve Windows VPN

Přesměrování TCP 1723 často otevře první část PPTP a zbytek nechá rozbitý, takže Windows při pokusu stále vrací chybu 807. Další instinkt je přidat pravidlo pro port 47, a právě tento krok zabere celé odpoledne: GRE je číslo protokolu v IP hlavičce, ne port, který by přesměrovávací tabulka dokázala porovnat. Dokud router protokol 47 nepropustí a nepřipoutá ho ke stejnému volání, tunel nemůže začít. Následující části oba kanály oddělují a pak je zkoušejí jeden po druhém.

Tabulka portů nemá řádek pro číslo protokolu

PPTP používá dvě konverzace, které selhávají různým způsobem. Ta na TCP 1723 zahajuje volání, předává informace o spoji a ukončuje ho, když se uživatel odpojí. Datová strana běží uvnitř GRE, které IP hlavička označuje číslem protokolu 47, a uvnitř tohoto tunelu PPP vyjednává spoj, zatímco MS-CHAPv2 ověřuje přihlašovací údaje.

Protože GRE nenese žádnou transportní hlavičku, nevykazuje žádné porty, takže pravidlo napsané pro porty nemá co porovnat. Router, který přesměrovává 1723, vytvoří mapování pro tuto TCP relaci a tím skončí. Firmware, který zvládá druhou polovinu, tuto funkci nazývá průchod PPTP nebo PPTP ALG, a některý firmware nenabízí ani jedno a mezeru nikdy nezmiňuje. Popisek u zaškrtávacího pole je méně důležitý než to, zda je protokol 47 vůbec rozpoznán.

Co Windows hlásí, když datová cesta zemře

Chyba 807 říká, že připojení nebylo možné dokončit, což v praxi znamená, že volání dorazilo na server a datový kanál se nezvedl. Je to verdikt o transportu, ne o účtu. Chyba 691 je ta, která ukazuje na přihlašovací údaje nebo na nesoulad autentizačního protokolu, takže vás pošle docela jinam.

Pracujte na transportu, než se dotknete hesla. Změna přihlašovacích údajů při honbě za 807 nechá skutečnou závadu na místě a další pokus udělá hůř čitelným.

Proč druhý klient rozbije fungující tunel

Bez portů, které by je odlišily, nedokáže zařízení NAT oddělit dva klienty PPTP tak, jak odděluje dvě relace HTTPS. Proto mnohá spotřebitelská zařízení povolují jedno volání PPTP a sledují ho podle zdrojové adresy. Notebook, který fungoval sám, přestane dokončovat, jakmile vytočí druhý stroj, a z pohledu klienta selhání vypadá náhodně. Tento vzorec patří firmwaru a žádná změna profilu ho neovlivní.

Sledujte tabulku spojení, zatímco oba klienti vytáčejí. Pokud mapování drží vždy jen první hostitel, router dosáhl hranice toho, co podporuje, a žádné nastavení na klientu s tím nepohne.

Dokažte, která polovina selhává

Než na routeru cokoli změníte, ověřte, že TCP 1723 dorazí, protože tato odpověď určuje, kterou polovinu testujete. Spusťte tyto příkazy z klienta Windows proti vlastnímu názvu serveru. První vypíše, zda port odpověděl, a druhý volá bez dialogu, což činí opakované pokusy srovnatelnými.

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

Pravdivý výsledek testu portu znamená, že řídicí kanál je otevřený a GRE je zbývající podezřelý. Nepravdivý výsledek znamená, že je rozbité směrování, filtr nebo přesměrování, a žádná změna GRE to nezachrání. Datovou stranu je třeba sledovat tam, kde je vidět, na serveru nebo na routeru.

tcpdump -ni any proto 47

Ekvivalentem ve Wiresharku je zobrazovací filtr ip proto 47, který se snáze předá někomu, komu není příjemný příkazový řádek. GRE, které dorazí, aniž by cokoli odešlo v odpovědi, znamená, že je třeba opravit zpáteční cestu.

Co chybu skutečně opraví

Tam, kde router nastavení zpřístupňuje, zapněte průchod PPTP, nebo povolte protokol 47 výslovně na firmwaru, který přijímá pravidla. Na RouterOS pravidlo přesměrování porovnává protokol přímo, což přesměrování založené na portech nikdy nedokázalo. Spotřebitelský firmware obvykle skrývá stejné rozhodnutí za zaškrtávacím polem, někdy v nastavení zabezpečení, ne v přesměrování portů. Pokud taková kontrola neexistuje, nic na klientu to nenahradí.

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

Nahradit PPTP je druhá možnost a často ta levnější. Router, který VPN sám ukončí, se vyhne dvojímu NAT pro příchozí klienty a protokol, který NAT založený na portech už zvládá, žádný průchod nepotřebuje: OpenVPN přes UDP, SSTP přes TCP 443 nebo L2TP/IPsec s NAT-T, které zabaluje ESP do UDP 4500. PPTP také závisí na MS-CHAPv2, jehož zdokumentované slabiny z něj dělají špatnou volbu pro nové nasazení i poté, co chyba zmizí.

Zapište, které pravidlo udělalo rozdíl, protože stejné místo narazí na stejný limit, až druhý uživatel požádá o přístup. Oprava na úrovni protokolu patří do síťových poznámek, kde se podívá další inženýr.