Dlaczego tabela routingu VPN w Windows pokazuje 0.0.0.0/1 i 128.0.0.0/1

Połącz się z VPN w Windows i otwórz tabelę routingu, a dwa wpisy rzucają się w oczy: 0.0.0.0/1 i 128.0.0.0/1. Nie są literówką i nie zastępują trasy domyślnej. Ich pojawienie się zależy od jednej opcji profilu, a para ta jest sposobem budowania pełnego tunelu, nie funkcją split tunelu. Przeczytaj opcję, prefiks i interfejs razem, zanim zmienisz choć jedną linię.

Co instaluje opcja domyślnej bramy

Opcja profilu, która wysyła wszystko przez tunel, działa przez dodanie tych dwóch prefiksów. Wyłącz opcję, a one znikną, zostawiając trasę obejmującą tylko podsieć przydzieloną adapterowi tunelu. Pole wyboru steruje parą; nie przepisuje jedynej trasy domyślnej. Dlatego tabela po odznaczeniu wygląda jak częściowe przepisanie, a nie usunięcie.

0.0.0.0/1 obejmuje dolną połowę przestrzeni IPv4, a 128.0.0.0/1 górną, więc razem obejmują każdy adres unicast. Każdy z nich jest bardziej szczegółowy niż domyślna trasa 0.0.0.0/0, co oznacza, że dopasowanie najdłuższego prefiksu kieruje zwykły ruch do tunelu, podczas gdy fizyczna trasa domyślna pozostaje tam, gdzie była. Zachowanie tej trasy domyślnej nie jest kosmetyką: pakiety opakowujące zaszyfrowany ładunek są adresowane na publiczny adres serwera i muszą wychodzić przez fizyczny adapter. Zastąp trasę domyślną zamiast ją dzielić, a transport samego tunelu spróbuje wejść do tunelu, co jest pętlą, a nie połączeniem.

Dlatego dosłowna trasa 0.0.0.0/0 wskazująca adapter VPN jest warta zatrzymania. Natywny klient zwykle takiej nie zapisuje, więc ręczna trasa lub konfiguracja innego klienta zmieniła tabelę za Twoimi plecami. Znajdź ją, zanim zaczniesz debugować cokolwiek niżej.

Demontaż jest tańszy niż zachowanie bramy

Demontaż to praktyczny argument za dwoma wpisami zamiast jednego. Klient posiada dokładnie dwie trasy podczas połączenia i usuwa je przy rozłączeniu, zostawiając to, co fizyczny adapter ma w tej chwili. Klient, który zastąpiłby jedyną trasę domyślną, musiałby pamiętać poprzednią bramę, a po zmianie dzierżawy DHCP mógłby przywrócić taką, która już nie istnieje. Dwa własne wpisy nie noszą takiego stanu.

Inni klienci dochodzą do tego samego projektu. Profil OpenVPN z redirect-gateway def1 instaluje te dwa prefiksy zamiast usuwać trasę domyślną, a klient Windows podąża tym samym wzorcem z tego samego powodu routingu.

Dlatego tabela może wyglądać jak pełny tunel, gdy oczekiwałeś podziału. Para jest sposobem budowania pełnego tunelu, a nie dowodem błędu split tunelu. Jeśli profil jest ustawiony na korzystanie ze zdalnej bramy, wszystko jest routowane, cokolwiek jedna lokalna aplikacja jeszcze osiągnie.

Najdłuższy prefiks wygrywa przed jakąkolwiek metryką

Długość prefiksu decyduje o wyszukiwaniu przed każdym innym polem. Metryka tylko rozstrzyga remisy między trasami o identycznym prefiksie, więc wpis /1 bije domyślną /0 nawet gdy jego metryka jest gorsza. Powiązanie z interfejsem decyduje o tym, co zostaje, gdy dwie trasy dzielą prefiks i Windows musi wybrać, który adapter wyśle pakiet.

route print -4
Get-NetRoute -AddressFamily IPv4 | Sort-Object DestinationPrefix
Find-NetRoute -RemoteIPAddress 10.50.5.20

Tabela split tunelu zawiera fizyczną trasę domyślną, dwie półdomyślne, trasę podsieci tunelu i każdy dodany prefiks biurowy. Fizyczna trasa domyślna może mieć niższą lub wyższą metrykę w zależności od klienta i profilu, a dopóki istnieje para /1, ta różnica niczego nie zmienia. Zmienia wszystko w momencie usunięcia pary, i wtedy ujawnia się przestarzała brama lub niewłaściwy interfejs. Czytaj całą tabelę, a nie tę jedną linię, którą spodziewałeś się zmienić.

Wybierz jednego właściciela prefiksu biurowego

Dla split tunelu nazwij tylko prefiks, który musi używać VPN, i wybierz jeden sposób jego posiadania. Kierowanie trasy na przydzielony adres tunelu działa, dopóki adres się nie zmieni, natomiast powiązanie z interfejsem przeżywa zmianę adresu, ale psuje się, gdy indeks zostanie przydzielony ponownie po odbudowie profilu. Cmdlet powiązany z profilem unika obu problemów, kosztem konieczności posiadania profilu.

route -p add 10.50.0.0 mask 255.255.0.0 172.16.8.1
route -p add 10.50.0.0 mask 255.255.0.0 0.0.0.0 IF 31
Add-VpnConnectionRoute -ConnectionName Office -DestinationPrefix 10.50.0.0/16

Cmdlet wiąże prefiks z nazwanym profilem, więc trasa pojawia się wraz z połączeniem i znika wraz z nim, czego chce zarządzany laptop. Trwała trasa przeżywa restarty i przeżywa profil, który ją wywołał, i tak wycofany VPN zostawia wpisy na lata. Wybierz jedną metodę na prefiks i zanotuj wybór, ponieważ trwała trasa plus trasa profilu dla tego samego prefiksu tworzą duplikaty, które przy demontażu trudno rozplątać. Cokolwiek wybierzesz, własność powinna być widoczna w zgłoszeniu, a nie tylko na maszynie.

Własność to pytanie, na które odpowiada ta sekcja, a nie składnia. Dwóch właścicieli jednego prefiksu to tryb awarii, którego warto unikać.

Weryfikuj celem, nie stroną internetową

Testuj cel, który musi przejść przez tunel, a nie stronę internetową raportującą adres wyjściowy. Find-NetRoute zwraca wybraną trasę i adres źródłowy, więc widzisz, czy wygrał prefiks biurowy, czy fizyczna trasa domyślna, a potem otwierasz sam udział.

Find-NetRoute -RemoteIPAddress 10.50.5.20
Get-VpnConnection -Name Office

Strona z adresem wyjściowym to słaba kontrola, ponieważ DNS, IPv6 i proxy przeglądarki mogą każde wysłać to żądanie inną drogą. IPv4 i IPv6 mają też osobne ustawienia w tym samym oknie dialogowym, a wyczyszczenie jednego pola pozostawia drugą rodzinę nietkniętą, więc maszyna z podwójnym stosem może prowadzić IPv6 przez tunel, podczas gdy IPv4 podąża trasą podziału. Sprawdź obie rodziny, zanim nazwiesz profil podzielonym. Jeśli trasa jest poprawna, a usługa nadal zawodzi, pozostałą warstwą jest filtrowanie, a nie routing.

Zapora zarządzana przez klienta może blokować podsieć biurową mimo idealnej tabeli routingu. Ta polityka należy do tego, kto wdrożył profil, a nie do osoby edytującej trasy.