Brak internetu w VPN Windows? Podejrzanym jest pula adresów

Windows pokazuje tunel jako połączony i oznacza go etykietą Brak dostępu do internetu, co ludzie czytają jako osobliwość Windows. To stwierdzenie o tym, co otrzymał klient: brak użytecznej bramy domyślnej, brak działającego resolvera lub brak drogi powrotnej dla adresów wewnątrz tunelu. Gdy serwerem jest Windows Incoming Connection, jedno ustawienie wyjaśnia większość takich zgłoszeń. Etykieta nie jest diagnozą, ale zawęża poszukiwania do trzech miejsc.

Przeczytaj przydział, zanim go zmienisz

Uruchom ipconfig /all na kliencie i znajdź kartę VPN wśród wpisów. Adres, brama domyślna i serwer DNS, które wymienia, to fakty, których potrzebujesz, i często różnią się od tego, co administrator zakłada, że przydzielono.

Trzy wzorce odpowiadają trzem usterkom. Adres w 169.254.0.0/16 oznacza, że klient nie otrzymał niczego i sam przydzielił sobie adres link-local. Prawdopodobny adres bez bramy oznacza, że pulę obsłużono bez opcji dającej klientowi trasę domyślną. Pełny przydział, który mimo to donikąd nie dociera, wskazuje na przekazywanie lub tłumaczenie po stronie serwera.

Zapisz wartości, zanim dotkniesz serwera. Następny krok porównuje je z zakresem, który serwer uważa, że rozdaje, a pamięć to słaby substytut przydziału.

Dlaczego automatyczne przydzielanie może zostawić bez bramy

Wpis Incoming Connections ma własne właściwości IPv4, oddzielne od karty fizycznej. Domyślne ustawienie tam oferuje automatyczne przydzielanie adresów, które opiera się na wbudowanym przydzielaczu połączenia, aby dostarczyć adres, maskę, bramę i DNS.

Na samodzielnej stacji roboczej ten przydzielacz nie ma zakresu, z którego mógłby czerpać, chyba że coś innego na maszynie dostarczy jeden, więc klient może skończyć z adresem link-local lub z adresem, ale bez bramy. Połączenie wydaje się nawiązane, bo łącze się podniosło, podczas gdy konfiguracja za nim jest niepełna.

Dlatego przejście na określony zakres naprawia tak wiele z tych zgłoszeń. Przestajesz prosić usługę, która może nie działać, o wymyślenie przydziału, i zaczynasz sam deklarować przydział.

To samo zamieszanie pojawia się, gdy ktoś oczekuje, że serwer DHCP routera LAN będzie obsługiwał klientów tunelu. Wykrywanie rozgłoszeniowe nie przechodzi przez trasowany tunel, więc ten serwer nigdy nie widzi żądania. Zakładanie odwrotności jest najczęstszą przyczyną obwiniania puli za klienta, który nigdy o nic jej nie poprosił.

Ustaw jawny zakres, który serwer może trasować

Wybierz mały blok w podsieci osiągalnej dla serwera, poza zakresem rozdawanym przez router LAN i poza każdą inną pulą w sieci. Jeśli serwer siedzi na 172.20.10.0/24, a router ma 172.20.10.1, krótki blok przy górze tej podsieci, powiedzmy od 172.20.10.201 do 172.20.10.209, trzyma przydziały tunelu z dala od rozdania, którym router już zarządza.

Wpisz go we właściwościach IPv4 Incoming Connection, połącz klienta ponownie i odczytaj kartę jeszcze raz, zanim zmienisz cokolwiek innego. Drugi odczyt mówi, czy pulą była usterką, czy tylko jedną z kilku.

Te polecenia wypisują wynikową konfigurację i trasy, które klient ma teraz:

ipconfig /all
route print -4
Get-NetIPConfiguration -InterfaceAlias \"Incoming Connection\"

Brama w przydziale powinna być adresem, który posiada serwer, a trasa domyślna klienta powinna na nią wskazywać. Jeśli przydział jest pełny, ale nie istnieje żadna trasa, serwer przydzielił bez wypchnięcia bramy, a ustawienia puli nadal są miejscem do sprawdzenia.

Adres nie jest drogą do internetu

Otrzymanie przydziału tylko przenosi pakiety od klienta do serwera. Aby uzyskać dostęp do internetu, serwer musi przekazywać te pakiety i tłumaczyć je w stronę własnego uplinku, a to osobna konfiguracja z własnymi trybami awarii.

Internet Connection Sharing to skrót. Zamienia kartę skierowaną do internetu we współdzieloną bramę i prowadzi własną adresację, co może przepisać adres tej karty i pozostawić istniejącą regułę NAT wskazującą wartość, która już nie istnieje. Zapisz oryginalne ustawienia przed włączeniem.

Alternatywa trasowana utrzymuje adresację stabilną i prosi o jawne skonfigurowanie przekazywania i tłumaczenia. Żadne podejście nie jest błędne; mieszanie ich do połowy daje tunel z przydziałem i bez wyjścia, a to dokładnie objaw, od którego zacząłeś. Wybierz jeden model i dokończ go, zanim dodasz drugi.

Najpierw wyklucz drogę zewnętrzną

Żadna pula nie pomoże, jeśli tunel nigdy nie powstanie. Protokół decyduje, co musi nieść droga: PPTP chce TCP 1723 i GRE, czyli protokołu IP 47, a nie portu; L2TP/IPsec chce UDP 1701 plus 500 i 4500; SSTP chce TCP 443.

Router, który przekazuje port, ale nie protokół, tworzy próbę połączenia, która nigdy się nie uwierzytelnia. To inna awaria niż tunel, który powstaje, a potem donikąd nie dociera, i obu nie należy diagnozować razem.

Testuj z tej samej sieci LAN i z sieci zdalnej. Jeśli próba z LAN działa, a zdalna nigdy nie dociera do uwierzytelnienia, problemem jest droga zewnętrzna. Jeśli obie się uwierzytelniają i tylko zdalny klient nie ma internetu, wróć do puli i wyjścia.