Kieruj do tunelu tylko port 25, nie host

Cztery rzeczy muszą się zgadzać, zanim host Linux wyśle przez tunel tylko własny SMTP: trasa w dedykowanej tabeli, reguła polityki wybierająca ruch, adres źródłowy akceptowany przez peera i ścieżka powrotna, która przetrwa asymetrię. Każda z nich to osobna konfiguracja z własnym trybem awarii. Kolejność poniżej sprawia, że awaria wskazuje część, która naprawdę jest błędna. To zadanie routingu specyficzne dla portu, a nie prośba o domyślną trasę VPN.

Reguła portu to nie trasa domyślna

Reguła dopasowująca lokalnie utworzony TCP do portu docelowego 25 wysyła ten ruch do tabeli, którą nazwiesz. Reguła sama nic nie tworzy: wybiera, a tabela musi zawierać trasę zdolną przenieść pakiet. Połączenie obu obejmuje tylko kierunek wychodzący jednego protokołu, więc przekazywanie dla innych hostów, połączenia poczty przychodzącej i IPv6 pozostają poza tym układem. Nazywanie tego polityką specyficzną dla portu, a nie domyślną VPN, zachowuje tę granicę uczciwie.

Dwa ustawienia wg-quick są warunkami wstępnymi, a nie częścią polityki. AllowedIPs = 0.0.0.0/0 pozwala peerowi nieść dowolne cele IPv4, a Table = off powstrzymuje wg-quick przed zainstalowaniem własnej trasy domyślnej dla tego prefiksu. Nie mieszaj tych instrukcji z menedżerem stosującym własną politykę tras, bo oba nie zgodzą się, kto jest właścicielem tabeli głównej.

Napisz trasę, selektor i strażnika

Wybierz numer tabeli i parę priorytetów, których nic innego nie używa, a następnie zastosuj trasę, selektor i strażnika w tej kolejności. Liczby poniżej są przykładami, nie wartościami zarezerwowanymi:

ip -4 route add default dev wg0 src 10.77.0.2 table 51825
ip -4 rule add priority 10000 iif lo ipproto tcp dport 25 lookup 51825
ip -4 rule add priority 10001 iif lo ipproto tcp dport 25 unreachable

iif lo ogranicza regułę do ruchu pochodzenia lokalnego, a ipproto tcp dport 25 identyfikuje kierunek połączenia; dokumentacja ip-rule opisuje oba selektory. Istnieją w obecnych jądrach i wydaniach iproute2, a w starszym systemie reguła jest wprost odrzucana, co jest jaśniejszą awarią niż reguła, która się ładuje i do niczego nie pasuje.

Reguła unreachable na następnym priorytecie jest strażnikiem. Bez niej brakująca trasa w tabeli 51825 przechodzi do zwykłej domyślnej, a poczta wychodzi przez łącze fizyczne podczas awarii tunelu, co jest dokładnie tym przypadkiem, któremu polityka miała zapobiegać.

Adres źródłowy musi się zgadzać

Preferencja src trasy wypełnia źródło tylko dla połączeń, które nie związały własnego. To nie jest translacja i nie unieważnia jawnego powiązania, więc demon związany z adresem fizycznym nadal wysyła z tego adresu. Jeśli to właśnie znajdziesz, zmień ustawienie samego demona lub zaprojektuj świadomą politykę translacji, bo późny ogólny masquerade to inne rozwiązanie o innych konsekwencjach.

Na bramie peer klienta musi autoryzować źródło, które faktycznie odbiera, czyli 10.77.0.2/32, a nie szeroki prefiks docelowy. Kopiowanie 0.0.0.0/0 klienta do każdego peera bramy zaciera, który peer posiada który ruch. Brama potrzebuje też przekazywania, polityki zapory, która dopuszcza przepływ, oraz ścieżki powrotnej, w tym translacji wyjścia, gdy strona nadrzędna nie potrafi trasować prywatnego adresu tunelu.

Sprawdź ścieżkę powrotną, potem trwałość

Przeczytaj wyszukiwania, zanim czemukolwiek zaufasz, bo pokazują, którą tabelę i które źródło dostaje każdy kierunek. Jeden cel na porcie 25 i ten sam cel na porcie 443 wystarczą:

ip -4 route get 198.51.100.25 ipproto tcp dport 25
ip -4 route get 198.51.100.25 ipproto tcp dport 443

Pierwsze wyszukiwanie powinno wskazać wg0 i zamierzone źródło, a drugie zachować zwykłe łącze nadrzędne. Gdy aplikacja wiąże własny adres, dodaj from z tym adresem do wyszukiwania. Kierunek odpowiedzi, który dociera do wg0 i zostaje lokalnie odrzucony, wskazuje na filtrowanie odwrotnej ścieżki IPv4, bo reguła tylko dla portu wyjściowego nie skłania odwrotnego wyszukiwania do wyboru tunelu.

Tam, gdzie dozwolone jest routing asymetryczny, odpowiedni może być luźny tryb ograniczony do interfejsu przez net.ipv4.conf.wg0.rp_filter=2 i warto najpierw sprawdzić efektywne maksimum wartości all i interfejsu. Nie wyłączaj walidacji globalnie jako skrótu. Następnie przekaż tabelę, priorytety i strażnika temu, kto posiada konfigurację, i otwórz nowe połączenia po ponownym połączeniu, aby potwierdzić, że wybór nadal się utrzymuje. Pamiętaj, że odpowiedzi lokalnego nasłuchu SMTP niosą port źródłowy 25, a nie port docelowy 25, co jest osobnym pytaniem polityki.