Zakaj vsebnik macvlan ne more odgovoriti odjemalcu VPN

Predstavljajte si gostitelja Linux, ki zaključi VPN in hkrati izvaja vsebnik v omrežju macvlan. LAN je 192.168.60.0/24, vsebnik ima 192.168.60.210, odjemalci VPN pa prihajajo iz 10.95.0.0/24. Odjemalec doseže storitev, odgovor se nikoli ne vrne in vsako pravilo požarnega zidu na gostitelju je videti pravilno. Ta simptom povzročita dve ločeni omejitvi, popravilo ene pa pusti drugo na mestu.

Dve omejitvi, en simptom

Prva omejitev je izolacija: gonilnik macvlan v Dockerju vsebniku ne dovoli pogovora z lastnim gostiteljem prek nadrejenega vmesnika. Promet med skladom gostitelja in vsebnikom nima poti, ne glede na to, kako so zapisane poti na gostitelju.

Druga omejitev je pot nazaj. Privzeti prehod vsebnika je običajno usmerjevalnik LAN, zato odgovor, naslovljen na odjemalca VPN, odide skozi ta usmerjevalnik. Če usmerjevalnik nima poti nazaj v sklad VPN, se odgovor nekje vmes zavrže.

Obe napaki sta z vidika odjemalca videti enako: zahteva prispe in odgovor nikoli ne prispe. Potrebujeta različna popravila, široko pravilo masquerade pa lahko skrije, katera od njiju je še pokvarjena. Zato je prvi test zajem na strani vsebnika in ne še ena sprememba požarnega zidu. Če se zahteva tam nikoli ne pojavi, velja omejitev izolacije.

Zgradite shim na strani gostitelja, ozko

Drugi vmesnik macvlan na gostitelju, priključen na isti nadrejeni vmesnik v načinu mostu, da skladu gostitelja lastno identiteto v tem segmentu LAN. Zanj rezervirajte naslov zunaj sklada DHCP in zunaj obsega vsebnika ter skozi njega usmerjajte samo vsebnik.

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

Prvi ukaz ustvari vmesnik v načinu mostu, kar je dokumentirana privzeta nastavitev tega gonilnika in način, ki ga želite za promet med gostiteljem in vsebnikom. Drugi dodeli /32, da naslov ne trči s predpono LAN, četrti pa skozi shim pošlje samo naslov vsebnika.

Ne preusmerjajte celotnega LAN skozi novi vmesnik. Običajna povezana pot ostane takšna, kot je, pot gostitelja pa je namerno ozka, da en vsebnik dobi pot, ne da bi preostali del segmenta spremenil vedenje. Privzeta pot proti shimu bi bila drugačna zasnova z drugačnimi posledicami. Naj bo konkretna in obseg škode ostane majhen.

Ti ukazi spreminjajo omrežne nastavitve na delujočem gostitelju. Na napravi ali upravljani platformi uporabite podprti konfiguracijski mehanizem te platforme, ker interaktivna sprememba v lupini root morda ne bo preživela nadgradnje.

Odločite, kako se vir ohrani

Ko je shim na mestu, lahko vsebnik doseže gostitelja, vprašanje pa postane, kateri naslov vira nosi odgovor. Ohranjanje izvirnega vira VPN je čistejši model: vsebnik vidi pravi naslov odjemalca, dnevniki in pravila dostopa storitve pa ga lahko uporabijo.

Da bi to delovalo, mora omrežna konfiguracija vsebnika za to pot pošiljati promet za 10.95.0.0/24 na 192.168.60.250 kot svoj prehod. To je podprta nastavitev poti ali prehoda znotraj konfiguracije samega vsebnika, ne trik na strani gostitelja. Potrdite jo od znotraj vsebnika, namesto da domnevate, da je nastavitev začela veljati. Privzeti prehod, ki še vedno kaže na usmerjevalnik LAN, bo še naprej pošiljal odgovore v isto luknjo.

Če odobrena zasnova namesto tega skriva vire VPN, omejite prevod ozko: pravi sklad VPN, shim kot izhodni vmesnik ter konkretni vsebnik in storitev.

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

Ujemite shim kot izhodni vmesnik, ne tunel. Pravilo, ki tunel navaja kot izhodni vmesnik, se ne bo ujemalo s paketom na poti proti vsebniku, in prav ta napaka je običajno v takšni postavitvi. Pravilo naj bo tako ozko kot zgornji stavek, in ga pregledajte, ko se sklad spremeni.

Preverite z odjemalca, ne z gostitelja

Zahteva z gostitelja samega, vezana na naslov shima, dokazuje, da shim lahko doseže vsebnik. Ne dokazuje, da lahko vsebnik pošlje promet nazaj ohranjenemu viru 10.95.0.x, ker je naslov vira v tem testu naslov samega shima.

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

Prvi ukaz preizkusi odsek od gostitelja do vsebnika, drugi pa pokaže, kaj v resnici prečka shim, medtem ko pravi odjemalec VPN pošilja zahtevo. Poglejte naslov vira na poti navznoter in ali se pojavi odgovor z enakim tokom.

Na gostitelju mora biti omogočeno posredovanje, pot posredovanja pa potrebuje dovoljenje za sklad VPN proti shimu na vratih storitve in za vzpostavljene odgovore. Pravilo INPUT na gostitelju ne dovoljuje posredovanega prometa, in to je pogost razlog, da se paket zavrže po tem, ko je usmerjanje videti pravilno.

Zaženite pravo aplikacijo s pravimi poverilnicami in nato preverite, ali vas druga, nepovezana storitev v istem vsebniku še vedno zavrača. Če je bila edina pot do delovanja odpreti vsako pravilo posredovanja, zasnova ni dokončana. Zabeležite tudi, kateri naslov vira je storitev zapisala, saj ga bodo od zdaj naprej uporabljala njena lastna pravila dostopa.