Co mówi tabela tras VPN, a czego nie może powiedzieć

Łączysz się, uruchamiasz listę tras i widzisz podsieć, o której nigdy nie słyszałeś, wskazującą na tunel. Ten wiersz mówi jedną rzecz precyzyjnie, a kilku rzeczy wcale. Zapisuje, jak ta maszyna będzie przekazywać pakiety do tego prefiksu, nic o tym, jakie hosty tam istnieją, i nic o tym, co może osiągnąć twoje konto. Przeczytanie go poprawnie zajmuje minutę; czytanie go jako inwentarza zajmuje znacznie więcej czasu, zanim się tego oduczy.

Czytaj tabelę jako lokalne instrukcje

Trasa to instrukcja przekazywania trzymana przez lokalne jądro: dla tego prefiksu użyj tego interfejsu i tego następnego skoku. Długość prefiksu decyduje, jak konkretna jest instrukcja, i wygrywa najdłuższe dopasowanie. Nic w tej regule nie wspomina uprawnień, stanu usługi ani zdalnej topologii.

Reguły polityki mogą zadziałać, zanim tabela zostanie sprawdzona, dlatego trasa może istnieć i mimo to nie być tą, której używa dany pakiet. Czytaj reguły obok tabeli, a potem zapytaj jądro, którą ścieżkę wybrałoby dla konkretnego celu. Odpowiedź dla jednego adresu jest warta więcej niż strona prefiksów i jest jedyną odpowiedzią, która odzwierciedla znaczniki, przestrzenie nazw i powiązania interfejsów zastosowane przez klienta.

Szeroki prefiks to nie katalog

Prefiks /16 kierowany przez tunel nie oznacza szesnastu tysięcy osiągalnych hostów, a trasa domyślna oznacza jeszcze mniej. Serwer decyduje, kto odpowiada, zapora decyduje, co jest dozwolone, a konto decyduje, co jest autoryzowane.

Wąska tabela ma odwrotną pułapkę: brakujący prefiks może oznaczać, że cel jest osiągalny inną drogą, albo po prostu że wcale nie jest trasowany. Te dwa przypadki wyglądają identycznie, dopóki ich nie przetestujesz. Porównuj tabelę z zasobem, który kazano ci użyć, a nie z własnymi oczekiwaniami co do tego, co powinien zawierać VPN.

Skąd pochodzą wpisy

Trasy przychodzą z co najmniej czterech miejsc: z pliku konfiguracyjnego, od serwera, który wypycha trasę podczas nawiązywania połączenia, od menedżera sieci, który posiada interfejs, oraz od osoby wpisującej polecenie podczas incydentu. Każde ma inny czas życia i innego właściciela.

Ta wpisana podczas awarii to ta, która znika przy ponownym uruchomieniu i nie pojawia się w niczyjej dokumentacji. Trasa wypychana przez serwer zmienia się, gdy zmienia się serwer, dlatego niewyjaśniony nowy prefiks często pojawia się po aktualizacji bramy, a nie po zmianie klienta. podręcznik ip-route dokumentuje składnię tabeli i pól, jeśli musisz czytać flagi.

Sprawdź trasę wobec umowy o usługę

Użyteczne porównanie to zestawienie tabeli z usługą, którą ci obiecano: nazwa, zakres adresów, port i właściciel. Zapisz te cztery obok prefiksu, a luki staną się widoczne.

ip route show table all dev tun0
ip route get 10.20.5.9
ip rule show

Jeśli prefiks istnieje, a usługa nadal zawodzi, tabela zrobiła swoje, a problem jest gdzie indziej: rozwiązywanie nazw, zapora po drugiej stronie albo konto bez właściwej grupy. Jeśli prefiksu brakuje, pytanie brzmi, kto powinien go dostarczyć, a nie co wpisać. Każda z tych dwóch odpowiedzi wskazuje zespół, o który zapytać następnym razem, i to jest jedyny użyteczny wynik czytania tabeli tras. Zapisz tę nazwę, zanim zamkniesz terminal.

Zapisuj stan przed i po każdej zmianie, z datą i interfejsem. Tabela tras to migawka jednej chwili na jednej maszynie i staje się dowodem dopiero wtedy, gdy ktoś zapisze, kiedy ją wykonano.