web-dev-qa-db-fra.com

virtualbox invité par vpn

J'ai un invité Oracle Linux exécutant un serveur Web dans VirtualBox sur un hôte Windows 7. J'ai besoin de configurer le réseau pour pouvoir faire 3 choses:

  1. l'hôte peut se connecter à l'invité via un navigateur et ssh
  2. l'invité peut parler à d'autres serveurs du réseau interne via le VPN de l'hôte
  3. l'invité peut accéder à l'internet extérieur

J'ai lu quelques réponses et essayé quelques configurations, et voici ce qui se passe:

Ponté

  1. L'hôte ne peut pas atteindre l'invité
  2. l'invité ne peut pas voir à travers un VPN
  3. invité peut accéder à Internet

NAT

  1. L'hôte ne peut pas atteindre l'invité
  2. invité peut voir à travers VPN
  3. invité ne peut pas accéder à Internet

Host-Only

les 3 conditions échouent.

Réseau NAT

  1. L'hôte ne peut pas atteindre l'invité
  2. invité peut voir à travers VPN
  3. invité ne peut pas accéder à Internet

Je devrais également souligner que parfois l'hôte est connecté via un VPN alors que d'autres fois, il est simplement branché directement sur le réseau de l'entreprise. Lorsqu'il est branché directement, un adaptateur ponté satisfait à toutes les 3 conditions. Idéalement, il devrait exister une configuration qui réponde aux trois conditions, qu’il s’agisse d’un VPN ou d’une connexion directe.

networkingvirtualboxvpn
37
ewok

Le même problème se posait exact et j’ai résolu le problème. Je me ferai donc un plaisir de l’expliquer en détail.

Sans impliquer 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, 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 le mode NAT, qui permet à l'invité d'accéder aux ressources réseau (y compris Internet) via l'interface réseau de l'hôte.

 Adapter 1: NAT

Le deuxième adaptateur doit être défini sur Host-only, ce qui active la 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 la modification des préférences de réseau globales de VirtualBox afin de configurer l'adaptateur pour hôte uniquement (remarque: cela nécessite des privilèges d'administrateur).

Dans VirtualBox, accédez à File -> Preferences -> Network. Cliquez sur l'onglet Host-only Networks, puis sur la petite icône + pour ajouter un nouvel adaptateur. Vous serez invité à élever les autorisations de VirtualBox.

Remplir l'onglet Adapter est obligatoire; cela devrait ressembler à quelque chose comme ceci (ignorer l'adaptateur nommé #2; c'est utilisé pour quelque chose qui n'a pas de relation):

 Networking Preferences 1

Les valeurs de l'onglet DHCP server 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 sont inutiles. Si, en revanche, vous avez l'intention d'utiliser DHCP, les valeurs peuvent ressembler à ceci:

 Networking Preferences 2

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 second adaptateur, qui fait référence à l'adaptateur pour 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 qu’il ressemble à 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 préférera peut-être utiliser le répertoire /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 la machine virtuelle invitée complète et tout devrait "fonctionner".

À ce stade, vous devriez être en mesure d’envoyer une requête ping à l’invité VM selon 192.168.56.101 et de recevoir une réponse (à condition que le pare-feu logiciel n’interfère pas).

De même, on devrait pouvoir envoyer une requête ping à l'hôte à 10.0.2.2. Cette adresse IP semble être "codée en dur" dans l'implémentation de VirtualBox NAT, ou au moins spécifiée via une directive de configuration non évidente, et il existe peu d'informations disponibles sur son origine. Mais, hélas, "ça fonctionne".

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 pose un problème spectaculaire (bien en fonction du VPN spécifique et de sa configuration).

Les VPN modernes sont capables de Split Tunneling , ce qui est nécessaire pour que la configuration de VirtualBox susmentionnée puisse fonctionner 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 qui se pose dans votre cas (et le mien).

Lorsque vous vous connectez au VPN, le client VPN (le client Cisco AnyConnect Secure Mobility, 3.1.02026, dans mon cas) examine les tables de routage de l'ordinateur hôte, les mémorise, puis les dépose avec des valeurs provenant généralement de certaines emplacement géré (c.-à-d., même avec les privilèges d'administrateur local, il est impossible de remplacer les paramètres).

Vous pouvez examiner vous-même les tables de routage en ouvrant command.exe (sous Windows):

C:\>route print

Avant de se connecter au VPN, la table de routage contient des entrées cruciales permettant à cette configuration de 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 fondamentale de ce problème.)

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 la connexion 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. Il s'agit précisément du comportement souhaité lorsque le tunneling fractionné est désactivé 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 ouvrir les deux à la fois périodiquement; je n'ai pas testé pour cela.)

Si votre VPN spécifique et sa configuration d'opérateur permettent d'activer le tunneling fractionné, il est généralement activé comme suit:

 Cisco VPN client: allow access to LAN resources

Lors de la déconnexion du VPN, les clients VPN bien tenus restaurent les tables de routage 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 l'invité VM ne doit pas nécessairement être redémarré lorsque je me connecte ou me déconnecte du VPN. Dans ce cas, l'adaptateur secondaire de la machine virtuelle est réinitialisé, mais celle-ci ré-acquiert son adresse IP automatiquement et de manière transparente, ce qui rétablit 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 improbable où votre VPN autorisera le tunneling fractionné, il vous suffira peut-être de l'activer. Dans ce cas, j'aimerais connaître votre avis sur le point de savoir si "tout fonctionne correctement".

56
Ben Johnson