Encaminhar o tráfego de VM na rede host-only por meio de um servidor TUN OpenVPN

Os adaptadores host-only criam uma rede virtual local, e os túneis TUN encaminhados transportam pacotes IP entre endereços. Nenhum dos dois é uma ponte para o outro, por isso uma configuração que funcione deve dizer quem encaminha e a quem pertence a rota de volta. Trocar essas duas atribuições faz o convidado responder ao túnel com uma origem que o cliente do túnel nunca pediu. O desenho abaixo mantém os dois prefixos separados e torna o caminho de volta explícito.

Duas redes, dois prefixos

Dê ao pool do túnel e à rede host-only prefixos diferentes e nunca reutilize um pelo outro. Neste exemplo o pool de VPN é 10.44.0.0/24 e a rede host-only é 192.168.99.0/24, com o host em 192.168.99.1 e um convidado em 192.168.99.20. Atribuir o mesmo prefixo tanto a um dispositivo TUN como ao adaptador host-only não os une. Isso cria duas reivindicações sobre um mesmo intervalo de endereços, e a tabela de rotas passa a responder pela que acabou conservando.

O adaptador host-only existe no host e dentro do convidado, e não tem caminho para fora da máquina por si só. As conexões em ponte e NAT têm exposição diferente, e mudar para o modo ponte não é requisito para alcançar um único serviço do convidado.

O host já detém o caminho

Veja o que existe antes de acrescentar qualquer coisa. O host tem uma interface na rede host-only e uma rota para esse prefixo, ambas criadas quando o adaptador subiu.

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

A terceira linha é o mecanismo que transforma o host em um salto. Sem ela, um pacote que chega do túnel é endereçado a uma rede que o host alcança mas não encaminhará. O encaminhamento é necessário e não suficiente. A política de filtragem ainda decide se um fluxo específico entre a interface do túnel e a interface host-only é permitido, e essa decisão deve estar por escrito, não em uma política padrão que ninguém leu.

Empurre a rota e depois filtre o que ela alcança

O servidor pode fornecer o prefixo host-only aos clientes que aceitam rotas empurradas, que é o mesmo mecanismo usado para qualquer outra sub-rede atrá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

Essas duas regras permitem um serviço em uma direção e as respostas dele. Uma rota que alcança todo o prefixo e um filtro que permite uma só porta formam uma combinação deliberada; uma rota mais uma aceitação incondicional é como um serviço de laboratório se torna um serviço exposto. Uma rota empurrada também não é autorização. O cliente a aceita, o host a encaminha, e o firewall do convidado e o próprio serviço ainda têm voz.

O convidado precisa de um caminho de volta

Um convidado alcançado a partir de 10.44.0.x precisa enviar suas respostas para o endereço host-only do host, ou o host precisa traduzir a origem. Receber um endereço do DHCP do VirtualBox não diz nada sobre nenhuma das duas disposições.

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

Acrescentar essa rota dentro do convidado preserva a origem original, o que mantém significativas a política e os registros por cliente. A tradução de origem limitada no host é a alternativa, e funciona, ao custo de ocultar qual cliente se conectou. A sobreposição é o outro modo de falha. Um cliente remoto cuja LAN doméstica já usa 192.168.99.0/24 lerá a rota empurrada como sua própria rede, e nenhuma mudança no lado do servidor corrige essa ambiguidade. Renumere um lado ou escolha um prefixo que provavelmente não colida.

Um dispositivo TUN transporta pacotes IP, então acrescentar um gateway padrão dentro de um convidado não transforma o túnel em um segmento Ethernet com o adaptador host-only. A ponte TAP é um desenho diferente, com seu próprio suporte a clientes e propriedade de endereços, e misturar as duas descrições leva a configurações que nunca convergem.

Verifique e depois faça com que sobreviva a uma reinicialização

Teste um serviço inofensivo a partir de um cliente remoto comum, confira a rota de volta do convidado e confirme que um serviço que você não permitiu é recusado em vez de ficar lento.

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

Depois reinicie o serviço de VPN e a rede da máquina virtual, e repita as mesmas três verificações. Uma rota acrescentada à mão sobrevive até a próxima reinicialização, e uma configuração que só funciona em sessão quente não é um desenho. Anote os dois prefixos, a política de encaminhamento e a rota do convidado juntos. Quem acrescentar a próxima máquina virtual precisará dos três e, caso contrário, os redescobrirá uma conexão falha após a outra.