Docker: усмерите један контејнер кроз VPN и оставите други директно

Један домаћин, два радна оптерећења и захтев који их раздваја: клијент за преузимање који мора да изађе кроз комерцијални VPN и интерфејс за управљање који мора да настави да користи везу домаћина. Инсталирање VPN клијента на домаћина одмах крши захтев, јер тада оба оптерећења деле један излаз. Образац који заиста функционише јесте да преместите тунел у његов сопствени контејнер и дозволите само оптерећењима којима је потребан да се придруже мрежном простору имена тог контејнера. Све остало задржава уобичајену Docker путању, а детаљи који следе последица су тога ко поседује простор имена.

Зашто заједнички простор имена мења правила

Контејнер који се придружи простору имена другог не добија сопствени мрежни стек. Он види исте интерфејсе, исту табелу рутирања и исти loopback као контејнер коме се придружио, и управо зато је образац користан: оптерећење нормално разрешава и повезује се, а тунел испод хвата саобраћај без знања апликације. Цена је да свако мрежно подешавање сада има једног власника, а контејнер који се придружује није тај.

Ово правило власништва одговара на већину конфигурационих питања пре него што буду постављена. Ако подешавање живи у мрежном стеку, припада бочном контејнеру. Ако описује процес, остаје уз оптерећење.

Loopback је део који изненађује људе. Унутар контејнера који се придружује, localhost се разрешава на loopback бочног контејнера, а не на сопствени приватни, тако да услуга која се везује на 127.0.0.1 очекујући изолацију сада дели ту адресу са контејнером тунела.

Објавите портове на контејнеру који поседује простор имена

Мапирање портова припада власнику простора имена, чак и када процес који слуша ради у другом контејнеру. Декларишите мапирање на бочном контејнеру, а оптерећење нека задржи сопствену конфигурацију процеса нетакнутом. Мапирање на услузи која се придружује не може да ступи на снагу, било да га мотор одбија или тихо игнорише у зависности од тога како се контејнер покреће, и зато интерфејс који је био доступан пре тренутка нестаје чим се образац примени.

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

Читајте овај блок као три одлуке, а не три услуге. Бочни контејнер поседује тунел и објављени порт; клијент који се придружује уопште не декларише мрежу; директни клијент задржава сопствено мапирање на подразумеваној мрежи. Способност NET_ADMIN је оно што омогућава бочном контејнеру да ствара интерфејсе и мења руте, и то је разлог зашто овај контејнер захтева више привилегија од оптерећења којима служи.

Услуга која остаје директна задржава сопствену мрежу

Оптерећење које не сме да прође кроз тунел задржава подразумевани мост или сопствену мрежу дефинисану од корисника, са сопственим објављеним портом и сопственим излазом. Примамљиво је прикачити га на мрежу бочног контејнера да би два контејнера могла да разговарају по имену, али тај један корак тихо премешта његов саобраћај у тунел. Ако треба да се достигну, изградите посебну мрежу дефинисану од корисника, прикачите оба на њу и оставите бочни контејнер као једини пут напоље.

Држите два питања одвојено: који контејнери могу да се достигну и који одакле излази. Њихово спајање је најчешћи начин на који овај дизајн поново постаје VPN за цео домаћин.

Матрица отказивања за први сат

Већина првих покушаја не успева на један од четири начина, и сваки има другачији узрок. Проверите их овим редоследом, јер прва два објашњавају скоро сваки извештај.

Четврти ред је онај који људи погрешно дијагностикују као грешку апликације. Провера написана против сопственог loopback-а оптерећења сада тестира контејнер тунела, па или не успева или пријављује потпуно погрешну услугу.

Када једно име домаћина има потребу за тунелом

Понекад је пун тунел превише: једно унутрашње име мора да прође кроз корпоративни VPN док локални сокет или веза за екран наставља да ради. Пун тунел унутар контејнера ломи ту путању и све што је адресирано на домаћина, зато рутирајте само префикс коме је то потребно. Омотач за подељено рутирање око клијента то чини, шаље именованог домаћина кроз тунел и оставља претходну руту нетакнутом за све остало.

Изаберите ово када треба да достигнете само једну услугу и не покушавате да преместите сав саобраћај контејнера. То је другачији алат од бочног контејнера и одговара на другачије питање.

Проверите, а затим учините да преживи поновно покретање

Питајте сваки контејнер са које адресе изгледа да долази. Онај у тунелу треба да испише адресу провајдера, а директни излаз домаћина. Идентични одговори значе да је директна услуга наследила погрешан простор имена или да VPN на нивоу домаћина још увек хвата све, и те две поправке су различите. Покрените проверу поново после сваке измене compose-а, јер је један копирани блок услуге довољан да врати проблем.

Три ствари имају тенденцију да се покваре касније. DNS следи власника простора имена, зато подешавања резолвера и домена претраге припадају бочном контејнеру, а не домаћину. VPN са прослеђивањем портова мења свој порт за слушање при поновним повезивању, зато прослеђени порт провајдера и порт за слушање на страни контејнера морају да се упишу назад у конфигурацију клијента или у мапирање портова, обично малим ажурирачем који чита API провајдера. И свака провера написана против localhost сада пита контејнер тунела, а не оптерећење.

Запишите образац, укључујући који контејнер поседује простор имена и који портови му припадају. Следећа особа ће додати услугу, копирати погрешан блок и поновити први отказ из овог чланка.