VPN ligada, VM inacessível? A rota provavelmente nunca foi o problema

Conecte a VPN e a VM de desenvolvimento que respondia há um minuto fica muda. A história óbvia escreve-se sozinha: o túnel assumiu a rota, o host agora envia o tráfego do convidado para a rede corporativa, e a correção é adicionar uma rota estática ou mudar o adaptador para modo ponte. Essa história às vezes é verdadeira. Mas não é a causa habitual, e agir com base nela primeiro costuma quebrar outra coisa.

A rede host-only é uma rede de software pertencente ao host e compartilhada com os seus convidados, separada de qualquer ligação física. Nada na própria interface do cliente VPN altera essa rede, portanto antes de a tocar, descubra qual das quatro camadas falhou realmente.

A rota normalmente continua local

Pergunte ao kernel em vez de à primeira página da tabela de rotas. No Linux, ip route get 192.168.56.10 informa a rota, a interface e o endereço de origem exatos que seriam usados, o que é uma resposta diferente de ler uma rota padrão e adivinhar. Se a saída nomear a interface host-only, o túnel não participa de forma alguma nesse caminho.

Duas coisas podem realmente quebrá-lo, e ambas são problemas de endereços e não de VPN. Uma sub-rede remota que se sobreponha ao prefixo host-only faz ganhar a rota mais específica, e um cliente VPN que instale uma rota ampla com métrica mais baixa pode puxar o prefixo. Ambos são visíveis no mesmo comando: a interface nomeada na saída será o túnel, e a correção pertence a quem possui esse plano de endereçamento.

Seleção de rota e admissão de pacotes são decisões diferentes

Esta é a parte que o modelo mental costuma omitir. Mesmo com uma rota local perfeita, um cliente VPN pode rejeitar o pacote. Muitos clientes aplicam uma política de acesso local à rede que decide que destinos são permitidos fora do túnel, e uma sub-rede conectada não atualiza essa lista automaticamente.

Assim, a falha parece idêntica a um problema de encaminhamento do lado da aplicação, e completamente diferente do lado do cliente. Se ip route get nomear a interface correta e a ligação continuar a expirar, pare de editar rotas e leia, em vez disso, o comportamento documentado de acesso local do cliente. Alguns clientes expõem uma lista de permitidos para sub-redes locais, outros bloqueiam tudo o que não seja o túnel, e outros só bloqueiam quando há um kill switch ativo.

Essa distinção importa porque as correções não são intercambiáveis. Adicionar uma rota não satisfaz um filtro, e desativar um filtro para chegar a um único convidado é uma decisão muito maior do que o sintoma sugere.

O convidado tem três formas de dizer não

Um convidado que consegue navegar na internet não provou nada sobre o serviço que você quer. O serviço de escuta pode estar ligado a 127.0.0.1 dentro do convidado, e nesse caso nenhum pedido do host pode chegar, por melhor que seja o caminho. Verifique com ss -ltn dentro do convidado e olhe para a coluna do endereço local, não apenas para a porta.

Depois vem a firewall do próprio convidado. Uma imagem de desenvolvimento com um padrão restritivo pode aceitar os pacotes do host e descartá-los na fronteira do serviço, o que produz um tempo esgotado que parece exatamente um buraco negro de encaminhamento. Por fim, há a configuração do próprio serviço: uma aplicação web ligada a um nome de host específico, ou uma lista de endereços de cliente permitidos, recusará um pedido da sub-rede host-only mesmo quando todos os pacotes chegam.

Percorra esses três pontos antes de considerar mudar o modo de rede da VM. Cada um é uma mudança menor do que redesenhar a ligação do convidado, e cada um tem um teste claro.

O que é realmente uma ponte, e quanto custa

Mudar o adaptador para modo ponte não é uma reparação do caminho host-only. É a decisão de colocar o convidado noutra rede, normalmente a LAN física, onde ele se torna visível para tudo o resto que vive ali. Pode ser exatamente o que você quer. Mas não é o que a configuração original fazia.

Use-a quando o convidado realmente precisar de ser um par naquela LAN e a exposição estiver aprovada. Não a use porque um único serviço deixou de responder, já que a mudança pode retirar o convidado do isolamento que tornava seguro desenvolver contra ele.

Depois de qualquer correção aprovada, teste numa ordem fixa: um novo pedido do host para o convidado, um recurso corporativo necessário através do túnel, e o comportamento de recusa pretendido com o túnel desligado. Se o último já não se verificar, a correção foi além do problema.

A secção do VirtualBox sobre redes host-only descreve a interface de software do lado do host e em que difere de uma ligação em ponte, que é a referência que vale a pena ler antes de assumir que os dois modos são intercambiáveis.