J'avais le exact J'ai rencontré le même problème et je l'ai résolu. Je suis donc heureux d'expliquer le problème et la solution en détail.
Sans passer par un VPN
Il est important de comprendre la configuration requise pour répondre à vos besoins. sans impliquant un VPN. En outre, ces informations supposent qu'aucun pare-feu logiciel n'interfère, ni sur l'hôte ni sur l'invité.
Sans VPN, ce problème est normalement résolu en créant deux adaptateurs réseau dans la configuration de la machine virtuelle.
Le premier adaptateur doit être réglé sur NAT qui permet à l'invité d'accéder aux ressources du réseau (y compris l'Internet) via l'interface réseau de l'hôte.
![Adapter 1: NAT]()
Le deuxième adaptateur doit être réglé sur Host-only qui permet une communication bidirectionnelle entre l'hôte et l'invité.
Cet adaptateur est un peu plus complexe à configurer que le premier, car il faut modifier les préférences globales de VirtualBox en matière de réseau afin de configurer l'adaptateur réservé à l'hôte (remarque : cette opération nécessite des droits d'administrateur).
Dans VirtualBox, allez dans File -> Preferences -> Network . Cliquez sur le bouton Host-only Networks et cliquez sur le petit + pour ajouter un nouvel adaptateur. Vous serez invité à élever les permissions de VirtualBox.
Remplir le formulaire Adapter est obligatoire ; il doit ressembler à quelque chose comme ceci (ignorez l'adaptateur étiqueté #2 ; qui est utilisé pour quelque chose sans rapport) :
![Networking Preferences 1]()
Les valeurs sur le DHCP l'onglet du serveur sont facultatifs. Si vous avez l'intention de coder en dur l'adresse IP de cette carte dans la configuration réseau de l'invité, ces valeurs sont inutiles. Si, par contre, vous avez l'intention d'utiliser le DHCP, les valeurs peuvent ressembler à ceci :
![Networking Preferences 2]()
La dernière étape de la configuration de VirtualBox consiste à retourner dans la configuration réseau de la VM et à ajouter le deuxième adaptateur, qui fait référence à l'adaptateur hôte uniquement que nous venons de créer :
![Adapter 2: Host-only]()
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/interfaces pour ressembler à ça :
# 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
(les puristes peuvent préférer utiliser l'option /etc/network/interfaces.d à 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'ensemble de la VM de l'invité, et tout devrait "fonctionner".
À ce stade, on devrait pouvoir envoyer un ping à la VM invitée à l'adresse suivante 192.168.56.101 et recevoir une réponse (à condition qu'un pare-feu logiciel n'interfère pas).
De même, on devrait pouvoir envoyer un ping à l'hôte à l'adresse 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".
Dans cette configuration, les trois conditions énoncées dans votre question sont remplies.
Entrer : le VPN
Mais, voilà le hic. L'introduction du VPN pose un problème de taille (enfin, selon le VPN spécifique et sa configuration).
Les VPN modernes sont capables de Split Tunneling qui est nécessaire pour que la configuration de VirtualBox mentionnée ci-dessus fonctionne selon vos trois exigences. Pour de (bonnes) raisons de sécurité, le split tunneling 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, les mémorise, puis les remplace par des valeurs qui proviennent généralement d'un emplacement géré de manière centralisée (c'est-à-dire que 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 y a beaucoup d'autres entrées, que j'ai omises ici, car elles ne sont pas pertinentes pour la cause fondamentale de ce comportement).
Avant de se 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 s'ê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 le tunnelage fractionné est désactivé dans la configuration du VPN.
Normalement, ces deux commandes devraient restaurer 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 il se peut qu'il pave les deux de façon périodique ; je n'ai pas testé cela).
Si Si votre VPN spécifique et sa configuration permettent d'activer le tunnelage fractionné, il est généralement activé de la manière suivante :
![Cisco VPN client: allow access to LAN resources]()
Lors de la déconnexion du VPN, les clients VPN qui se comportent bien restaurent 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 VM invitée n'a pas besoin d'être redémarrée lorsque je me connecte ou me déconnecte du VPN. Dans ce cas, l'adaptateur secondaire de la VM est réinitialisé, mais il récupère son adresse IP automatiquement et de manière transparente, ce qui rétablit presque immédiatement la communication entre l'hôte et l'invité. Mieux encore, les montages NFS entre l'hôte et l'invité (j'utilise des montages CIFS) restent connectés pendant les opérations de connexion/déconnexion du VPN.
Dans le cas improbable où votre VPN permet le tunneling fractionné, il suffit de l'activer. Dans ce cas, j'aimerais que vous me disiez si "tout fonctionne" ou non.
