Chyba PPTP 800 versus 812 a výpadky po minutě

Chyba 800, chyba 812 a tunel PPTP, který po minutě umře, jsou tři různé závady. Přiřaďte každý příznak vrstvě, která skutečně selhala.

Tři chybové zprávy od jednoho klienta PPTP obvykle popisují tři různé závady. Chyba 800 znamená, že tunel vůbec nevznikl, chyba 812 znamená, že server odmítl metodu ověřování, a výpadek po minutě je keepalive časovač, který usoudí, že zdravý protějšek zmizel. Každá fáze selhává ze svého důvodu, takže každá potřebuje vlastní kontrolu.

Chyba 800 znamená, že tunel vůbec nevznikl

Windows vyvolá chybu 800, když tunel vůbec nedokáže sestavit, a text o nedostupném serveru nebo nevhodných bezpečnostních parametrech je shrnutí, nikoli diagnóza. PPTP potřebuje od sítě dvě samostatné věci, než se prověří jakýkoli přihlašovací údaj. TCP 1723 nese řídicí kanál a IP protokol 47, GRE, nese zapouzdřený obsah.

Otestujte tu vnější cestu zvenčí své LAN, protože spojení, které funguje v kanceláři, o okraji nic nedokazuje:

$ 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

Pokud 1723 odpovídá a zachytávání zůstane prázdné, zatímco se klient snaží připojit, cesta zahazuje protokol 47. Router s přesměrovaným 1723, ale vypnutým průchodem PPTP dává přesně takový obraz: TCP handshake se dokončí, pak pakety GRE zmizí, takže porucha vypadá jako problém s přihlašovacími údaji, i když žádný pokus o přihlášení neproběhl.

Nasměrujte přesměrování na aktuální adresu serveru v LAN, zapněte průchod PPTP tam, kde ho router nabízí, a zkuste to znovu ze stejného vnějšího místa. Když je GRE filtrován výše v síti a nemůžete to změnit, má SSTP přes TCP 443 nebo L2TP/IPsec přes UDP 500 a 4500 lepší šanci než jakákoli změna na straně Windows.

Chyba 812 je odmítnutí vaší metody ověřování serverem

Chyba 812 se vrací poté, co je tunel nahoře, a proto to vypadá jako problém s heslem. Server odmítá metodu ověřování vyjednanou pro spojení, ne nutně samotné heslo. Na klientovi otevřete položku VPN, přejděte na kartu zabezpečení, nastavte typ na Point-to-Point Tunneling Protocol, zvolte explicitní seznam protokolů a zaškrtněte Microsoft CHAP verze 2.

Aktuální nastavení můžete přečíst, aniž byste proklikávali dialog:

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

Server, který vyžaduje MS-CHAP v2, odmítá klienta ponechaného na PAP nebo na automatickém typu, který vyjednává něco slabšího, a chyba dorazí dříve, než se vyhodnotí jakékoli uživatelské heslo. Formát účtu je druhá polovina stejného odmítnutí. V jednom případě Windows poslal identitu účtu Microsoft ve tvaru MicrosoftAccount\[email protected], zatímco server chtěl místní nebo doménový účet. Zapsání SERVERNAME\username řeklo Windows, které úložiště účtů má použít, a chybu odstranilo. Zadejte jméno ručně, místo abyste nechali uložený údaj přehrát předchozí formát.

Výpadky po minutě jsou rozhodnutí keepalive

Když se tunel připojí, propustí trochu provozu a pak se odpojí, podívejte se na chování LCP echa na serveru, než sáhnete na klienta. Démon pravidelně žádá protějšek o potvrzení, že je stále tam. Pokud v nastaveném rozpočtu dorazí příliš málo odpovědí, relace se ukončí, i když uživatel má stále funkční spojení.

Na Linux serveru pptpd tyto hodnoty žijí v /etc/ppp/options.pptpd a obvyklá oprava je rozpočet rozšířit, ne zkrátit interval:

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

Třicet minutí při intervalu pěti sekund odpustí krátké zaseknutí, místo aby protějšek prohlásilo za zmizelý. Snížení počtu na jeden nebo dva promění běžné chvění na přeložené cestě v odpojení zhruba každou minutu. Pokud je váš server Windows RRAS a ne pptpd, podívejte se místo toho na časový limit relace PPP a zásadu odpojení při nečinnosti. Ty žijí jinde a úprava souboru pppd, který neexistuje, nic nezmění.

Překrývající se podsítě rozbíjejí datovou cestu

Tunel PPTP se může čistě ověřit a přesto nikam nedojít, když obě místa používají stejný privátní rozsah, například 192.168.1.0/24 v kanceláři i doma. Klient nemůže říct, ke kterému hostiteli daná adresa patří, a některé sítě odmítají trasu vůbec nainstalovat, místo aby si jednu vybraly.

Berte to jako návrhovou vadu a přečíslujte jednu stranu, nebo klientovi dejte záměrně přeložený rozsah přístupu. Ladění klienta PPTP nemůže opravit adresní prostor, který existuje dvakrát, a příznak bude dál vypadat jako náhodný výpadek.

Začněte fází, která selhala: GRE pro 800, metoda a řetězec účtu pro 812, nastavení echa pro tunel, který umírá podle plánu.

Související články