Miks macvlan-konteiner ei saa VPN-kliendile vastata

Kujutage ette Linuxi hosti, mis lõpetab VPN-i ja käitab samal ajal konteinerit macvlan-võrgus. LAN on 192.168.60.0/24, konteineril on 192.168.60.210 ja VPN-kliendid tulevad aadressilt 10.95.0.0/24. Klient jõuab teenuseni, vastus ei tule kunagi tagasi ja iga tulemüürireegel hostil näib õige. Selle sümptomi tekitavad kaks eraldiseisvat piirangut ja ühe parandamine jätab teise paigale.

Kaks piirangut, üks sümptom

Esimene piirang on isolatsioon: Dockeri macvlan-draiver ei luba konteineril oma hostiga läbi vanemliidese rääkida. Hostipinu ja konteineri vahelisel liiklusel pole teed, ükskõik kuidas hosti marsruudid on kirjutatud.

Teine piirang on tagasitee. Konteineri vaikelüüs on tavaliselt LAN-i ruuter, seega VPN-kliendile adresseeritud vastus väljub sellest ruuterist. Kui ruuteril pole marsruuti tagasi VPN-i basseini, visatakse vastus kuskil vahepeal ära.

Need kaks riket näevad kliendi poolt vaadates identsed välja: päring saabub ja vastust ei tule kunagi. Need vajavad erinevaid parandusi ja lai masquerade-reegel võib varjata, kumb neist on endiselt katki. Seetõttu on esimene test konteineri poolel tehtav andmepüük, mitte veel üks tulemüüri muudatus. Kui päring seal kunagi ei ilmu, on mängus isolatsioonipiirang.

Ehitage hostipoolne shim kitsalt

Teine macvlan-liides hostil, mis on sama vanemaga sillarežiimis ühendatud, annab hostipinule selles LAN-segmendis oma identiteedi. Broneerige sellele aadress väljaspool DHCP-basseini ja väljaspool konteineri vahemikku ning suunake selle kaudu ainult konteinerit.

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

Esimene käsk loob liidese sillarežiimis, mis on selle draiveri dokumenteeritud vaikeväärtus ja režiim, mida soovite hosti ja konteineri vaheliseks liikluseks. Teine määrab /32, et aadress ei läheks LAN-i prefiksiga vastuollu, ja neljas saadab läbi shimi ainult konteineri aadressi.

Ärge suunake kogu LAN-i uue liidese kaudu. Tavaline ühendatud marsruut jääb nii, nagu on, ja hosti marsruut on meelega kitsas, et üks konteiner saaks tee, ilma et ülejäänud segment oma käitumist muudaks. Vaikemarsruut shimi suunas oleks teistsugune lahendus teistsuguste tagajärgedega. Hoidke see konkreetne ja kahjuala jääb väikeseks.

Need käsud muudavad võrguseadeid töötaval hostil. Seadmel või hallatud platvormil kasutage selle platvormi toetatud konfiguratsioonimehhanismi, sest interaktiivne muudatus root-shellis ei pruugi uuendust üle elada.

Otsustage, kuidas läte säilitatakse

Kui shim on paigas, pääseb konteiner hostile ligi ja küsimuseks saab, millist lähteaadressi vastus kannab. Algse VPN-lätte säilitamine on puhtam mudel: konteiner näeb kliendi tegelikku aadressi ning teenuse logid ja juurdepääsureeglid saavad seda kasutada.

Selle toimimiseks peab konteineri võrgukonfiguratsioon saatma selle tee jaoks liikluse aadressilt 10.95.0.0/24 aadressile 192.168.60.250 oma lüüsina. See on toetatud marsruudi- või lüüsiseade konteineri enda konfiguratsioonis, mitte hostipoolne trikk. Kinnitage see konteineri seest, selle asemel et eeldada, et seade jõustus. Vaikelüüs, mis osutab endiselt LAN-i ruuterile, saadab vastused edasi samasse auku.

Kui kinnitatud lahendus peidab hoopis VPN-i lätted, piiritlege tõlge kitsalt: tegelik VPN-i bassein, shim väljuva liidesena ning konkreetne konteiner ja teenus.

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

Sobitage shim väljuva liidesena, mitte tunneliga. Reegel, mis nimetab tunneli väljuvaks liideseks, ei sobi konteineri poole liikuva paketiga ja just see viga sisaldub tavaliselt sellises seadistuses. Hoidke reegel sama kitsas kui ülalolev lause ja vaadake see üle, kui bassein muutub.

Kontrollige kliendilt, mitte hostilt

Hostilt endalt lähtuv päring, mis on seotud shimi aadressiga, tõestab, et shim jõuab konteinerini. See ei tõesta, et konteiner suudab liikluse tagasi saata säilitatud lähtele 10.95.0.x, sest selle testi lähteaadress on shimi enda oma.

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

Esimene käsk testib lõiku hostist konteinerini ja teine näitab, mis tegelikult shimist läbi läheb, kui tõeline VPN-klient päringu teeb. Vaadake lähteaadressi sissepoole tuleval teel ja seda, kas sama vooga ilmub vastus.

Hostil peab olema edasisaatmine lubatud ja edasisaatmise teel on vaja luba VPN-i basseinilt shimile teenuse pordil ning lisaks loodud vastuseid. Hostil olev INPUT-reegel ei volita edasisaadetavat liiklust, mis on tavaline põhjus, miks pakett visatakse ära pärast seda, kui marsruutimine näib õige.

Käivitage tegelik rakendus tegelike mandaatidega ja kontrollige seejärel, et teine, mitteseotud teenus samas konteineris keeldub teist endiselt. Kui ainus viis selle töölesaamiseks oli avada iga edasisaatmise reegel, ei ole lahendus valmis. Märkige üles ka see, millise lähteaadressi teenus salvestas, sest just seda hakkavad tema enda juurdepääsureeglid edaspidi kasutama.