Docker: nasměrujte jeden kontejner přes VPN a druhý nechte přímo

Jeden hostitel, dvě pracovní zátěže a požadavek, který je odděluje: klient pro stahování, který musí vycházet přes komerční VPN, a rozhraní pro správu, které musí dál používat připojení hostitele. Instalace VPN klienta na hostitele požadavek okamžitě nesplní, protože obě zátěže pak sdílejí jeden výstup. Vzor, který opravdu funguje, je přesunout tunel do vlastního kontejneru a dovolit jen těm zátěžím, které ho potřebují, připojit se ke jmennému prostoru sítě tohoto kontejneru. Vše ostatní si drží obvyklou cestu Dockeru a podrobnosti, které následují, jsou důsledkem toho, kdo jmenný prostor vlastní.

Proč sdílený jmenný prostor mění pravidla

Kontejner, který se připojí ke jmennému prostoru jiného, nedostane vlastní síťový stack. Vidí stejná rozhraní, stejnou směrovací tabulku a stejný loopback jako kontejner, ke kterému se připojil, a právě proto je vzor užitečný: zátěž normálně překládá a připojuje se a tunel pod ní zachycuje provoz, aniž by o tom aplikace věděla. Cenou je, že každé síťové nastavení má nyní jednoho vlastníka a připojující se kontejner jím není.

Toto pravidlo vlastnictví odpovídá na většinu otázek ke konfiguraci dřív, než se položí. Pokud nastavení žije v síťovém stacku, patří doprovodnému kontejneru. Pokud popisuje proces, zůstává u zátěže.

Loopback je část, která lidi překvapí. Uvnitř připojujícího se kontejneru se localhost překládá na loopback doprovodného kontejneru, ne na vlastní soukromý, takže služba, která se váže na 127.0.0.1 a čeká izolaci, nyní sdílí tuto adresu s kontejnerem tunelu.

Publikujte porty na kontejneru, který vlastní jmenný prostor

Mapování portů patří vlastníku jmenného prostoru, i když naslouchající proces běží v druhém kontejneru. Deklarujte mapování na doprovodném kontejneru a zátěž ať si nechá vlastní konfiguraci procesu netknutou. Mapování na připojující se službě nemůže nabýt účinku, ať už ho engine odmítne, nebo tiše ignoruje podle toho, jak je kontejner spuštěn, a proto rozhraní, které bylo před chvílí dostupné, po nasazení vzoru zmizí.

services:
  gluetun:
    image: qmcgaw/gluetun
    cap_add: [NET_ADMIN]
    ports: ["8080:8080"]
  client-vpn:
    image: example/client
    network_mode: "service:gluetun"
  client-direct:
    image: example/client
    ports: ["8081:8080"]

Čtěte tento blok jako tři rozhodnutí, ne tři služby. Doprovodný kontejner vlastní tunel a publikovaný port; připojující se klient nedeklaruje žádnou síť; přímý klient si drží vlastní mapování na výchozí síti. Schopnost NET_ADMIN je to, co doprovodnému kontejneru umožňuje vytvářet rozhraní a měnit trasy, a je to důvod, proč tento kontejner potřebuje více oprávnění než zátěže, kterým slouží.

Služba, která zůstává přímá, si drží vlastní síť

Zátěž, která nesmí procházet tunelem, si drží výchozí bridge nebo vlastní uživatelsky definovanou síť, s vlastním publikovaným portem a vlastním výstupem. Je lákavé připojit ji k síti doprovodného kontejneru, aby spolu oba kontejnery mohly mluvit podle jména, ale ten jediný krok tiše přesune její provoz do tunelu. Pokud se mají navzájem dosáhnout, postavte samostatnou uživatelsky definovanou síť, připojte k ní oba a nechte doprovodný kontejner jedinou cestou ven.

Držte obě otázky oddělené: které kontejnery na sebe dosáhnou a který kudy vychází. Jejich sloučení je nejběžnější způsob, jak se tento návrh vrátí k VPN pro celého hostitele.

Matice selhání pro první hodinu

Většina prvních pokusů selže jedním ze čtyř způsobů a každý má jinou příčinu. Kontrolujte je v tomto pořadí, protože první dva vysvětlují téměř každé hlášení.

Čtvrtý řádek je ten, který lidé chybně diagnostikují jako chybu aplikace. Sonda napsaná proti vlastnímu loopbacku zátěže nyní testuje kontejner tunelu, takže buď selže, nebo hlásí úplně špatnou službu.

Když jedno jméno hostitele potřebuje tunel

Někdy je plný tunel příliš: jedno interní jméno musí projít firemní VPN, zatímco místní socket nebo připojení displeje dál funguje. Plný tunel uvnitř kontejneru rozbíjí tuto cestu i vše adresované hostiteli, takže směrujte jen předponu, která to potřebuje. Obal s rozděleným směrováním kolem klienta to dělá, posílá pojmenovaného hostitele tunelem a předchozí trasu nechává netknutou pro vše ostatní.

Zvolte to, když potřebujete dosáhnout jen jedné služby a nesnažíte se přesunout veškerý provoz kontejneru. Je to jiný nástroj než doprovodný kontejner a odpovídá na jinou otázku.

Ověřte a pak to nechte přežít restart

Zeptejte se každého kontejneru, z jaké adresy to vypadá, že přichází. Ten v tunelu by měl vypsat adresu poskytovatele a přímý výstup hostitele. Shodné odpovědi znamenají, že přímá služba zdědila špatný jmenný prostor nebo že VPN na úrovni hostitele stále zachycuje vše, a ty dvě opravy jsou různé. Spusťte kontrolu znovu po každé úpravě compose, protože jeden zkopírovaný blok služby stačí k tomu, aby se problém vrátil.

Tři věci se obvykle rozbijí později. DNS následuje vlastníka jmenného prostoru, takže nastavení resolveru a vyhledávací domény patří doprovodnému kontejneru, ne hostiteli. VPN s přesměrováním portů mění svůj naslouchající port při opětovném připojení, takže přesměrovaný port poskytovatele a naslouchající port na straně kontejneru se musí zapsat zpět do konfigurace klienta nebo do mapování portů, obvykle malým aktualizátorem, který čte API poskytovatele. A každá sonda napsaná proti localhost se nyní ptá kontejneru tunelu, ne zátěže.

Zapište vzor včetně toho, který kontejner vlastní jmenný prostor a které porty mu patří. Další člověk přidá službu, zkopíruje špatný blok a zopakuje první selhání z tohoto článku.