DNAT w kontenerze VPN: przekazywanie, nie INPUT

Żądanie przychodzi zaadresowane do adresu IP tunelu i opuszcza ten sam kontener zaadresowane do sąsiedniej usługi. Między tymi dwoma momentami DNAT przepisał cel, a pakiet przestał być wejściem dla kontenera VPN. Teraz jest ruchem przekazywanym, ocenianym przez inną regułę. Ta zmiana wyjaśnia, dlaczego reguła firewalla, która wygląda poprawnie dla adresu tunelu, nie ma żadnego wpływu na przetłumaczone połączenie.

Śledź pakiet po tłumaczeniu

Weź pulę klientów 10.90.0.0/24 i adres tunelu 10.90.0.1. Dwa kontenery stoją na jednym bridge'u: 192.0.2.2 uruchamia VPN, a 192.0.2.3 uruchamia aplikację. Klient łączy się z 10.90.0.1:8080, a reguła DNAT w przestrzeni nazw kontenera VPN przepisuje to na rzeczywisty adres i port aplikacji. Następnie trasa wysyła pakiet przez bridge. Te adresy są ilustracyjne, to nie przepis na wdrożenie.

Port, na którym aplikacja naprawdę nasłuchuje, może różnić się od dowolnego portu opublikowanego na hoście. Czytaj nasłuchiwacz wewnątrz kontenera, zamiast zakładać, że obie liczby się zgadzają.

Zgoda należy do ścieżki przekazywania

Kontener VPN potrzebuje przekazywania IP oraz decyzji o przekazywaniu ograniczonej do puli klientów, adresu aplikacji i zamierzonego portu. Ustanowione odpowiedzi potrzebują własnej zgody. Reguła pasująca do pierwotnego adresu tunelu nie będzie pasować po DNAT, ponieważ cel już się zmienił. Zgoda INPUT to niewłaściwy hak dla ruchu, który nie jest już adresowany do tego hosta.

Utrzymuj wąski zakres: jeden zakres źródeł, jeden cel, jedna usługa. Liberalna reguła przekazywania jest łatwiejsza do napisania i znacznie trudniejsza do obrony później.

docker exec vpn-container ip route get 192.0.2.3
docker exec vpn-container iptables -t nat -S
docker exec vpn-container iptables -S FORWARD

Łańcuchy Dockera to nie łańcuchy twojego kontenera

Reguły wewnątrz przestrzeni nazw kontenera to nie reguły hosta Dockera. Gdy ruch przechodzi z interfejsu tunelu na bridge, firewall bridge'a na hoście może podjąć inną decyzję. W przypadku backendu iptables Dockera udokumentowane łańcuchy przekazywania i punkty dopasowania po DNAT to miejsce, w którym ta decyzja się pojawia.

Dokumentacja firewalla Dockera opisuje te łańcuchy i dopasowanie po DNAT. Nie naprawiaj brakującej akceptacji przez wyłączenie zarządzania firewallem Dockera albo uczynienie każdego łańcucha liberalnym, ponieważ usuwa to granicę, której próbujesz użyć.

Uczyń drogę powrotną świadomym wyborem

Jeśli adres źródłowy jest zachowany, aplikacja widzi 10.90.0.x i musi kierować odpowiedzi z powrotem przez kontener VPN. W przeciwnym razie jej zwykła brama Dockera wyśle je do hosta, który nie posiada tunelu. Alternatywą jest wąsko ograniczone tłumaczenie źródła w kontenerze VPN, które upraszcza odpowiedź, ale ukrywa klienta przed aplikacją. Wybierz świadomie i zapisz, którą opcję wybrałeś.

Przetestuj nowe dozwolone połączenie ze zwykłego klienta, a następnie potwierdź, że niepowiązane porty pozostają zamknięte. Gdy pakiet zniknie, sprawdź przestrzeń nazw VPN, przestrzeń nazw aplikacji i własny log aplikacji. Ping do bramy bridge'a nie jest testem akceptacyjnym usługi.

Trzymaj reguły w obsługiwanej konfiguracji startowej kontenera, ponieważ interaktywne zmiany znikają przy jego ponownym utworzeniu. Publikacja portu na hoście to inna ścieżka ekspozycji i nie jest potrzebna tylko dlatego, że usługa jest osiągalna przez tunel.