Eu tive exatamente o mesmo problema e resolvi o problema, por isso, fico 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 requisitos sem envolver uma VPN. Além disso, essas informações pressupõem que nenhum firewall de software esteja interferindo, nem no host nem no convidado.
Sem uma VPN, isso normalmente é resolvido com a criação de dois adaptadores de rede na configuração da máquina virtual.
O primeiro adaptador deve estar definido no NATmodo, que permita ao convidado acessar recursos de rede (incluindo a Internet) através da interface de rede do host.
O segundo adaptador deve estar 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 Adapterguia é obrigatório; deve ser algo como 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 são desnecessários. Se, por outro lado, você pretende usar o DHCP, os valores podem ser algo assim:
A última etapa em relação à 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 se parecer com isto:
# 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 do convidado, e tudo deve "funcionar".
Nesse ponto, deve-se conseguir efetuar ping na VM convidada 192.168.56.101e receber uma resposta (desde que um firewall de software não esteja interferindo).
Da mesma forma, um deve poder executar ping no host em 10.0.2.2. Esse endereço IP parece estar "codificado" na implementação de NAT do VirtualBox, ou pelo menos especificado por meio de alguma diretiva de configuração não óbvia, e há poucas informações disponíveis sobre sua origem. Mas, infelizmente, "simplesmente funciona".
Dada essa configuração, todas as três condições descritas em sua pergunta são atendidas.
Enter: a VPN
Mas, aqui está o problema. A introdução da VPN causa um problema de parada da exibição (bem, dependendo da VPN específica e de sua configuração).
As VPNs modernas são capazes de dividir o encapsulamento , necessário para a configuração do VirtualBox acima mencionada para funcionar de acordo com seus três requisitos. Por (boas) razões de segurança, o tunelamento dividido geralmente é 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 as distribui com valores que geralmente vêm de local gerenciado (ou seja, mesmo com privilégios de administrador local, é impossível substituir as configurações).
Você pode examinar as tabelas de roteamento por si mesmo abrindo command.exe(no Windows):
C:\>route print
Antes de conectar-se à VPN, a tabela de roteamento contém entradas cruciais que permitem que essa 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.
(Existem muitas outras entradas que omiti aqui, pois são irrelevantes para a causa raiz desse comportamento.)
Antes de conectar-se à 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
Após 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 tunelamento dividido é desativado na configuração da VPN.
Normalmente, esses 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: intercepta tentativas de modificar a tabela de roteamento. Meu cliente parece permitir a segunda entrada, mas não a primeira. (E pode pavimentar os dois periodicamente; não testei isso.)
Se sua VPN específica e sua configuração de atendente permitem que o tunelamento dividido seja ativado, normalmente é ativado assim:
Ao se desconectar da VPN, os clientes VPN bem comportados restaurarão as tabelas de roteamento existentes 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 me desconecto da VPN. Nesses casos, o adaptador secundário da VM é redefinido, mas ele adquire seu endereço IP de forma automática e transparente, restaurando a comunicação entre o host e o convidado quase que 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 gostaria de saber se você "tudo funciona" ou não.