PPTP 800-as és 812-es hiba, valamint egy perc utáni szakadások

Egy PPTP-kliens három hibaüzenete általában három különböző hibát ír le. A 800-as hiba azt jelenti, hogy az alagút soha nem jött létre, a 812-es hiba azt, hogy a kiszolgáló elutasította a hitelesítési módszert, az egy perc utáni szakadás pedig egy keepalive időzítő, amely úgy dönt, hogy egy egészséges partner eltűnt. Minden szakasz a saját okából hiúsul meg, ezért mindegyiknek saját ellenőrzés kell.

A 800-as hiba azt jelenti, hogy az alagút soha nem jött létre

A Windows akkor jelzi a 800-as hibát, amikor egyáltalán nem tudja felépíteni az alagutat, és az elérhetetlen kiszolgálóról vagy alkalmatlan biztonsági paraméterekről szóló szöveg összefoglaló, nem diagnózis. A PPTP-nek két külön dolgot kell kapnia a hálózattól, mielőtt bármilyen hitelesítő adatot megvizsgálnának. A TCP 1723 viszi a vezérlőcsatornát, és az IP 47-es protokoll, a GRE, viszi a beágyazott hasznos terhet.

Ezt a külső útvonalat a saját LAN-ján kívülről tesztelje, mert az irodában működő kapcsolat semmit nem bizonyít a peremről:

$ 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

Ha az 1723 válaszol, és a rögzítés üres marad, miközben a kliens kapcsolódni próbál, az útvonal eldobja a 47-es protokollt. Az a router, amelyen az 1723 továbbítva van, de a PPTP-átjárás ki van kapcsolva, pontosan ezt a mintát adja: a TCP kézfogás befejeződik, aztán a GRE-csomagok eltűnnek, így a hiba hitelesítő adatok problémájának tűnik, pedig nem történt bejelentkezési kísérlet.

Irányítsa a továbbítást a kiszolgáló jelenlegi LAN-címére, kapcsolja be a PPTP-átjárást ott, ahol a router kínálja, és próbálja újra ugyanabból a külső pontból. Ha a GRE-t feljebb szűrik, és ezt nem tudja megváltoztatni, az SSTP TCP 443 felett vagy az L2TP/IPsec UDP 500 és 4500 felett jobb eséllyel indul, mint bármilyen változtatás a Windows oldalán.

A 812-es hiba a kiszolgáló elutasítása a hitelesítési módszerével szemben

A 812-es hiba azután jön vissza, hogy az alagút felállt, ezért tűnik jelszóproblémának. A kiszolgáló a kapcsolathoz kialkudott hitelesítési módszert utasítja el, nem feltétlenül magát a jelszót. A kliensen nyissa meg a VPN-bejegyzést, lépjen a biztonság lapra, állítsa a típust Point-to-Point Tunneling Protocol értékre, válassza a kifejezett protokollistát, és jelölje be a Microsoft CHAP 2-es verzióját.

Az aktuális beállítást a párbeszédablak végigkattintása nélkül is kiolvashatja:

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

Az MS-CHAP v2-t megkövetelő kiszolgáló elutasítja azt a klienst, amelyet PAP-on vagy olyan automatikus típuson hagytak, amely gyengébbet tárgyal, és a hiba még bármilyen felhasználói jelszó kiértékelése előtt megérkezik. A fiókformátum ugyanennek az elutasításnak a másik fele. Egy esetben a Windows MicrosoftAccount\[email protected] alakú Microsoft-fiók-identitást küldött, miközben a kiszolgáló helyi vagy tartományi fiókot akart. A SERVERNAME\username begépelése megmondta a Windowsnak, melyik fióktárat kérdezze, és eltüntette a hibát. Írja be kézzel a nevet, ahelyett hogy egy mentett hitelesítő adat megismételné a korábbi formátumot.

Az egy perc utáni szakadások keepalive-döntések

Amikor az alagút csatlakozik, átenged egy kis forgalmat, majd bontja a kapcsolatot, nézze meg a kiszolgáló LCP-visszhang viselkedését, mielőtt a klienshez nyúlna. A daemon rendszeresen megkéri a partnert, hogy erősítse meg, még ott van. Ha a beállított kereten belül túl kevés válasz érkezik, a munkamenet lebontásra kerül, pedig a felhasználónak még van működő kapcsolata.

Linux pptpd kiszolgálón ezek az értékek a /etc/ppp/options.pptpd fájlban élnek, és a szokásos javítás a keret szélesítése, nem az intervallum rövidítése:

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

Harminc kihagyás öt másodperces intervallumnál megbocsát egy rövid akadást, ahelyett hogy a partnert eltűntnek nyilvánítaná. Ha a számot egyre vagy kettőre csökkenti, a szokásos remegés egy lefordított útvonalon körülbelül percenkénti bontássá válik. Ha a kiszolgálója Windows RRAS, és nem pptpd, akkor inkább a PPP-munkamenet időtúllépését és a tétlenségi bontási szabályzatot nézze. Azok máshol élnek, és egy nem létező pppd-fájl szerkesztése semmit nem változtat.

Az átfedő alhálózatok megtörik az adatútvonalat

Egy PPTP-alagút tisztán hitelesíthet, és mégis semmit nem érhet el, ha mindkét hely ugyanazt a magán tartományt használja, például 192.168.1.0/24 az irodában és otthon. A kliens nem tudja megmondani, melyik gazdagépre utal egy adott cím, és egyes vermek egyáltalán nem hajlandók telepíteni az útvonalat, ahelyett hogy választanának egyet.

Tekintse ezt tervezési hibának, és számozza újra az egyik oldalt, vagy adjon a kliensnek szándékosan lefordított hozzáférési tartományt. A PPTP-kliens hibakeresése nem tudja megjavítani a kétszer létező címteret, és a tünet továbbra is véletlenszerű szakadásnak fog látszani.

Kezdje a meghibásodott szakasszal: GRE a 800-hoz, a módszer és a fiók-karakterlánc a 812-hez, visszhangbeállítások az ütemterv szerint meghaló alagúthoz.