Traitez l’invité et le Mac comme deux réseaux distincts reliés par une seule porte étroite. La machine virtuelle conserve son client VPN et son propre chemin vers internet ; le Mac atteint exactement un service via un adaptateur réservé à l’hôte et un seul port redirigé. Rien d’autre ne doit franchir. Suivez les étapes dans l’ordre et arrêtez-vous quand l’une échoue, car chaque étape suivante suppose que les précédentes ont tenu.

Notez les deux chemins avant de changer quoi que ce soit

Sur l’invité, ipconfig /all affiche l’adaptateur qui porte le transport VPN et l’adresse qu’il a reçue du DHCP du réseau virtuel. Sur le Mac, notez l’interface virtuelle que l’hyperviseur a créée pour ce segment ; avec VMware Fusion, le périphérique réservé à l’hôte est généralement vmnet1, et Parallels donne au sien un nom propre. Repérez qui distribue les adresses à cet endroit, puis écrivez tout, car le sous-réseau réservé à l’hôte est souvent réattribué quand un réseau virtuel est recréé. Vérifiez le mode réseau de la machine virtuelle dans l’hyperviseur plutôt que dans votre souvenir de celui-ci. Le mode partagé ou NAT pour l’adaptateur tourné vers internet, plus le mode réservé à l’hôte pour l’adaptateur tourné vers le Mac, voilà la disposition que ces étapes supposent.

Deux adaptateurs, deux usages. Les mélanger pour qu’un seul adaptateur serve à la fois le Mac et internet, c’est ce qui transforme une porte étroite en chemin routé.

Confirmez d’abord le VPN propre à l’invité

Démarrez le client dans Windows et confirmez qu’il se termine, avec le test que l’éditeur documente. Ne passez pas à la suite tant que l’invité seul n’atteint pas le service privé, car un problème de redirection superposé à un tunnel cassé a deux causes et aucun message d’erreur utile. Notez l’adresse privée vers laquelle le service se résout depuis l’intérieur de l’invité. Cette adresse est la seule chose que la règle de redirection doive nommer.

Si le client pousse un tunnel complet, l’adaptateur réservé à l’hôte porte encore le trafic local, mais vérifiez que la destination privée n’est pas captée par le tunnel d’une manière qui change son adresse. Un profil à tunnel divisé simplifie cela et vaut la peine d’être demandé à qui possède le VPN.

Ajoutez la branche réservée à l’hôte et testez-la seule

Branchez un adaptateur réservé à l’hôte sur l’invité, donnez-lui une adresse statique sur un sous-réseau que rien d’autre n’utilise, et confirmez que le Mac peut le pinguer. Testez avec le VPN connecté et déconnecté, car l’adresse doit survivre aux deux. Un invité qui ne répond que tant que son tunnel est monté a un problème de routage que vous n’avez pas encore trouvé.

Windows peut classer le nouvel adaptateur comme réseau public, ce qui bloque le trafic entrant par défaut. Réglez le profil avant de déboguer quoi que ce soit d’autre.

Redirigez un port, pas le sous-réseau

Préférez un seul port redirigé à une redirection IP générale. Windows fournit netsh interface portproxy, qui redirige un port en écoute vers un hôte et un port de destination, et il exige que le service IP Helper tourne.

Réglez toujours listenaddress sur l’adresse réservée à l’hôte. L’omettre lie toutes les interfaces, ce qui expose le service à n’importe quel réseau où la machine virtuelle se trouve. Ajoutez une règle de pare-feu limitée à l’interface réservée à l’hôte et à ce seul port, pour que l’écouteur et la permission concordent. Une application consciente du proxy préférera peut-être un petit proxy dans l’invité, qui termine la connexion et n’a besoin d’aucune route de retour vers le Mac. Choisissez le proxy quand le protocole le permet, car il échoue fermé par construction.

Vérifiez, puis écrivez le retour arrière

Depuis le Mac, résolvez le nom privé, exécutez l’opération prévue, puis arrêtez le VPN de l’invité et confirmez que l’opération échoue au lieu de retomber silencieusement. C’est cette dernière vérification qui prouve que le chemin est bien celui que vous avez construit. Notez quelle identité voit la passerelle et qui a le droit d’utiliser la redirection.

Écrivez le retour arrière en trois étapes : supprimez l’entrée portproxy, supprimez la règle de pare-feu, détachez l’adaptateur réservé à l’hôte. Exécutez-le ensuite une fois, avant d’en avoir besoin, et confirmez que le VPN propre à l’invité fonctionne toujours après. Si votre organisation exige que chaque Mac s’enregistre indépendamment, arrêtez-vous ici et utilisez plutôt ce modèle, car un point de redirection partagé concentre l’accès sur un seul invité. Quoi qu’il en soit, mettez les adresses et le port dans le journal des changements ; la personne suivante ne voudra pas les redécouvrir.

Articles similaires