Эмне үчүн 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 эрежеси өткөрүлүүчү трафикке уруксат бербейт, жана бул маршруттоо туура көрүнгөндөн кийин пакеттин ыргытылышынын кеңири тараган себеби.

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

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