VPN w Windows pokazuje 255.255.255.255: czy maska jest błędna?
W tunelu punkt-punkt maska hosta jest normalna. Potwierdź model interfejsu, odczytaj trasę dla niedziałającego hosta i oddziel DNS od dostępu do usługi.
Tunel się łączy, otwierasz szczegóły adaptera, a maska pokazuje 255.255.255.255. W porównaniu z 255.255.255.0 sieci LAN biura wygląda to na zepsute i właśnie tam zwykle zaczyna się błąd. W łączu punkt-punkt maska hosta jest prawidłowym opisem lokalnego końca, a zdalne sieci przychodzą jako trasy, a nie jako podłączona podsieć. Poniższa procedura rozdziela oba pytania, abyś nie odbudowywał działającego zakresu DHCP tylko po to, by poprawić wyświetlaną wartość.
Łącze punkt-punkt nie jest segmentem Ethernetu
Interfejs Ethernet potrzebuje maski podsieci, ponieważ każdy adres w tym zakresie jest potencjalnie osiągalny w tym samym kablu. Tunel w stylu PPP ma dokładnie jednego partnera na drugim końcu. Nie ma domeny rozgłoszeniowej, nie ma ARP ani powodu, by adres lokalny opisywał zakres.
Negocjacja adresów dla tego modelu jest zdefiniowana w RFC 1332, która opisuje, jak oba końce uzgadniają swoje adresy. Czego nie robi, to przekazanie klientowi sieci LAN biura jako sieci bezpośrednio podłączonej. Klient dowiaduje się, gdzie jest biuro, instalując trasy przez łącze, i to te trasy decydują o osiągalności.
To nie znaczy, że każda maska, którą zobaczysz, jest poprawna. Błędnie skonfigurowany klient może również wytworzyć dziwne adresowanie. Rzecz jest węższa: maska hosta na tym typie adaptera jest oczekiwana, więc sama w sobie nie jest dowodem usterki.
Krok 1: potwierdź model interfejsu
Spójrz, czym jest adapter, zanim ocenisz, co mówi. Ciąg opisu identyfikuje sterownik, a długość prefiksu przypisanego adresu potwierdza, co wynegocjował klient:
Get-NetAdapter | Select-Object Name,InterfaceDescription,Status,ifIndex
Get-NetIPAddress -InterfaceAlias 'Corp VPN' | Select-Object IPAddress,PrefixLength,PrefixOrigin
Get-NetIPInterface -InterfaceAlias 'Corp VPN' | Select-Object AddressFamily,ConnectionState,NlMtuTrzecie polecenie rozstrzyga większość sporów. Niska maksymalna jednostka transmisji jest charakterystyczna dla łącza kapsułkowanego, podczas gdy wartość podobna do Ethernetu wskazuje na inny model adaptera wirtualnego. Jeśli opis wymienia sterownik PPP lub RAS, a prefiks wynosi 32, widzisz dokładnie opisany powyżej projekt i możesz przestać martwić się maską.
| Observation | What it means | Reasonable next step |
|---|---|---|
| /32 on a PPP or RAS adapter | Point-to-point endpoint addressing | Look at routes, not the mask |
| /32 on an Ethernet-like adapter | Client chose host addressing deliberately | Confirm against the server's push policy |
| Mask differs from the office LAN | Usually irrelevant to reachability | Test the destination instead |
Krok 2: odczytaj trasę dla niedziałającego celu
Osiągalność jest rozstrzygana dla każdego celu i pojedynczy podłączony interfejs nic o tym nie mówi. Zapytaj tabelę routingu wprost o adres, który użytkownik naprawdę próbuje osiągnąć:
Get-NetRoute -InterfaceAlias 'Corp VPN' | Select-Object DestinationPrefix,NextHop,RouteMetric
Find-NetRoute -RemoteIPAddress 10.24.6.15
route print -4Find-NetRoute to bezpośrednia odpowiedź: wskazuje interfejs i adres źródłowy, którego system użyłby dla tego celu. Jeśli zwraca tunel, ruch do tego hosta idzie przez tunel i maska nigdy nie była problemem.
Jeśli zwraca adapter fizyczny, porównaj dwie kandydackie trasy i ich metryki. Bardziej szczegółowa trasa lokalna, pozostałość po innym kliencie lub niższa metryka na ścieżce fizycznej wygrywają ze szeroką trasą tunelu. Widocznym skutkiem jest nieosiągalny zasób, podczas gdy wszystko inne działa. Dłuższe prefiksy zawsze wygrywają, więc zwycięzcą jest często trasa hosta, którą ktoś dodał miesiące temu i zapomniał.
Sprawdź tu także oba kierunki. Trasa do strony serwera jest konieczna, ale niewystarczająca, ponieważ odpowiedź też musi wrócić przez tunel. Gdy jeden host wewnętrzny działa, a inny nie, różnica zwykle tkwi w tej tabeli, a nie w konfiguracji adaptera.
Krok 3: oddziel rozwiązywanie nazw od dostępu do usługi
Aplikacja, która nie otwiera udziału, może zawodzić na jednym z dwóch bardzo różnych etapów. Rozwiąż nazwę, a następnie osiągnij adres. Jeśli pierwsze zawodzi, a drugie działa, tunel jest w porządku, a resolver nie:
Resolve-DnsName files.corp.example.internal
Get-DnsClientServerAddress -InterfaceAlias 'Corp VPN'
Test-NetConnection -ComputerName 10.24.6.15 -Port 445Udany test adresu wraz z nieudanym testem nazwy lokalizuje problem w rozwiązywaniu nazw, a drugie polecenie pokazuje, czy interfejs tunelu w ogóle otrzymał serwer. Wiele klientów wysyła DNS jako część konfiguracji tunelu, a profil, który ignoruje te wysłane opcje, pozostawia komputer z resolverem, który nie widzi strefy prywatnej.
Nie traktuj działającego adresu jako trwałej naprawy. Łączenie się przez adres omija rozwiązywanie nazw i może osłabić weryfikację tożsamości serwera, którą aplikacja wykonałaby inaczej. To regresja bezpieczeństwa przebrana za obejście. Użyj jej do zlokalizowania usterki, a następnie napraw rozwiązywanie nazw.
Wycofanie: nie odbudowuj DHCP z powodu wyświetlanej wartości
Jeśli już zacząłeś zmieniać usługę adresową, zatrzymaj się i sprawdź, czy cokolwiek, co zmieniłeś, jest nośne. Odtworzenie zakresu, ponowne wydanie dzierżaw lub przeniesienie puli zmienia stan, od którego zależą inni klienci, i nic z tego nie jest uzasadnione maską hosta na adapterze punkt-punkt.
Get-DnsClientServerAddress -InterfaceAlias 'Corp VPN'
Find-NetRoute -RemoteIPAddress 10.24.6.15
Test-NetConnection -ComputerName files.corp.example.internal -Port 445Uruchom te trzy po każdej ukierunkowanej zmianie i porównaj z poprzednim uruchomieniem. Przydatnym wynikiem jest udokumentowana ścieżka do zasobu, a nie adapter, którego maska przypomina sieć LAN biura.
Potem zapisz, co maska naprawdę znaczyła, ponieważ następna osoba otworzy ten sam dialog i dojdzie do tego samego błędnego wniosku. Jedno zdanie w notatkach profilu, że tunel jest punkt-punkt, a zdalne podsieci przychodzą jako trasy, oszczędza całe śledztwo następnym razem.