Tuve exactamente el mismo problema y lo resolví, así que estoy feliz de explicar el problema y la solución en detalle.
Sin involucrar una VPN
Es importante comprender la configuración que se requiere para cumplir con sus requisitos sin involucrar una VPN. Además, esta información supone que ningún firewall de software está interfiriendo, ni en el host ni en el invitado.
Sin una VPN, esto normalmente se resuelve creando dos adaptadores de red en la configuración de la máquina virtual.
El primer adaptador debe configurarse en NATmodo, lo que permite al invitado acceder a los recursos de la red (incluido Internet) a través de la interfaz de red del host.
El segundo adaptador debe establecerse en Host-only, lo que permite la comunicación bidireccional entre el host y el invitado.
Este adaptador es un poco más complejo de configurar que el primero, ya que requiere modificar las preferencias de red globales de VirtualBox para configurar el adaptador solo de host (nota: esto requiere privilegios de administrador).
En VirtualBox, ve a File -> Preferences -> Network. Haga clic en la Host-only Networkspestaña y haga clic en el pequeño +icono para agregar un nuevo adaptador. Se le pedirá que eleve los permisos de VirtualBox.
Completar la Adapterpestaña es obligatorio; debería verse así (ignore el adaptador etiquetado #2; se usa para algo no relacionado):
Los valores en la DHCPpestaña del servidor son opcionales. Si tiene la intención de codificar la dirección IP de este adaptador dentro de la configuración de red del invitado, estos valores son innecesarios. Si, por otro lado, tiene la intención de usar DHCP, los valores podrían verse así:
El último paso con respecto a la configuración de VirtualBox es volver a la configuración de red de la VM y agregar el segundo adaptador, que hace referencia al adaptador de solo host que acabamos de crear:
Ahora, en el sistema operativo invitado, la red debe estar configurada para utilizar estas dos interfaces de red.
En Debian o Ubuntu GNU / Linux, la configuración es tan simple como modificar /etc/network/interfacespara que se vea así:
# 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
(el purista puede preferir utilizar el /etc/network/interfaces.ddirectorio en su lugar, pero eso está más allá del alcance de esta explicación)
Reinicie los servicios de red del invitado, o más simplemente, reinicie toda la VM invitada, y todo debería "funcionar".
En este punto, uno debería poder hacer ping a la máquina virtual invitada 192.168.56.101y recibir una respuesta (siempre que un firewall de software no interfiera).
Del mismo modo, uno debería poder hacer ping al host en 10.0.2.2. Esta dirección IP parece estar "codificada" en la implementación NAT de VirtualBox, o al menos especificada a través de alguna directiva de configuración no obvia, y hay poca información disponible sobre su origen. Pero, por desgracia, "simplemente funciona".
Dada esta configuración, se cumplen las tres condiciones descritas en su pregunta.
Ingrese: la VPN
Pero, aquí está el problema. La introducción de la VPN causa un problema que detiene el espectáculo (bueno, dependiendo de la VPN específica y su configuración).
Las VPN modernas son capaces de dividir el túnel , que se requiere para que la configuración de VirtualBox mencionada funcione según sus tres requisitos. Por (buenas) razones de seguridad, el túnel dividido a menudo está deshabilitado, y este es precisamente el problema en su caso (y el mío).
Cuando se conecta a la VPN, el cliente VPN (Cisco AnyConnect Secure Mobility Client, 3.1.02026, en mi caso) examina las tablas de enrutamiento de la computadora host, las recuerda y luego las pavimenta con valores que generalmente provienen de algunos ubicación administrada (es decir, incluso con privilegios de administrador local, es imposible anular la configuración).
Puede examinar las tablas de enrutamiento por sí mismo abriendo command.exe(en Windows):
C:\>route print
Antes de conectarse a la VPN, la tabla de enrutamiento contiene entradas cruciales que permiten que esta configuración de VirtualBox funcione correctamente. La conexión a la VPN hace que estas entradas se eliminen, lo que impide la comunicación entre el host y el invitado.
(Hay muchas otras entradas, que he omitido aquí, ya que son irrelevantes para la causa raíz de este comportamiento).
Antes de conectarse a la 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
Después de conectarse a la 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
El cliente VPN elimina las siguientes líneas:
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
Sin esas dos últimas entradas, el host y el invitado no pueden comunicarse, y este es precisamente el comportamiento previsto cuando el túnel dividido está deshabilitado en la configuración de VPN.
Normalmente, estos dos comandos restaurarían esas rutas:
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
Pero el cliente VPN permanece atento: intercepta los intentos de modificar la tabla de enrutamiento. Mi cliente parece permitir la segunda entrada, pero no la primera. (Y puede pavimentar ambos de forma periódica; no lo probé).
Si su VPN específica y su configuración de asistente permiten que se habilite el túnel dividido, generalmente se activa de la siguiente manera:
Al desconectarse de la VPN, los clientes VPN que se comporten bien restaurarán las tablas de enrutamiento que estaban en su lugar antes de conectarse. Mi cliente VPN parece hacer esto de manera confiable, lo cual es beneficioso porque significa que la VM invitada no necesita reiniciarse cuando me conecto o me desconecto de la VPN. En tales casos, el adaptador secundario de la VM se restablece, pero vuelve a adquirir su dirección IP de forma automática y transparente, restaurando la comunicación entre el host y el invitado casi de inmediato. Mejor aún, los montajes NFS entre el host y el invitado (estoy usando montajes CIFS) permanecen conectados a través de las operaciones de conexión / desconexión de VPN.
En el improbable caso de que su VPN permita el túnel dividido, puede ser una simple cuestión habilitarlo, en cuyo caso, me encantaría saber de usted si "todo simplemente funciona".