Dotrzeć do interfejsu web w kontenerze VPN: wybierz właściciela portu

Aplikacja współdzieli przestrzeń nazw VPN, więc port należy do kontenera VPN. Powiąż nasłuch prawidłowo, publikuj u właściciela i utrzymuj wąską ścieżkę.

Z aplikacją nie jest nic nie tak i z tunelem nie jest nic nie tak, a mimo to pulpit się nie wczytuje. Gdy usługa działa z network_mode: service:vpn, współdzieli przestrzeń nazw sieci kontenera VPN, co oznacza, że jej nasłuch i opublikowane porty należą do tej przestrzeni nazw, a nie do usługi. Wynikają z tego trzy decyzje: gdzie aplikacja się wiąże, który kontener publikuje port i jak wąska jest ścieżka zarządzania. Ustaw je w złej kolejności, a każde pojedyncze ustawienie będzie wyglądać poprawnie, podczas gdy kombinacja nie może działać.

Kto jest właścicielem przestrzeni nazw portu

We współdzielonej przestrzeni nazw dodanie wpisu ports: do usługi zależnej nic nie daje, a kilka opcji sieciowych nie jest dla niej obsługiwanych z założenia. Publikuj zamiast tego na kontenerze, który jest właścicielem przestrzeni nazw. Ten kontener to także ten, którego adres pojawia się na hoście, więc mapowanie czyta się jako jeden wpis, a nie jeden na usługę.

services:
  vpn:
    image: vpn-client-image
    cap_add: [NET_ADMIN]
    ports:
      - "127.0.0.1:8080:8080"
  app:
    network_mode: "service:vpn"

Zwróć uwagę na adres po lewej stronie mapowania. Powiązanie z 127.0.0.1 utrzymuje opublikowany port na loopbacku hosta, czego zwykle chce interfejs zarządzania. Powiązanie z 0.0.0.0 wystawia go na każdym interfejsie hosta, a to inna decyzja bezpieczeństwa, nie wygoda.

Spraw, by aplikacja nasłuchiwała tam, gdzie przestrzeń nazw tego oczekuje

Nasłuch powiązany z 127.0.0.1 wewnątrz przestrzeni nazw jest osiągalny tylko z jej wnętrza. Opublikowane porty hosta przychodzą z zewnątrz, więc aplikacja musi powiązać szerszy adres, aby mapowanie działało. To zmiana jednej linii na większości serwerów, i właśnie ten krok się pomija po skopiowaniu poradnika utwardzania napisanego dla wdrożenia bez kontenerów.

docker compose exec app ss -lntp
docker port vpn
curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8080/

Lista nasłuchów w aplikacji mówi prawdę o adresie powiązania, a docker port pokazuje, co właściciel faktycznie opublikował. Jeśli pierwszy pokazuje 127.0.0.1, a drugi pokazuje mapowanie na hoście, znalazłeś niezgodność bez dotykania konfiguracji VPN.

Wybierz, jak wchodzi ścieżka zarządzania

Istnieją trzy rozsądne układy. Publikuj na kontenerze VPN i docieraj do niego z hosta lub z sieci lokalnej. Postaw odwrotne proxy przed przestrzenią nazw i daj proxy jedyny wystawiony port. Albo utrzymuj pulpit osiągalny tylko z wnętrza przestrzeni nazw przez sesję exec lub tunel SSH, co jest najmniejszym wystawieniem i najmniejszą wygodą.

Który pasuje, zależy od tego, kto i skąd potrzebuje interfejsu. Jeden administrator na tym samym hoście zadowoli się powiązaniem z loopbackiem. Zespół docierający przez VPN potrzebuje przemyślanej ścieżki i nazwanego właściciela. Wybór opcji proxy daje TLS i dzienniki dostępu, kosztem jeszcze jednego komponentu do utrzymania.

Otwórz port zarządzania, nie otwierając wszystkiego

Własna polityka dostępu lokalnego lub blokady klienta VPN może odrzucić przychodzące żądanie zarządzania nawet wtedy, gdy tunel wychodzący działa bezbłędnie. Zezwól na jeden udokumentowany wyjątek dla zamierzonego źródła i portu, a następnie potwierdź, że zwykła ochrona tunelu się nie zmieniła. Wyłączenie kill switcha, aby pulpit się wczytał, wymienia realną kontrolę na kartę przeglądarki.

Zostaw włączone uwierzytelnianie samej aplikacji. Przebywanie w stosie połączonym z VPN nie upoważnia każdego lokalnego użytkownika ani każdego urządzenia, które może dotrzeć do hosta, a panel administracyjny bez uwierzytelniania za tunelem nadal jest panelem bez uwierzytelniania.

Zweryfikuj z urządzenia zarządzającego, a potem zweryfikuj ponownie później

Testuj z maszyny, która faktycznie będzie zarządzać usługą, nie z hosta, a następnie zweryfikuj osobno wymaganą przez aplikację ścieżkę internetową. Sukces zarządzania dowodzi jednego kierunku i nic nie mówi o ruchu wychodzącym.

Przetestuj ponownie po odtworzeniu stosu. Wymieniony właściciel sieci zmienia przestrzeń nazw, do której przyłącza się aplikacja, a URL, który działał przed aktualizacją, może potem na nic nie wskazywać. Zapisz opublikowane mapowanie i adres powiązania, aby następna przebudowa była dwuminutowym sprawdzeniem, a nie powtórzonym dochodzeniem.

Powiązane artykuły