Неге macvlan контейнері VPN клиентіне жауап бере алмайды

macvlan контейнері өз хостымен сөйлесе алмайды, ал оның жауаптары қате шлюз арқылы шығуы мүмкін. Хост жағында shim маршрутын қосыңыз, содан кейін бастау көзінің моделін таңдаңыз.

VPN-ді тоқтатып, сонымен бірге macvlan желісінде контейнер іске қосатын Linux хостты елестетіңіз. LAN — 192.168.60.0/24, контейнерде 192.168.60.210 бар, ал VPN клиенттері 10.95.0.0/24-тен келеді. Клиент қызметке жетеді, жауап ешқашан қайтпайды, ал хосттағы әрбір firewall ережесі дұрыс көрінеді. Бұл симптомды екі бөлек шектеу тудырады, ал біреуін түзету екіншісін орнында қалдырады.

Екі шектеу, бір симптом

Бірінші шектеу — оқшаулау: Docker-дің macvlan драйвері контейнерге ата-ана интерфейсі арқылы өз хостпен сөйлесуге рұқсат бермейді. Хост стекі мен контейнер арасындағы трафиктің жолы жоқ, хосттағы маршруттар қалай жазылса да.

Екінші шектеу — қайту жолы. Контейнердің әдепкі шлюзі әдетте LAN маршрутизаторы, сондықтан VPN клиентіне арналған жауап сол маршрутизатор арқылы шығады. Егер маршрутизатордың VPN пулына қайтатын маршруты болмаса, жауап ортада бір жерде тасталады.

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

Хост жағындағы shim-ді тар етіп құрыңыз

Хосттағы бірдей ата-анаға көпір режимінде қосылған екінші macvlan интерфейсі хост стекіне сол LAN сегментінде өз сәйкестігін береді. Ол үшін DHCP пулының сыртында және контейнер ауқымының сыртында мекенжай бөліп қойыңыз, ал тек контейнерді оның арқылы өткізіңіз.

ip link add macvlan-vpn link eth0 type macvlan mode bridge
ip address add 192.168.60.250/32 dev macvlan-vpn
ip link set macvlan-vpn up
ip route add 192.168.60.210/32 dev macvlan-vpn src 192.168.60.250

Бірінші пәрмен интерфейсті көпір режимінде жасайды, бұл осы драйвер үшін құжатталған әдепкі және хост-контейнер трафигі үшін қалайтын режим. Екіншісі /32 тағайындайды, мекенжай LAN префиксімен соқтығыспауы үшін, ал төртіншісі shim арқылы тек контейнер мекенжайын жібереді.

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

Бұл пәрмендер жұмыс істеп тұрған хосттың желілік параметрлерін өзгертеді. Құрылғыда немесе басқарылатын платформада сол платформаның қолдалатын конфигурация механизмін пайдаланыңыз, өйткені root-shell арқылы интерактивті өзгеріс жаңартудан кейін сақталмауы мүмкін.

Дереккөздің қалай сақталатынын шешіңіз

shim орнында болғанда контейнер хостқа жете алады, ал сұрақ — жауап қандай дереккөз мекенжайын алып жүреді дегенге айналады. Бастапқы VPN дереккөзін сақтау тазарақ модель: контейнер клиенттің нақты мекенжайын көреді, ал қызметтің журналдары мен қатынау ережелері оны пайдалана алады.

Бұл жұмыс істеуі үшін контейнердің желілік конфигурациясы осы жол үшін 10.95.0.0/24 трафигін 192.168.60.250-ге өз шлюзі ретінде жіберуі керек. Бұл контейнердің өз конфигурациясының ішіндегі қолдалатын маршрут немесе шлюз параметрі, хост жағындағы айла емес. Оны контейнердің ішінен растаңыз, параметр күшіне енді деп болжамаңыз. Әлі де LAN маршрутизаторына сілтейтін әдепкі шлюз жауаптарды сол тесікке жіберуді жалғастырады.

Егер бекітілген дизайн оның орнына VPN дереккөздерін жасырса, аударманы тар шектеңіз: нақты VPN пулы, шығатын интерфейс ретінде shim, және нақты контейнер мен қызмет.

iptables -t nat -A POSTROUTING -s 10.95.0.0/24 -o macvlan-vpn -j SNAT --to-source 192.168.60.250

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

Клиенттен тексеріңіз, хосттан емес

Хосттың өзінен shim мекенжайына байланған сұраныс shim-нің контейнерге жете алатынын дәлелдейді. Бірақ ол контейнердің сақталған 10.95.0.x дереккөзіне трафикті қайтара алатынын дәлелдемейді, өйткені бұл сынақтағы дереккөз мекенжайы shim-нің өзінің мекенжайы.

curl -sS --interface 192.168.60.250 -o /dev/null -w '%{http_code}\n' http://192.168.60.210:8080/health
sudo tcpdump -ni macvlan-vpn host 192.168.60.210

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

Хостта жіберу қосулы болуы керек, ал жіберу жолына қызмет портында VPN пулынан shim-ге рұқсат және орнатылған жауаптарға рұқсат қажет. Хосттағы INPUT ережесі жіберілетін трафикке рұқсат бермейді, және бұл маршруттау дұрыс көрінгеннен кейін пакеттің тасталуының жиі себебі.

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

Қатысты мақалалар