Rozdzielone wyjście: pula VPN na usb0, ruch bramy na eth0

Klienci łączą się i uwierzytelniają, a potem ich ruch wychodzi niewłaściwym łączem, bo jedyna trasa domyślna na maszynie należy do samej bramy. Zastąpienie tej trasy domyślnej zepsułoby własne aktualizacje maszyny i dostęp administracyjny, więc wybór musi być węższy niż „cały ruch”. Działająca forma to reguła polityki oparta na wewnętrznym adresie źródłowym puli klientów, wskazująca drugą tabelę routingu, do której należy alternatywny WAN. Dalej lista kontrolna dotyczy kompletności i zachowania przy awarii, nie samej reguły.

Potwierdź, że adres źródłowy przetrwa do decyzji routingu

Reguła polityki pasująca do zakresu źródłowego zadziała tylko wtedy, gdy pakiet nadal niesie to źródło w chwili wyszukiwania. Przekazywany ruch klientów tak robi, dopóki nic wyżej nie przepisało go przed routingiem. Ruch generowany przez samą bramę tego nie robi, i właśnie dlatego jej własna trasa domyślna może zostać tam, gdzie jest.

Tu lokalne testy mylą. curl uruchomiony na bramie to lokalnie utworzony przepływ z adresem bramy, więc bierze tabelę główną i niczego nie dowodzi o ścieżce klienta. Testuj z podłączonego klienta albo generuj ruch ze źródła, które naprawdę należy do puli.

Zacznij od zapisania rzeczywistych wartości: prefiksu puli, interfejsu tunelu, który ją niesie, adresu i następnego skoku drugiego WAN oraz numeru tabeli, której zamierzasz użyć. Przed dodaniem nowych reguł wyczyść stare reguły z każdej wcześniejszej próby, bo zduplikowane reguły o różnych priorytetach dają awarie, które wyglądają na losowe.

Zbuduj wybraną tabelę, która jest kompletna

Tabela to nie trasa domyślna z przyjacielem. Potrzebuje dość tras, by każde wyszukiwanie rozwiązywało się w niej, łącznie z trasą połączoną dla podsieci WAN, aby następny skok był osiągalny. Dla puli 10.77.0.0/24 na tun1, adresu WAN 203.0.113.20/24 z następnym skokiem 203.0.113.1 i tabeli 600:

ip -4 route replace 203.0.113.0/24 dev usb0 src 203.0.113.20 table 600
ip -4 route replace 10.77.0.0/24 dev tun1 table 600
ip -4 route replace default via 203.0.113.1 dev usb0 table 600
ip -4 rule add priority 1500 from 10.77.0.0/24 lookup 600

Reguła stoi na priorytecie niższym niż każda istniejąca reguła łapiąca wszystko, więc pasujący klienci trafiają najpierw do tabeli 600, a wszystko inne spada do tabeli głównej. Dokumentacja ip-rule opisuje w pełni model uporządkowanego wyszukiwania i składnię selektora.

Potem pomyśl, czego tabela nie zawiera. Cel, który ma trasę tylko w tabeli głównej, na przykład podsieć zarządzania osiągalna przez eth0, nie zostanie znaleziony w tabeli 600 i nie wróci do głównej, gdy pojawi się tam trasa domyślna. Jeśli te ścieżki są ważne, dodaj je jawnie do wybranej tabeli, co zwykle jest właściwą odpowiedzią dla tabeli wyjścia VPN.

Trzymaj własny ruch nasłuchującego poza polityką

Nasłuchujący OpenVPN ma własne połączenie zewnętrzne, przenoszone przez to łącze, którym klient do niego dotarł. Ten ruch musi zachować ścieżkę powrotną, z którą przyszedł, a szeroka reguła obejmująca publiczny adres serwera lub cały interfejs tunelu może wciągnąć go do tabeli alternatywnej. Ogranicz regułę do puli wewnętrznej i niczego więcej.

Filtrowanie ścieżki powrotnej zasługuje na spojrzenie z tego samego powodu. Gdy odpowiedzi do klientów wychodzą przez usb0, a żądanie przyszło innym łączem, restrykcyjne ustawienie rp_filter może odrzucić pakiety, które polityka routingu uznaje za prawidłowe. Sprawdź obowiązujące wartości sysctl na obu interfejsach, zanim uznasz, że reguła zawiodła.

Kolejność ma znaczenie także względem wszystkiego innego na maszynie. Mosty Dockera, drugi VPN i wszelkie wcześniejsze reguły z obrazu dostawcy dodają priorytety, więc przeczytaj całą listę reguł, zamiast zakładać, że priorytet 100 jest sam.

Dopasuj przekazywanie i tłumaczenie do trasy

Routing wybiera łącze; nie daje pozwolenia na przekazywanie. Jądro musi mieć włączone przekazywanie IPv4, a zapora musi akceptować kierunek od klienta do WAN i ruch powrotny. Poprawna tabela z łańcuchem FORWARD, który odrzuca przepływ, daje ten sam objaw co brakująca trasa, dlatego oba sprawdza się w tym samym przejściu.

Jeśli drugi WAN nie będzie routował prywatnej puli z powrotem do ciebie, przetłumacz źródło na tym wyjściu. Dla interfejsu z adresem dynamicznym zwykłym wyborem jest wąska reguła masquerade ograniczona do puli i interfejsu:

iptables -t nat -A POSTROUTING -s 10.77.0.0/24 -o usb0 -j MASQUERADE

Zakres jest tu ważniejszy niż cel. Reguła masquerade pasująca do dowolnego interfejsu wyjściowego przepisze też ruch, który poprawnie wychodzi przez eth0, a to ukrywa błędy routingu zamiast je naprawiać. Tłumaczenie działa po decyzji routingu, więc nigdy nie naprawi pakietu wysłanego na niewłaściwe łącze.

Narzut tunelu też wymaga uwagi, gdy ścieżki się różnią. Jeśli klienci wynegocjują duży TCP MSS, a alternatywny WAN ma niższe MTU lub tunel w środku, duże segmenty się zatykają, podczas gdy małe działają. Ograniczenie MSS na ścieżce przekazywania zamienia to w przewidywalne zachowanie zamiast sporadycznego zawieszania.

Zdecyduj, co się stanie, gdy usb0 zniknie

Pusta tabela nie jest stanem zamknięcia przy awarii. Jeśli pasująca trasa zniknie, wyszukiwanie przechodzi do następnej reguły, dociera do tabeli głównej i bierze trasę domyślną eth0. Ruch, który miał wyjść drugim WAN, cicho wychodzi pierwszym, co we wdrożeniu z routingiem polityki jest zwykle wynikiem, którego chcesz najmniej.

Tam, gdzie takie cofnięcie jest nie do przyjęcia, dodaj jawną trasę końcową w tabeli 600, na przykład trasę domyślną blackhole, albo wyrzuć pulę w zaporze, dopóki interfejs jest wyłączony. Każda z tych opcji to decyzja, którą możesz zapisać; milczenie nią nie jest.

Trwałość to ostatni punkt. Ktokolwiek posiada oba łącza, czy to menedżer sieci, skrypt dyspozytora, czy cykl życia połączenia, musi przy każdym ponownym połączeniu odtworzyć trasy i regułę bez dodawania duplikatów. Sprawdź żądaniem od prawdziwego klienta i osobnym żądaniem z bramy, potwierdź zaobserwowane wyjście w obu przypadkach, następnie odłącz drugi WAN i zobacz, który z dwóch zaprojektowanych wyników faktycznie występuje. IPv6 potrzebuje własnej tabeli, reguły i tłumaczenia; powyższa reguła IPv4 nic o tym nie mówi.