Kāpēc macvlan konteiners nevar atbildēt VPN klientam

Iedomājieties Linux saimnieku, kas pārtrauc VPN un vienlaikus darbina konteineru macvlan tīklā. LAN ir 192.168.60.0/24, konteineram ir 192.168.60.210, un VPN klienti nāk no 10.95.0.0/24. Klients sasniedz pakalpojumu, atbilde nekad neatgriežas, un katra ugunsmūra kārtula saimniekā izskatās pareiza. Šo simptomu rada divi atsevišķi ierobežojumi, un viena labošana otru atstāj savā vietā.

Divi ierobežojumi, viens simptoms

Pirmais ierobežojums ir izolācija: Docker macvlan draiveris neļauj konteineram sazināties ar savu pašu saimnieku caur vecāka saskarni. Satiksmei starp saimnieka steku un konteineru nav ceļa, lai kā arī būtu rakstīti maršruti saimniekā.

Otrais ierobežojums ir atgriešanās ceļš. Konteinera noklusējuma vārteja parasti ir LAN maršrutētājs, tāpēc VPN klientam adresētā atbilde iziet caur šo maršrutētāju. Ja maršrutētājam nav maršruta atpakaļ uz VPN baseinu, atbilde tiek izmesta kaut kur pa vidu.

Abi bojājumi no klienta viedokļa izskatās vienādi: pieprasījums atnāk, bet atbilde nekad neatnāk. Tiem vajadzīgi dažādi labojumi, un plaša masquerade kārtula var noslēpt, kurš no tiem vēl ir salūzis. Tāpēc pirmais tests ir uztveršana konteinera pusē, nevis vēl viena ugunsmūra izmaiņa. Ja pieprasījums tur nekad neparādās, tad darbojas izolācijas ierobežojums.

Veidojiet saimnieka puses shim šauri

Otra macvlan saskarne saimniekā, kas tilta režīmā pievienota tam pašam vecākam, piešķir saimnieka stekam savu identitāti šajā LAN segmentā. Rezervējiet tai adresi ārpus DHCP baseina un ārpus konteinera diapazona, un laižiet caur to tikai konteineru.

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

Pirmā komanda izveido saskarni tilta režīmā, kas ir šī draivera dokumentētais noklusējums un režīms, kuru vēlaties satiksmei starp saimnieku un konteineru. Otrā piešķir /32, lai adrese nesadurtos ar LAN prefiksu, un ceturtā caur shim sūta tikai konteinera adresi.

Nepārvirziet visu LAN caur jauno saskarni. Parastais savienotais maršruts paliek tāds, kāds tas ir, un saimnieka maršruts ir apzināti šaurs, lai viens konteiners iegūtu ceļu, bet pārējā segmenta daļa nemainītu savu uzvedību. Noklusējuma maršruts uz shim būtu cits projekts ar citām sekām. Turiet to konkrētu, un bojājumu rādiuss paliek mazs.

Šīs komandas maina tīkla iestatījumus darbojošā saimniekā. Ierīcē vai pārvaldītā platformā izmantojiet šīs platformas atbalstīto konfigurācijas mehānismu, jo interaktīva izmaiņa root-shell vidē var neizdzīvot atjauninājumu.

Izlemiet, kā avots tiek saglabāts

Ar shim savā vietā konteiners var sasniegt saimnieku, un jautājums kļūst par to, kādu avota adresi nes atbilde. Sākotnējā VPN avota saglabāšana ir tīrākais modelis: konteiners redz īsto klienta adresi, un pakalpojuma žurnāli un piekļuves kārtulas var to izmantot.

Lai tas darbotos, konteinera tīkla konfigurācijai šim ceļam ir jāsūta 10.95.0.0/24 satiksme uz 192.168.60.250 kā savu vārteju. Tas ir atbalstīts maršruta vai vārtejas iestatījums paša konteinera konfigurācijā, nevis saimnieka puses triks. Apstipriniet to konteinera iekšpusē, nevis pieņemiet, ka iestatījums ir stājies spēkā. Noklusējuma vārteja, kas joprojām rāda uz LAN maršrutētāju, turpinās sūtīt atbildes tajā pašā caurumā.

Ja apstiprinātais projekts tā vietā slēpj VPN avotus, sašauriniet tulkojumu: īstais VPN baseins, shim kā izejošā saskarne un konkrētais konteiners un pakalpojums.

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

Saskaņojiet shim kā izejas saskarni, nevis tuneli. Kārtula, kas tuneli nosauc par izejošo saskarni, nesaskanēs ar paketi, kas dodas uz konteineru, un tieši šī kļūda šādā uzstādījumā parasti ir. Turiet kārtulu tikpat šauru kā teikums augstāk, un pārskatiet to, kad baseins mainās.

Pārbaudiet no klienta, nevis no saimnieka

Pieprasījums no paša saimnieka, piesaistīts shim adresei, pierāda, ka shim var sasniegt konteineru. Tas nepierāda, ka konteiners var nosūtīt satiksmi atpakaļ uz saglabātu 10.95.0.x avotu, jo šajā testā avota adrese ir paša shim adrese.

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

Pirmā komanda pārbauda posmu no saimnieka līdz konteineram, un otrā parāda, kas patiešām iet caur shim, kamēr īsts VPN klients veic pieprasījumu. Paskatieties uz avota adresi ieejas ceļā un uz to, vai parādās atbilde ar to pašu plūsmu.

Saimniekā jābūt iespējotai pāradresācijai, un pāradresācijas ceļam vajadzīga atļauja VPN baseinam uz shim pakalpojuma portā, kā arī izveidotām atbildēm. INPUT kārtula saimniekā neatļauj pāradresēto satiksmi, un tas ir biežs iemesls, kāpēc pakete tiek izmesta pēc tam, kad maršrutēšana izskatās pareiza.

Palaidiet īsto lietojumprogrammu ar īstiem akreditācijas datiem, pēc tam pārbaudiet, vai otra, nesaistīta pakalpojuma instance tajā pašā konteinerā joprojām jūs noraida. Ja vienīgais veids, kā to panākt, bija atvērt katru pāradresācijas kārtulu, projekts nav pabeigts. Ņemiet vērā arī to, kādu avota adresi pakalpojums reģistrēja, jo tieši to turpmāk izmantos tā paša piekļuves kārtulas.