Zergatik ezin dion macvlan edukiontziak VPN bezeroari erantzun

Imajinatu VPN bat amaitzen duen eta aldi berean macvlan sare batean edukiontzi bat exekutatzen duen Linux ostalari bat. LANa 192.168.60.0/24 da, edukiontziak 192.168.60.210 dauka, eta VPN bezeroak 10.95.0.0/24-tik datoz. Bezeroa zerbitzura iristen da, erantzuna ez da inoiz itzultzen, eta ostalariko suhorma-araubide guztiek zuzenak dirudite. Muga bereizi bik sintoma hori sortzen dute, eta bat konpontzeak bestea bere lekuan uzten du.

Bi muga, sintoma bat

Lehen muga isolamendua da: Dockerren macvlan kontrolatzaileak ez dio edukiontziari uzten bere ostalariarekin guraso-interfazearen bidez hitz egiten. Ostalariaren pila eta edukiontziaren arteko trafikoak ez du biderik, ostalariko bideak nola idatzita dauden ere.

Bigarren muga itzulera-bidea da. Edukiontziaren ate lehenetsia LANeko bideratzailea izan ohi da, beraz VPN bezero bati zuzendutako erantzuna bideratzaile horretatik irteten da. Bideratzaileak VPN igerilekura itzultzeko biderik ez badu, erantzuna erdian nonbait botatzen da.

Hutsegite biok berdinak dirudite bezeroaren ikuspegitik: iristen den eskaera bat eta inoiz iristen ez den erantzun bat. Konponketa desberdinak behar dituzte, eta masquerade araubide zabal batek ezkuta dezake zein dagoen oraindik hautsita. Horregatik lehen proba edukiontziaren aldeko harrapaketa bat da, eta ez suhormako beste aldaketa bat. Eskaera han inoiz agertzen ez bada, isolamendu-muga da indarrean dagoena.

Eraiki ostalariaren aldeko shima, estu

Ostalarian bigarren macvlan interfaze bat, guraso berari zubi moduan lotuta, ostalariaren pilari identitate propioa ematen dio LAN segmentu horretan. Erreserbatu hari DHCP igerilekutik kanpo eta edukiontziaren barrutitik kanpo dagoen helbide bat, eta bideratu edukiontzia soilik haren bidez.

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

Lehen komandoak interfazea zubi moduan sortzen du, hau da, kontrolatzaile honetarako dokumentatutako lehenespena eta ostalariaren eta edukiontziaren arteko trafikorako nahi duzun modua. Bigarrenak /32 esleitzen dio helbidea LAN aurrizkiarekin talka ez dadin, eta laugarrenak edukiontziaren helbidea soilik bidaltzen du shimaren bidez.

Ez birbideratu LAN osoa interfaze berritik. Konektatutako bide arrunta dagoen bezala geratzen da, eta ostalariaren bidea nahita estua da edukiontzi batek bidea irabaz dezan segmentuaren gainerakoak jokaera aldatu gabe. Shimerantz doan bide lehenetsia beste diseinu bat litzateke, beste ondorio batzuekin. Eduki ezazu zehatza eta kalte-erradioa txiki mantenduko da.

Komando hauek sare-ezarpenak aldatzen dituzte martxan dagoen ostalari batean. Gailu batean edo kudeatutako plataforma batean, erabili plataforma horrek onartzen duen konfigurazio-mekanismoa, root-shell bidezko aldaketa interaktibo batek baliteke berritze bat gainditzea.

Erabaki nola gordetzen den iturburua

Shima lekuan dela, edukiontzia ostalarira irits daiteke, eta galdera erantzunak zein iturburu-helbide daraman bihurtzen da. Jatorrizko VPN iturburua gordetzea eredu garbiagoa da: edukiontziak bezeroaren benetako helbidea ikusten du, eta zerbitzuaren erregistroek eta sarbide-arauek erabil dezakete.

Hori funtziona dezan, edukiontziaren sare-konfigurazioak bide honetarako 10.95.0.0/24-ko trafikoak 192.168.60.250era bidali behar du bere ate gisa. Hau edukiontziaren beraren konfigurazioan onartutako bide edo ate ezarpena da, ez ostalariaren aldeko trikimailua. Berretsi edukiontziaren barrutik, ezarpena indarrean sartu dela suposatu beharrean. Oraindik LANeko bideratzaileari seinalatzen dion ate lehenetsi batek zulo berera bidaltzen jarraituko du.

Onartutako diseinuak VPN iturburuak ezkutatzen baditu, mugatu itzulpena estu: benetako VPN igerilekua, shima irteerako interfaze gisa, eta edukiontzi eta zerbitzu zehatza.

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

Pareka ezazu shima irteerako interfaze gisa, ez tunela. Tunela irteerako interfaze gisa izendatzen duen araubide bat ez dator bat edukiontziaren aldera doan pakete batekin, eta hori da horrelako muntaiek normalean duten akatsa. Eduki ezazu araua goiko esaldia bezain estua eta berrikusi igerilekua aldatzen denean.

Egiaztatu bezeroarengandik, ez ostalariarengandik

Ostalariak berak shimaren helbidera lotutako eskaera batek frogatzen du shimak edukiontzira irits daitekeela. Ez du frogatzen edukiontziak gordetako 10.95.0.x iturburu batera trafikoa itzul dezakeenik, proba horretako iturburu-helbidea shimarena bera delako.

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

Lehen komandoak ostalariaren eta edukiontziaren arteko tartea probatzen du, eta bigarrenak shimatik benetan zer igarotzen den erakusten du benetako VPN bezero batek eskaera egiten duen bitartean. Begiratu sarrerako bidean iturburu-helbideari eta erantzun bat fluxu berarekin agertzen den.

Birbidaltzea gaituta egon behar du ostalarian, eta birbidaltze-bideak VPN igerilekutik shimera baimen bat behar du zerbitzuaren portuan, eta gainera ezarritako erantzunak. Ostalariko INPUT araubide batek ez du birbidalitako trafikoa baimentzen, eta hori ohiko arrazoia da paketea baztertzeko bideratzea zuzena dirudien ondoren.

Exekutatu benetako aplikazioa benetako kredentzialekin, eta egiaztatu gero edukiontzi berean dagoen bigarren zerbitzu erlazionatu gabe batek ukatzen jarraitzen dizula. Funtziona dezan modu bakarra birbidaltze-araubide guztiak irekitzea bazen, diseinua ez dago amaituta. Idatzi ere zerbitzuak erregistratu duen iturburu-helbidea, hemendik aurrera haren sarbide-arauek hori erabiliko dutelako.