Proč macvlan kontejner nemůže odpovědět VPN klientovi

Představte si Linuxový hostitel, který ukončuje VPN a zároveň provozuje kontejner v síti macvlan. LAN je 192.168.60.0/24, kontejner má 192.168.60.210 a VPN klienti přicházejí z 10.95.0.0/24. Klient se dostane ke službě, odpověď se nikdy nevrátí a každé pravidlo firewallu na hostiteli vypadá správně. Tento příznak vytvářejí dvě oddělená omezení a oprava jednoho nechává druhé na místě.

Dvě omezení, jeden příznak

Prvním omezením je izolace: ovladač macvlan v Dockeru nedovolí kontejneru komunikovat s vlastním hostitelem přes nadřazené rozhraní. Provoz mezi síťovým zásobníkem hostitele a kontejnerem nemá cestu, ať jsou trasy na hostiteli napsané jakkoli.

Druhým omezením je zpětná cesta. Výchozí brána kontejneru bývá obvykle LAN router, takže odpověď adresovaná VPN klientovi odchází přes tento router. Pokud router nemá trasu zpět do fondu VPN, odpověď se někde uprostřed zahodí.

Obě poruchy vypadají z pohledu klienta stejně: požadavek dorazí a odpověď nikdy nepřijde. Potřebují různé opravy a široké pravidlo masquerade může skrýt, která z nich je stále rozbitá. Proto je prvním testem zachycení paketů na straně kontejneru, nikoli další změna firewallu. Pokud se požadavek tam nikdy neobjeví, platí omezení izolace.

Postavte pomocnou trasu na straně hostitele, úzce

Druhé rozhraní macvlan na hostiteli, připojené ke stejnému nadřazenému rozhraní v režimu bridge, dává zásobníku hostitele vlastní identitu v tomto segmentu LAN. Rezervujte pro něj adresu mimo fond DHCP a mimo rozsah kontejnerů a směrujte přes něj pouze kontejner.

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

První příkaz vytvoří rozhraní v režimu bridge, což je dokumentovaný výchozí stav tohoto ovladače a režim, který chcete pro provoz mezi hostitelem a kontejnerem. Druhý přiřadí /32, aby adresa nekolidovala s prefixem LAN, a čtvrtý posílá přes pomocnou trasu pouze adresu kontejneru.

Nepřesměrovávejte celou LAN přes nové rozhraní. Běžná připojená trasa zůstává tak, jak je, a trasa hostitele je záměrně úzká, aby jeden kontejner získal cestu, aniž by zbytek segmentu měnil chování. Výchozí trasa směrem k pomocné trase by byla jiný návrh s jinými důsledky. Držte ji konkrétní a dosah škod zůstane malý.

Tyto příkazy mění síťové nastavení na běžícím hostiteli. Na zařízení nebo spravované platformě použijte podporovaný konfigurační mechanismus dané platformy, protože interaktivní změna přes root-shell nemusí přežít upgrade.

Rozhodněte, jak se zdroj zachová

S pomocnou trasou na místě se kontejner dostane k hostiteli a otázkou se stává, jakou adresu zdroje odpověď nese. Zachování původního zdroje VPN je čistší model: kontejner vidí skutečnou adresu klienta a protokoly a přístupová pravidla služby ji mohou použít.

Aby to fungovalo, musí síťová konfigurace kontejneru pro tuto cestu posílat provoz pro 10.95.0.0/24 na 192.168.60.250 jako na svou bránu. To je podporované nastavení trasy nebo brány uvnitř vlastní konfigurace kontejneru, ne trik na straně hostitele. Ověřte to zevnitř kontejneru, místo abyste předpokládali, že nastavení již platí. Výchozí brána, která stále ukazuje na LAN router, bude i nadále posílat odpovědi do stejné díry.

Pokud schválený návrh naopak zdroje VPN skrývá, omezte překlad úzce: skutečný fond VPN, pomocná trasa jako výstupní rozhraní a konkrétní kontejner a služba.

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

Srovnejte pomocnou trasu jako výstupní rozhraní, nikoli tunel. Pravidlo, které označí tunel jako výstupní rozhraní, nebude odpovídat paketu směřujícímu ke kontejneru, a to je chyba, kterou takové zapojení obvykle obsahuje. Držte pravidlo stejně úzké jako věta výše a při změně fondu ho zkontrolujte.

Ověřujte z klienta, ne z hostitele

Požadavek z hostitele samotného, vázaný na adresu pomocné trasy, dokazuje, že pomocná trasa dosáhne na kontejner. Nedokazuje, že kontejner dokáže vrátit provoz zachovanému zdroji 10.95.0.x, protože adresa zdroje je v tomto testu vlastní adresa pomocné trasy.

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

První příkaz testuje úsek z hostitele do kontejneru a druhý ukazuje, co skutečně prochází pomocnou trasou, když skutečný VPN klient posílá požadavek. Podívejte se na adresu zdroje na cestě dovnitř a zda se objeví odpověď se stejným tokem.

Na hostiteli musí být zapnuté přeposílání a cesta přeposílání potřebuje povolení pro fond VPN směrem k pomocné trase na portu služby plus navázané odpovědi. Pravidlo INPUT na hostiteli nepovoluje přeposílaný provoz, což je častý důvod, proč se paket zahodí poté, co směrování vypadá správně.

Spusťte skutečnou aplikaci se skutečnými přihlašovacími údaji a poté zkontrolujte, že druhá, nesouvisející služba na stejném kontejneru vás stále odmítá. Pokud jediným způsobem, jak to rozchodit, bylo otevřít všechna pravidla přeposílání, návrh není hotový. Poznamenejte si také, jakou adresu zdroje služba zaznamenala, protože tu budou od nynějška používat její vlastní přístupová pravidla.