Trapik ng Docker at VM sa likod ng OpenVPN: ruta o muling pagbilang?

Nagba-browse ang host sa tunnel at ang container sa tabi nito ay walang naaabot. Mas masama ang pag-publish ng port mula sa container na nagpapatakbo ng sariling VPN client: dumarating ang kahilingan at hindi kailanman lumalabas ang sagot. Pareho silang desisyon sa ruta sa host, at si Docker ay sugo lamang.

Tatlong tanong ang nagtatakda kung alin sa dalawa ang nakikita mo, at tumatagal ito ng mga isang minuto.

Dalawang kabiguan na magkapareho ang ayos

Ang una ay problema sa rutang pabalik. Ang na-publish na port ay isinasalin papasok sa container, dumarating ang kahilingan, at ang sagot ay iruruta sa default na ruta ng host, na itinuro ng OpenVPN client sa tun0. Lumabas ang sagot mula sa address na hindi inaasahan ng malayong kapareha, at ito ay itinatapon. Ang pangalawa ay banggaan ng prefix: ang default na tulay ng Docker ay may 172.17.0.0/16 at ang corporate tunnel ay nagtutulak ng parehong saklaw.

Ang isa ay inaayos sa talahanayan ng ruta, ang isa pa sa muling pagbilang ng tulay. Ang pag-edit bago malaman kung alin ang alin ay siyang paraan ng pagsira sa gumaganang container.

Magpasya gamit ang tatlong tanong

Tanong isa: nawawala ba ang kabiguan kapag hininto mo ang VPN? Kung gumagana ang lahat habang patay ang tunnel, hinala ang rutang pabalik. Tanong dalawa: ip route show table all ba ay naglilista ng parehong prefix nang dalawang beses, isa sa tulay at isa sa tun0? Iyon ang banggaan. Tanong tatlo: ang apektadong address ba ay container, NAT guest o naka-bridge na guest?

Mahalaga ang ikatlong tanong dahil bawat isa ay may ibang tamang lunas, at ang paglapat ng lunas ng container sa libvirt guest ay nagsasayang ng isang gabi.

ip route
ip route show table all | grep -E '172\.1[7-9]|10\.8'
docker network inspect bridge --format '{{.IPAM.Config}}'

Rutang pabalik: isang talahanayan para sa isang source address

Kapag ang trapik ng container ay dapat lumabas sa pisikal na interface habang ang host mismo ay gumagamit ng tunnel, ang routing na nakabatay sa source ang pinakamaliit na pagbabago. Magdagdag ng tuntuning tumutugma sa address ng container at ipadala ito sa isang nakalaang talahanayan. Wala nang iba pang gumagalaw sa host.

ip rule add from 172.22.0.3 lookup 10
ip route add default via 172.22.0.1 table 10

Bawat packet na ang source ay ang address na iyon ay tumitingin muna sa talahanayan 10, at ipinapadala ito ng talahanayan 10 sa gateway ng tulay sa halip na sa tunnel.

Kumpirmahin gamit ang ip route get 1.1.1.1 from 172.22.0.3. Dapat banggitin ng sagot ang interface ng tulay, hindi tun0. Ang mga tuntuning idinagdag nang ganito ay nawawala sa reboot, kaya ilagay ang mga ito sa unit o network hook na may-ari ng container.

Gumagana rin ang parehong pattern sa container na WireGuard, kung saan kailangan din ng rutang pabalik ng tahasang tuntunin.

Banggaan ng prefix: muling bilangin ang tulay

Ang talahanayan ng ruta ay nagpapadala ng isang prefix sa isang lugar. Kung itinutulak ng VPN ang 172.17.0.0/16 habang naroon na ang tulay ng Docker, mananalo ang mas mababang metric: inilalagay ng Docker ang konektadong ruta nito sa metric 0, at dumarating ang itinulak na ruta sa 50. Tila sira ang tunnel habang patuloy na gumagana ang Docker, o kabaligtaran, ayon sa pagkakasunod-sunod ng pag-install. Muling bilangin ang tulay sa halip na makipag-away sa metric.

{
  "bip": "10.200.0.1/24",
  "default-address-pools": [{"base": "10.201.0.0/16", "size": 24}]
}

I-restart ang Docker pagkatapos ng pagbabago at muling gawin ang mga network na ginawa sa lumang pool. Ang pagpapalit ng metric ay naglilipat lang ng hidwaan sa susunod na boot.

Kailangan na naman ng ibang sagot ng mga VM

Ang libvirt guest sa default na NAT network ay nagmamana ng routing ng host at tumitigil sa pag-abot sa labas kapag ang tunnel ng host ay may default na ruta. Ang paglipat ng guest sa bridge o macvtap device ay nagbibigay sa kanya ng sariling landas sa pisikal na network. Sa virt-manager, magdagdag ng hardware, piliin ang Network, itakda ang source sa macvtap host device, panatilihin ang virtio bilang modelo, pagkatapos ay i-deactivate ang lumang NAT interface.

Ang macvtap guest ay karaniwang hindi naaabot ang sariling host. Inaasahang pag-uugali iyon at hindi kabiguan, at kasama ito sa tala na iniiwan mo.

Para sa guest na kailangan lang ng LAN ng host, maaaring may nawawalang switch ang client ng vendor: sa Mullvad, mullvad lan set allow ibinabalik ang lokal na maabot nang hindi hinahawakan ang libvirt. At kapag kailangang maabot ang container sa tunnel lamang, itali ang na-publish na port sa address ng tunnel, -p 10.8.0.5:8080:8080, sa halip na i-publish ito sa lahat ng address.