iptables: pozwól klientom VPN dotrzeć tylko do jednego hosta

Reguła, której potrzebujesz, jest w FORWARD, a nie w INPUT. Zezwól na jedno miejsce docelowe dla puli VPN, odrzuć resztę, a potem udowodnij to licznikami i poleceniem wycofania.

Dwa zgłoszenia do pomocy technicznej, które wyglądają na niepowiązane, mają ostatecznie jedną przyczynę. W pierwszym administrator chce, aby serwer przyjmował połączenia tylko z tunelu; w drugim użytkownicy VPN mają docierać do jednego hosta wewnętrznego i niczego więcej. Obie zasady należą do FORWARD, a obie zwykle próbuje się w INPUT. Wynik wygląda jak zapora sieciowa, a zachowuje się jak element zastępczy.

Który łańcuch odpowiada na twoje pytanie

Pakiety, które klient VPN wysyła do hosta w sieci LAN albo dalej do internetu, są przekazywane przez jądro i oceniane w FORWARD. INPUT i OUTPUT widzą tylko ruch kończący się na samym serwerze lub z niego wychodzący. Dlatego odrzucanie wszystkiego, co nie przychodzi przez tun0, chroni własne nasłuchy serwera i zakończy także twoją sesję SSH, jeśli wcześniej nie zostaną dopuszczone ustanowione przepływy. Nie zmienia to niczego w kwestii, dokąd klienci mogą trafić.

Najpierw nazwij pytanie: kto może dotrzeć do serwera, albo dokąd mogą iść klienci. Większość sieci potrzebuje obu odpowiedzi, w różnych łańcuchach.

Najpierw stan, potem zezwolenie, potem odmowa

Lista zezwoleń działa tylko wtedy, gdy konkretne zezwolenie stoi powyżej ogólnej odmowy i gdy ruch powrotny jest dopuszczony powyżej obu. Wstaw reguły na jawnych pozycjach, a potem zrzuć łańcuch za pomocą iptables -S FORWARD, aby kolejność była widoczna, a nie założona.

POOL=10.99.0.0/24
iptables -I FORWARD 1 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -I FORWARD 2 -s "$POOL" -d 172.31.20.15 -p tcp -m multiport --dports 443,3389 -j ACCEPT
iptables -I FORWARD 3 -s "$POOL" -j REJECT

Dwa szczegóły decydują, czy przetrwa to kontakt z rzeczywistym ruchem. Bez reguły stanu odpowiedzi na właśnie dopuszczone połączenia są same oceniane wobec odmowy i odrzucane. Reguła LOG bez limitu może zapełnić małą partycję przy pierwszym skanowaniu, więc dodaj -m limit --limit 10/min, zanim zaczniesz dalej logować. REJECT zwraca błąd natychmiast, co jest łagodniejsze podczas strojenia listy; DROP odrzuca po cichu, więc każdy błąd wygląda jak przekroczenie czasu. Wybierz jedno świadomie i zapisz wybór w zapisie zmiany.

Przekazywanie i NAT muszą już działać

Filtrowanie nie może udowodnić, że ścieżka istnieje. Najpierw potwierdź, że jądro w ogóle przekazuje, i uczyń to ustawienie trwałym, a nie jednorazowym poleceniem w powłoce. Filtr to ostatnia warstwa, nie pierwsza.

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s "$POOL" -o eth0 -j MASQUERADE

To, gdzie należy maskowanie, zależy od tego, którędy klienci wychodzą. Jeśli wychodzą przez tunel do sieci zdalnej, reguła NAT trafia na ten interfejs, a nie na interfejs WAN. Potem patrz na liczniki: jeśli licznik POSTROUTING nigdy się nie rusza, a liczba akceptacji w FORWARD rośnie, ścieżka powrotna jest zepsuta, a filtr jest w porządku. Ten odczyt oszczędza popołudnie na przepisywaniu reguł, które nigdy nie były problemem.

Blok poczty należy o łańcuch dalej

Blokowanie portu 25 w INPUT zatrzymuje tylko pocztę adresowaną do serwera VPN. Zainfekowany klient wysyłający pocztę przez tunel jest przekazywany, więc blok musi stać w FORWARD obok 465 i 587. Jeśli jedna aplikacja legalnie przekazuje pocztę, umieść jej cel i port powyżej tej reguły.

iptables -I FORWARD 2 -s "$POOL" -p tcp -m multiport --dports 25,465,587 -j REJECT

Pozwól licznikowi odrzuceń działać przez tydzień, zanim cokolwiek innego zaostrzysz. Liczba, która przestaje rosnąć, to legalny przepływ, który właśnie zepsułeś.

Przeczytaj to z powrotem, a potem udowodnij z klienta

Czytaj zestaw reguł tak, jak raportuje go jądro, a nie tak, jak napisał go twój skrypt. Zacznij od iptables -S FORWARD, potem tabela NAT z iptables -t nat -L POSTROUTING -n -v, potem wpis conntrack dla badanego przepływu. Trzymaj polecenie wycofania albo zaplanowane czyszczenie, dopóki trwa praca. Każde wywołanie wymaga -w, inaczej dwóch administratorów zderzy się na blokadzie xtables. Nic z tego nie jest opcjonalne w oknie zmian.

Zakończ testem z klienta wewnątrz puli i z klienta spoza niej. Reguła, która działa tylko z maszyny, na której ją wpisałeś, nie jest polityką.

Powiązane artykuły