Dostat se k webovému rozhraní uvnitř kontejneru VPN: vyberte vlastníka portu

Aplikace sdílí jmenný prostor VPN, takže port patří kontejneru VPN. Přivažte naslouchač správně, publikujte na vlastníkovi a držte cestu úzkou.

S aplikací není nic špatně a s tunelem není nic špatně, a přesto se panel nenačte. Když služba běží s network_mode: service:vpn, sdílí síťový jmenný prostor kontejneru VPN, což znamená, že její naslouchač a její publikované porty patří tomuto jmennému prostoru, ne službě. Z toho plynou tři rozhodnutí: kam se aplikace přiváže, který kontejner port publikuje a jak úzká je cesta správy. Udělejte je ve špatném pořadí a každé jednotlivé nastavení vypadá správně, zatímco kombinace fungovat nemůže.

Kdo vlastní jmenný prostor portu

Ve sdíleném jmenném prostoru nepřinese přidání záznamu ports: závislé službě nic užitečného a několik síťových voleb pro ni podle návrhu není podporováno. Publikujte místo toho na kontejneru, který jmenný prostor vlastní. Tento kontejner je také ten, jehož adresa se objevuje na hostiteli, takže se mapování čte jako jeden záznam, ne jeden na službu.

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

Všimněte si adresy nalevo od mapování. Přivázání na 127.0.0.1 ponechá publikovaný port na loopbacku hostitele, což je obvykle to, co správní rozhraní chce. Přivázání na 0.0.0.0 ho vystaví na každém rozhraní hostitele, a to je jiné bezpečnostní rozhodnutí, ne pohodlí.

Nechte aplikaci naslouchat tam, kde jmenný prostor očekává

Naslouchač přivázaný na 127.0.0.1 uvnitř jmenného prostoru je dostupný jen z jeho nitra. Publikované porty hostitele přicházejí zvenčí, takže se aplikace musí přivázat na širší adresu, aby mapování fungovalo. Většina serverů to řeší změnou na jednom řádku, a právě tento krok lidé vynechají po zkopírování příručky k zpevnění napsané pro nasazení bez kontejneru.

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

Výpis naslouchačů uvnitř aplikace říká pravdu o adrese přivázání a docker port ukazuje, co vlastník skutečně publikoval. Pokud první ukazuje 127.0.0.1 a druhý mapování na hostiteli, našli jste nesoulad, aniž byste se dotkli konfigurace VPN.

Vyberte, jak se cesta správy dostane dovnitř

Existují tři rozumná uspořádání. Publikujte na kontejneru VPN a přistupujte k němu z hostitele nebo z lokální sítě. Postavte před jmenný prostor reverzní proxy a dejte jí jediný vystavený port. Nebo ponechte panel dostupný jen z nitra jmenného prostoru přes relaci exec nebo SSH tunel, což je nejmenší expozice a nejmenší pohodlí.

Které se hodí, závisí na tom, kdo rozhraní potřebuje a odkud. Jednomu správci na stejném hostiteli stačí přivázání na loopback. Tým, který se k němu dostává přes VPN, potřebuje promyšlenou cestu a jmenovaného vlastníka. Volba proxy vám koupí TLS a přístupové záznamy za cenu další komponenty, kterou je třeba udržovat.

Otevřete správní port, aniž byste otevřeli všechno

Vlastní politika místního přístupu nebo uzamčení klienta VPN může zahodit příchozí správní požadavek, i když odchozí tunel funguje bezchybně. Povolte jednu zdokumentovanou výjimku pro zamýšlený zdroj a port a pak potvrďte, že obvyklá ochrana tunelu zůstala nezměněná. Vypnutí kill switch, aby se panel načetl, vyměňuje skutečnou kontrolu za kartu v prohlížeči.

Ponechte vlastní autentizaci aplikace zapnutou. Být uvnitř zásobníku připojeného k VPN neopravňuje každého místního uživatele ani každé zařízení, které se k hostiteli dostane, a administrační panel bez autentizace za tunelem zůstává administračním panelem bez autentizace.

Ověřte z řídicího zařízení a pak ověřte znovu později

Testujte ze stroje, který bude službu skutečně spravovat, ne z hostitele, a potom samostatně ověřte internetovou cestu, kterou aplikace vyžaduje. Úspěch správy dokazuje jeden směr a o odchozím provozu neříká nic.

Otestujte znovu poté, co se zásobník znovu vytvoří. Vyměněný síťový vlastník mění jmenný prostor, ke kterému se aplikace připojuje, a URL, které fungovalo před aktualizací, po ní nemusí ukazovat nikam. Zapište publikované mapování a adresu přivázání, aby příští přestavba byla dvouminutovou kontrolou místo opakovaného vyšetřování.

Související články