Docker: stuur een houer deur 'n VPN en hou 'n ander een direk

Een gasheer, twee werkladings, en 'n vereiste wat hulle skei: 'n aflaai-kliënt wat uit 'n kommersiële VPN moet verskyn, en 'n bestuerskerm wat die gasheer se verbinding moet bly gebruik. Om die VPN-kliënt op die gasheer te installeer, laat die vereiste dadelik misluk, want albei werkladings deel dan een uitgang. Die patroon wat wel werk, is om die tonnel in sy eie houer te plaas en net die werkladings wat dit nodig het by daardie houer se netwerknaamruimte te laat aansluit. Alles anders hou die gewone Docker-pad, en die besonderhede wat volg is gevolge van wie die naamruimte besit.

Waarom 'n gedeelde naamruimte die reëls verander

'n Houer wat by 'n ander se naamruimte aansluit, kry nie sy eie netwerkstapel nie. Dit sien dieselfde koppelvlakke, dieselfde roetetabel en dieselfde loopback as die houer waarby dit aangesluit het, en dit is juis waarom die patroon nuttig is: die werklading los en verbind normaal, en die tonnel onder dit vang die verkeer op sonder dat die toepassing dit weet. Die koste is dat elke netwerk-agtige instelling nou een eienaar het, en die aansluitende houer is nie dit nie.

Daardie eienaarskapreël beantwoord die meeste konfigurasievrae voordat hulle gevra word. As 'n instelling in die netwerkstapel woon, hoort dit by die sidecar. As dit die proses beskryf, bly dit by die werklading.

Loopback is die deel wat mense verras. Binne die aansluitende houer los localhost na die sidecar se loopback op, nie na 'n private een van sy eie nie, so 'n diens wat aan 127.0.0.1 bind en isolasie verwag, deel nou daardie adres met die tonnelhouer.

Publiseer poorte op die houer wat die naamruimte besit

Die poorttoewysing hoort by die eienaar van die naamruimte, selfs wanneer die luisterende proses in die ander houer loop. Verklaar die toewysing op die sidecar, en laat die werklading sy eie proseskonfigurasie onaangeraak. 'n Toewysing op die aansluitende diens kan nie in werking tree nie, of die enjin dit nou verwerp of dit stilweg ignoreer na gelang van hoe die houer begin word, en dit is waarom 'n koppelvlak wat 'n oomblik gelede bereikbaar was, verdwyn sodra die patroon toegepas word.

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

Lees daardie blok as drie besluite eerder as drie dienste. Die sidecar besit die tonnel en die gepubliseerde poort; die aansluitende kliënt verklaar glad geen netwerk nie; die direkte kliënt hou 'n eie toewysing op die versteknetwerk. Die NET_ADMIN-vermoë is wat die sidecar in staat stel om koppelvlakke te skep en roetes te verander, en dit is die rede waarom hierdie houer meer voorregte nodig het as die werkladings wat dit bedien.

Die diens wat direk bly, hou sy eie netwerk

Die werklading wat nie deur die tonnel moet gaan nie, hou die verstekbrug of 'n gebruikergedefinieerde netwerk van sy eie, met sy eie gepubliseerde poort en sy eie uitgang. Dit is aanloklik om dit aan die sidecar-netwerk te koppel sodat die twee houers op naam kan praat, en daardie een stap skuif stilweg sy verkeer in die tonnel in. As hulle mekaar moet bereik, bou 'n aparte gebruikergedefinieerde netwerk, koppel albei daaraan, en laat die sidecar as die enigste uitwaartse pad.

Hou die twee vrae apart: watter houers mekaar kan bereik, en watter een waar uitgaan. Om hulle saam te voeg is die enkele mees algemene manier waarop hierdie ontwerp weer in 'n gasheervye VPN verander.

'n Mislukkingsmatriks vir die eerste uur

Die meeste eerste pogings misluk op een van vier maniere, en elkeen het 'n ander oorsaak. Kyk in hierdie volgorde daarna, want die eerste twee verantwoord byna elke verslag.

Die vierde ry is die een wat mense verkeerd diagnostiseer as 'n toepassingsfout. 'n Peiling wat teen die werklading se eie loopback geskryf is, toets nou die tonnelhouer, so dit misluk of rapporteer heeltemal die verkeerde diens.

Wanneer 'n enkele gasheernaam die tonnel nodig het

Soms is 'n volledige tonnel te veel: een interne naam moet deur 'n korporatiewe VPN gaan terwyl 'n plaaslike sok of vertoonskakeling aan die werk bly. 'n Volledige tonnel binne die houer breek daardie pad en enigiets wat aan die gasheer geadresseer is, so roet alleen die voorvoegsel wat dit nodig het. 'n Split-roeterende wikkel om die kliënt doen dit, wat die genoemde gasheer deur die tonnel stuur en die vorige roete onaangeraak laat vir alles anders.

Kies dit wanneer jy net een diens hoef te bereik en nie probeer om al die houer se verkeer te skuif nie. Dit is 'n ander instrument as die sidecar en dit beantwoord 'n ander vraag.

Verifieer, en maak dit dan 'n herstart oorleef

Vra elke houer watter adres dit blyk te kom. Die een in die tonnel moet die verskaffer se adres druk en die direkte een moet die gasheer se uitgang druk. Identiese antwoorde beteken die direkte diens het die verkeerde naamruimte geërf of 'n gasheervlak-VPN vang nog alles, en daardie twee regstellings is verskillend. Hardloop die kontrole weer na elke compose-wysiging, want een gekopieerde diensblok is genoeg om die probleem weer in te bring.

Drie dinge is geneig om later te breek. DNS volg die eienaar van die naamruimte, so resolveerder- en soekdomeininstellings hoort op die sidecar eerder as op die gasheer. 'n Poortgeforwarde VPN verander sy luisterpoort met herverbinding, so die verskaffer se geforwarde poort en die houerkant se luisterpoort moet terug in die kliëntkonfigurasie of die poorttoewysing geskryf word, gewoonlik deur 'n klein opdatering wat die verskaffer se API lees. En enige peiling wat teen localhost geskryf is, vra nou die tonnelhouer eerder as die werklading.

Skryf die patroon neer, insluitend watter houer die naamruimte besit en watter poorte daaraan behoort. Die volgende persoon sal 'n diens byvoeg, die verkeerde blok kopieer en die eerste mislukking in hierdie artikel reproduseer.