Docker: nukreipkite vieną konteinerį per VPN, o kitą palikite tiesioginį

Vienas pagrindinis kompiuteris, dvi darbo apkrovos ir reikalavimas, kuris jas skiria: atsisiuntimo klientas, kuris turi išeiti per komercinį VPN, ir valdymo sąsaja, kuri turi toliau naudoti pagrindinio kompiuterio ryšį. Įdiegus VPN klientą pagrindiniame kompiuteryje reikalavimas iš karto pažeidžiamas, nes tada abi apkrovos dalijasi viena išėjimo vieta. Šablonas, kuris tikrai veikia, yra perkelti tunelį į jo paties konteinerį ir leisti tik toms apkrovoms, kurioms jo reikia, prisijungti prie to konteinerio tinklo vardų erdvės. Visa kita išlaiko įprastą Docker kelią, o toliau pateiktos detalės yra pasekmės to, kas valdo vardų erdvę.

Kodėl bendra vardų erdvė keičia taisykles

Konteineris, kuris prisijungia prie kito vardų erdvės, negauna savo tinklo kamino. Jis mato tuos pačius sąsajas, tą pačią maršrutų lentelę ir tą patį loopback kaip konteineris, prie kurio prisijungė, ir būtent todėl šablonas naudingas: apkrova įprastai išsprendžia ir prisijungia, o tunelis po ja pagauna srautą apie tai nežinant programai. Kaina yra tai, kad kiekvienas tinklo nustatymas dabar turi vieną savininką, o prisijungiantis konteineris nėra jis.

Ši nuosavybės taisyklė atsako į daugumą konfigūracijos klausimų dar prieš juos užduodant. Jei nustatymas gyvena tinklo kamine, jis priklauso šoniniam konteineriui. Jei jis aprašo procesą, jis lieka su apkrova.

Loopback yra ta dalis, kuri nustebina žmones. Prisijungiančio konteinerio viduje localhost išsprendžiamas į šoninio konteinerio loopback, o ne į savo privatų, todėl paslauga, kuri prisiriša prie 127.0.0.1 tikėdamasi izoliacijos, dabar dalijasi šiuo adresu su tunelio konteineriu.

Paskelbkite prievadus konteineryje, kuris valdo vardų erdvę

Prievadų susiejimas priklauso vardų erdvės savininkui, net kai klausantis procesas veikia kitame konteineryje. Deklaruokite susiejimą šoniniame konteineryje ir leiskite apkrovai išlaikyti savo proceso konfigūraciją nepakeistą. Susiejimas prisijungiančioje paslaugoje negali įsigalioti, nesvarbu, ar variklis jį atmeta, ar tyliai ignoruoja priklausomai nuo to, kaip konteineris paleidžiamas, ir todėl sąsaja, kuri prieš akimirką buvo pasiekiama, išnyksta vos pritaikius šabloną.

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

Skaitykite šį bloką kaip tris sprendimus, o ne tris paslaugas. Šoninis konteineris valdo tunelį ir paskelbtą prievadą; prisijungiantis klientas visai neskelbia tinklo; tiesioginis klientas išlaiko savo susiejimą numatytajame tinkle. Galimybė NET_ADMIN yra tai, kas leidžia šoniniam konteineriui kurti sąsajas ir keisti maršrutus, ir tai yra priežastis, kodėl šiam konteineriui reikia daugiau privilegijų nei apkrovoms, kurioms jis tarnauja.

Tiesiogine liekanti paslauga išlaiko savo tinklą

Apkrova, kuri neturi eiti per tunelį, išlaiko numatytąjį tiltą arba savo vartotojo apibrėžtą tinklą su savo paskelbtu prievadu ir savo išėjimu. Vilioja ją prijungti prie šoninio konteinerio tinklo, kad du konteineriai galėtų kalbėtis pagal vardą, bet tas vienas žingsnis tyliai perkelia jos srautą į tunelį. Jei jiems reikia pasiekti vienas kitą, sukurkite atskirą vartotojo apibrėžtą tinklą, prijunkite abu prie jo ir palikite šoninį konteinerį vieninteliu keliu į išorę.

Laikykite du klausimus atskirai: kurie konteineriai gali pasiekti vienas kitą ir kuris iš kur išeina. Jų sujungimas yra dažniausias būdas, kuriuo šis dizainas vėl tampa viso pagrindinio kompiuterio VPN.

Gedimų matrica pirmajai valandai

Dauguma pirmųjų bandymų nepavyksta vienu iš keturių būdų, ir kiekvienas turi skirtingą priežastį. Tikrinkite juos šia tvarka, nes pirmieji du paaiškina beveik kiekvieną ataskaitą.

Ketvirtoji eilutė yra ta, kurią žmonės klaidingai diagnozuoja kaip programos klaidą. Zondas, parašytas prieš pačios apkrovos loopback, dabar testuoja tunelio konteinerį, todėl jis arba nepavyksta, arba praneša apie visiškai neteisingą paslaugą.

Kai vienam pagrindinio kompiuterio vardui reikia tunelio

Kartais visas tunelis yra per daug: vienas vidinis vardas turi eiti per įmonės VPN, o vietinis lizdas arba ekrano ryšys toliau veikia. Visas tunelis konteinerio viduje sugriauna tą kelią ir viską, kas adresuota pagrindiniam kompiuteriui, todėl maršrutizuokite tik tą prefiksą, kuriam to reikia. Padalinto maršrutizavimo apvalkalas aplink klientą tai daro, siųsdamas nurodytą pagrindinio kompiuterio vardą per tunelį ir palikdamas ankstesnį maršrutą nepakeistą viskam kitam.

Rinkitės tai, kai jums reikia pasiekti tik vieną paslaugą ir nebandote perkelti viso konteinerio srauto. Tai kitas įrankis nei šoninis konteineris, ir jis atsako į kitą klausimą.

Patikrinkite, o tada padarykite atsparų perkrovimui

Paklauskite kiekvieno konteinerio, iš kokio adreso jis atrodo atvykstantis. Tunelyje esantis turėtų išspausdinti teikėjo adresą, o tiesioginis – pagrindinio kompiuterio išėjimą. Identiški atsakymai reiškia, kad tiesioginė paslauga paveldėjo neteisingą vardų erdvę arba pagrindinio kompiuterio lygio VPN vis dar pagauna viską, ir šios dvi pataisos skiriasi. Paleiskite patikrą dar kartą po kiekvieno compose pakeitimo, nes vieno nukopijuoto paslaugos bloko pakanka problemai grąžinti.

Trys dalykai linkę sugesti vėliau. DNS seka vardų erdvės savininką, todėl sprendėjo ir paieškos domeno nustatymai priklauso šoniniam konteineriui, o ne pagrindiniam kompiuteriui. VPN su prievadų peradresavimu keičia savo klausymosi prievadą prisijungus iš naujo, todėl teikėjo peradresuotas prievadas ir konteinerio pusės klausymosi prievadas turi būti įrašyti atgal į kliento konfigūraciją arba prievadų susiejimą, paprastai nedideliu atnaujintoju, kuris skaito teikėjo API. Ir bet koks zondas, parašytas prieš localhost, dabar klausia tunelio konteinerio, o ne apkrovos.

Užrašykite šabloną, įskaitant tai, kuris konteineris valdo vardų erdvę ir kurie prievadai jam priklauso. Kitas žmogus pridės paslaugą, nukopijuos neteisingą bloką ir atkurs pirmąjį šio straipsnio gedimą.