Ogranicz regułę SNAT OpenVPN, zanim zepsuje nginx

Dwa błędy stale przychodzą z tego samego typu hosta. W pierwszym klienci uwierzytelniają się, a potem nie docierają nigdzie poza tunel. W drugim VPN wstaje i własna witryna serwera przestaje odpowiadać, co jest bardziej alarmujące, bo wygląda na szkody uboczne. Na VPS opartym na kontenerach oba zwykle sprowadzają się do tej samej krótkiej listy kontroli, a kolejność jest ważna: najpierw urządzenie, potem tłumaczenie, na końcu zakres.

Potwierdź, że kontener może utworzyć urządzenie tun

Nic innego się nie liczy, jeśli interfejs tunelu nie może istnieć. Sprawdź, czy /dev/net/tun istnieje i czy utworzenie urządzenia testowego się udaje, bo wielu dostawców domyślnie wyłącza tun w kontenerach. Żadna praca z firewallem nie zrekompensuje urządzenia, które nigdy nie powstało.

Jeśli urządzenia brakuje, może je włączyć tylko host lub dostawca. Inny plan jest często tańszy niż otwarty wątek wsparcia trwający tydzień. Potwierdź to, zanim przeczytasz choćby jedną linię logu OpenVPN. Inaczej spędzisz wieczór na dostrajaniu reguł, które nigdy nie zobaczą pakietu.

Zdecyduj, co MASQUERADE robi na tym interfejsie

Na zwykłej maszynie wirtualnej zwykłą regułą wyjścia jest POSTROUTING MASQUERADE z głównego interfejsu. W kontenerze OpenVZ widoczne urządzenie to często venet0, wirtualny interfejs zarządzany przez hosta, a nie routowana karta sieciowa, i MASQUERADE nie zawsze zachowuje się tam tak, jak zakładają poradniki.

Działająca forma to jawna translacja na adres, który klienci już osiągają, z dozwolonym przekazywaniem w obu kierunkach. Zastąpienie pool z konfiguracji serwera jest równie ważne jak zastąpienie adresu. Przeczytaj każdą linię przed wklejeniem.

iptables -t nat -A POSTROUTING -o venet0 -s 10.8.0.0/24 -j SNAT --to-source 203.0.113.10
iptables -A FORWARD -i tun0 -j ACCEPT
iptables -A FORWARD -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Bez reguł przekazywania translacja nadal się odbywa, a jądro nadal odmawia przekazywania. Ta kombinacja daje mylący stan, w którym liczniki reguły NAT rosną, podczas gdy klient nic nie otrzymuje. Oba wiersze FORWARD muszą też stać przed każdą szeroką regułą drop w tym samym łańcuchu. Kolejność jest częścią konfiguracji, a nie szczegółem implementacji.

Ogranicz regułę do jednego pool i jednego interfejsu

Drugi objaw ma inną przyczynę: reguła POSTROUTING bez ograniczenia źródła i bez ograniczenia wyjścia. Taka reguła przepisuje każdy pakiet opuszczający host.

Usługi zależne od pierwotnego źródła zachowują się wtedy źle. Serwer WWW za lokalnym proxy może przestać odpowiadać, a restart niczego nie zmienia, bo reguła wciąż jest na ścieżce. Dotknięty jest też ruch, który host wysyła na własny publiczny adres, dlatego awaria może wyglądać na problem DNS lub certyfikatu, a nie firewalla. Regułę prawie na pewno dodano, aby naprawić pierwszy objaw.

Rozwiązaniem jest zawężenie dopasowania do pool tunelu i interfejsu wyjścia, a następnie dodanie jednej reguły na pool zamiast rozszerzania jednej reguły na kilka.

Uczyń reguły trwałymi i ustal, kto jeszcze jest ich właścicielem

Reguły dodane ręcznie znikają po restarcie, więc zapisz je za pomocą iptables-save lub zarządzaj nimi przez netfilter-persistent tam, gdzie jest zainstalowany. Potwierdź, że przywracanie działa przed startem OpenVPN. Potem zrestartuj raz celowo, zamiast odkrywać lukę podczas incydentu.

Na hoście kontenerowym potwierdź też, że plik trwałości znajduje się w zapisywalnym magazynie kontenera i że dostawca nie zastępuje filtrowania przy starcie. Niektóre platformy zarządzają polityką poza kontenerem, gdzie lokalne reguły są albo ignorowane, albo kolidują z regułami samego hosta.

Zweryfikuj licznikami i jednym przechwyconym przepływem

Z podłączonego klienta sprawdź publiczny adres raportowany przez usługę zewnętrzną. Jeśli zgadza się z adresem serwera, translacja działa; jeśli nie, pakiet wychodzi inną drogą lub nie wychodzi wcale. Następnie przetestuj zarówno usługę hostowaną na serwerze, jak i usługę w publicznym internecie, bo idą różnymi drogami przez ten sam zestaw reguł.

Na serwerze odczytaj liczniki pakietów na regułach NAT i FORWARD za pomocą iptables -t nat -L -v -n i obejrzyj jeden przepływ w przechwyceniu. Jeśli adres klienta pojawia się w przechwyceniu i nie następuje odpowiedź, luka jest na drodze powrotnej lub w filtrowaniu dostawcy, a nie w profilu klienta. Porównaj przechwycone źródło z adresem, na który tłumaczy reguła, bo rozbieżność oznacza, że jako pierwsza dopasowała inna reguła. Jeden zaobserwowany przepływ rozstrzyga więcej niż strona lektury konfiguracji.

Trzymaj pool, przetłumaczony adres i nazwę interfejsu razem w rejestrze zmian. Reguła poprawna dla jednego pool błędnie tłumaczy następny.