Dlaczego trasa VPN nie pokazuje bramy w wyniku ip route
Wiersz z urządzeniem i bez bramy to trasa bezpośrednia, a nie zepsuta. Przeczytaj cel, dev i scope, a następnie potwierdź za pomocą ip route get.
Tabele routingu bywają czytane jako zepsute, ilekroć kolumna bramy pozostaje pusta, choć wiersz zwykle jest kompletny sam w sobie. Pole via pojawia się tylko wtedy, gdy jądro przekazuje pakiet adresowi następnego skoku; trasa przypisana do interfejsu osiąga swoje cele raczej przez rozwiązywanie na warstwie łącza lub przez partnera punkt-punkt. Czytanie kolumn od lewej do prawej mówi, w którym przypadku jesteś, i to czytanie powinno nastąpić, zanim ktokolwiek zmieni trasę domyślną. Większość zgłoszeń o brakującej bramie kończy się na tym rozróżnieniu.
Czytaj wiersz trasy kolumna po kolumnie
Każdy wpis zaczyna się od celu i długości jego prefiksu, a następnie dodaje modyfikatory w stałym słowniku: via, dev, proto, scope, src i metric. Wiersz taki jak 198.51.100.0/24 dev tun0 proto kernel scope link src 198.51.100.2 jest gęsty, ale w pełni określony. Niczego w nim nie brakuje i nie sugeruje się żadnego adresu routera.
Ciekawa jest nieobecność via. Bez następnego skoku jądro rozwiązuje cel bezpośrednio na wskazanym interfejsie, co w przypadku tunelu oznacza przekazanie ramki urządzeniu tunelowemu i pozwolenie enkapsulacji przejąć ją dalej. proto kernel odnotowuje, że wpis został zainstalowany automatycznie przy przydzielaniu adresu, a nie wpisany przez administratora. scope link mówi, że cel jest osiągalny w tym łączu bez przechodzenia przez router, a src wskazuje adres, który jądro przedłoży jako źródło dla pasującego ruchu.
Teraz przeczytaj trasę domyślną w ten sam sposób: default via 192.0.2.254 dev eth0 proto static metric 100. Tutaj via jest obecne, ponieważ pakiet naprawdę potrzebuje następnego skoku, a ten skok sam musi być osiągalny w eth0. Te dwa wiersze nie są wariantami siebie; odpowiadają na różne pytania o to, dokąd trafia ruch.
Dwa kształty tras, które są ze sobą mylone
Trasa podsieci tunelu i trasa domyślna wyglądają podobnie na zrzucie ekranu i zachowują się zupełnie inaczej. Użyj poniższej tabeli jako pomocy w czytaniu pól, a następnie potwierdź rzeczywiste liczby na maszynie, którą debugujesz, zamiast ufać przykładowi z poradnika.
| Piece of the line | What it settles | What it says nothing about |
|---|---|---|
| The destination and mask | Which packets are eligible to match | Where those packets leave the host |
via plus its address | Which next hop receives them, and therefore that a router is involved | Whether that router is reachable or sane |
dev | Which interface carries the encapsulated or raw packet | Whether the interface is up or has a carrier |
proto and scope | Who installed the entry and how far the destination is considered to be | Whether a firewall later drops the traffic |
Tabela nie może powiedzieć ci o intencji. Bezpośrednia trasa do zakresu prywatnego przez tunel to celowy projekt tunelu dzielonego; ten sam kształt na hoście, który powinien wysyłać wszystko przez VPN, jest objawem. Intencja żyje w konfiguracji, która wytworzyła wpis, więc spójrz na narzędzie, które go zainstalowało, zanim stwierdzisz, że jądro zrobiło coś źle.
Podobnie brakująca brama nie jest pozwoleniem na wymyślenie jej. Jeśli trasa naprawdę potrzebuje następnego skoku, ten skok musi być osiągalny na interfejsie, który go niesie, a w przypadku tunelu punkt-punkt adres partnera nie jest tym samym obiektem co adres lokalny. Traktowanie lokalnego adresu tunelu jako routera Ethernet to częsty sposób tworzenia trasy, która wygląda poprawnie i niczego nie przekazuje.
Zapytaj jądro, którego wiersza naprawdę użyje
Czytanie tabeli to nie to samo co wykonanie wyszukiwania, ponieważ jądro przed odpowiedzią konsultuje reguły polityki, kilka tabel i wpisy w pamięci podręcznej. Czasownikiem wykonującym prawdziwe wyszukiwanie jest ip route get, i wypisuje on trasę, którą obrałby pakiet o tych właściwościach.
ip route get 203.0.113.37 from 198.51.100.2 iif tun0Podstaw cel, na którym naprawdę ci zależy, a następnie dodaj from lub iif, gdy ruch jest wybierany według źródła lub przekazywany dalej, ponieważ zwykłe lokalne wyszukiwanie może wybrać inną ścieżkę niż przekazywany klient. Odpowiedź wskazuje interfejs, wybrany adres źródłowy i ewentualny następny skok, czyli te same informacje, z którymi pakiet byłby w tym momencie routowany.
Jeśli odpowiedź cię zaskoczy, wypisz reguły przed jakąkolwiek zmianą: ip -4 rule show wymienia je w kolejności priorytetu, a klient VPN, który instaluje własną tabelę lub regułę dla oznaczonych pakietów, w ogóle nie pojawi się w tabeli głównej. Wyliczenie wszystkich tabel zamyka tę lukę.
ip -4 route show table all | grep -E 'tun|default'Sprawdź warstwę niższą, zanim zastąpisz trasę domyślną
Własne pakiety tunelu muszą dotrzeć do zdalnego punktu końcowego, i robią to przez interfejs fizyczny, korzystając z trasy, która istniała przed podniesieniem VPN. Zastąpienie całej trasy domyślnej bez przypięcia tego punktu końcowego wysyła enkapsulowane pakiety do tunelu, który mają zbudować, i połączenie się załamuje. Najpierw potwierdź ścieżkę do punktu końcowego wyszukiwaniem tylko jego adresu.
Trzymaj trzy rzeczy osobno, gdy wprowadzasz zmianę: trasę do punktu końcowego, która musi pozostać na interfejsie fizycznym, zakresy prywatne, które powinny wejść do tunelu, oraz trasę domyślną, która decyduje o wszystkim innym. Rozdziel je w tej kolejności, stosuj po jednej i po każdym kroku ponownie uruchamiaj wyszukiwanie. Nieudany ping później sam w sobie dowodzi bardzo niewiele, ponieważ uprawnienia, routing odpowiedzi, DNS i sama usługa leżą poniżej poprawnej trasy.
Zapisz cztery wartości, które dał ci wiersz przed edycją: cel, następny skok lub jego brak, urządzenie i wybrane źródło. Jeśli późniejsza zmiana przesunie którąkolwiek z nich, wiesz, która decyzja została faktycznie zmieniona, i możesz przywrócić jeden wpis zamiast zgadywać całą tabelę.