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 каршы жазылган ар кандай текшерүү эми жүктөмдөн эмес, туннель контейнеринен сурайт.

Үлгүнү жазып коюңуз, анын ичинде кайсы контейнер ат мейкиндигине ээ жана кайсы порттор ага таандык. Кийинки адам кызмат кошуп, туура эмес блокту көчүрүп, бул макаладагы биринчи бузулууну кайталайт.