Publikowanie portów Dockera i źródła VPN: dwa dopasowania, które pomijasz

Reguła mówi: zezwól na adres serwera VPN do opublikowanej usługi, a połączenie nadal spada. Taki wynik jest częsty i nie jest błędem Dockera. Dwa osobne dopasowania są błędne: źródło, które zapisałeś, może nie być źródłem, które odbiera host, a port, który zapisałeś, może nie być portem, który widzi filtr. Naprawa obu wymaga spojrzenia na ścieżkę pakietu, a nie na schemat usługi.

Mit: zezwól serwerowi VPN i gotowe

Routowany VPN może zachować adres tunelu klienta aż do hosta Dockera. Brama, która wykonuje tłumaczenie źródła, może zastąpić ten adres swoim. Oba rozwiązania są zgodne z prawem i dają różne źródła dla tej samej czynności użytkownika.

Zatem sformułowanie IP serwera VPN opisuje założenie, a nie obserwację. Dopóki nie wiesz, które z dwóch rozwiązań masz przed sobą, reguła jest przypuszczeniem.

Źródło: pula klientów czy przetłumaczona brama

Sprawdź cztery rzeczy po kolei. Po pierwsze, pulę adresów klientów, na przykład 10.90.0.0/24. Po drugie, czy brama tłumaczy tę pulę, zanim dotrze do hosta. Po trzecie, źródło, które host faktycznie obserwuje dla jednego nowego połączenia. Po czwarte, czy uwierzytelnianie aplikacji rozróżnia poszczególnych użytkowników, bo współdzielony przetłumaczony adres tego nie potrafi.

Jeśli pula zostanie zachowana, reguła dopasowująca tylko publiczny adres bramy pomija każdego klienta. Jeśli brama tłumaczy celowo, zezwolenie na przetłumaczony adres wpuszcza każdego użytkownika za nim, co może być dopuszczalne dla usługi z własnym logowaniem i niedopuszczalne dla wszystkiego innego.

Port: DNAT zmienia numer, który dopasowujesz

Przy zwykłym publikowaniu przez most Linuksa z iptables Dockera mapowanie hosta z 8443 na port kontenera 443 jest tłumaczone, zanim uruchomi się filtr przekazywania. Pakiet dociera do filtra z portem docelowym 443. Reguła dopasowująca 8443 w tym momencie nigdy się nie uruchamia, choć klient wpisał 8443.

Opublikowany port nadal istnieje w śledzeniu połączeń, dlatego można tam dopasować pierwotne miejsce docelowe, gdy naprawdę jest potrzebne.

Zdecyduj, który numer wyraża intencję. Dopasuj port kontenera po DNAT, gdy reguła chroni usługę wewnątrz kontenera. Dopasuj pierwotne miejsce docelowe z opcją conntrack, gdy reguła musi opisać, o co prosił klient, i zaakceptuj dodatkowy koszt dopasowania oraz staranność w kolejności reguł, które się z tym wiążą.

Łańcuch: DOCKER-USER, nie INPUT

Przewodnik Dockera po iptables umieszcza politykę przekazywania użytkownika w łańcuchu DOCKER-USER, który jest oceniany przed własnymi regułami przekazywania Dockera. Reguła skopiowana z usługi hosta do łańcucha INPUT filtruje ruch adresowany do hosta, a nie ruch przekazywany do kontenera. Ten błąd daje regułę, która wygląda poprawnie i nie ma żadnego wpływu na ścieżkę kontenera.

Trzymaj zakres źródłowy, efektywny port docelowy, protokół i interfejs wejściowy razem w tej samej regule. Zezwolenie tylko po źródle dla każdego przekazywanego miejsca docelowego jest szersze niż zezwolenie na jedną opublikowaną usługę.

Zweryfikuj świeżymi połączeniami

Przetestuj oba kierunki nowymi połączeniami: jednego dozwolonego klienta VPN i jedno źródło, które powinno pozostać odrzucone. Istniejący stan połączenia może utrzymać sesję przy życiu po zmianie polityki, więc stare połączenie niczego nie dowodzi o nowej regule. Następnie sprawdź ścieżkę odpowiedzi, ponieważ kontener nadal musi trasować z powrotem do źródła, które widzi.

Kolejność łańcuchów i zachowanie tłumaczenia portów za tymi sprawdzeniami opisuje przewodnik Dockera po iptables. Przeczytaj go przed skopiowaniem przepisu i potwierdź, którego backendu używa zainstalowany Docker, ponieważ backend nftables integruje politykę inaczej.