Dlaczego route -interface nie dociera do hosta poza łączem

route przyjmuje nazwę interfejsu Wi-Fi, kończy się bez skargi, a host pozostaje nieosiągalny. Nic nie jest uszkodzone; relacja w trasie jest po prostu błędna: flaga interfejsu mówi, na którym łączu znajduje się cel, a nie który router ma odbierać ruch do celu znajdującego się gdzie indziej. Polecenie udaje się, bo jest składniowo poprawne, a nie dlatego, że opisuje działającą ścieżkę.

Ta różnica decyduje, czy wyjątek trasy obok VPN będzie działał, czy tylko będzie wyglądał wiarygodnie.

Interfejs to wyjście, następny skok to przekazanie

Na Macu z adresem 192.168.50.20 i routerem pod 192.168.50.1 inna maszyna w tym samym łączu jest osiągalna bezpośrednio. Ramka jest adresowana do tej maszyny i kładziona na przewodzie. Router nie jest zaangażowany, a trasa ograniczona do interfejsu wyraża dokładnie to. Zmień drugi koniec na hosta w innym budynku, a to samo polecenie traci sens. Mac nie ma adresu drugiej warstwy, który mógłby położyć na przewodzie, więc flaga interfejsu nie ma czego opisywać.

Cel poza łączem jest inny. Mac nie może położyć na przewodzie ramki adresowanej do hosta, do którego nie dociera w drugiej warstwie; przekazuje pakiet routerowi, który potrafi. Trasa wymaga więc bramy, a sama brama musi być osiągalna w podłączonym łączu.

Użycie flagi interfejsu dla celu poza łączem mówi macOS, aby traktował ten cel tak, jakby był na przewodzie. Wtedy jądro nie potrafi rozwiązać dla niego adresu drugiej warstwy, a pakiet jest odrzucany bez niczego użytecznego w błędzie.

Co flaga interfejsu faktycznie twierdzi

Dokumentacja tras Apple definiuje formę interfejsu dla celów osiągalnych bezpośrednio bez pośrednika. To stwierdzenie o modelu łącza, a nie preferencja co do adaptera. Osiągnięcie hosta internetowego przez Wi-Fi nadal wymaga routera w tym łączu Wi-Fi, a trasa musi go nazwać.

Zakres interfejsu to osobny atrybut. Wiąże trasę z konkretnym interfejsem na potrzeby decyzji o zakresie, takich jak który adres źródłowy obowiązuje, ale nie tworzy osiągalności dla celu, do którego interfejs sam nie dociera. Oba atrybuty odpowiadają na różne pytania.

Dlatego polecenie może zostać przyjęte, pojawić się w tabeli i mimo to zawieść. Jądro nie weryfikuje twojej intencji; zapisuje to, co stwierdziłeś, a stwierdzeniem było, że cel jest w łączu. Cichy sukces, po którym następuje ciche odrzucenie, to oczekiwany wynik, a nie błąd. Przeczytaj to stwierdzenie jeszcze raz, zanim obwinisz sieć.

Trasa, której potrzebuje cel poza łączem

Dla zatwierdzonej ścieżki do adresu dokumentacyjnego, takiego jak 198.51.100.25, przez router LAN zamierzona relacja to cel, następny skok 192.168.50.1 i interfejs LAN, który dociera do tego następnego skoku. Interfejs wynika z wyszukania następnego skoku, a nie jest wymuszany przez polecenie trasy.

W macOS inspekcja tylko do odczytu to route -n get 198.51.100.25. Czytaj razem wiersze bramy i interfejsu i sprawdź, czy brama jest adresem, do którego Mac faktycznie dociera. Brama w innej podsieci albo taka, która zniknęła od ostatniej zmiany sieci, daje trasę, która wygląda poprawnie i niczego nie przekazuje.

Nie zakoduj na stałe en0 w trwałej instrukcji. Nazwy interfejsów zmieniają się wraz z adapterami, stacjami dokującymi i klientami VPN, a trasa wskazująca niewłaściwy zawodzi w sposób łatwy do odczytania jako szersza awaria sieci.

Przeczytaj bieżący wybór, zanim go zastąpisz

Zanim cokolwiek dodasz, sprawdź, co system już wybrał i dlaczego. Ten wynik mówi, czy ruch idzie przez tunel, przez router LAN czy donikąd, i daje punkt odniesienia do porównania po zmianie. Bez niego nie możesz stwierdzić, czy nowa trasa zadziałała.

Następnie sprawdź rodzinę adresów. Trasa dodana dla IPv4 nic nie robi dla celu IPv6, a usługa rozwiązująca się w obu rodzinach może wydawać się okresowo osiągalna. Tabela tras i resolver odpowiadają na różne pytania i oba muszą zgadzać się z zamierzoną ścieżką.

Na koniec pamiętaj, że trasa to wybór, a nie zezwolenie. Zarządzany profil VPN lub filtr klienta nadal może zabronić bezpośredniej ścieżki, nawet gdy tabela na nią wskazuje, więc testuj z rzeczywistą aplikacją, zamiast zakładać, że udany wpis w tabeli kończy dochodzenie.

Tunele i polityki zmieniają kształt

Interfejsy punkt-punkt to osobny przypadek. Tunel może przenosić trasę bez adresu bramy w stylu Ethernet i nie jest to automatycznie błędne. Zastosuj rzeczywisty model łącza interfejsu, zamiast rozciągać przykład Wi-Fi na każdy widziany wpis w tabeli.

W żądaniach zmian zapisz cel, zatwierdzoną ścieżkę sieciową, bieżącą bramę i interfejs oraz to, kto ma utrzymywać wyjątek. Właściciel ma znaczenie, bo jednorazowa trasa wpisana w wierszu poleceń nie jest polityką, a następne ponowne połączenie ją usunie.

Jeśli wymaganiem jest osiągnięcie tego hosta przy włączonym VPN, uczciwa odpowiedź to zwykle konkretna trasa do hosta przez lokalny router, instalowana przez menedżera sieci, który zarządza interfejsem. Jeśli wymaganiem jest osiągnięcie czegokolwiek bezpośrednio, samo wymaganie potrzebuje przeglądu polityki, zanim potrzebuje polecenia trasy.