Błąd PPTP 800 kontra 812 i zerwania po minucie

Trzy komunikaty błędu z jednego klienta PPTP zwykle opisują trzy różne usterki. Błąd 800 oznacza, że tunel nigdy nie powstał, błąd 812 oznacza, że serwer odrzucił metodę uwierzytelniania, a zerwanie po minucie to timer keepalive, który uznaje, że zdrowy partner zniknął. Każdy etap zawodzi z własnego powodu, więc każdy potrzebuje własnego sprawdzenia.

Błąd 800 oznacza, że tunel nigdy nie powstał

Windows zgłasza błąd 800, gdy nie potrafi w ogóle zbudować tunelu, a tekst o nieosiągalnym serwerze lub nieodpowiednich parametrach bezpieczeństwa jest podsumowaniem, nie diagnozą. PPTP potrzebuje dwóch osobnych rzeczy z sieci, zanim sprawdzony zostanie jakikolwiek dowód tożsamości. TCP 1723 przenosi kanał sterujący, a protokół IP 47, GRE, przenosi enkapsulowany ładunek.

Przetestuj tę zewnętrzną ścieżkę spoza własnego LAN, bo połączenie działające w biurze niczego nie dowodzi o krawędzi:

$ 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

Jeśli 1723 odpowiada, a przechwycenie pozostaje puste, gdy klient próbuje się połączyć, ścieżka zrzuca protokół 47. Router z przekierowanym 1723, ale wyłączonym passthrough PPTP daje dokładnie taki wzorzec: uzgadnianie TCP kończy się, potem pakiety GRE znikają, więc awaria wygląda jak problem z poświadczeniami, choć nie podjęto próby logowania.

Skieruj przekierowanie na bieżący adres LAN serwera, włącz passthrough PPTP tam, gdzie router go oferuje, i spróbuj ponownie z tego samego punktu zewnętrznego. Gdy GRE jest filtrowany wyżej i nie możesz tego zmienić, SSTP przez TCP 443 lub L2TP/IPsec przez UDP 500 i 4500 ma lepsze szanse niż jakakolwiek zmiana po stronie Windows.

Błąd 812 to odrzucenie twojej metody uwierzytelniania przez serwer

Błąd 812 wraca po podniesieniu tunelu, dlatego wygląda jak problem z hasłem. Serwer odrzuca metodę uwierzytelniania uzgodnioną dla połączenia, a niekoniecznie samo hasło. Na kliencie otwórz wpis VPN, przejdź do karty zabezpieczeń, ustaw typ na Point-to-Point Tunneling Protocol, wybierz jawną listę protokołów i zaznacz Microsoft CHAP w wersji 2.

Bieżące ustawienie możesz odczytać bez klikania w oknie dialogowym:

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

Serwer wymagający MS-CHAP v2 odrzuca klienta pozostawionego na PAP lub na typie automatycznym, który negocjuje coś słabszego, a błąd pojawia się, zanim ocenione zostanie jakiekolwiek hasło użytkownika. Format konta to druga połowa tego samego odrzucenia. W jednym przypadku Windows wysłał tożsamość konta Microsoft w postaci MicrosoftAccount\[email protected], podczas gdy serwer chciał konta lokalnego lub domenowego. Wpisanie SERVERNAME\username powiedziało Windows, którego magazynu kont użyć, i usunęło błąd. Wpisz nazwę ręcznie, zamiast pozwalać zapisanym poświadczeniom powtórzyć poprzedni format.

Zerwania po minucie to decyzja keepalive

Gdy tunel się łączy, przepuszcza trochę ruchu i potem się rozłącza, spójrz na zachowanie echa LCP serwera, zanim dotkniesz klienta. Demon okresowo prosi partnera o potwierdzenie, że wciąż tam jest. Jeśli w ustalonym budżecie przyjdzie zbyt mało odpowiedzi, sesja jest zrywana, mimo że użytkownik wciąż ma działające łącze.

Na serwerze Linux pptpd te wartości żyją w /etc/ppp/options.pptpd, a zwykła naprawa to poszerzenie budżetu, nie skrócenie interwału:

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

Trzydzieści pominięć przy interwale pięciu sekund wybacza krótkie zacięcie, zamiast ogłaszać partnera nieobecnym. Zmniejszenie liczby do jednego lub dwóch zamienia zwykły jitter na tłumaczonej ścieżce w rozłączenie mniej więcej co minutę. Jeśli twój serwer to Windows RRAS, a nie pptpd, patrz zamiast tego na limit czasu sesji PPP i politykę rozłączania przy bezczynności. One żyją gdzie indziej, a edycja nieistniejącego pliku pppd niczego nie zmieni.

Nakładające się podsieci psują ścieżkę danych

Tunel PPTP może się czysto uwierzytelnić i mimo to nigdzie nie dotrzeć, gdy obie lokalizacje używają tego samego zakresu prywatnego, na przykład 192.168.1.0/24 w biurze i w domu. Klient nie potrafi powiedzieć, do którego hosta odnosi się dany adres, a niektóre stosy odmawiają w ogóle zainstalowania trasy, zamiast wybrać jedną.

Potraktuj to jako wadę projektową i przenumeruj jedną stronę albo daj klientowi celowo przetłumaczony zakres dostępu. Debugowanie klienta PPTP nie naprawi przestrzeni adresowej, która istnieje dwa razy, a objaw nadal będzie wyglądał jak losowe zerwanie.

Zacznij od etapu, który zawiódł: GRE dla 800, metoda i ciąg konta dla 812, ustawienia echa dla tunelu, który umiera zgodnie z harmonogramem.