Publikowanie portów Dockera a VPN: dokąd trafia odpowiedź

Opublikowany kontener odpowiada z własnego adresu przed odwrotnym NAT. Dwa projekty mogą utrzymać tę odpowiedź na publicznej ścieżce, przy różnych kosztach.

Host nadal odpowiada na SSH po podniesieniu VPN z pełnym tunelem, a usługa opublikowana przez Dockera na tej samej maszynie milknie. Z nasłuchiwaczem wszystko jest w porządku: kontener działa, mapowanie portu istnieje, a pakiet dociera. Kontener jest zdrowy i żądanie rzeczywiście do niego trafia. Różnica polega na tym, skąd zaczyna się odpowiedź, gdy Linux wybiera trasę, i ta różnica decyduje, którego z dwóch projektów poniżej potrzebujesz.

Prześledź tuple przez NAT docelowy

Weź host pod adresem 192.0.2.10, który publikuje TCP 2222 do kontenera pod adresem 172.30.240.5:22. Żądanie z 198.51.100.25 jest tłumaczone, zanim dotrze do kontenera, a kontener odpowiada jako on sam.

WAN request:      198.51.100.25 -> 192.0.2.10:2222
after DNAT:       198.51.100.25 -> 172.30.240.5:22
container reply:  172.30.240.5:22 -> 198.51.100.25

Przy decyzji o trasie hosta odpowiedź nadal niesie adres źródłowy kontenera. Odwrotne tłumaczenie przywraca opublikowany tuple dopiero później, i właśnie dlatego pakiet wygląda źle dokładnie w chwili wybierania trasy.

Dlaczego reguła tylko dla hosta to pomija

Reguła, która wybiera tabelę WAN tylko dla pakietów z 192.0.2.10, obejmuje własne demony hosta i całkowicie pomija tę przekazaną odpowiedź. Adres źródłowy odpowiedzi to 172.30.240.5, a nie host.

Nadmierną korektą jest kierowanie wszystkiego z kontenera przez WAN, co zwalnia z VPN także niepowiązane połączenia wychodzące kontenera. To inna polityka niż zamówiona i zwykle kogoś później zaskakuje.

Dopasowanie po DNAT to inny hook

Dokumentacja Dockera dotycząca zapór sieciowych zauważa, że zwykłe filtrowanie użytkownika widzi cel po DNAT, więc dopasowanie opublikowanego portu 2222 w zwykłej regule nie jest tym samym co dopasowanie portu 22 kontenera. Jeśli oryginalny tuple ma znaczenie, użyj obsługiwanego mechanizmu oryginalnego celu zamiast zgadywać, który port jest widoczny.

To zamieszanie z hookami tworzy reguły, które wyglądają poprawnie i nigdy nie pasują. Sprawdź liczniki na samej regule, zanim przepiszesz politykę. Reguła bez żadnych trafień mówi ci, że jest oceniana w miejscu, do którego pakiet nigdy nie dociera.

Projekt A: nieść decyzję jako stan połączenia

Znacznik połączenia może nieść decyzję o wejściu przez tłumaczenie, ale musi zostać przywrócony na pakiecie przed tym wyszukaniem trasy, które ma znaczenie. Etapy są następujące:

  1. Zarezerwuj pole znacznika i priorytet reguły, które nie kolidują z Dockerem, VPN ani innym właścicielem polityki.
  2. Zidentyfikuj tylko zamierzone nowe połączenie WAN w punkcie przed DNAT, w którym dostępne jest śledzenie połączeń.
  3. Zapisz decyzję na znaczniku połączenia, nie wciskając samego oryginalnego żądania do tabeli WAN.
  4. W kierunku odpowiedzi przywróć na pakiecie tylko własne bity znacznika przed routingiem.
  5. Wybierz pełną tabelę WAN wystarczająco wcześnie, aby reguła VPN nie mogła wygrać pierwsza.

Ta tabela potrzebuje rzeczywistych tras połączonych i bramy. Potrzebuje też zdefiniowanego zachowania, gdy trasy brakuje. Ciche wpadnięcie do tunelu to najgorszy wynik, bo konfiguracja nadal wygląda na działającą. Zamiast tego zawiedź w sposób zamknięty i zaloguj to.

Projekt B: zakończ na hoście

Celowo skonfigurowany frontend po stronie hosta, na przykład proxy TCP lub odwrotne proxy przed kontenerem, utrzymuje odpowiedź pochodzącą z adresu hosta. Reguły napisane dla hosta zachowują się wtedy zgodnie z oczekiwaniami, a kontener zostaje w swojej sieci prywatnej.

Kosztem jest kolejny ruchomy element z własną konfiguracją, obsługą adresów źródłowych i kontrolami dostępu. Zwykle jest to prostsza obsługiwana granica i często jest to właściwa odpowiedź, gdy politykę routingu utrzymywałaby jedna osoba, która może odejść.

Zweryfikuj zmianę, nie zamiar

Otwórz nowe autoryzowane połączenie od strony publicznej i potwierdź, że odpowiedź wychodzi zamierzonym interfejsem. Następnie sprawdź, czy niepowiązane żądanie zainicjowane przez kontener nadal podąża za VPN.

Nie czyść tabeli połączeń maszyny, aby przetestować jedną regułę: istniejące wpisy zachowują wcześniejsze mapowanie, a czyszczenie psuje wszystko inne na hoście. Opublikowanie portu definiuje osiągalność. Nie definiuje ścieżki odpowiedzi. Zapisz wybrany projekt wraz z nazwami jego tabel, aby następna osoba nie musiała odkrywać go ponownie podczas incydentu.

Powiązane artykuły