Routing jednego konta Linux przez OpenVPN z regułą UID

Routing oparty na koncie pasuje, gdy każde gniazdo IPv4 należące do jednego użytkownika Linux ma wychodzić przez istniejący tunel, a nie pasuje, gdy potrzebna jest izolacja na poziomie programu. Wybiera według UID, więc wszystko uruchomione pod tym kontem wchodzi w zakres, łącznie z zapomnianym zadaniem wsadowym. Rozstrzygnij tę kwestię, zanim dotkniesz choćby jednej ip rule.

Poniższy przykład zakłada dedykowane konto przeglądarki o UID 1500, urządzenie tunelowe tun-office z adresem lokalnym 10.80.0.11 oraz VPN, który dopuszcza omawiane cele. Sam demon działa poza tym UID.

Trzy warunki, które wybierają mechanizm

Wybierz regułę UID, gdy tożsamością wykonującą pracę jest konto, gdy przeniesienie całego jego ruchu jest akceptowalne i gdy namespace byłby cięższy, niż zasługuje na to zadanie. Wybierz namespace sieciowy, gdy obciążenie potrzebuje własnych interfejsów, resolvera i tabeli routingu. Wybierz proxy lub przypisanie na proces gdy dokładnie jedna aplikacja ma zostać przeniesiona, a reszta sesji zostaje na ścieżce lokalnej. Zapisanie tych trzech rzeczy zapobiega regule, która po cichu obejmuje więcej, niż zamierzono.

Błąd, którego należy unikać, to założenie, że launcher określa właściciela. Przeglądarka, której inna sesja użytkownika przekazała URL, nie utworzyła gniazd pod UID 1500 i żadna reguła nie przeniesie generowanego przez nią ruchu.

Tabela, reguła i strażnik

Po sprawdzeniu istniejących reguł i wybraniu nieużywanych numerów tabeli i priorytetu układ jest krótki: trasa domyślna w dedykowanej tabeli niosąca adres źródłowy tunelu, reguła wysyłająca wyszukiwania konta do tej tabeli oraz reguła kończąca, która blokuje ścieżkę zapasową. Zapisane, to idempotentne zastąpienie trasy, ip -4 route replace default dev tun-office src 10.80.0.11 table 51820, po którym następuje ip -4 rule add priority 12100 uidrange 1500-1500 lookup 51820.

Strażnikiem jest ip -4 rule add priority 12101 uidrange 1500-1500 unreachable i znaczy więcej, niż sugeruje jego długość. Bez niego brakująca trasa w tabeli 51820 przechodzi na zwykły uplink, a konto po cichu wypuszcza ruch, który polityka miała przechwycić. Z nim ta sama awaria staje się przekroczeniem czasu, czyli blokowaniem, a nie ścieżką zapasową.

Trzymaj zwykłą regułę adresu lokalnego przed tymi i świadomie zdecyduj, czy wyjątki LAN lub zarządzania należą przed wybraną tabelą. Znaleziona tam trasa domyślna nie pyta później main o bardziej szczegółową trasę LAN, co zaskakuje tych, którzy oczekują, że dopasowanie najdłuższego prefiksu obowiązuje między tabelami. Zapisz zamierzoną listę wyjątków w notatce o zmianie, dopóki uzasadnienie jest świeże.

Co pomija routing UID: DNS

Demon resolvera otwiera swoje gniazda nadrzędne pod własnym UID, więc wybór 1500 nie przenosi tych zapytań do tabeli 51820. Integracja DNS to osobna decyzja: skieruj konto na resolver osiągalny przez tunel albo zaakceptuj, że rozwiązywanie nazw idzie ścieżką hosta, a ruch nie.

Zapytanie loopback do lokalnego stub nie jest dowodem, że zapytanie nadrzędne użyło trasy przeglądarki, podobnie jak udane wczytanie strony z pamięci podręcznej.

IPv6 potrzebuje własnego zdania w projekcie

Powyższe reguły obejmują tylko IPv4. Jeśli wymaganiem jest tunel IPv4 bez bezpośredniego IPv6 z tego konta, dodaj sprawdzoną regułę kończącą, na przykład ip -6 rule add priority 12101 uidrange 1500-1500 unreachable, a następnie sprawdź wcześniejsze reguły IPv6 i wyjątki loopback, które chcesz zachować.

Blokowanie bezpośredniego IPv6 nie jest tunelowaniem dwustosowym; to granica. Nazwanie tego tunelowaniem zdezorientuje następną osobę czytającą politykę, a zamieszanie pojawi się jako zgłoszenie do pomocy technicznej o zepsutej stronie IPv6.

Zweryfikuj na prawdziwym koncie, a potem przejmij cykl życia

Porównaj wyszukiwania: ip -4 route get 198.51.100.25 uid 1500 wobec tego samego celu ze zwykłym UID. Potem wykonaj dozwolone żądanie pod dedykowanym kontem i sprawdź adres źródłowy widziany przez drugą stronę. Preferowany adres źródłowy nie jest source NAT i nie nadpisze aplikacji, która wiąże coś innego. Jeśli oba wyszukiwania zwracają tę samą ścieżkę, reguła nie robi tego, co myślisz.

Trzymaj tabelę, reguły i czas życia trasy tunelu u jednego właściciela, przetestuj ponowne połączenie i utratę tunelu, a przy wycofywaniu polityki usuwaj tylko jej dokładne wpisy. Namespace jest nadal dostępny, jeśli osobne interfejsy i osobny stan to naprawdę to, czego potrzebujesz.