Pse një kontejner macvlan nuk mund t'i përgjigjet një klienti VPN

Imagjinoni një host Linux që përfundon një VPN dhe njëkohësisht ekzekuton një kontejner në një rrjet macvlan. LAN-i është 192.168.60.0/24, kontejneri ka 192.168.60.210, dhe klientët VPN vijnë nga 10.95.0.0/24. Klienti arrin te shërbimi, përgjigjja nuk kthehet kurrë, dhe çdo rregull muri zjarri në host duket i saktë. Dy kufizime të ndara krijojnë atë simptomë, dhe rregullimi i njërit e lë tjetrin në vendin e vet.

Dy kufizime, një simptomë

Kufizimi i parë është izolimi: drejtuesi macvlan i Docker nuk lejon një kontejner të flasë me hostin e vet përmes ndërfaqes prindërore. Trafiku midis stivës së hostit dhe kontejnerit nuk ka rrugë, sado mirë të jenë shkruar rrugët në host.

Kufizimi i dytë është rruga e kthimit. Porta e paracaktuar e kontejnerit është zakonisht ruteri i LAN-it, kështu që një përgjigje drejtuar një klienti VPN del përmes atij ruteri. Nëse ruteri nuk ka rrugë kthimi drejt grupit VPN, përgjigjja hidhet diku në mes.

Të dyja dështimet duken njësoj nga këndvështrimi i klientit: një kërkesë që arrin dhe një përgjigje që nuk vjen kurrë. Ato kërkojnë rregullime të ndryshme, dhe një rregull i gjerë masquerade mund të fshehë cila prej tyre është ende e prishur. Prandaj testi i parë është një kapje në anën e kontejnerit dhe jo një ndryshim tjetër i murit të zjarrit. Nëse kërkesa nuk shfaqet kurrë atje, kufizimi i izolimit është ai që vepron.

Ndërtoni shimin në anën e hostit, ngushtë

Një ndërfaqe e dytë macvlan në host, e lidhur me të njëjtin prind në modalitetin urë, i jep stivës së hostit identitetin e vet në atë segment LAN. Rezervoni për të një adresë jashtë grupit DHCP dhe jashtë diapazonit të kontejnerit, dhe kaloni vetëm kontejnerin përmes saj.

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

Komanda e parë krijon ndërfaqen në modalitetin urë, që është vlera e paracaktuar e dokumentuar për këtë drejtues dhe modaliteti që dëshironi për trafikun midis hostit dhe kontejnerit. E dyta cakton një /32 që adresa të mos përplaset me prefiksin e LAN-it, dhe e katërta dërgon përmes shimit vetëm adresën e kontejnerit.

Mos e ridrejtoni të gjithë LAN-in përmes ndërfaqes së re. Rruga e zakonshme e lidhur mbetet ashtu si është, dhe rruga e hostit është qëllimisht e ngushtë që një kontejner të fitojë një rrugë pa ndryshuar sjelljen e pjesës tjetër të segmentit. Një rrugë e paracaktuar drejt shimit do të ishte një dizajn tjetër me pasoja të tjera. Mbajeni specifike dhe rrezja e dëmit mbetet e vogël.

Këto komanda ndryshojnë konfigurimin e rrjetit në një host që punon. Në një pajisje ose platformë të menaxhuar, përdorni mekanizmin e konfigurimit të mbështetur të asaj platforme, sepse një ndryshim interaktiv në root shell mund të mos i mbijetojë një përmirësimi.

Vendosni si ruhet burimi

Me shimin në vend, kontejneri mund të arrijë hostin, dhe pyetja bëhet se çfarë adrese burimi mbart përgjigjja. Ruajtja e burimit origjinal VPN është modeli më i pastër: kontejneri sheh adresën e vërtetë të klientit, dhe regjistrat dhe rregullat e aksesit të shërbimit mund ta përdorin.

Që kjo të funksionojë, konfigurimi i rrjetit të kontejnerit duhet të dërgojë për këtë rrugë trafikun për 10.95.0.0/24 drejt 192.168.60.250 si portën e vet. Ky është një rregullim i mbështetur rruge ose porte brenda konfigurimit të vetë kontejnerit, jo një mashtrim në anën e hostit. Konfirmojeni nga brenda kontejnerit në vend që të supozoni se rregullimi ka hyrë në fuqi. Një portë e paracaktuar që vazhdon të tregojë drejt ruterit të LAN-it do të vazhdojë t'i dërgojë përgjigjet në të njëjtën vrimë.

Nëse dizajni i miratuar i fsheh burimet VPN në vend të kësaj, kufizoni përkthimin ngushtë: grupi real VPN, shimi si ndërfaqe dalëse, dhe kontejneri e shërbimi konkret.

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

Përputhni shimin si ndërfaqe dalëse, jo tunelin. Një rregull që emërton tunelin si ndërfaqe dalëse nuk do të përputhet me një paketë që shkon drejt kontejnerit, dhe pikërisht ky është gabimi që një konfigurim i tillë zakonisht përmban. Mbajeni rregullin po aq të ngushtë sa fjalia më sipër dhe rishikojeni kur grupi ndryshon.

Verifikoni nga klienti, jo nga hosti

Një kërkesë nga vetë hosti, e lidhur me adresën e shimit, provon se shimi mund të arrijë kontejnerin. Nuk provon se kontejneri mund ta dërgojë trafikun mbrapsht te një burim i ruajtur 10.95.0.x, sepse adresa e burimit në atë test është ajo e vetë shimit.

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

Komanda e parë teston pjesën nga hosti në kontejner, dhe e dyta tregon çfarë kalon në të vërtetë përmes shimit ndërsa një klient real VPN bën kërkesën. Shikoni adresën e burimit në rrugën hyrëse dhe nëse shfaqet një përgjigje me të njëjtin rrjedhë.

Përcillja duhet të jetë e aktivizuar në host, dhe rruga e përcilljes ka nevojë për një leje për grupin VPN drejt shimit në portën e shërbimit, plus përgjigjet e vendosura. Një rregull INPUT në host nuk e autorizon trafikun e përcjellë, dhe kjo është një arsye e zakonshme që paketa hidhet pasi rrugëtimi duket i saktë.

Ekzekutoni aplikacionin real me kredenciale reale, më pas kontrolloni që një shërbim i dytë, i palidhur, në të njëjtin kontejner ju refuzon ende. Nëse mënyra e vetme për ta bërë të funksionojë ishte hapja e çdo rregulli të përcilljes, dizajni nuk është përfunduar. Vini re edhe cilën adresë burimi regjistroi shërbimi, sepse atë do të përdorin rregullat e tij të aksesit prej tani.