Docker: бір контейнерді VPN арқылы өткізіп, екіншісін тікелей қалдыру

Бір хост, екі жұмыс жүктемесі және оларды бөлетін талап: коммерциялық VPN арқылы шығуы керек жүктеу клиенті және хосттың қосылымын пайдалануды жалғастыруы керек басқару интерфейсі. VPN клиентін хостқа орнату талапты бірден бұзады, өйткені сонда екі жүктеме де бір шығысты бөліседі. Шын мәнінде жұмыс істейтін үлгі — туннельді өз контейнеріне көшіру және оған қажет жүктемелерге ғана сол контейнердің желілік ат кеңістігіне қосылуға рұқсат ету. Қалғанының бәрі әдеттегі Docker жолын сақтайды, ал келесі мәліметтер ат кеңістігі кімге тиесілі екенінің салдары.

Неліктен ортақ ат кеңістігі ережелерді өзгертеді

Басқаның ат кеңістігіне қосылған контейнер өзінің желілік стегін алмайды. Ол қосылған контейнермен бірдей интерфейстерді, бірдей маршруттау кестесін және бірдей loopback-ты көреді, сондықтан бұл үлгі пайдалы: жүктеме әдеттегідей шешіп, қосылады, ал астындағы туннель қосымша білмей-ақ трафикті ұстап алады. Бағасы — әрбір желілік параметрдің енді бір ғана иесі бар, ал қосылған контейнер ол емес.

Бұл иелік ережесі конфигурация сұрақтарының көбіне олар қойылмай тұрып жауап береді. Егер параметр желілік стекте болса, ол бүйір контейнерге тиесілі. Егер ол процесті сипаттаса, ол жүктемемен қалады.

loopback — адамдарды таңғалдыратын бөлік. Қосылған контейнердің ішінде localhost бүйір контейнердің loopback-ына шешіледі, өзінің жеке 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 қарсы жазылған кез келген тексеру енді жүктемеден емес, туннель контейнерінен сұрайды.

Үлгіні жазып қойыңыз, оның ішінде қай контейнер ат кеңістігіне ие және қай порттар оған тиесілі. Келесі адам қызмет қосып, дұрыс емес блокты көшіріп, осы мақаладағы бірінші ақауды қайталайды.