Przełącznik awaryjny UFW blokuje Twój VPN? Zezwól partnerowi

Przeszedłeś listę kontrolną: odmów ruchu wychodzącego, zezwól na tunel, włącz ufw. Potem klient czeka na uścisk dłoni i nigdy się nie łączy albo łączy się i żadna strona się nie ładuje. Oba błędy mają to samo źródło. Brakuje reguły, która pozwala tunelowi istnieć, bo tunel nie jest interfejsem, z którego wychodzą Twoje pakiety.

Dlaczego zezwolenie na tun0 początkowo do niczego nie pasuje

tun0 tworzy klient po tym, jak istnieje sesja. Datagramy, które budują tę sesję, to zwykłe pakiety UDP adresowane do dostawcy na port 1194, i wychodzą przez wlan0 lub eth0 z fizycznym adresem źródłowym. allow out on tun0 pasuje tylko do ruchu, którego interfejsem wyjściowym jest tun0, więc podczas uścisku dłoni nie pasuje do niczego.

Połóż default deny outgoing na wierzchu, a zewnętrzne pakiety są odrzucane, zanim interfejs w ogóle się pojawi. Klient ponawia, kończy się czas i zgłasza błąd TLS lub uścisku dłoni, co wysyła ludzi na poszukiwania w certyfikatach i MTU, podczas gdy zapora po cichu zjada połączenie. Reguła, która miała powstrzymać Twój ruch, uniemożliwia powstrzymanie tego ruchu.

Odrutowy fix czyni wyciek trwałym. sudo ufw allow out on wlan0, albo przywrócenie domyślnego zezwolenia, podnosi tunel i zostawia maszynę bez przełącznika awaryjnego: następnym razem, gdy tunel padnie, wszystko wraca przez fizyczny adapter. Straciłem popołudnie dokładnie na tej parze zmian, zanim ustaliłem, który pakiet naprawdę filtruję.

Czego potrzebują dwa zestawy pakietów

Twój ruch przechodzi przez zaporę dwa razy, w dwóch postaciach. Pakiet wewnętrzny idzie od adresu tunelu na zewnątrz przez tun0. Pakiet zewnętrzny idzie od adresu fizycznego do partnera i to jedyna rzecz widoczna na drucie. Jedna reguła na postać:

sudo ufw allow out on tun0
sudo ufw allow out to 203.0.113.10 port 1194 proto udp
sudo ufw allow out to 203.0.113.10 port 443 proto tcp comment 'tcp fallback'

Zastąp adres i port tymi z własnego profilu. Partnerzy WireGuard zwykle odpowiadają na 51820/udp; profile OpenVPN jadące przez TCP 443 potrzebują zamiast tego tego portu. Szczegóły się różnią, postać nie: obie reguły są wąskie i razem określają jedyne cele, do których maszyna może dotrzeć, gdy tunel leży.

Kolejność to drugi mit. Przy surowym iptables czytasz łańcuch z góry na dół i zastanawiasz się, która reguła wygrywa. ufw nie jest cienkim opakowaniem wpisanej listy; kompiluje Twoje reguły do własnych łańcuchów i wybiera punkty wstawienia. ufw status wypisuje je w kolejności ufw, nie Twojej. Gdy reguła wygląda na ignorowaną, porównaj ufw show added ze skompilowanym zbiorem z iptables -S | grep ufw zanim cokolwiek przepiszesz.

Wyjątek musi pozostać szeroki na jeden adres

Reguła partnera jest poprawna tylko dopóki wymienia adres, na który dzwoni klient. Dostawcy rotują punkty końcowe, a profil rozwiązujący nazwę hosta pójdzie za zmianą DNS na nowy adres, podczas gdy reguła nadal wskazuje stary. Gdy tunel działający od miesięcy przestaje się podnosić, porównaj adres z reguły z tym, którego szuka klient, zanim cokolwiek rozszerzysz.

Rozszerzenie na całą podsieć albo na każdy cel na porcie 1194 zamienia politykę z powrotem w zaporę z dziurą. Wyjątkiem jest przełącznik awaryjny; gdy jest szeroki, nie ma już czego wyłączać. Trzymaj go na jednym adresie i zostaw komentarz z nazwą profilu i dostawcy, do którego należy, bo za pół roku adres będzie wyglądał arbitralnie.

Rozwiązywanie nazw zasługuje na własną linię. Wyszukiwanie odbywa się zanim tunel istnieje, przez interfejs fizyczny, więc ścisła polityka odmowy ruchu wychodzącego może zostawić klienta bez możliwości znalezienia własnego serwera. Zezwól na port 53 do adresu swojego resolvera albo rozwiąż raz i przypnij adres w profilu. Zezwalanie na DNS na każdym interfejsie to decyzja, nie domyślne ustawienie.

Zbuduj politykę, zanim tunel będzie potrzebny

ufw enable stosuje całą politykę naraz i przeładowuje swoje łańcuchy, a zmiana polityki domyślnej na działającej zaporze też je przeładowuje. podręcznik ufw ostrzega, że może to zerwać istniejące połączenia, takie jak SSH. Dlatego polecenia idą w tej kolejności, z regułą SSH przed włączeniem i otwartą sesją konsoli:

sudo ufw default deny incoming
sudo ufw default deny outgoing
sudo ufw allow out on tun0
sudo ufw allow out to 203.0.113.10 port 1194 proto udp
sudo ufw allow 22/tcp
sudo ufw enable
sudo ufw status verbose

ufw reset celowo pominięto w tym bloku. Usuwa każdą regułę i wyłącza zaporę, a na zdalnym hoście to właśnie następne włączenie zrywa Twoją sesję. Jeśli mimo to zresetujesz, dodaj regułę SSH i potwierdź drugą drogę powrotu przez konsolę, zanim pójdziesz dalej.

Kolejność nie jest kosmetyczna. Reguły dodane podczas działania ufw niczego nie płuczą, ale w chwili, gdy odwracasz politykę domyślną, łańcuchy są przeładowywane, a sesja, którą pozwalała stara polityka, odchodzi razem z nimi. Zrób wartości domyślne, zezwolenia i włączenie w jednym przebiegu, póki masz jeszcze drogę do środka, która nie zależy od maszyny.

Sprawdź stan zablokowania i zachowaj wycofanie

Niesprawdzony przełącznik awaryjny to zgadywanie. Rozłącz klienta celowo i spróbuj wczytać stronę: musi się nie udać. Połącz ponownie, a musi się podnieść bez dotykania żadnej reguły. sudo ufw status verbose potwierdza wartości domyślne i stan logowania, a ufw status numbered pokazuje, którą regułę testową usunąć, gdy przeżyje swój cel.

Trzymaj skrypt odwrotny obok skryptu prostego. Maszyna z odmową ruchu wychodzącego i martwym tunelem nie może pobrać własnej naprawy, więc wycofanie musi leżeć na dysku i być czytelne z konsoli:

sudo ufw reset
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw enable

Uruchom go, gdy tunel już leży i reguły trzeba zdjąć, nie jako rutynowy krok. Zanim zamkniesz terminal, cztery rzeczy muszą być prawdziwe: reguła partnera wymienia dokładnie jeden adres, DNS ma nazwany wyjątek, włączenie przyszło po zezwoleniach, a zerwanie tunelu zabija zwykły ruch, nie zabijając klienta na dobre.