J'ai eu exactement le même problème et l'ai résolu jusqu'à la résolution, donc je suis heureux d'expliquer le problème et la solution en détail.
Sans impliquer un VPN
Il est important de comprendre la configuration requise pour répondre à vos besoins sans impliquer de VPN. De plus, ces informations supposent qu'aucun pare-feu logiciel n'interfère, ni sur l'hôte ni sur l'invité.
Sans VPN, cela est normalement résolu en créant deux adaptateurs réseau dans la configuration de la machine virtuelle.
Le premier adaptateur doit être défini sur NATmode, ce qui permet à l'invité d'accéder aux ressources réseau (y compris Internet) via l'interface réseau de l'hôte.
Le deuxième adaptateur doit être défini sur Host-only, ce qui permet une communication bidirectionnelle entre l'hôte et l'invité.
Cet adaptateur est légèrement plus complexe à installer que le premier, car il nécessite de modifier les préférences de mise en réseau globales de VirtualBox afin de configurer l'adaptateur hôte uniquement (remarque: cela nécessite des privilèges d'administrateur).
Dans VirtualBox, accédez à File -> Preferences -> Network. Cliquez sur l' Host-only Networksonglet, puis sur la petite +icône pour ajouter un nouvel adaptateur. Vous serez invité à élever les autorisations de VirtualBox.
Remplir l' Adapteronglet est obligatoire; il devrait ressembler à ceci (ignorer l'adaptateur étiqueté #2; qui est utilisé pour quelque chose sans rapport):
Les valeurs de l' DHCPonglet serveur sont facultatives. Si vous avez l'intention de coder en dur l'adresse IP de cet adaptateur dans la configuration réseau de l'invité, ces valeurs ne sont pas nécessaires. Si, d'autre part, vous avez l'intention d'utiliser DHCP, les valeurs peuvent ressembler à ceci:
La dernière étape en ce qui concerne la configuration de VirtualBox consiste à revenir dans la configuration réseau de la machine virtuelle et à ajouter le deuxième adaptateur, qui fait référence à l'adaptateur hôte uniquement que nous venons de créer:
Maintenant, dans le système d'exploitation invité, le réseau doit être configuré pour utiliser ces deux interfaces réseau.
Sur Debian ou Ubuntu GNU / Linux, la configuration est aussi simple que de modifier /etc/network/interfacespour ressembler à ceci:
# 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
(le puriste peut préférer utiliser le /etc/network/interfaces.drépertoire à la place, mais cela dépasse le cadre de cette explication)
Redémarrez les services réseau de l'invité, ou plus simplement, redémarrez l'intégralité de la machine virtuelle invitée, et tout devrait "simplement fonctionner".
À ce stade, on devrait être en mesure d'envoyer une requête ping à la machine virtuelle invitée 192.168.56.101et de recevoir une réponse (à condition qu'un pare-feu logiciel n'interfère pas).
De même, on devrait être en mesure d'envoyer une requête ping à l'hôte sur 10.0.2.2. Cette adresse IP semble être "codée en dur" dans l'implémentation NAT de VirtualBox, ou du moins spécifiée via une directive de configuration non évidente, et il y a peu d'informations disponibles quant à son origine. Mais, hélas, "ça marche".
Compte tenu de cette configuration, les trois conditions décrites dans votre question sont remplies.
Entrez: le VPN
Mais, voici le hic. L'introduction du VPN provoque un problème d'arrêt (enfin, selon le VPN spécifique et sa configuration).
Les VPN modernes sont capables de fractionner le tunneling , ce qui est requis pour que la configuration de VirtualBox susmentionnée fonctionne selon vos trois exigences. Pour de (bonnes) raisons de sécurité, le tunneling fractionné est souvent désactivé, et c'est précisément le problème dans votre cas (et le mien).
Lorsque vous vous connectez au VPN, le client VPN (Cisco AnyConnect Secure Mobility Client, 3.1.02026, dans mon cas) examine les tables de routage de l'ordinateur hôte, s'en souvient, puis les ouvre avec des valeurs qui proviennent généralement de certains de manière centralisée. emplacement géré (c.-à-d., même avec des privilèges d'administrateur local, il est impossible de remplacer les paramètres).
Vous pouvez examiner les tables de routage par vous-même en ouvrant command.exe(sous Windows):
C:\>route print
Avant de se connecter au VPN, la table de routage contient des entrées cruciales qui permettent à cette configuration VirtualBox de fonctionner correctement. La connexion au VPN entraîne la suppression de ces entrées, ce qui empêche la communication entre l'hôte et l'invité.
(Il existe de nombreuses autres entrées, que j'ai omises ici, car elles ne sont pas pertinentes pour la cause première de ce comportement.)
Avant de vous connecter au 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
Après vous être connecté au 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
Le client VPN supprime les lignes suivantes:
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
Sans ces deux dernières entrées, l'hôte et l'invité ne peuvent pas communiquer, et c'est précisément le comportement souhaité lorsque la tunnellisation fractionnée est désactivée dans la configuration VPN.
Normalement, ces deux commandes restaurent ces routes:
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
Mais le client VPN reste vigilant: il intercepte les tentatives de modification de la table de routage. Mon client semble autoriser la deuxième entrée, mais pas la première. (Et cela peut paver les deux sur une base périodique; je n'ai pas testé pour cela.)
Si votre VPN spécifique et la configuration qui l'accompagne permettent d'activer le tunnelage fractionné, il est généralement activé comme ceci:
Lors de la déconnexion du VPN, les clients VPN qui se comportent correctement restaureront les tables de routage qui étaient en place avant la connexion. Mon client VPN semble le faire de manière fiable, ce qui est bénéfique car cela signifie que la machine virtuelle invitée n'a pas besoin d'être redémarrée lorsque je me connecte ou me déconnecte du VPN. Dans de tels cas, l'adaptateur secondaire de la machine virtuelle est réinitialisé, mais il acquiert de nouveau son adresse IP automatiquement et de manière transparente, rétablissant la communication entre l'hôte et l'invité presque immédiatement. Mieux encore, les montages NFS entre l'hôte et l'invité (j'utilise des montages CIFS) restent connectés entre les opérations de connexion / déconnexion VPN.
Dans le cas peu probable où votre VPN autoriserait le tunneling fractionné, il pourrait être simple de l'activer, auquel cas, j'aimerais avoir de vos nouvelles si "tout fonctionne bien".