Skieruj jedną podsieć LAN przez OpenVPN i zachowaj trasę domyślną

Urządzenia, które routują dla LAN i jednocześnie łączą się z VPN, wpadają w ten sam spór same ze sobą: tunel chce posiadać trasę domyślną, a LAN potrzebuje jej z powrotem. Gdy OpenVPN się łączy, może zainstalować trasę domyślną przez tunel albo parę połowicznych tras domyślnych, co jest dobre dla laptopa, a złe dla bramy, której sąsiedzi oczekują odpowiedzi z jej adresu LAN. Odpowiedzią nie jest pominięcie VPN. Odpowiedzią jest danie obu decyzjom różnych tabel.

Jedna trasa domyślna, dwóch właścicieli

Ruch przekazywany i ruch powstający lokalnie nie muszą iść tą samą drogą. Klienci LAN potrzebują tunelu tylko dla wybranych przez ciebie celów, natomiast własne sesje zarządzania hosta i jego odpowiedzi do tych klientów potrzebują domyślnej trasy LAN. Mieszanie obu w tabeli głównej wymusza jedną odpowiedź na dwa różne pytania.

OpenVPN ma przełącznik dokładnie do tego. route-noexec powstrzymuje klienta przed dotykaniem tabeli głównej, a wartości, których by użył, są eksportowane do skryptu route-up jako route_vpn_gateway, dev i adresy interfejsu. Potem decydujesz, która tabela dostanie którą trasę, w kodzie, który możesz później przeczytać.

Tabela polityk kontra przepisywanie tabeli głównej

Osobna tabela to jedyna opcja, która skaluje się poza jedną podsieć. Nazwij ją raz, a potem odwołuj się do niej po nazwie, żeby nikt nie musiał pamiętać liczby:

echo "10 vpn" >> /etc/iproute2/rt_tables
ip rule add from 192.168.50.0/24 table vpn
ip route add default via 10.8.0.1 dev tun0 table vpn

Adresy tutaj są zastępcze. Zastąp prefiks LAN, bramę tunelu i nazwę urządzenia z własnego wdrożenia, zanim cokolwiek uruchomisz.

Reguła musi pasować także do hosta

Reguła pasująca tylko do prefiksu LAN obejmuje pakiety przekazywane. Nie obejmuje ruchu, który sama brama tworzy, ani odpowiedzi wysyłanych z powrotem do klientów LAN, które niosą adres LAN bramy jako źródło. Te wyszukiwania spadają do main i nadal mogą wyjść przez tunel.

Dodaj drugą regułę dla własnego adresu LAN bramy albo rozszerz pierwszą regułę na zbiór obejmujący oba. Kolejność ma znaczenie: bardziej szczegółową regułę umieść pierwszą i sprawdź wynik wyszukiwaniem, które wprost podaje źródło.

ip route get 203.0.113.9 from 192.168.50.1

Jeśli to wskazuje urządzenie tunelu dla celu, który powinien pozostać lokalny, zestaw reguł jest błędny niezależnie od tego, co zawiera tabela.

NAT albo trasa po drugiej stronie

Serwer VPN zna podsieć tunelu i nic więcej. Pakiety przychodzące z adresem źródłowym LAN nie mają drogi powrotnej, chyba że ktoś ją zapewni, a zapewnić ją można dokładnie na dwa sposoby. Dodanie trasy dla prefiksu LAN na serwerze utrzymuje pierwotne źródło widoczne od początku do końca, czego zwykle chce audytowany projekt. Maskowanie na bramie przepisuje źródło na adres tunelu i nie wymaga współpracy serwera.

iptables -t nat -A POSTROUTING -s 192.168.50.0/24 -o tun0 -j MASQUERADE

Wybierz NAT, gdy nie kontrolujesz serwera i nie możesz tam dodać tras. Wybierz trasę po stronie serwera, gdy liczą się logi, kontrola dostępu lub symetria drogi powrotnej, bo maskowanie usuwa pierwotny adres ze wszystkiego, co rejestruje druga strona.

Tak czy inaczej przekazywanie musi być włączone, a ścisłe filtrowanie drogi powrotnej może odrzucić odpowiedź, gdy main nie wybrałby tunelu dla tego źródła. Sprawdź wartość rzeczywistą, zanim obwinisz tunel.

Spraw, by podział przetrwał ponowne połączenie

Reguły i trasy dodane ręcznie znikają, gdy interfejs jest tworzony od nowa, a nieaktualny wpis w tabeli może przetrwać sesję, która go uzasadniała. Umieść regułę tabeli, trasę tunelu i wpis maskowania w skrypcie route-up klienta i wyczyść tabelę na początku skryptu, aby stara brama nie przetrwała do nowej sesji.

Sprawdź z obu stron: wyszukiwanie na bramie ze źródłem LAN oraz prawdziwe żądanie od klienta LAN do celu, który powinien przejść przez tunel. Trasa, która istnieje, ale nigdy nie jest wybierana, zachowuje się dokładnie jak brak trasy, dopóki nie odczytasz liczników.