Como conectar-se a um sistema operacional convidado do VirtualBox por meio de uma VPN?

Question 1

Eu tinha oexatomesmo problema e consegui resolvê-lo, então ficarei feliz em explicar o problema e a solução em detalhes.

Sem envolver uma VPN

É importante entender a configuração necessária para atender aos seus requisitossemenvolvendo uma VPN. Além disso, essas informações pressupõem que nenhum firewall de software está interferindo, nem no host nem no convidado.

Sem VPN, isso normalmente é resolvido com a criação de dois adaptadores de rede na configuração da máquina virtual.

O primeiro adaptador deve ser definido no NATmodo que permite ao convidado acessar recursos de rede (incluindo a Internet) por meio da interface de rede do host.

O segundo adaptador deve ser definido como Host-only, o que permite a comunicação bidirecional entre o host e o convidado.

Este adaptador é um pouco mais complexo de configurar do que o primeiro, porque requer a modificação das preferências de rede global do VirtualBox para configurar o adaptador somente host (nota: isso requer privilégios de administrador).

No VirtualBox, vá para File -> Preferences -> Network. Clique na Host-only Networksguia e clique no pequeno +ícone para adicionar um novo adaptador. Você será solicitado a elevar as permissões do VirtualBox.

O preenchimento da Adapteraba é obrigatório; deve ser parecido com isto (ignore o adaptador rotulado #2; que é usado para algo não relacionado):

Os valores na DHCPguia do servidor são opcionais. Se você pretende codificar o endereço IP desse adaptador na configuração de rede do convidado, esses valores serão desnecessários. Se, por outro lado, você pretende usar DHCP, os valores podem ser mais ou menos assim:

A última etapa da configuração do VirtualBox é voltar à configuração de rede da VM e adicionar o segundo adaptador, que faz referência ao adaptador somente host que acabamos de criar:

Agora, no sistema operacional convidado, a rede deve ser configurada para utilizar essas duas interfaces de rede.

No Debian ou Ubuntu GNU/Linux, a configuração é tão simples quanto modificar /etc/network/interfacespara ficar assim:

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet dhcp

# The secondary network interface
auto eth1
iface eth1 inet static
     address 192.168.56.101
     netmask 255.255.255.0

(o purista pode preferir utilizar o /etc/network/interfaces.ddiretório, mas isso está além do escopo desta explicação)

Reinicie os serviços de rede do convidado ou, mais simplesmente, reinicie toda a VM convidada e tudo deverá "simplesmente funcionar".

Neste ponto, deve-se ser capaz de executar ping na VM convidada 192.168.56.101e receber uma resposta (desde que um firewall de software não esteja interferindo).

Da mesma forma, deve-se ser capaz de executar ping no host em 10.0.2.2. Este endereço IP parece estar "codificado" na implementação NAT do VirtualBox, ou pelo menos especificado através de alguma diretiva de configuração não óbvia, e há pouca informação disponível sobre sua origem. Mas, infelizmente, “simplesmente funciona”.

Dada esta configuração, todas as três condições descritas na sua pergunta foram atendidas.

Digite: a VPN

Mas aqui está o problema. A introdução da VPN causa um problema terrível (bem, dependendo da VPN específica e de sua configuração).

VPNs modernas são capazes deTunelamento dividido, que é necessário para que a configuração do VirtualBox acima mencionada funcione de acordo com seus três requisitos. Por (boas) razões de segurança, o tunelamento dividido é frequentemente desativado, e esse é precisamente o problema no seu caso (e no meu).

Quando você se conecta à VPN, o cliente VPN (Cisco AnyConnect Secure Mobility Client, 3.1.02026, no meu caso) examina as tabelas de roteamento do computador host, lembra-se delas e, em seguida, as pavimenta com valores que normalmente vêm de algum ponto central. local gerenciado (ou seja, mesmo com privilégios de administrador local, é impossível substituir as configurações).

Você pode examinar as tabelas de roteamento abrindo command.exe(no Windows):

C:\>route print

Antes de conectar-se à VPN, a tabela de roteamento contém entradas cruciais que permitem que esta configuração do VirtualBox funcione corretamente. A conexão à VPN faz com que essas entradas sejam removidas, o que impede a comunicação entre o host e o convidado.

(Há muitas outras entradas, que omiti aqui, pois são irrelevantes para a causa raiz desse comportamento.)

Antes de se conectar à VPN:

     192.168.56.0    255.255.255.0         On-link      192.168.56.1    266
     192.168.56.1  255.255.255.255         On-link      192.168.56.1    266
   192.168.56.255  255.255.255.255         On-link      192.168.56.1    266
        224.0.0.0        240.0.0.0         On-link      192.168.56.1    266
  255.255.255.255  255.255.255.255         On-link      192.168.56.1    266

Depois de conectar-se à VPN:

     192.168.56.1  255.255.255.255         On-link      192.168.56.1    266
        224.0.0.0        240.0.0.0         On-link      192.168.56.1    266
  255.255.255.255  255.255.255.255         On-link      192.168.56.1    266

O cliente VPN remove as seguintes linhas:

     192.168.56.0    255.255.255.0         On-link      192.168.56.1    266
   192.168.56.255  255.255.255.255         On-link      192.168.56.1    266

Sem essas duas últimas entradas, o host e o convidado não podem se comunicar, e esse é precisamente o comportamento pretendido quando o túnel dividido está desabilitado na configuração da VPN.

Normalmente, estes dois comandos restaurariam essas rotas:

C:\>route ADD 192.168.56.0 MASK 255.255.255.0 192.168.56.1 METRIC 266
C:\>route ADD 192.168.56.255 MASK 255.255.255.255 192.168.56.1 METRIC 266

Mas o cliente VPN permanece vigilante: ele intercepta tentativas de modificar a tabela de roteamento. Meu cliente parece permitir a segunda entrada, mas não a primeira. (E pode pavimentar ambos periodicamente; não testei isso.)

Sesua VPN específica e sua configuração de atendimento permitem que o tunelamento dividido seja habilitado, normalmente é ativado assim:

Ao se desconectar da VPN, os clientes VPN bem comportados restaurarão as tabelas de roteamento que estavam em vigor antes da conexão. Meu cliente VPN parece fazer isso de maneira confiável, o que é benéfico porque significa que a VM convidada não precisa ser reiniciada quando eu me conecto ou desconecto da VPN. Nesses casos, o adaptador secundário da VM é redefinido, mas readquire seu endereço IP de forma automática e transparente, restaurando a comunicação entre o host e o convidado quase imediatamente. Melhor ainda, as montagens NFS entre o host e o convidado (estou usando montagens CIFS) permanecem conectadas nas operações de conexão/desconexão da VPN.

No caso improvável de sua VPN permitir o tunelamento dividido, pode ser uma simples questão de habilitá-lo; nesse caso, eu adoraria ouvir de você se "tudo funciona" ou não.

Answer