Docker: nasmerujte jeden kontajner cez VPN a druhý nechajte priamo

Jeden hostiteľ, dve pracovné zaťaženia a požiadavka, ktorá ich oddeľuje: klient na sťahovanie, ktorý musí vychádzať cez komerčnú VPN, a rozhranie na správu, ktoré musí ďalej používať pripojenie hostiteľa. Inštalácia VPN klienta na hostiteľa požiadavku okamžite nesplní, pretože obe zaťaženia potom zdieľajú jeden výstup. Vzor, ktorý naozaj funguje, je presunúť tunel do vlastného kontajnera a dovoliť iba tým zaťaženiam, ktoré ho potrebujú, pripojiť sa k sieťovému mennému priestoru tohto kontajnera. Všetko ostatné si drží obvyklú cestu Docker, a podrobnosti, ktoré nasledujú, sú dôsledkom toho, kto menný priestor vlastní.

Prečo zdieľaný menný priestor mení pravidlá

Kontajner, ktorý sa pripojí k mennému priestoru iného, nedostane vlastný sieťový stack. Vidí rovnaké rozhrania, rovnakú smerovaciu tabuľku a rovnaký loopback ako kontajner, ku ktorému sa pripojil, a práve preto je vzor užitočný: zaťaženie normálne prekladá a pripája sa a tunel pod ním zachytáva prevádzku bez toho, aby o tom aplikácia vedela. Cenou je, že každé sieťové nastavenie má teraz jedného vlastníka a pripájajúci sa kontajner ním nie je.

Toto pravidlo vlastníctva odpovedá na väčšinu otázok ku konfigurácii skôr, než sa položia. Ak nastavenie žije v sieťovom stacku, patrí doprovodnému kontajneru. Ak opisuje proces, zostáva pri zaťažení.

Loopback je časť, ktorá ľudí prekvapí. Vnútri pripájajúceho sa kontajnera sa localhost prekladá na loopback doprovodného kontajnera, nie na vlastný súkromný, takže služba, ktorá sa viaže na 127.0.0.1 a očakáva izoláciu, teraz zdieľa túto adresu s kontajnerom tunela.

Publikujte porty na kontajneri, ktorý vlastní menný priestor

Mapovanie portov patrí vlastníkovi menného priestoru, aj keď nasluchujúci proces beží v druhom kontajneri. Deklarujte mapovanie na doprovodnom kontajneri a zaťaženie nech si nechá vlastnú konfiguráciu procesu nedotknutú. Mapovanie na pripájajúcej sa službe nemôže nadobudnúť účinnosť, či už ho engine odmietne alebo ticho ignoruje podľa toho, ako je kontajner spustený, a preto rozhranie, ktoré bolo pred chvíľou dostupné, po nasadení vzoru zmizne.

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"]

Čítajte tento blok ako tri rozhodnutia, nie tri služby. Doprovodný kontajner vlastní tunel a publikovaný port; pripájajúci sa klient nedeklaruje žiadnu sieť; priamy klient si drží vlastné mapovanie na predvolenej sieti. Schopnosť NET_ADMIN je to, čo doprovodnému kontajneru umožňuje vytvárať rozhrania a meniť trasy, a je to dôvod, prečo tento kontajner potrebuje viac oprávnení než zaťaženia, ktorým slúži.

Služba, ktorá zostáva priama, si drží vlastnú sieť

Zaťaženie, ktoré nesmie prechádzať tunelom, si drží predvolený most alebo vlastnú používateľsky definovanú sieť, s vlastným publikovaným portom a vlastným výstupom. Je lákavé pripojiť ho k sieti doprovodného kontajnera, aby spolu oba kontajnery mohli hovoriť podľa mena, ale ten jediný krok ticho presunie jeho prevádzku do tunela. Ak sa majú navzájom dosiahnuť, postavte samostatnú používateľsky definovanú sieť, pripojte k nej oba a nechajte doprovodný kontajner jedinou cestou von.

Držte obe otázky oddelené: ktoré kontajnery na seba dosiahnu a ktorý kade vychádza. Ich zlúčenie je najbežnejší spôsob, akým sa tento návrh vráti k VPN pre celého hostiteľa.

Matica zlyhaní na prvú hodinu

Väčšina prvých pokusov zlyhá jedným zo štyroch spôsobov a každý má inú príčinu. Kontrolujte ich v tomto poradí, pretože prvé dva vysvetľujú takmer každé hlásenie.

Štvrtý riadok je ten, ktorý ľudia nesprávne diagnostikujú ako chybu aplikácie. Sonda napísaná proti vlastnému loopbacku zaťaženia teraz testuje kontajner tunela, takže buď zlyhá, alebo hlási úplne nesprávnu službu.

Keď jedno meno hostiteľa potrebuje tunel

Niekedy je plný tunel príliš: jedno interné meno musí prejsť firemnou VPN, zatiaľ čo miestny socket alebo pripojenie displeja ďalej funguje. Plný tunel vnútri kontajnera rozbíja túto cestu aj všetko adresované hostiteľovi, takže smerujte iba predponu, ktorá to potrebuje. Obal s rozdeleným smerovaním okolo klienta to robí, posiela pomenovaného hostiteľa tunelom a predchádzajúcu trasu necháva nedotknutú pre všetko ostatné.

Zvoľte to, keď potrebujete dosiahnuť iba jednu službu a nesnažíte sa presunúť všetku prevádzku kontajnera. Je to iný nástroj než doprovodný kontajner a odpovedá na inú otázku.

Overte a potom to nechajte prežiť reštart

Opýtajte sa každého kontajnera, z akej adresy to vyzerá, že prichádza. Ten v tuneli by mal vypísať adresu poskytovateľa a priamy výstup hostiteľa. Zhodné odpovede znamenajú, že priama služba zdedila nesprávny menný priestor alebo že VPN na úrovni hostiteľa stále zachytáva všetko, a tie dve opravy sú rôzne. Spustite kontrolu znova po každej úprave compose, pretože jeden skopírovaný blok služby stačí na to, aby sa problém vrátil.

Tri veci sa zvyčajne rozbijú neskôr. DNS nasleduje vlastníka menného priestoru, takže nastavenia resolvera a vyhľadávacej domény patria doprovodnému kontajneru, nie hostiteľovi. VPN s presmerovaním portov mení svoj nasluchujúci port pri opätovnom pripojení, takže presmerovaný port poskytovateľa a nasluchujúci port na strane kontajnera sa musia zapísať späť do konfigurácie klienta alebo do mapovania portov, zvyčajne malým aktualizátorom, ktorý číta API poskytovateľa. A každá sonda napísaná proti localhost sa teraz pýta kontajnera tunela, nie zaťaženia.

Zapíšte vzor vrátane toho, ktorý kontajner vlastní menný priestor a ktoré porty mu patria. Ďalší človek pridá službu, skopíruje nesprávny blok a zopakuje prvé zlyhanie z tohto článku.