Dante SOCKS przez VPN: pełny tunel a routing według źródła

Chcesz, aby ruch proxy SOCKS wychodził przez VPN, a reszta hosta zachowywała swoją zwykłą trasę. Robią to dwa projekty i różnią się tym, co się psuje, gdy coś pójdzie nie tak. Jeden wpycha trasę domyślną do tunelu, a potem ją omija; drugi zostawia tabelę główną w spokoju i wysyła jeden adres źródłowy do drugiej tabeli. Drugi jest czystszy i ma własne pułapki.

Dwa projekty, dwa różne promienie szkód

Projekt pełnego tunelu to to, co domyślnie robi większość klientów VPN: zastępuje trasę domyślną, by wszystko szło tunelem, a potem wyklucza to, co nie powinno. Łatwo go przemyśleć i trudno utrzymać wąskim, bo każda dodana usługa lokalna dziedziczy tunel, dopóki jej nie wykluczysz. Tryb awarii jest szeroki, ponieważ jedna zła trasa zabiera ze sobą łączność samego hosta.

Projekt z wyborem źródła idzie w przeciwną stronę. Tabela główna zostaje taka, jaka była, a jedna reguła polityki wysyła pakiety z konkretnego adresu lokalnego do tabeli z trasą domyślną przez tunel. Nic więcej się nie zmienia, co oznacza, że promień szkód to jeden adres.

Ta wąskość jest też ograniczeniem: projekt działa tylko wtedy, gdy pakiety wychodzące proxy naprawdę niosą ten adres.

Co robi ustawienie external w Dancie

Ustawienie external wybiera adresy, których proxy używa do połączeń wychodzących; nie dotyka polityki routingu jądra. Właśnie to rozdzielenie umożliwia drugi projekt, i tutaj ludzie błędnie czytają dokumentację. Skierowanie external na adres tunelu sprawia, że proxy inicjuje połączenia z tego adresu, a tabela routingu decyduje następnie, dokąd trafiają te pakiety.

Listener to osobna sprawa. Ogranicz internal do klientów, którzy powinni używać proxy, wymagaj uwierzytelniania i zamknij port firewallem, ponieważ otwarty listener nie jest cechą wyjścia VPN.

Potwierdź, że skonfigurowany adres naprawdę należy do tunelu w przestrzeni nazw sieci proxy.

Budowanie tabeli z wyborem źródła

Dla adresu TUN 10.90.0.2/24 z osiągalnym peerem pod 10.90.0.1 i numerem tabeli, którego nic innego nie używa, układ wygląda tak:

ip -4 route add table 100 10.90.0.0/24 dev tun0 src 10.90.0.2
ip -4 route add table 100 default via 10.90.0.1 dev tun0 metric 10
ip -4 route add table 100 unreachable default metric 32760
ip -4 rule add priority 1000 from 10.90.0.2/32 lookup 100

Trasa nieosiągalna to część, którą ludzie pomijają. Bez niej tabela, której trasa tunelowa znika, spada na zwykłą trasę domyślną i proxy po cichu wychodzi przez WAN. Z nią wyszukiwanie kończy się niepowodzeniem, co jest widoczną awarią zamiast cichego wycieku. Priorytet reguły także musi stać przed wszystkim innym, co pasuje do tego źródła.

Te wartości opisują jedną topologię. Peery punkt-punkt, adresacja net30 i klienci przydzielający inny prefiks potrzebują własnych tras, więc kopiuj kształt, a nie adresy.

Gdzie wycieka reguła źródła

Reguła pasująca do adresu źródłowego wpływa na każdy proces, który go używa, nie tylko na proxy. Jeśli inny demon przypisze ten sam adres, jego ruch także wejdzie w tunel, a awaria będzie wyglądać jak problem niezwiązanej usługi. Daj proxy adres, którego nic innego nie używa, albo zaakceptuj, że zakresem jest adres, a nie proces.

DNS to drugi wyciek. Gniazdo resolvera niekoniecznie używa źródła danych połączeń wychodzących proxy, więc wyszukiwania nazw nadal mogą wychodzić przez WAN. Testuj rozwiązywanie osobno od nawiązywania połączenia i zdecyduj, czy taki wynik jest akceptowalny.

IPv6 wymaga własnych reguł i tras, ponieważ układ IPv4 niczego o nim nie dowodzi.

Wybierz według awarii, którą możesz tolerować

Wybierz pełny tunel, gdy host ma być chroniony jako całość i możesz utrzymywać listę wyjątków. Wybierz routing oparty na źródle, gdy host musi zachować własną trasę, a przekierowana ma być tylko jedna usługa. Oba są uzasadnione; błędem jest wybrać jeden, a potem testować go tak, jakby był drugim.

Cokolwiek wybierzesz, weryfikuj z obu stron: żądanie przez proxy i bezpośrednie żądanie z hosta, z zapisanym zaobserwowanym adresem wyjścia dla każdego.

Jeśli tunel padnie, zdecyduj z góry, czy proxy ma zawieść, czy wrócić na zwykłą trasę, i pozwól tabeli routingu wyrazić tę decyzję.