Laboratório VPN com VirtualBox: VM de gateway ou rede só de host

Você precisa decidir quanta maquinaria seu laboratório VPN merece. Uma VM de gateway roteada entre dois segmentos do VirtualBox reproduz a tradução de endereços, o caminho de volta e a posição do firewall atrás do qual um cliente real se senta. Um único segmento só de host lhe dá uma porta controlada e nada mais. A versão com gateway custa três convidados e uma tabela de roteamento que você mantém; a versão só de host custa um convidado e uma política. Três perguntas as separam, e a terceira decide se seu teste pode passar.

Responda a três perguntas antes de clonar qualquer coisa

Comece pelo que o servidor VPN precisa observar. Se o servidor precisa ver um endereço de origem que não é o do convidado de teste, algo precisa traduzir entre eles, e esse algo precisa ser um roteador que você controla. A rede só de host dá ao host um adaptador no segmento do convidado, não um tradutor. Quando o convidado precisa alcançar algo externo, você conecta um adaptador NAT, e o próprio motor NAT do VirtualBox reescreve a origem sem perguntar.

Em seguida, pergunte se o convidado pode alcançar qualquer coisa além do túnel. Essa resposta escolhe interno ou só de host, e é a pergunta que a maioria das descrições de laboratório pula. Por fim, pergunte o que deve acontecer quando o túnel cai, porque isso decide política e não topologia, e um laboratório que só prova o caminho feliz não testou quase nada.

Conecte os três papéis com redes internas

Use três convidados e dois segmentos nomeados, com o gateway como a única máquina que tem adaptador nos dois:

VBoxManage modifyvm lab-client --nic1 intnet --intnet1 WAN
VBoxManage modifyvm lab-server --nic1 intnet --intnet1 LAN
VBoxManage modifyvm lab-gw --nic1 intnet --intnet1 WAN --nic2 intnet --intnet2 LAN

Não há uma etapa de criação separada para uma rede interna. A string em --intnet1 é o segmento: duas máquinas o compartilham só se o nome coincidir exatamente, e nada no host está conectado a ele. Essa última propriedade é o motivo pelo qual o laboratório se repete limpo, já que as rotas do host, seu próprio cliente VPN e seu firewall não podem alcançar os convidados por acidente. Um segmento interno também não tem servidor DHCP a menos que você adicione um, então endereços estáticos são o caminho mais curto.

Dê ao cliente apenas seu endereço WAN, com um gateway padrão apontando para o endereço WAN do gateway. O servidor recebe um endereço LAN e usa o endereço LAN do gateway como seu gateway padrão. Um convidado que mantém dois endereços em um segmento, ou tem uma rota perdida para o outro segmento, tem um caminho ao redor do roteador, e os testes abaixo vão mentir para você.

Mantenho um arquivo de texto ao lado dos nomes das VM com os quatro endereços e os dois nomes de segmento, e colo em cada shell. Semanas depois, quando uma mudança de perfil quebra algo, esse arquivo é a diferença entre depurar o perfil e depurar minha própria memória.

Escolha interno ou só de host para o segmento que não deve vazar

O modo só de host cria um adaptador virtual no próprio host, geralmente vboxnet0, e dá ao host um endereço no segmento do convidado. Isso é conveniente para administração e fatal para um teste de isolamento, porque o host agora pode alcançar o convidado diretamente e cada serviço do lado do host vira um caminho possível. O modo interno não tem adaptador de host nenhum. Os dois modos se confundem facilmente no painel de configurações de rede, então verifique a diferença documentada em vez do rótulo (veja a página detalhes de rede do VirtualBox).

Para um convidado que precisa usar o túnel, o interno é o padrão mais seguro, com o gateway como única saída. Se mantiver só de host, trate o adaptador do host como caminho de gestão e diga isso em voz alta: o host pode alcançar o convidado, e o convidado não deve poder usar o host como saída.

VBoxManage modifyvm lab-client --nic1 hostonly --hostonlyadapter1 vboxnet0

O isolamento que você pode provar é o isolamento que você configurou. Um convidado com um adaptador interno, rota padrão no gateway e nenhum adaptador NAT não tem caminho que contorne o gateway. Um convidado com adaptador só de host e adaptador NAT tem dois caminhos, e só um deles é o que você queria testar.

Roteie e traduza no gateway, e então faça-o falhar fechado

O VirtualBox não encaminha entre segmentos; o convidado faz isso. Com a VM do servidor VPN atrás do gateway, ative o encaminhamento e traduza o tráfego do cliente quando ele sai em direção ao servidor:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE

Com essa regra o servidor vê o endereço LAN do gateway em vez do endereço do cliente, e é assim que um cliente real atrás de um NAT de operadora aparece para uma cabeceira de rede. Salve o valor de sysctl em /etc/sysctl.d/ e a regra no serviço de firewall que a distribuição usa, ou uma reinicialização devolve o laboratório silenciosamente a um estado roteado mas não traduzido.

Encaminhar não é autorização. Sob a política FORWARD padrão de ACCEPT, um convidado cuja rota padrão aponta para o gateway sai pela interface que a tabela de roteamento escolher, com ou sem túnel. Se o gateway também tem um adaptador NAT para instalar pacotes, esse adaptador é uma saída não cifrada funcionando no momento em que o túnel cai, e seu teste só-VPN nunca foi um teste só-VPN.

Quando o servidor é remoto e é o gateway que termina o túnel, a mesma decisão aponta para a interface do túnel, não para a NIC que chega à internet:

iptables -P FORWARD DROP
iptables -A FORWARD -i eth0 -o tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -o eth0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Mantenha o transporte externo próprio do túnel e uma rota de gestão fora de banda separados do tráfego encaminhado. Se o único jeito de consertar o gateway é através do túnel que você está depurando, o laboratório vira um exercício de bloqueio. Um console serial, um adaptador de gestão só de host ou um instantâneo de um estado bom conhecido custam menos que recuperar à mão um roteador quebrado.

Verifique o caminho a partir do convidado, não do host

Trabalhe para fora. Confirme que o cliente alcança o endereço WAN do gateway, depois o servidor através do gateway, depois que uma conexão à porta VPN sai e volta. Uma captura nas duas interfaces do gateway mostra se a resposta chega e é descartada no caminho de volta, o que uma captura só no cliente não consegue distinguir:

tcpdump -ni eth0 udp port 1194
tcpdump -ni tun0 udp port 1194

Depois prove a saída. Pergunte do convidado a um serviço de reflexão de endereços qual origem ele vê e compare com o endereço de saída do próprio gateway; se a resposta coincidir com o endereço do host, existe um caminho ao redor do túnel. Verifique qual resolvedor o convidado realmente usa, e verifique IPv6 separadamente, porque um segmento em que IPv6 está ativado enquanto o túnel carrega só IPv4 vaza por projeto e não por acidente.

Por fim, quebre-o de propósito. Pare o túnel, ou bloqueie sua porta externa, e abra uma nova conexão a partir do convidado. Ela deve falhar, e o motivo deve ser um que você consiga nomear: nenhuma rota, uma regra de rejeição ou um resolvedor morto. Reinicie o túnel e confirme que o convidado se recupera sem reconstruir a rede. Se uma VPN em malha como Hamachi ou ZeroTier compartilha o laboratório, lembre que um adaptador em ponte segue o nome do adaptador, não a malha, então a ponte precisa ser reapontada depois que o cliente instalar seu próprio adaptador virtual.

VBoxManage list bridgedifs
VBoxManage modifyvm lab-client --bridgeadapter1 <mesh-adapter-name>

Compartilhar o túnel de um convidado com o host reflete o problema. Apontar a rota padrão do host para o convidado funciona, e um proxy dentro do convidado também; NAT através do host não carrega o túnel do convidado para tráfego que o host originou. Salve os nomes dos segmentos e as regras de firewall em um só lugar, tire um instantâneo do estado que funciona e registre o endereço de origem que o servidor observou. A próxima mudança de perfil então custa uma execução de script em vez de um laboratório reconstruído.