Wêrom in macvlan-container net antwurdzje kin oan in VPN-klant

Stel jo in Linux-host foar dy’t in VPN beëiniget en tagelyk in container op in macvlan-netwurk draait. It LAN is 192.168.60.0/24, de container hat 192.168.60.210, en VPN-klanten komme fan 10.95.0.0/24. De klant berikt de tsjinst, it antwurd komt nea werom, en elke firewallregel op ’e host liket goed. Twa aparte beheiningen meitsje dat symptoom, en ien reparearje lit de oare gewoan stean.

Twa beheiningen, ien symptoom

De earste beheining is isolaasje: de macvlan-stjoerder fan Docker lit in container net mei syn eigen host prate fia de âlder-ynterface. Ferkear tusken de host-stapel en de container hat gjin paad, hoe’t de rûtes op ’e host ek skreaun binne.

De twadde beheining is it werompaad. De standertgateway fan ’e container is meast de LAN-router, sadat in antwurd oan in VPN-klant fia dy router nei bûten giet. Hat de router gjin rûte werom nei de VPN-pool, dan wurdt it antwurd earne yn ’e midden weilitten.

Dy beide flaters sjogge der fan ’e klant út itselde: in fersyk dat oankomt en in antwurd dat nea komt. Se hawwe ferskillende reparaasjes nedich, en in brede masquerade-regel kin ferbergje hokker fan ’e beide noch stikken is. Dêrom is de earste test in opname oan ’e containerkant ynstee fan noch in firewallwiziging. Komt it fersyk dêr nea, dan is it isolaasjebeheining oan ’e gong.

Bou de shim oan ’e hostkant, smel

In twadde macvlan-ynterface op ’e host, oan deselde âlder yn brêgemodus keppele, jout de host-stapel syn eigen identiteit op dat LAN-segmint. Reservesearje dêrfoar in adres bûten de DHCP-pool en bûten it containerberik, en rûte allinnich de container der troch.

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

It earste kommando makket it ynterface yn brêgemodus, dat is de dokumintearre standert foar dizze stjoerder en de modus dy’t jo wolle foar ferkear tusken host en container. It twadde jout in /32 ta sadat it adres net mei it LAN-prefiks botst, en it fjirde stjoert allinnich it adres fan ’e container troch de shim.

Stjoer net it hiele LAN troch it nije ynterface. De gewoane ferbûne rûte bliuwt sa’t er is, en de hostrûte is mei opsetsin smel sadat ien container in paad krijt sûnder dat de rest fan it segmint syn gedrach feroaret. In standertrûte nei de shim soe in oar ûntwerp mei oare gefolgen wêze. Hâld it spesifyk en it skea-oerflak bliuwt lyts.

Dizze kommando’s feroarje netwurkyustellingen op in libbene host. Op in apparaat of in beheard platfoarm brûk jo it stipe konfiguraasjemeganisme fan dat platfoarm, want in ynteraktive feroaring fia root-shell oerlibbet miskien gjin upgrade.

Beslis hoe’t de boarne bewarre wurdt

Mei de shim op syn plak kin de container de host berikke, en de fraach wurdt hokker boarneadres it antwurd draacht. De oarspronklike VPN-boarne bewarje is it skjinner model: de container sjocht it echte klientadres, en de logs en tagongsregels fan ’e tsjinst kinne it brûke.

Om dat wurkje te litten moat de netwurkkonfiguraasje fan ’e container foar dit paad ferkear foar 10.95.0.0/24 nei 192.168.60.250 stjoere as syn gateway. Dat is in stipe rûte- of gateway-ynstelling yn ’e eigen konfiguraasje fan ’e container, gjin trúk oan ’e hostkant. Befêstigje it fan binnen de container ynstee fan oan te nimmen dat de ynstelling yngien is. In standertgateway dy’t noch nei de LAN-router wiist, sil antwurden yn itselde gat bliuwe stjoeren.

As it goedkarde ûntwerp ynstee de VPN-boarnen ferberget, behein de oersetting dan smel: de echte VPN-pool, de shim as útgongsynterface, en de spesifike container en tsjinst.

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

Koppel de shim as útgongsynterface, net de tunnel. In regel dy’t de tunnel as útgongsynterface neamt, sil net oerienkomme mei in pakket dat nei de container giet, en dat is de flater dy’t sa’n opset meastentiids befettet. Hâld de regel like smel as de sin hjirboppe en besjoch him opnij as de pool feroaret.

Kontrolearje fan ’e klant, net fan ’e host

In fersyk fan ’e host sels, bûn oan it adres fan ’e shim, bewiist dat de shim de container berikke kin. It bewiist net dat de container ferkear weromstjoere kin nei in bewarre boarne 10.95.0.x, want it boarneadres is yn dy test dat fan ’e shim sels.

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

It earste kommando testet it stik fan host nei container, en it twadde lit sjen wat der eins troch de shim giet wylst in echte VPN-klant it fersyk docht. Sjoch nei it boarneadres op ’e yngong en oft der in antwurd mei deselde stream ferskynt.

Trochstjoere moat op ’e host ynskeakele wêze, en it trochstjoerpaad hat in tastimming nedich foar de VPN-pool nei de shim op ’e tsjinstpoarte plus fêstige antwurden. In INPUT-regel op ’e host autorisearret trochstjoerd ferkear net, en dat is in faak foarkommende reden dat it pakket weilitten wurdt neidat de rûtering goed liket.

Rin de echte applikaasje mei echte ynloggegevens, en kontrolearje dan dat in twadde, net besibbe tsjinst op deselde container jo noch ôfwist. As de iennichste manier om it wurkje te litten wie it iepenjen fan elke trochstjoerregel, dan is it ûntwerp net klear. Notearje ek hokker boarneadres de tsjinst registrearre hat, want dat is wat syn eigen tagongsregels fan no ôf brûke sille.