Host iptables tylko z VPN: nazwij urządzenie tun, nie tun+

Zapis -o tun+ wygląda jak precyzyjna instrukcja, a w rzeczywistości jest symbolem wieloznacznym pasującym do każdego tunelu, jaki ma jądro. Drugi klient VPN, mostek kontenerowy albo interfejs pozostawiony przez zawieszoną sesję wszystkie go spełniają, a host przepuszcza wtedy ruch, któremu polityka miała zapobiec. Poniższa procedura ustala jedną nazwę urządzenia, porządkuje wyjątki tak, aby tunel mógł naprawdę powstać, i zostawia drogę powrotu, jeśli reguły wypadną źle. Każdy krok jest dość krótki, by cofnąć go osobno.

Krok 1: zapisz reguły, które masz teraz

Przed zmianą polityki domyślnej zapisz bieżący stan, aby wycofanie było poleceniem, a nie wspomnieniem. iptables-save > /root/iptables.pre zapisuje każdą tabelę do pliku, który możesz przywrócić, a drugi terminal z otwartą sesją root nie jest paranoją, gdy ustawiana polityka zrywa połączenie, które ją niesie. Jeśli pracujesz zdalnie, zaplanuj też flush jako wyłącznik bezpieczeństwa.

Następnie wypisz interfejsy, bo nazwa, którą założyłeś, jest nazwą, którą powinieneś był przeczytać: ip -br link pokazuje, co istnieje w tej chwili, a tunel nie pojawi się, dopóki nie zostanie podniesiony. Zapisuj nazwy urządzeń, czytając je.

Krok 2: nadaj tunelowi własną nazwę

OpenVPN przyjmuje dev tun_work w konfiguracji klienta, a Linux tworzy wtedy interfejs dokładnie o tej nazwie zamiast przydzielać tun0. Nazwa pozostaje stabilna między połączeniami, dopóki nic innego jej nie rości, i właśnie to czyni regułę nazywającą urządzenie sensowną.

Tam, gdzie nazwą nie można sterować, dopasuj adres tunelu albo znacznik pakietu. Oba działają, oba trudniej się czyta, i oba zawijają ciszej, gdy tunel się przenumerowuje. Tak czy inaczej, dopasuj jedną rzecz i powiedz jasno którą.

Krok 3: napisz politykę z wyjątkiem dla endpointu na początku

Host tylko z VPN to host z domyślnym odrzucaniem i krótką listą wyjątków, a wyjątek, który liczy się najbardziej, to ten, który pozwala tunelowi istnieć. Zbuduj go w tej kolejności, z regułą endpointu przed regułą urządzenia tunelu, żeby uzgadnianie miało gdzie trafić:

# allow the tunnel to be built, then everything the tunnel carries
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -A INPUT  -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -d 198.51.100.7 -p udp --dport 1194 -j ACCEPT
iptables -A OUTPUT -o tun_work -j ACCEPT
iptables -A INPUT  -i tun_work -j ACCEPT
iptables -A INPUT  -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Dosłowny adres endpointu i port należą do twojego dostawcy, nie do tej strony. Jeśli endpoint jest nazwą hosta, rozwiąż ją raz i ustal wynik, bo reguła nie potrafi wyszukać nazwy, a zmieniająca się odpowiedź po cichu zepsuje politykę po następnej zmianie DNS. Sprawdź też port, bo dostawcy, którzy przenoszą cię na TCP 443, będą inaczej potrzebować reguły, której nikt nie zapisał. Tunel działający tylko na jednym protokole to zwykle właśnie to przeoczenie, a nie usterka firewalla.

Na routerze ta sama forma trafia do łańcucha FORWARD dla klientów za nim, a własny ruch routera wymaga własnych reguł. Zestaw reguł obejmujący tylko przekazywane pakiety zostawia SSH i DNS na starej ścieżce, i tak router staje się nieosiągalny w chwili, gdy tunel wstaje.

Krok 4: sprawdź kolejność, nie tylko obecność

Reguły są oceniane po kolei, więc ACCEPT występujący wcześniej po prostu zasłania REJECT dodany później. Dopasowanie established i related pozwala odpowiedziom na własne zapytania wychodzące wrócić bez otwierania ogólnej ścieżki wejściowej, a umieszczenie go po akceptacji tunelu oznacza, że upadły tunel nadal przepuszcza ruch powrotny na własnym interfejsie.

Utrzymuj liczbę reguł na tyle małą, by zmieściły się na jednym ekranie. Zestaw reguł, którego nie możesz zaudytować, to ten, który będziesz łatać, dodając wyjątki na górze, i tak polityki domyślnego odrzucania zyskują z czasem krawędź domyślnego pozwolenia. Policz ACCEPT przed zmianą i po niej.

Krok 5: spraw, by przetrwał rozruch i rodzinę adresów

Reguły wprowadzone ręcznie znikają przy ponownym uruchomieniu, więc ładuj je z usługi firewalla dystrybucji albo z jednostki uruchamianej po powstaniu interfejsu tunelu. Odwołanie do tun_work w skrypcie uruchamianym przed startem OpenVPN to częsty sposób na pętlę rozruchową z odrzuconym ruchem.

Następnie sprawdź IPv6 osobno, bo dobra polityka domyślnego odrzucania dla IPv4 nic nie mówi o drugiej rodzinie. ip -6 route powie ci, czy host ma trasę, która mogłaby nieść ruch wokół tunelu obsługującego tylko IPv4, a ip6tables albo nftables potrzebuje własnych równoważnych reguł. Testuj z miejscem docelowym IPv6-only, zamiast ufać symetrii zestawu reguł.

Krok 6: zweryfikuj i bądź gotów przywrócić

Podnieś tunel, potwierdź, że zamierzona usługa działa, a potem spróbuj czegoś, co polityka powinna odrzucić. Przywróć za pomocą iptables-restore < /root/iptables.pre, jeśli odpowiedź cię zaskoczy, i dopiero wtedy zacznij edytować reguły. Trwałość plus sprawdzona ścieżka przywracania to to, co czyni z tego zmianę, którą możesz wykonać dwa razy.