Skrypt wyłączający czy reguła firewalla: co zatrzymuje wyciek?

Dwa projekty obiecują to samo: gdy tunel padnie, nic nie wychodzi na zewnątrz otwartym tekstem. Jeden uruchamia skrypt przy zamykaniu i tnie interfejsy. Drugi zostawia regułę firewalla w mocy i niczego nie żąda od klienta VPN. Różnią się tym, kto ma uprawnienia do działania, co dzieje się w luce i jak maszyna wraca potem do sieci. Porównanie ich w tych trzech punktach jest użyteczniejsze niż spieranie się, który jest surowszy.

Ta sama praca dwoma mechanizmami

Klient może uruchamiać haki, gdy tunel wstaje i gdy jest zamykany, o ile profil pozwala na uruchamianie skryptów. Ten hak działa w cyklu życia klienta, w momencie, gdy połączenie się zamyka. Reguła firewalla natomiast należy do systemu i nie obchodzi jej, czy klient działa, zawiesił się czy został zabity.

Ta tabela to cały argument. Skrypt, który działa tylko przy czystym zamknięciu, obejmuje przypadek, który martwił cię najmniej; ważny przypadek to awaria albo zniknięcie sieci, a żaden z nich nie daje czystego zamknięcia.

Co hak zamykający może, a czego nie może

Udokumentowany wzorzec przechodzi przez interfejsy sieciowe i opuszcza wszystko poza loopback. Gdy urządzenie fizyczne jest wyłączone, nic nie może uciec poza tunel, i dokładnie o to chodzi.

#!/bin/sh
for dev in /sys/class/net/*; do
  name=$(basename "$dev")
  [ "$name" = lo ] || ip link set dev "$name" down
done

Opuszcza też sieć lokalną, każdą usługę, którą maszyna hostuje, i ścieżkę, której użyłbyś do naprawy problemu. Na laptopie urządzenie bezprzewodowe czasem wymaga potem ręcznego przełączenia, więc krótka przerwa zmienia się w sesję naprawczą. Co gorsza, hak może w ogóle nie mieć na to pozwolenia: gdy klient zrzeka się uprawnień, skrypt zamykający działa na koncie bez uprawnień i każda zmiana interfejsu kończy się błędem uprawnień zapisanym w chwili, gdy nikt nie czyta logu.

Sprawdź, jak klient jest uruchamiany, zanim zaufasz hakowi. Skrypt, który działa przy ręcznym uruchomieniu jako root, niczego nie dowodzi o usłudze startującej przy bootowaniu.

Co reguła firewalla robi inaczej

Reguła, która pozwala tylko na ruch tunelu, działa dalej, gdy proces klienta zniknie, bo jądro nie zależy od tego procesu. Reguła jest też węższa: blokuje dokładnie te przepływy, do których pasuje, i zostawia w spokoju loopback, lokalną podsieć i ścieżkę odzyskiwania, dlatego nie zostawia maszyny bez wyjścia.

Cena jest taka, że regułę musi napisać i utrzymywać ten, kto posiada firewall hosta, i musi ona nazwać urządzenie tunelu, które klient naprawdę tworzy. To znaczy, że regułę i profil trzeba utrzymywać razem; przemianowany interfejs zostawia firewall, który blokuje wszystko i niczego nie wyjaśnia.

Żaden z tych mechanizmów nie czyni drugiego zbędnym. Reguła firewalla, która po edycji nigdy nie jest przeładowywana, jest tak fikcyjna jak skrypt, który nigdy się nie uruchamia.

persist-tun decyduje, czy luka istnieje

Gdy urządzenie tunelu przetrwa rozłączenie, przetrwają też trasy, które do niego prowadzą. Ruch jest wtedy odrzucany, a nie przekierowywany, więc trasa domyślna nie wraca do fizycznej bramy. To zachowanie sprawia, że wyciek jest mało prawdopodobny jeszcze zanim w grę wejdzie jakakolwiek reguła firewalla.

Bez tego ustawienia urządzenie jest usuwane razem z trasami, a trasa domyślna może znów wskazywać fizyczną bramę. Czy tak się stanie, zależy od platformy i klienta, i właśnie dlatego stan trzeba obserwować, a nie zakładać. Traktuj ustawienie jako część kill switcha, nie jako opcję wydajności.

Utrzymaj ścieżkę ponownego połączenia i przetestuj cztery stany

Ścisła blokada może też uniemożliwić klientowi ponowne połączenie, bo klient nadal potrzebuje trasy do serwera przez fizyczną bramę, podczas gdy wszystko inne jest odrzucane. Zainstaluj trasę hosta dla tego jednego adresu, zanim tunel wstanie, i najpierw rozwiąż nazwę, bo DNS może być zablokowany do czasu, gdy będzie potrzebny.

ip route add 198.51.100.20/32 via 192.168.0.1 dev wlan0

Potem sprawdzaj stany, a nie etykietę. Przejdź świadomie przez cztery momenty: zimny start bez tunelu, zdrową sesję, zerwanie, o które nikt nie prosił, i sesję po odzyskaniu. W każdym momencie odczytaj trasę domyślną i wykonaj jedno żądanie, którego adres wyjściowy jest widoczny. Aplikacja, która poddaje się, gdy tunel jest wyłączony, nic nie mówi o kliencie poczty ani o aktualizatorze, więc powtórz ostatnią kontrolę z jedną aplikacją w tle. Zapisz regułę, nazwy interfejsów i kroki odzyskiwania, bo kill switch, którego nikt nie może zweryfikować, jest tylko plotką.