Dlaczego sam route-nopull zostawia serwer plików nieosiągalny
Ignorowanie wypchniętych tras to tylko połowa tunelu dzielonego. Wybierz właściciela trasy, dodaj ręcznie prefiks biura i przetestuj trzy przepływy, zanim uznasz to za naprawione.
Serwer plików otwiera się poprawnie, a rozmowa wideo w sąsiednim oknie zaczyna się zacinąć. Nic nie jest wolne i żaden MTU nie jest zły: klient przyjął listę tras podaną przez serwer, więc każdy pakiet wychodzi teraz przez zaporę biurową. Rozwiązaniem nie jest kolejna flaga strojenia, ale decyzja o tym, kto jest właścicielem tabeli tras klienta. Ta decyzja należy do jednego miejsca, a opisane niżej tryby awarii mówią, które miejsce rzeczywiście wybrałeś.
Zdecyduj, kto jest właścicielem tabeli tras
Możliwych jest trzech właścicieli. Serwer może wypychać trasy i domyślną bramę, a wtedy klient instaluje to, co mu powiedziano, i staje się pełnym tunelem. Profil klienta może przejąć własność, odrzucając wypchnięcia i nosząc własne wiersze tras. Menedżer połączeń na pulpicie też może być właścicielem decyzji poprzez własne właściwości trasy i trasy domyślnej.
Każdy wybór zawodzi inaczej, dlatego warto przeczytać tabelę przed edycją profilu. Wiersz pasujący do twojego objawu to właściciel, którego naprawdę masz.
| Owner | Where it lives | Result |
|---|---|---|
| Server | server config, redirect-gateway, pushed routes | client becomes a full tunnel |
| Profile | route-nopull and its own route lines | tunnel up, office prefix missing |
| Manager | never-default plus its own routes | desktop decides, profile ignored |
Wybierz jeden i zapisz go. Mieszanie dwóch zostawia hosta, którego domyślna ścieżka przeczy własnej dokumentacji, a następny inżynier nie może powiedzieć, która warstwa wygrała. Usuń przegranego jednoznacznie.
route-nopull filtruje wypchnięcia, nie dodaje tras
route-nopull należy do profilu klienta, a jego kolejność w tym pliku nie ma znaczenia, ponieważ odrzuca tylko wartości przychodzące z serwera. Odrzuca wypchnięte trasy, w tym wypchniętą trasę domyślną, podczas gdy tunel nadal podnosi się normalnie.
Konsekwencja, którą ludzie przeoczają, to fakt, że wypchnięte opcje DHCP odchodzą razem z nimi. Ustawienia DNS wysyłane przez serwer też są odrzucane, więc nazwy wewnętrzne przestają się rozwiązywać, mimo że tunel jest zdrowy, a serwer osiągalny po adresie.
To zostawia tunel bez ścieżki do prefiksu biura, chyba że sam ją dodasz: route-nopull, po którym następuje route 10.30.0.0 255.255.0.0 w tym samym profilu. Ten wiersz niesie adres i maskę; nie wskazuje następnego skoku.
Alternatywna forma dodaje token bramy, route 10.30.0.0 255.255.0.0 vpn_gateway, który wskazuje wpis na tunel po nazwie. Importery różnią się tym, czy tłumaczą ten wariant, więc sprawdź zapisane połączenie, jeśli wpisu brakuje w tabeli jądra.
Weryfikuj przez wyszukiwanie tras, nie przez ping
Ping mówi, że coś odpowiedziało. Wyszukiwanie trasy mówi, który interfejs wybrałoby jądro, i to jest pytanie, które naprawdę zadałeś. Cztery krótkie polecenia oddzielają brakującą trasę od trasy wskazującej niewłaściwe urządzenie.
Przeczytaj, co tunel zainstalował, za pomocą ip route show dev tun0. Całkowity brak wyjścia oznacza zero tras, co nie jest działającym tunelem dzielonym, i to zwykły wynik dodania filtra bez jawnego wiersza.
Następnie sprawdź jeden adres biurowy za pomocą ip route get 10.30.5.7 i jeden zwykły adres internetowy za pomocą ip route get 1.1.1.1. Drugi powinien wskazać interfejs fizyczny; jeśli wskazuje tunel, wypchnięcie w ogóle nie zostało przefiltrowane.
Na koniec przeczytaj ip rule, ponieważ reguła polityki pozostawiona przez wcześniejszą próbę może nadpisać tabelę, którą właśnie poprawiłeś. Poprawny profil z nieaktualną regułą na wierzchu wygląda dokładnie jak zepsuty profil. Usuń regułę dodaną ostatnim razem, zanim dodasz kolejną.
Nakładające się podsieci wyglądają jak zepsuty tunel
Dwa zakresy prywatne mogą być identyczne z punktu widzenia klienta, i właśnie tam tunel dzielony jest obwiniany o coś, czego nie spowodował. Jeśli biuro przydziela ten sam prefiks, którego używa twój domowy router, trasa tunelu obejmuje router i domowa sieć wydaje się znikać.
Porównaj adres na własnym interfejsie z trasą instalowaną przez profil, używając zwykłej listy adresów, zanim cokolwiek zmienisz. Nakładanie się jest realne i żadna opcja profilu go nie rozwiązuje. Naprawić możesz nazewnictwo, aby następna osoba widziała dwa zakresy zamiast jednego.
Uczciwe poprawki to przenumerowanie jednej strony lub tłumaczenie adresów w biurze. Przypięcie jednej trasy hosta do routera działa do zmiany adresu routera, a potem staje się drugą zagadką na wierzchu pierwszej.
Spraw, aby decyzja przetrwała ponowne połączenie
Wpisy wpisane ręcznie nie przetrwają ponownego połączenia, a menedżer połączeń odbudowuje tabelę za każdym razem, gdy profil się uruchamia. Umieść decyzję tam, gdzie powstaje połączenie, czy to profil, czy zapisane ustawienia menedżera. Następnie raz celowo zrestartuj połączenie, zamiast odkrywać zachowanie podczas rozmowy. Profil, który działa tylko do następnego ponownego połączenia, nie jest gotowy.
Przećwicz trzy ścieżki naraz: host biurowy po dosłownym adresie, ten sam host po nazwie i zwykłą stronę publiczną. Środkowa zależy od usługi nazw skonfigurowanej po odrzuceniu wypchniętych opcji DNS, i to ona po cichu zawodzi.