Następny skok w trasie VPN: dlaczego brama musi być osiągalna lokalnie

Adres via trasy musi być osiągalny na łączu, z którego wysyłasz. Prześledź przekazanie, sprawdź wyszukiwanie i przetestuj z hosta, do którego należy ruch.

Trasa do sieci VPN niesie dwa adresy, które łatwo pomylić: prefiks celu, do którego pakiet próbuje dotrzeć, i następny skok, który przesunie go o krok bliżej. Na hoście LAN ten następny skok musi być routerem, do którego naprawdę można dotrzeć w tym samym łączu. Zdalny adres VPN nie jest następnym skokiem, choćby najstaranniej pasował do celu, który masz na myśli.

Ten podręcznik obejmuje zwykły przypadek: laptop w 192.168.20.0/24, brama VPN z adresem LAN 192.168.20.5 i sieć zdalna 10.70.0.0/24 za tą bramą. Wszystkie poniższe polecenia zakładają, że jesteś na laptopie, o ile nie powiedziano inaczej.

Dwa adresy, jedna trasa

Zamierzony wpis to 10.70.0.0/24 via 192.168.20.5. Prefiks mówi, dokąd idzie pakiet; adres via mówi, kto go tam niesie. Jądro odmawia zainstalowania trasy, której bramy nie może osiągnąć przez wskazany interfejs, i ta odmowa jest całą istotą: następny skok, który potrzebuje tunelu, aby być osiągalnym, nie może być następnym skokiem, który buduje tunel.

Pierwsze sprawdzenie nie brzmi więc «czy brama działa», ale «czy brama jest w tym łączu». Własna podsieć laptopa, jego wpis ARP lub sąsiada i interfejs w trasie muszą się zgadzać. Adres, który istnieje tylko wewnątrz 10.70.0.0/24, może być celem drugiej trasy, ale nigdy via pierwszej.

Do czego następny skok zobowiązuje bramę

Zainstalowanie trasy na laptopie rozstrzyga tylko pierwsze przekazanie. Potem brama potrzebuje własnej drogi: włączone przekazywanie, trasa tunelowa do 10.70.0.0/24 i każda polityka dostępu, która określa, kto może jej używać. W systemie Linux to net.ipv4.ip_forward=1 plus trasa tunelowa; zapora przed nią potrzebuje reguły, która pozwala na przekazywany strumień.

Kierunek powrotny to część, o której ludzie zapominają. Strona zdalna musi mieć trasę powrotną do 192.168.20.0/24, albo projekt musi przetłumaczyć źródło laptopa na coś, co strona zdalna zna. Działający ping z bramy dowodzi, że brama dociera do sieci zdalnej; nie mówi nic o tym, czy pakiety laptopa przetrwają drogę powrotną.

Sprawdź wyszukiwanie z hosta, który wysyła

Zapytaj jądro, który następny skok by wybrało, i odczytaj interfejs w odpowiedzi:

ip route get 10.70.0.10
ip route show 10.70.0.0/24
ip neigh show 192.168.20.5

Jeśli wyszukiwanie zgłasza bramę i interfejs LAN, pierwszy odcinek jest skonfigurowany zgodnie z zamiarem. Jeśli zgłasza urządzenie tunelowe, coś wcześniejszego w tabeli jest bardziej szczegółowe i wygrywa. Jeśli trasa w ogóle się nie instaluje, jądro mówi ci, że brama jest nieosiągalna, i ten komunikat jest użyteczniejszy niż dowolne przechwycenie pakietów.

Następnie powtórz test z właściwego miejsca. Żądanie utworzone na bramie używa własnego adresu źródłowego bramy, co może ukryć brakującą trasę powrotną lub politykę, która dopuszcza tylko określone źródła. Podręcznik ip-route rozdziela cel, bramę i nadpisanie onlink, a nadpisanie warto zrozumieć, zanim się go użyje.

Nie używaj onlink do pozorowania osiągalności

onlink każe jądru pominąć sprawdzenie osiągalności bramy i mimo to wysłać do niej. Nie tworzy drogi, nie rozwiązuje ARP dla adresu, którego nie ma, i nie zmusza zdalnego routera do odpowiedzi w twoim segmencie Ethernet. Jest uzasadnione dla bram, które odpowiadają, ale nie leżą w podłączonej podsieci, i jest pułapką, gdy służy do wyciszenia błędu, którego nie wyjaśniłeś.

Jeśli trasa instaluje się tylko z onlink, następne pytanie brzmi, dlaczego brama nie jest tam, gdzie myślisz. Zły VLAN, drugi adres na złym interfejsie lub literówka w ostatnim oktecie dają to wszystko, a każde z nich psuje też drogę powrotną, gdy tylko ruch zacznie płynąć.

Tunele punkt-punkt nie są Ethernetem

Urządzenie tunelowe nie robi ARP i często nie ma sensownej podsieci sąsiadów. Jego trasy często wyglądają jak 10.70.0.0/24 dev tun0, bez żadnego via, bo partner jest jedynym drugim końcem. Skopiowanie via w stylu LAN do tej tabeli daje trasę, którą jądro może odrzucić albo, co gorsza, taką, która wskazuje adres, na który partner nigdy nie odpowiada.

Trzymaj oba modele osobno w podręczniku: trasa LAN ma osiągalną bramę, trasa tunelowa ma interfejs i partnera. WireGuard, OpenVPN i IPsec pokazują nieco inne kształty, więc zapisz kształt, którego naprawdę użyłeś, zamiast uogólniać z jednego hosta.

Dodaj, potwierdź, wycofaj

Cała zmiana to trzy polecenia i jedno sprawdzenie, i powinna być zapisana w tej kolejności:

sudo ip route add 10.70.0.0/24 via 192.168.20.5
ip route get 10.70.0.10
ping -c 3 10.70.0.10
sudo ip route del 10.70.0.0/24 via 192.168.20.5

Potwierdź drogę, potwierdź jeden cel, a potem trzymaj wiersz usuwania pod ręką, gdyby zmiana uczyniła host nieosiągalnym w sposób, którego nie przewidziałeś. Jeśli trasa ma przetrwać restart, umieść ją w konfiguracji sieci hosta, a nie w profilu powłoki, i przetestuj restart, zanim na niej polegniesz. Trasa, która istnieje tylko w powłoce, która ją dodała, to trasa, którą będziesz debugować dwa razy.

Powiązane artykuły