Jak zablokować wyjście Linuksa, żeby nic nie wyciekło, gdy VPN padnie

Wyobraź sobie odtwarzacz multimedialny na domowym łączu, który powinien docierać do internetu tylko przez tunel. Gdy tunel padnie, aplikacja powinna się zatrzymać, a nie po cichu działać dalej przez interfejs fizyczny. Uzyskanie takiego zachowania to problem zapory, a nie routingu, i ta różnica ma znaczenie, bo trasę można zastąpić restartem demona, a filtr zostaje tam, gdzie go położono. Dalej zobaczymy, jak naprawdę decyduje ścieżka pakietu, a potem jak ograniczyć wyjątki, które pozwalają tunelowi połączyć się ponownie.

Wyjście lokalne to inny hak niż przekazywanie

Pakiet opuszczający aplikację na maszynie przechodzi przez hak wyjściowy; pakiet, który maszyna routuje dla innego hosta, przechodzi przez przekazywanie. Polityka, która wymienia tylko forward, ogranicza drugi przypadek i zostawia pierwszy szeroko otwarty, dlatego wiele blokad wyjścia wygląda poprawnie i nie robi nic. Dopasowanie interfejsu należy do tej samej reguły: oifname "tun0" accept przepuszcza ruch, który już został zroutowany przez tunel. Routing i filtrowanie również pozostają osobnymi decyzjami, więc trasa do dostawcy może istnieć, gdy filtr odrzuca pakiet. Na tym rozdzieleniu polegasz.

Brama, która przekazuje ruch innych urządzeń, potrzebuje obu haków. Zablokowanie samego wyjścia chroni samą maszynę i zostawia każdego klienta poniżej wolnym do wycieku.

Listę wyjątków pisz od punktu końcowego na zewnątrz

Zacznij od punktu końcowego tunelu: jeden adres docelowy lub niewielki zatwierdzony zbiór, protokół transportowy i port docelowy, na przykład udp dport 1194 ip daddr 203.0.113.7 accept. Jeśli klient rozwiązuje nazwę hosta, początkowa wymiana DNS potrzebuje własnej reguły ograniczonej do resolvera i do portu 53, a nie ogólnego zezwolenia na adres tego resolvera. Każdy wyjątek powinien wymieniać powód, dla którego istnieje. Zezwolenie na cały ruch UDP do portu VPN obejmuje znacznie więcej niż ta jedna uwierzytelniona usługa, którą miałeś na myśli.

Początkowe rozwiązywanie nazw to miejsce, w którym blokady zwykle gniją. Zbiór adresów odświeżany timerem potrzebuje zdefiniowanego zachowania, gdy odświeżenie się nie powiedzie, a tym zachowaniem nie może być otwarcie łącza, dopóki się nie uda. Odświeżaj przez tunel, dopóki tunel stoi, a w przeciwnym razie wróć do ostatniego znanego zdrowego punktu końcowego.

Lokalna administracja wymaga takiego samego traktowania. Podsieć zarządzania nie jest wiarygodna tylko dlatego, że jej adresy są prywatne, a reguła, która jej ufa, zaprasza drugą ścieżkę wokół blokady.

Dopasowanie interfejsu nie jest dowodem zdrowego tunelu

Reguły, które akceptują wszystko wychodzące z tun0, zakładają, że pakiet na tym interfejsie przyszedł z tunelu. Nazwy interfejsów są tworzone od nowa, a nazwa nie jest tożsamością kryptograficzną. Partner może też zniknąć, podczas gdy interfejs pozostaje w górze, co czyni regułę bardzo przekonującym działaniem pustym.

Śledzenie połączeń dodaje pokrewną pułapkę. Szeroka reguła dla ustanowionych połączeń odtwarza zezwolenie, które przepływ otrzymał wcześniej, więc sesja rozpoczęta przed upadkiem tunelu działa dalej. Ogranicz akceptację stanową do interfejsów i adresów, które naprawdę masz na myśli, inaczej zbudowałeś blokadę, która sama się otwiera. Reguły wejścia i wyjścia odpowiadają też na różne pytania, a utwardzanie jednej przy ignorowaniu drugiej zostawia maszynę osiągalną w kierunku, o którym nie pomyślałeś.

Co przetrwa awarię demona

Filtr zainstalowany przez skrypt, który uruchamia się po podniesieniu tunelu, znika razem z tunelem, dokładnie w chwili, gdy był potrzebny. Wczytuj blokadę przy starcie i pozwól demonowi zarządzać tylko jego wyjątkami.

Usunięcie trasy domyślnej też nie jest zamiennikiem. Trasa to stan, który demon posiada i przepisuje, a jej usunięcie może odebrać ścieżkę potrzebną do ponownego połączenia. IPv6 potrzebuje własnego planu, ponieważ odkrywanie sąsiadów i ogłoszenia routera to usługi łącza, które muszą działać dalej, gdy zwykły ruch jest zablokowany. DHCP należy do tej samej kategorii. Zapisz to jako wyjątki z celem, zamiast odkrywać je później jako awarie.

Ścieżka odzyskiwania przed wdrożeniem

Przetestuj blokadę tak, jak zawiedzie: uruchom bez tunelu, zabij demona, zmień punkt końcowy i połącz ponownie. W każdym przypadku aplikacje powinny się zatrzymać, a kanał odzyskiwania działać. Rób to z konsoli, bo zdalna powłoka to sesja, która najprawdopodobniej zostanie odcięta przez twoją własną regułę.

Potem sprawdź, dokąd zwykła aplikacja jeszcze dotrze, używając nieszkodliwego celu i żądania, które możesz zweryfikować. Wynik, którego chcesz, to odmowa na łączu i sukces przez tunel, a nie dwuznaczny limit czasu, który może znaczyć jedno i drugie. Trzymaj zestaw reguł pod tym samym właścicielem co resztę zapory, zamiast zastępować całą tabelę ze skryptu powłoki. Polityka, w której każde zezwolenie potrafi się uzasadnić, jest warta więcej niż długi zestaw reguł, którego nikt nie umie wyjaśnić.