Laptop udostępnia swoje Wi-Fi, host przegląda przez tunel bez skarg, a tablet w tym udostępnieniu nie dociera donikąd. Host przestał być tylko klientem w chwili, gdy włączono udostępnianie: jest teraz routerem, a przekazywane pakiety napotykają inny zestaw reguł. To, co działa na hoście, nic nie mówi o urządzeniu za nim. Uruchom testy z klienta poniżej i rozróżnienie przestaje być teoretyczne.

Sukces hosta niczego nie dowodzi

Udostępnianie połączenia daje jednej maszynie cztery zadania: przydzielanie adresów, przekazywanie, tłumaczenie i filtrowanie. Klient VPN, który chroni ruch generowany lokalnie, może uznawać ruch przekazywany za poza swoim zakresem, albo celowo go blokować jako wyciek. Żadne z tych zachowań nie jest błędem i żadne nie jest opisane na ekranie, na którym włączono udostępnianie. Tylko test poniżej mówi, które masz.

Wiele klientów przekazuje tylko ruch hosta i nic więcej, więc sprawdź sekcję udostępniania w dokumentacji klienta, zamiast ufać, że tunel będzie routował za tablet. Widocznym objawem jest urządzenie, które się łączy, dostaje adres, a potem zawodzi przy pierwszym żądaniu. Klient, który odmawia przekazywania, nadal wygląda na hoście całkowicie zdrowo.

Który adapter jest udostępniany, który obsługuje klientów

Zapisz oba adaptery, bo mają różne adresy i różne filtry, a zmiana na niewłaściwym wyjaśnia wiele mylących wyników. Host udostępniania zwykle zajmuje stały adres po stronie niższej i uruchamia tam małą usługę DHCP i DNS. Windows trzyma przekazywanie na adapter, a nie globalnie, więc stan trzeba czytać interfejs po interfejsie.

Get-NetAdapter | Where-Object Status -eq 'Up' | Select-Object Name,InterfaceIndex,LinkSpeed
Get-NetIPAddress -AddressFamily IPv4 | Select-Object InterfaceAlias,IPAddress,PrefixLength
Get-NetIPInterface | Select-Object InterfaceAlias,Forwarding,ConnectionState
Get-NetConnectionProfile

Jeśli przekazywanie na udostępnianym adapterze jest wyświetlane jako Wyłączone, nic poniżej nie będzie działać, cokolwiek zrobi tunel. Włącz je tylko na maszynie, której zasady na to pozwalają dla innych urządzeń.

Przekazywanie, tłumaczenie i filtrowanie

Przekazywany pakiet musi dotrzeć do tunelu, zostać przetłumaczony na coś, co akceptuje dalsza strona, i wrócić przez to samo tłumaczenie. Każdy z tych trzech etapów może się zepsuć, a każde zepsucie daje ten sam limit czasu przeglądarki. Przechwycenie pakietów, sprawdzenie trasy i log z dalszej strony są warte więcej niż kolejny przegląd okna udostępniania. To, który etap zawodzi, mówi, czyja zmiana jest potrzebna.

Dalsza strona może też potrzebować trasy powrotnej dla udostępnionej podsieci, zakresu, którego serwer VPN nigdy nie widział. Tam, gdzie klient tłumaczy, serwer widzi tylko adres tunelu i trasa powrotna nie jest potrzebna. Tam, gdzie nie tłumaczy, właściciel bramy musi świadomie dodać tę trasę, a to prośba o zmianę, nie ustawienie klienta.

Testy wykonuj na kliencie, nie na hoście

Każdy test wykonuj na kliencie, który zawodzi, a nie na hoście, który działa. Trzymaj adres wyjściowy, odpowiedź resolvera i test aplikacji w tej samej sesji, bo wyniki zebrane w odstępie godziny nic nie mówią o tym, jak te trzy się łączą.

Resolve-DnsName intranet.example.net -Type A
Resolve-DnsName intranet.example.net -Type AAAA
Invoke-RestMethod https://api.ipify.org
Test-NetConnection intranet.example.net -Port 443 -InformationLevel Detailed

Porównaj adres wyjściowy z adresem samego hosta i zanotuj, czy się zgadzają. Inna odpowiedź oznacza, że przekazywana ścieżka omija tunel, co jest kwestią polityki z właścicielem, a nie szybką poprawką. Zgodna odpowiedź obok zawodzącej aplikacji przenosi pracę na rozwiązywanie nazw lub na politykę dalszej strony. Nie zatrzymuj się też na wyniku IPv4: udostępnianie może przejść każdy test IPv4, podczas gdy IPv6 wychodzi innym wyjściem, więc powtórz testy nazw i wyjścia z rekordem AAAA i szczegółowym testem połączenia.

Na maszynie zarządzanej potwierdź, że udostępnianie jest w ogóle dozwolone, bo wystawianie dostępu innemu urządzeniu to decyzja administracyjna, a nie przełącznik wygody. Po każdej obsługiwanej zmianie powtórz testy przy ponownym połączeniu i jeszcze raz podczas awarii. Czyste ponowne połączenie hosta nie przywraca przekazywanej trasy, której klient nigdy nie obsługiwał.

Powiązane artykuły