VPNде Docker контейнери жеткиликсизби? Ички тармактарды салыштырыңыз

Docker VPN да талап кылган ички тармакты берет. Эки дарек планын салыштырып, кайра туташууга туруштук бере турган оңдоону тандаңыз.

Контейнерлер кеңсе LAN-ында жооп берет, анан компаниянын VPN туташкан учурда жооп берүүнү токтотот. Контейнерде эч нерсе өзгөргөн жок: кайра баштоо жок, образды жаңыртуу жок, конфигурацияны оңдоо жок. Өзгөргөн нерсе — хосттун маршруттоо таблицасы, анда туннель кошкон маршрут эми Docker берген даректи камтыйт. Ички тармакты оңдоодон же VPNден чыгарууну суроодон мурун эки дарек планын катар коюңуз, анткени оңдоолор абдан башкача убакыт талап кылат.

Конфигурацияны өзгөртүүдөн мурун маршрутту окуңуз

Docker чындыгында курган тармактан баштаңыз. IPAM блогу — дарек планы, ал эми ички тармак — маанилүү сап:

docker network inspect project_default --format '{{json .IPAM.Config}}'
# [{"Subnet":"172.18.0.0/16","Gateway":"172.18.0.1"}]

Compose демейки боюнча ар бир жаңы долбоорго /16 бөлөт, ошондуктан эки кызмат 65,536 дарек диапазонунда жайгаша алат. Так ошол кенендик кагылышууларды кеңири кылат: туш келди тандалган /16 туннель аркылуу жеткен сайтты жутуп кетүүгө жетиштүү, жана туннель көтөрүлгөнгө чейин эч ким байкабайт.

Анан бир контейнер дареги үчүн маршрут тандоону салыштырыңыз — бир жолу туннель өчүк, бир жолу күйүк:

ip route get 172.18.0.7
# 172.18.0.7 dev br-3f2a9c src 172.18.0.1

Жооптун эки түрү ар башка жакка алып барат. Эгер чыгарылышта tun0, wg0 же башка туннель түзмөгү көрсөтүлсө, VPN префикси көпүрө маршрутунан кеминде ошончолук так жана пакет контейнерге такыр жетпейт. Эгер ал дагы эле көпүрөнү атаса, хост контейнерге жете алат, ал эми сиздин кемчилигиңиз — чыпкалоо, DNS же бир гана багытта ишке ашпаган кайтаруу жолу.

Эмне үчүн /16 кагылышуусу оңой болот

Docker көпүрө тармактарын жеке пулдардан алат, ал эми демейки пул 172.16.0.0/12 блогынан /16 кесиндилери менен чыгат. Корпоративдик тармактар көбүнчө ошол эле жеке мейкиндикти колдонушат, ал эми алыскы кирүү VPN бул префикстерди туташкан ар бир кардарга жөнөтөт. Эки тарап тең 172.18.0.0/16 ээм деп ишенсе, бир маршруттоо таблицасында эки карама-каршы доомат турат.

Жеңүүчүнү префикстин узундугу аныктайт, маршруттардын тартиби эмес. 10.0.0.0/8 префиксин жөнөткөн туннель 172.18.0.0/16 көпүрө маршрутунан басымдуулук кылбайт, анткени /8 анча так эмес. 172.18.0.0/16, же 172.18.5.0/24 анын ичиндеги префикти жөнөткөн туннель басымдуулук кылат. Ошондуктан бир ноутбук кеңсе тармагында иштеп, мейманкана Wi-Fiинде ошол эле VPN менен иштебейт: кардар ар башка префикстерди алат.

Ошол эле таблица карама-каршы багытты да башкарат. 10.8.4.20 дарегиндеги ички хост керек болгон контейнер пакетти өзүнүн көпүрө шлюзуна жөнөтөт, анан хост аны туннелге маршруттайт. Бул жол адатта иштейт, анткени NATты хост аткарат, бирок корпоративдик тарап ноутбуктун VPN дарегин гана кабыл алганда же кайтарма жол чыпкасы асимметриялуу жоопту таштаганда иштебейт.

Үч оңдоону салыштырыңыз

Чыгуунун үч гана жолу бар, алар кимдин уруксаты керектиги жана колдонгондо эмне бузулаары менен айырмаланат.

RepairWho owns itWhat it costs
Renumber the container networkYouRecreates the network, restarts services, invalidates literal addresses in configs and scripts
Exclude your range from the tunnelNetwork teamChanges what every laptop sees, needs a change request and a client profile update
Reach the service through a published portYou and the clientOne port only, no direct container-to-container routing across the tunnel

Кайра номерлөө — билетсиз бүтүрө ала турган жалгыз оңдоо, ошондуктан көп жазуулар ошол жерде токтойт. Жаш долбоордо ал арзан, ал эми миграция куралы же сакталган туташуу сабы так дарекке шилтесе — кымбат. YAMLды оңдоодон мурун ошол шилтемелерди санаңыз, кийин эмес.

Туннелден чыгаруу — кагылышуу компания чындап ээлик кылган диапазондо болсо, эң таза жооп. Ал ошондой эле эң жай, жана кардар профилин өзгөртө албаган мердигер үчүн пайдасыз. Жарыяланган порт же кичинекей тескери прокси талашты болтурбайт: кардар туннель туура маршруттаган дарек менен сүйлөшөт, жана ошол гана порт жеткиликтүү болушу керек.

Диапазонду атайын бекитиңиз

Бир долбоор үчүн ички тармакты compose файлында жарыялаңыз, ошондо долбоор жалпы пулдан алууну токтотот:

networks:
  default:
    ipam:
      config:
        - subnet: 10.201.7.0/24

Бул диапазонду издеп жүрүп тапкан мисалдан эмес, командаңыз кармаган реестрден алыңыз. Аны VPN жөнөткөн префикстер менен, адамдар иштеген үй LANдары менен жана ошол хосттогу башка контейнер тармактары менен салыштырыңыз. Анан кайра түзүүнү пландаңыз, анткени бар тармак эски ички тармагын сактайт: docker compose down, анан up -d. docker network rm четик пункттар бекитилгенде баш тартат, жана файлдагы каалаган ipv4_address жазуусу жаңы диапазондун ичинде болушу керек.

Docker өзү түзгөн тармактар үчүн демон пулун /etc/docker/daemon.json:

{
  "default-address-pools": [
    { "base": "10.201.0.0/16", "size": 24 },
    { "base": "10.202.0.0/16", "size": 24 }
  ]
}

Пул демон кайра башталгандан кийин түзүлгөн тармактарга колдонулат, ал эми мурунтан бар көпүрөлөр өз даректерин сактайт. Бул ыңгайлуу жана унутууга оңой, ошондуктан эски долбоорду бирөө анын тармагын кайра түзгөнгө чейин дагы эле кагылышып турат деп эсептеңиз. Dockerдин кыймылдаткыч тармак документациясы бөлүштүрүү эрежелерин сүрөттөйт, эгер пулду кароодо коргоо керек болсо.

Linux көпүрөсү жана Docker Desktop башкача ишке ашпайт

Linux хостто контейнерлер хосттун namespaceиндеги көпүрөлөрдө отурат. Баарын бир таблица чечет, ошондуктан жогорку салыштыруу — бүт окуя: көпүрө маршрутун окуңуз, туннель маршрутун окуңуз жана чыныгы контейнер дареги үчүн кайсынысы жеңерин көрүңүз.

Docker Desktop контейнерлерди өзүнүн NATы бар VMдин артына коёт. Хосттун контейнер дарегине маршруту такыр жок; ал кызматка жарыяланган порт аркылуу жетет, адатта 127.0.0.1 дарегине байланат. Ошондуктан VPN кардары кызматты ички тармак кагылышуусуз эле буза алат: VMдин ички диапазонуна маршрут орнотуп, же туннель туташканда loopback трафигин бөгөттөп. Эгер ip route get хостто контейнер дареги үчүн маршрутту билдирбесе, бул күтүлгөн нерсе, кемчилик эмес.

Практикалык жыйынтык — эң оболу кайда карайсыз. Linuxто маршруттоо таблицасынан баштаңыз. Desktopто жарыяланган порттон жана VPN кардарынын firewall эрежелеринен баштап, анан VMдин ички тармагы туннель жөнөткөн нерсе менен кагылышабы, текшериңиз.

Туннель күйүк абалда текшериңиз

Оңдолду деп айтпас мурун VPNди эки жолу кайра туташтырыңыз, анткени туташканда маршруттарды жөнөтүп, ажыраганда кайтарып алган профиль биринчи аракеттен кийин туура көрүнүшү мүмкүн. Анан кардар чындыгында аткарган текшерүүлөрдү иштетиңиз:

  1. ip route get хосттон, контейнердин чыныгы дарегин колдонуп.
  2. Башка контейнерден суроо — кызматтын өзү соо экенин далилдөө үчүн.
  3. curl -sv http://127.0.0.1:8080/ туннель күйүк абалда кардардан, анан traceroute -n LANдагы машинадан контейнер дарегине.
  4. sysctl net.ipv4.conf.all.rp_filter эгер суроо хостко жетип, жооп жоголсо.

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

Тектеш макалалар