Prečo macvlan kontajner nemôže odpovedať VPN klientovi

Predstavte si Linuxový hostiteľ, ktorý ukončuje VPN a zároveň prevádzkuje kontajner v sieti macvlan. LAN je 192.168.60.0/24, kontajner má 192.168.60.210 a VPN klienti prichádzajú z 10.95.0.0/24. Klient sa dostane k službe, odpoveď sa nikdy nevráti a každé pravidlo firewallu na hostiteľovi vyzerá správne. Tento príznak vytvárajú dve oddelené obmedzenia a oprava jedného necháva druhé na mieste.

Dve obmedzenia, jeden príznak

Prvým obmedzením je izolácia: ovládač macvlan v Dockeri nedovolí kontajneru komunikovať s vlastným hostiteľom cez nadradené rozhranie. Premávka medzi zásobníkom hostiteľa a kontajnerom nemá cestu, nech sú trasy na hostiteľovi napísané akokoľvek.

Druhým obmedzením je spätná cesta. Predvolená brána kontajnera býva zvyčajne LAN router, takže odpoveď adresovaná VPN klientovi odchádza cez tento router. Ak router nemá trasu späť do fondu VPN, odpoveď sa niekde v strede zahodí.

Obe poruchy vyzerajú z pohľadu klienta rovnako: požiadavka príde a odpoveď nikdy nepríde. Potrebujú rôzne opravy a široké pravidlo masquerade môže skryť, ktorá z nich je stále pokazená. Preto je prvým testom zachytenie paketov na strane kontajnera a nie ďalšia zmena firewallu. Ak sa požiadavka tam nikdy neobjaví, platí obmedzenie izolácie.

Postavte pomocnú trasu na strane hostiteľa, úzko

Druhé rozhranie macvlan na hostiteľovi, pripojené k tomu istému nadradenému rozhraniu v režime mosta, dáva zásobníku hostiteľa vlastnú identitu v tomto segmente LAN. Rezervujte preň adresu mimo fondu DHCP a mimo rozsahu kontajnera a smerujte cez neho iba kontajner.

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

Prvý príkaz vytvorí rozhranie v režime mosta, čo je dokumentovaný predvolený stav tohto ovládača a režim, ktorý chcete pre premávku medzi hostiteľom a kontajnerom. Druhý priradí /32, aby adresa nekolidovala s prefixom LAN, a štvrtý posiela cez pomocnú trasu iba adresu kontajnera.

Nepresmerúvajte celú LAN cez nové rozhranie. Bežná pripojená trasa zostáva tak, ako je, a trasa hostiteľa je zámerne úzka, aby jeden kontajner získal cestu bez toho, aby zvyšok segmentu menil správanie. Predvolená trasa smerom k pomocnej trase by bola iný návrh s inými dôsledkami. Držte ju konkrétnu a dosah škôd zostáva malý.

Tieto príkazy menia sieťové nastavenia na bežiacom hostiteľovi. Na zariadení alebo spravovanej platforme použite podporovaný konfiguračný mechanizmus danej platformy, pretože interaktívna zmena cez root-shell nemusí prežiť aktualizáciu.

Rozhodnite, ako sa zdroj zachová

S pomocnou trasou na mieste sa kontajner dostane k hostiteľovi a otázkou sa stáva, akú adresu zdroja odpoveď nesie. Zachovanie pôvodného zdroja VPN je čistejší model: kontajner vidí skutočnú adresu klienta a protokoly a prístupové pravidlá služby ju môžu použiť.

Aby to fungovalo, musí sieťová konfigurácia kontajnera pre túto cestu posielať premávku pre 10.95.0.0/24 na 192.168.60.250 ako svoju bránu. To je podporované nastavenie trasy alebo brány vo vnútri vlastnej konfigurácie kontajnera, nie trik na strane hostiteľa. Overte ho zvnútra kontajnera, namiesto toho, aby ste predpokladali, že nastavenie už platí. Predvolená brána, ktorá stále ukazuje na LAN router, bude naďalej posielať odpovede do tej istej diery.

Ak schválený návrh namiesto toho skrýva zdroje VPN, obmedzte preklad úzko: skutočný fond VPN, pomocná trasa ako výstupné rozhranie a konkrétny kontajner 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

Zlaďte pomocnú trasu ako výstupné rozhranie, nie tunel. Pravidlo, ktoré označí tunel ako výstupné rozhranie, nebude zodpovedať paketu smerujúcemu ku kontajneru, a to je chyba, ktorú takéto zapojenie zvyčajne obsahuje. Držte pravidlo rovnako úzke ako veta vyššie a pri zmene fondu ho skontrolujte.

Overujte z klienta, nie z hostiteľa

Požiadavka z hostiteľa samotného, viazaná na adresu pomocnej trasy, dokazuje, že pomocná trasa dosiahne na kontajner. Nedokazuje, že kontajner dokáže vrátiť premávku zachovanému zdroju 10.95.0.x, pretože adresa zdroja je v tomto teste vlastná adresa pomocnej 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

Prvý príkaz testuje úsek z hostiteľa do kontajnera a druhý ukazuje, čo skutočne prechádza pomocnou trasou, keď skutočný VPN klient posiela požiadavku. Pozrite sa na adresu zdroja na ceste dovnútra a či sa objaví odpoveď s rovnakým tokom.

Na hostiteľovi musí byť zapnuté preposielanie a cesta preposielania potrebuje povolenie pre fond VPN smerom k pomocnej trase na porte služby plus nadviazané odpovede. Pravidlo INPUT na hostiteľovi nepovoľuje preposielanú premávku, a to je častý dôvod, prečo sa paket zahodí po tom, čo smerovanie vyzerá správne.

Spustite skutočnú aplikáciu so skutočnými prihlasovacími údajmi a potom skontrolujte, že druhá, nesúvisiaca služba na tom istom kontajneri vás stále odmieta. Ak jediným spôsobom, ako to rozbehnúť, bolo otvoriť všetky pravidlá preposielania, návrh nie je hotový. Poznamenajte si aj to, akú adresu zdroja služba zaznamenala, pretože tú budú odteraz používať jej vlastné prístupové pravidlá.