Bakit hindi makakasagot ang isang macvlan container sa isang VPN client

Isipin ang isang Linux host na nagtatapos ng VPN at sabay na nagpapatakbo ng container sa isang macvlan network. Ang LAN ay 192.168.60.0/24, ang container ay may 192.168.60.210, at ang mga VPN client ay dumarating mula sa 10.95.0.0/24. Naabot ng client ang serbisyo, hindi kailanman bumabalik ang sagot, at mukhang tama ang bawat firewall rule sa host. Dalawang magkahiwalay na hadlang ang lumilikha ng sintomas na iyon, at ang pag-aayos ng isa ay iniiwan ang isa sa lugar nito.

Dalawang hadlang, isang sintomas

Ang unang hadlang ay paghihiwalay: hindi pinapayagan ng macvlan driver ng Docker ang isang container na makipag-usap sa sarili nitong host sa pamamagitan ng parent interface. Walang daan ang trapiko sa pagitan ng stack ng host at ng container, gaano man isulat ang mga ruta sa host.

Ang ikalawang hadlang ay ang daan pabalik. Ang default gateway ng container ay karaniwang ang LAN router, kaya lumalabas sa router na iyon ang sagot na nakadirekta sa isang VPN client. Kung walang ruta pabalik sa VPN pool ang router, itinatapon ang sagot sa isang lugar sa gitna.

Magkapareho ang anyo ng dalawang pagkabigo mula sa pananaw ng client: isang kahilingang dumarating at isang sagot na hindi kailanman dumarating. Kailangan nila ng magkaibang pag-aayos, at ang isang malawak na masquerade rule ay maaaring magtago kung alin sa dalawa ang sira pa. Kaya ang unang pagsubok ay isang pagkuha sa panig ng container at hindi isa pang pagbabago sa firewall. Kung hindi kailanman lumilitaw ang kahilingan doon, ang hadlang sa paghihiwalay ang gumagana.

Buuin ang shim sa panig ng host, nang makitid

Ang ikalawang macvlan interface sa host, na nakakabit sa parehong parent sa bridge mode, ay nagbibigay sa stack ng host ng sariling pagkakakilanlan sa segment ng LAN na iyon. Magreserba ng address sa labas ng DHCP pool at sa labas ng saklaw ng container para dito, at dumaan lamang ang container sa pamamagitan nito.

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

Ang unang utos ay lumilikha ng interface sa bridge mode, na siyang dokumentadong default para sa driver na ito at ang mode na gusto mo para sa trapiko sa pagitan ng host at container. Ang ikalawa ay nagtatalaga ng /32 upang hindi bumangga ang address sa prefix ng LAN, at ang ikaapat ay nagpapadala lamang ng address ng container sa pamamagitan ng shim.

Huwag i-redirect ang buong LAN sa bagong interface. Nananatili ang karaniwang konektadong ruta, at sadyang makitid ang ruta ng host upang makakuha ng daan ang isang container nang hindi nagbabago ang pag-uugali ng natitirang bahagi ng segment. Ang default na ruta patungo sa shim ay ibang disenyo na may ibang kahihinatnan. Panatilihin itong partikular at nananatiling maliit ang lawak ng pinsala.

Binabago ng mga utos na ito ang mga setting ng network sa isang tumatakbong host. Sa isang appliance o pinamamahalaang platform, gamitin ang sinusuportahang mekanismo ng configuration ng platform na iyon, dahil maaaring hindi mabuhay ang interactive na pagbabago sa root shell pagkatapos ng upgrade.

Magpasya kung paano pinapanatili ang pinagmulan

Sa shim na nasa lugar, maaabot ng container ang host, at ang tanong ay kung aling source address ang dinadala ng sagot. Ang pagpapanatili ng orihinal na pinagmulan ng VPN ay ang mas malinis na modelo: nakikita ng container ang tunay na address ng client, at magagamit ito ng mga log at access rule ng serbisyo.

Upang gumana iyon, kailangang ipadala ng configuration ng network ng container para sa daang ito ang trapiko para sa 10.95.0.0/24 patungo sa 192.168.60.250 bilang gateway nito. Ito ay sinusuportahang setting ng ruta o gateway sa loob ng configuration ng container mismo, hindi isang pakulo sa panig ng host. Kumpirmahin ito mula sa loob ng container sa halip na ipalagay na nagkabisa na ang setting. Ang default gateway na nakaturo pa rin sa LAN router ay patuloy na magpapadala ng mga sagot sa parehong butas.

Kung itinatago naman ng aprubadong disenyo ang mga pinagmulan ng VPN, limitahan ang pagsasalin nang makitid: ang tunay na VPN pool, ang shim bilang outgoing interface, at ang partikular na container at serbisyo.

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

Itugma ang shim bilang egress interface, hindi ang tunnel. Ang rule na tumutukoy sa tunnel bilang outgoing interface ay hindi tutugma sa packet na patungo sa container, at iyon ang pagkakamaling karaniwang taglay ng ganitong setup. Panatilihing kasingsikip ng pangungusap sa itaas ang rule at repasuhin ito kapag nagbago ang pool.

Beripikahin mula sa client, hindi sa host

Ang kahilingan mula sa host mismo, na nakatali sa address ng shim, ay nagpapatunay na naaabot ng shim ang container. Hindi nito pinapatunayan na maibabalik ng container ang trapiko sa pinanatiling pinagmulan na 10.95.0.x, dahil ang source address sa pagsubok na iyon ay ang sarili ng shim.

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

Sinusubok ng unang utos ang bahagi mula host hanggang container, at ipinapakita ng ikalawa kung ano talaga ang tumatawid sa shim habang gumagawa ng kahilingan ang isang tunay na VPN client. Tingnan ang source address sa papasok na daan at kung may sagot na lumilitaw na may parehong daloy.

Kailangang naka-enable ang forwarding sa host, at kailangan ng forwarding path ng pahintulot para sa VPN pool patungo sa shim sa port ng serbisyo at ng mga naitatag na sagot. Ang INPUT rule sa host ay hindi nagpapahintulot sa naipasa na trapiko, at iyon ay karaniwang dahilan kung bakit itinatapon ang packet pagkatapos magmukhang tama ang routing.

Patakbuhin ang tunay na aplikasyon gamit ang tunay na kredensyal, pagkatapos tingnan kung tinatanggihan ka pa rin ng ikalawa at walang kaugnayang serbisyo sa parehong container. Kung ang tanging paraan upang mapagana ito ay buksan ang bawat forwarding rule, hindi pa tapos ang disenyo. Tandaan din kung aling source address ang naitala ng serbisyo, dahil iyon ang gagamitin ng sarili nitong access rule mula ngayon.