Зашто macvlan контејнер не може да одговори VPN клијенту

macvlan контејнер не може да разговара са сопственим хостом, а његови одговори могу да изађу кроз погрешан гејтвеј. Додајте shim руту на страни хоста, па изаберите модел извора.

Замислите Linux хост који завршава VPN и истовремено покреће контејнер на macvlan мрежи. LAN је 192.168.60.0/24, контејнер држи 192.168.60.210, а VPN клијенти долазе са 10.95.0.0/24. Клијент стиже до услуге, одговор се никада не враћа, и свако правило заштитног зида на хосту изгледа исправно. Два одвојена ограничења стварају тај симптом, а поправка једног оставља друго на месту.

Два ограничења, један симптом

Прво ограничење је изолација: macvlan драјвер у Docker-у не дозвољава контејнеру да разговара са сопственим хостом преко родитељског интерфејса. Саобраћај између стека хоста и контејнера нема пут, како год да су руте на хосту написане.

Друго ограничење је повратни пут. Подразумевани гејтвеј контејнера је обично LAN рутер, тако да одговор упућен VPN клијенту излази кроз тај рутер. Ако рутер нема руту назад ка базену VPN, одговор се одбацује негде у средини.

Обе грешке изгледају исто са стране клијента: захтев који стиже и одговор који никада не стиже. Њима су потребне различите поправке, а широко masquerade правило може да сакрије која је од њих још покварена. Зато је први тест снимање пакета на страни контејнера, а не још једна измена заштитног зида. Ако се захтев тамо никада не појави, на делу је ограничење изолације.

Изградите 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

Прва команда тестира део од хоста до контејнера, а друга показује шта заиста пролази кроз shim док прави VPN клијент шаље захтев. Погледајте адресу извора на улазном путу и да ли се појављује одговор са истим током.

На хосту мора да буде омогућено прослеђивање, а пут прослеђивања захтева дозволу за VPN базен ка shim-у на порту услуге плус успостављене одговоре. INPUT правило на хосту не дозвољава прослеђени саобраћај, и то је чест разлог зашто се пакет одбацује након што рутирање изгледа исправно.

Покрените праву апликацију са правим акредитивима, па проверите да ли вам друга, неповезана услуга на истом контејнеру још одбија приступ. Ако је једини начин да то проради било отварање сваког правила прослеђивања, дизајн није довршен. Забележите и коју је адресу извора услуга забележила, јер ће је од сада користити њена сопствена правила приступа.

Повезани чланци