Rutahan ang trapiko ng VM sa host-only network sa pamamagitan ng TUN OpenVPN server

Ang mga host-only adapter ay gumagawa ng lokal na virtual network, at ang mga rutadong TUN tunnel ay nagdadala ng IP packet sa pagitan ng mga address. Wala sa kanila ang tulay patungo sa isa, kaya ang gumaganang configuration ay dapat magsabi kung sino ang nagpapasa at kanino ang return route. Kung mababaligtad ang dalawang takdang ito, sasagot ang guest sa tunnel gamit ang source na hindi kailanman hiniling ng tunnel client. Pinapanatili ng disenyo sa ibaba na hiwalay ang dalawang prefix at ginagawang malinaw ang daan pabalik.

Dalawang network, dalawang prefix

Bigyan ng magkaibang prefix ang tunnel pool at ang host-only network at huwag kailanman gamitin ang isa para sa isa. Sa halimbawang ito ang VPN pool ay 10.44.0.0/24 at ang host-only network ay 192.168.99.0/24, ang host ay nasa 192.168.99.1 at isang guest sa 192.168.99.20. Ang pagbibigay ng parehong prefix sa TUN device at sa host-only adapter ay hindi nag-uugnay sa kanila. Gumagawa ito ng dalawang pag-angkin sa isang hanay ng address, at ang routing table ay sasagot para sa pag-angkin na nagkataong natira.

Umiiral ang host-only adapter sa host at sa loob ng guest, at wala itong sariling daan palabas ng makina. Iba ang pagkakalantad ng bridged at NAT na koneksyon, at ang paglipat sa bridged mode ay hindi kailangan upang maabot ang isang serbisyo ng guest.

Nasa host na ang daan

Tingnan kung ano ang umiiral bago magdagdag ng anuman. May interface ang host sa host-only network at may ruta para sa prefix na iyon, parehong nilikha nang bumangon ang adapter.

ip -br addr show
ip route show 192.168.99.0/24
sysctl net.ipv4.ip_forward

Ang ikatlong linya ang mekanismong gumagawa sa host na hop. Kung wala ito, ang packet na dumarating mula sa tunnel ay nakapunta sa network na naaabot ng host ngunit hindi nito ipapasa. Kailangan ang pagpapasa at hindi sapat. Ang patakaran ng filter ang nagpapasya pa rin kung pinapayagan ang isang partikular na daloy sa pagitan ng tunnel interface at host-only interface, at ang desisyong iyon ay dapat nakasulat, hindi sa default na patakaran na walang nakabasa.

Itulak ang ruta, pagkatapos i-filter ang naaabot nito

Maaaring ibigay ng server ang host-only prefix sa mga client na tumatanggap ng itinulak na ruta, na siya ring mekanismong ginagamit para sa anumang iba pang subnet sa likod ng tunnel.

push "route 192.168.99.0 255.255.255.0"
iptables -A FORWARD -i tun0 -o vboxnet0 -d 192.168.99.20 -p tcp --dport 5432 -j ACCEPT
iptables -A FORWARD -i vboxnet0 -o tun0 -s 192.168.99.20 -p tcp --sport 5432 -m conntrack --ctstate ESTABLISHED -j ACCEPT

Pinapayagan ng dalawang patakarang ito ang isang serbisyo sa isang direksyon at ang mga sagot nito. Ang rutang umaabot sa buong prefix at filter na pumapayag sa isang port ay sadyang kombinasyon; ruta at walang kundisyong pagtanggap ang paraan para maging bukas na serbisyo ang isang serbisyo sa laboratoryo. Ang itinulak na ruta ay hindi rin pahintulot. Tinatanggap ito ng client, ipinapasa ito ng host, at may boses pa rin ang firewall ng guest at ang serbisyo mismo.

Kailangan ng guest ng daan pabalik

Ang guest na naaabot mula sa 10.44.0.x ay dapat magpadala ng mga sagot nito sa host-only address ng host, o kailangang isalin ng host ang source. Ang pagtanggap ng address mula sa DHCP ng VirtualBox ay walang sinasabi tungkol sa alinman sa dalawang kaayusan.

ip route add 10.44.0.0/24 via 192.168.99.1 dev enp0s8
ip route get 10.44.0.15

Ang pagdaragdag ng rutang iyon sa loob ng guest ay nagpapanatili ng orihinal na source, na nagpapanatiling makabuluhan ang patakaran at mga log bawat client. Ang limitadong pagsasalin ng source sa host ang alternatibo, at gumagana ito, kapalit ng pagtatago kung aling client ang kumonekta. Ang pag-overlap ang isa pang paraan ng pagpalya. Ang malayong client na ang LAN sa bahay ay gumagamit na ng 192.168.99.0/24 ay babasahin ang itinulak na ruta bilang sariling network, at walang pagbabago sa panig ng server ang makapag-aayos ng kalabuang iyon. Muling bilangin ang isang panig o pumili ng prefix na malamang hindi magbanggaan.

Nagdadala ng IP packet ang TUN device, kaya ang pagdaragdag ng default gateway sa loob ng guest ay hindi ginagawang Ethernet segment ang tunnel kasama ng host-only adapter. Ang TAP bridging ay ibang disenyo na may sariling suporta sa client at pagmamay-ari ng address, at ang paghahalo ng dalawang paglalarawan ay humahantong sa mga configuration na hindi nagtatagpo.

I-verify, pagkatapos gawing matibay laban sa restart

Subukan ang isang hindi mapaminsalang serbisyo mula sa ordinaryong malayong client, tingnan ang daan pabalik ng guest, at tiyakin na ang serbisyong hindi mo pinayagan ay tinatanggihan sa halip na mabagal.

ss -lntp '( sport = :5432 )'
conntrack -L | grep 192.168.99.20

Pagkatapos i-restart ang VPN service at ang networking ng virtual machine, at ulitin ang parehong tatlong pagsusuri. Ang rutang idinagdag sa kamay ay tatagal hanggang sa susunod na reboot, at ang configuration na gumagana lamang sa mainit na session ay hindi disenyo. Isulat nang magkasama ang dalawang prefix, ang patakaran sa pagpapasa at ang ruta ng guest. Ang sinumang magdagdag ng susunod na virtual machine ay kakailanganin ang lahat ng tatlo at kung hindi ay muli niyang matutuklasan ang mga iyon sa bawat bigong koneksyon.