PPTP przez hotspot: TCP 1723 to tylko połowa

Przejdź przez testy po kolei: czy otwiera się połączenie sterujące, czy GRE przetrwa ścieżkę, czy serwer przyjmie połączenie i czy uwierzytelnianie się zakończy. Klient PPTP potrzebuje zarówno sesji TCP na 1723, jak i ścieżki GRE niosącej dane, a hotspot może przepuścić jedno i zgubić drugie. Wykonanie ich po kolei mówi, którą granicę badać, zamiast zgadywać. Numery błędów Windows nie robią tego za ciebie.

GRE to protokół IP 47. To nie port 47 TCP ani UDP, i ta różnica wyjaśnia większość zamieszania wokół zapór ogniowych.

Dwie ścieżki, jedno połączenie

Połączenie sterujące to zwykła sesja TCP do portu docelowego 1723, którą większość sieci przepuszcza bez skargi. Ścieżka danych to GRE, protokół 47, a zapora, która pozwala na pierwsze, może w ogóle nie wiedzieć o drugim. Ta kombinacja daje klienta, który wygląda, jakby się zaczynał, a potem nic nie niesie, czyli znacznie mniej informacyjny objaw niż odrzucone połączenie. Sprawdź obie ścieżki osobno, zanim wyciągniesz jakikolwiek wniosek o operatorze.

Tłumaczenie dokłada własny wymóg. Bramy współdzielące port często potrzebują ALG rozumiejącego PPTP, aby przepisać identyfikatory połączenia wraz z adresami, a bez tego można uszkodzić sesję w sposób wyglądający jak utrata pakietów. Takie zachowanie jest częste, ale zależy od implementacji, więc każdy limit producenta traktuj jako przykład, a nie cechę każdego hotspotu.

Hotspot dodaje dwie kolejne granice

Ruch klienta zwykle przechodzi przez własny NAT udostępniania telefonu, a następnie tłumaczenie na poziomie operatora, zanim dotrze do serwera. Reguła na routerze biurowym nie naprawi urządzenia pośredniego należącego do kogoś innego, dlatego przekierowanie portów po stronie domu rzadko pomaga. Klient wychodzący nie potrzebuje też otwartego portu wejściowego; odpowiedzi na przetłumaczone połączenie wracają przez stan utworzony przez bramę. Serwer hostowany za NAT ma zupełnie inny zestaw wymagań.

Pozycja menu o nazwie PPTP passthrough, tam gdzie istnieje, określa, jak to urządzenie obsługuje ten protokół. To nie ta sama funkcja co hostowanie VPN na telefonie albo bezwarunkowe przekazywanie każdego protokołu, a jej włączenie nie jest ogólnym pozwoleniem na przepuszczanie GRE.

Czytaj 807 jako przerwanie, nie wyrok

Windows zgłasza 807 jako przerwane połączenie, co opisuje wynik, a nie przyczynę. Jego tabela błędów traktuje 806 osobno jako kategorię związaną z GRE, i tę różnicę warto znać przed budowaniem teorii. Żaden z tych numerów nie ujawnia, czy operator filtrował protokół 47, czy serwerowi skończyła się wydajność albo czy dane logowania były poprawne. Błąd mówi, że sesja się skończyła; ścieżka mówi gdzie.

Test przeglądarki, który udaje się na hotspocie, dowodzi tylko, że zwykła ścieżka aplikacji działa. O GRE nie mówi nic.

Wyizoluj etap, który zawiódł

Trzymaj laptop, serwer i profil bez zmian, a potem zmień tylko sieć dostępu na inną zatwierdzoną. Jeśli wynik się zmieni, przechwyć wymiany TCP i GRE na granicach, które kontrolujesz, i znajdź najwcześniejszy etap, który nigdy nie następuje: ustanowienie sterowania, przygotowanie połączenia, dostarczenie danych lub uwierzytelnianie PPP. Każdy zostawia inny podpis w zapisie. Porównanie działającej sieci z niedziałającą jest znacznie bardziej pouczające niż ponowne czytanie tekstu błędu.

To wszystko diagnozuje wdrożenie, które już istnieje. To nie argument za stawianiem nowej usługi PPTP, a protokołu nie da się obejść negocjacjami: instalacja innego klienta nie sprawi, że niezmieniony serwer zacznie mówić coś innego.

Dla stałego dostępu uzgodnij wspieraną migrację z właścicielem VPN. Lista kontrolna kończy się decyzją, a nie obejściem.