Encamiñar o tráfico de VM na rede host-only a través dun servidor TUN OpenVPN

Os adaptadores host-only crean unha rede virtual local, e os túneles TUN encamiñados transportan paquetes IP entre enderezos. Ningún dos dous é unha ponte cara ao outro, por iso unha configuración que funcione debe dicir quen reenvía e a quen pertence a ruta de volta. Se confundes estas dúas asignacións, o convidado responde ao túnel cunha orixe que o cliente do túnel nunca pediu. O deseño de abaixo mantén ambos prefixos separados e fai explícito o camiño de volta.

Dúas redes, dous prefixos

Dea ao pool do túnel e á rede host-only prefixos distintos e nunca reutilice un polo outro. Neste exemplo o pool de VPN é 10.44.0.0/24 e a rede host-only é 192.168.99.0/24, co anfitrión en 192.168.99.1 e un convidado en 192.168.99.20. Asignar o mesmo prefixo tanto a un dispositivo TUN como ao adaptador host-only non os une. Crea dúas reclamacións sobre un mesmo rango de enderezos, e a táboa de encamiñamento responde pola que resultou conservar.

O adaptador host-only existe no anfitrión e dentro do convidado, e non ten camiño fóra da máquina por si mesmo. As conexións en ponte e NAT teñen distinta exposición, e pasar a modo ponte non é un requisito para chegar a un só servizo do convidado.

O anfitrión xa ten o camiño

Mire o que existe antes de engadir nada. O anfitrión ten unha interface na rede host-only e unha ruta para ese prefixo, ambas creadas cando o adaptador subiu.

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

A terceira liña é o mecanismo que converte o anfitrión nun salto. Sen ela, un paquete que chega do túnel vai dirixido a unha rede que o anfitrión pode acadar pero non reenviará. O reenvío é necesario e non suficiente. A política de filtrado segue decidindo se se permite un fluxo concreto entre a interface do túnel e a interface host-only, e esa decisión debe estar por escrito en lugar de nunha política por defecto que ninguén leu.

Empurre a ruta e despois filtre o que acada

O servidor pode entregar o prefixo host-only aos clientes que aceptan rutas empurradas, que é o mesmo mecanismo que se usa para calquera outra subrede detrás do túnel.

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

Eses dous regras permiten un servizo nunha dirección e as súas respostas. Unha ruta que acada todo o prefixo e un filtro que permite un só porto son unha combinación deliberada; unha ruta máis unha aceptación incondicional é como un servizo de laboratorio se converte nun servizo exposto. Unha ruta empurrada tampouco é unha autorización. O cliente acéptaa, o anfitrión reenvíaa, e o devasa do convidado e o propio servizo aínda teñen voto.

O convidado necesita un camiño de volta

Un convidado ao que se chega desde 10.44.0.x ten que enviar as súas respostas ao enderezo host-only do anfitrión, ou o anfitrión ten que traducir a orixe. Recibir un enderezo do DHCP de VirtualBox non di nada sobre ningunha das dúas disposicións.

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

Engadir esa ruta dentro do convidado conserva a orixe orixinal, o que mantén significativas a política e os rexistros por cliente. A tradución de orixe limitada no anfitrión é a alternativa, e funciona, a costa de ocultar que cliente se conectou. O solapamento é o outro modo de fallo. Un cliente remoto cuxa LAN doméstica xa usa 192.168.99.0/24 lerá a ruta empurrada como a súa propia rede, e ningún cambio no lado do servidor arranxa esa ambigüidade. Renumere un lado ou escolla un prefixo que probablemente non colida.

Un dispositivo TUN transporta paquetes IP, así que engadir unha porta de enlace por defecto dentro dun convidado non converte o túnel nun segmento Ethernet co adaptador host-only. A ponte TAP é un deseño distinto co seu propio soporte de clientes e propiedade de enderezos, e mesturar as dúas descricións leva a configuracións que nunca converxen.

Verifique e despois faga que sobreviva a un reinicio

Probe un servizo inofensivo desde un cliente remoto común, comprobe a ruta de volta do convidado e confirme que un servizo que non permitiu se rexeita en lugar de ser lento.

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

Despois reinicie o servizo de VPN e a rede da máquina virtual, e repita as mesmas tres comprobacións. Unha ruta engadida a man sobrevive ata o seguinte reinicio, e unha configuración que só funciona nunha sesión quente non é un deseño. Anote os dous prefixos, a política de reenvío e a ruta do convidado xuntos. Quen engada a seguinte máquina virtual necesitará as tres cousas e, se non, redescubriráas unha conexión fallida tras outra.