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

Замислете 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 правило на хостот не дозволува проследен сообраќај, и тоа е честа причина пакетот да се отфрли откако рутирањето изгледа точно.

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