Dlaczego trasa lokalna wygrywa z domyślną trasą VPN

Drukarka na biurku działa dalej po podniesieniu tunelu, podczas gdy serwer w drugim biurze po cichu rozwiązuje się na coś lokalnego. Oba zachowania wynikają z tej samej reguły: wygrywa najbardziej szczegółowa trasa, a bezpośrednio podłączony prefiks jest tak szczegółowy, jak to możliwe. Zwykle to jest pożądany projekt, i właśnie tak zduplikowany zakres prywatny kradnie zdalny adres. Przeczytanie najpierw wyboru jądra zamienia tajemniczą awarię w porównanie prefiksów.

Podłączony prefiks jest bardziej szczegółowy niż trasa domyślna

Tunel zwykle instaluje trasę domyślną lub zestaw prefiksów, podczas gdy lokalny interfejs niesie podłączony prefiks oraz trasę do całej sieci LAN. Między nimi decyduje dopasowanie najdłuższego prefiksu, więc cel wewnątrz prefiksu LAN nigdy nie trafia do tunelu. Dlatego drukarka, strona administracyjna routera i lokalny NAS pozostają osiągalne, gdy VPN jest włączony. Dlatego też zdalny zasób w nakładającym się zakresie trafia do niewłaściwej maszyny.

Prywatna przestrzeń adresowa nie jest unikalna, a wybór tego samego prefiksu przez dwie lokalizacje jest dość częsty, by to planować. Gdy zakresy się nakładają, lokalna odpowiedź przychodzi szybko i wygląda autorytatywnie, więc awarię łatwo błędnie odczytać jako problem z logowaniem. Cel odpowiedział, tylko nie ten, o który chodziło.

Przeczytaj wybór, którego dokonałoby jądro

Zapytaj jądro, której trasy użyłoby dla dokładnego celu, zamiast czytać tabelę od góry. Potem poszukaj reguł polityki, które mogłyby wybrać inną tabelę. Dwie komendy odpowiadają na oba pytania w kilka sekund.

ip route get 10.20.30.41
ip route show table all | grep -E '10\.|default'
ip rule show

Pierwsze wyjście podaje interfejs, następny skok i adres źródłowy, których użyłoby jądro, i to jest odpowiedź, która się liczy. Wartość dev wskazująca lokalny mostek oznacza, że pakiet nigdy nie wchodzi do tunelu, cokolwiek twierdzi panel stanu klienta VPN. Przefiltrowana lista tabel pokazuje, czy inna tabela trzyma ten sam prefiks, a lista reguł pokazuje kolejność, w jakiej te tabele są konsultowane. Reguła polityki może wysłać prefiks przez konkretną tabelę nawet gdy główna tabela się nie zgadza, więc ta kolejność jest częścią odpowiedzi.

Dostęp lokalny to osobne uprawnienie

Posiadanie trasy to nie to samo co pozwolenie na jej użycie. Większość klientów potrafi blokować lokalną komunikację sieciową, gdy tunel jest podniesiony, a to ustawienie jest decyzją polityki, nie artefaktem routingu. Gdy zaufana usługa w pobliżu należy do projektu, włącz obsługiwaną opcję dostępu lokalnego zamiast wymyślać trasy. Gdy urządzenie jest w publicznym Wi-Fi, pozostaw ją wyłączoną.

Obie warstwy zawodzą inaczej. Zablokowana ścieżka lokalna daje przekroczenie czasu, choć trasa istnieje, a trasa nakładająca się daje odpowiedź od niewłaściwego hosta. Rozróżnienie ich kosztuje jedno zapytanie i oszczędza popołudnie zmian w zaporze, a układ przekazywania opisano w notatki strongSwan o przekazywaniu.

Napraw nakładanie się bez piętrzenia tras do hostów

Trasa do hosta dla jednego adresu wygląda na naprawę nakładania się i zawodzi w chwili, gdy potrzebny jest drugi adres z tego samego zakresu. Po dwudziestu takich nikt nie potrafi powiedzieć, który prefiks jest miarodajny. Trwałe rozwiązania to zmiana adresacji, udokumentowana topologia unikająca zduplikowanego zakresu albo translacja na jednym końcu. Każde kosztuje czas planowania raz, a nie utrzymanie na zawsze.

Jeśli tymczasowa trasa do hosta jest naprawdę konieczna, zapisz obok powód, właściciela i datę, aby można ją było później usunąć. Następnie przetestuj dokładny adres i usługę oraz cel publiczny, bo zmiana dostępu lokalnego, która po cichu wyłącza niepowiązane aplikacje z tunelu, jest gorsza od pierwotnej awarii. Trzymaj prefiks lokalny i prefiks zdalny zapisane osobno; ten nawyk powstrzymuje krążenie działającego lokalnego ping jako dowodu, że zdalne biuro jest osiągalne.