1 votes

Aucun trafic entrant sur l'adaptateur Hyper-V à l'intérieur de la VM

J'ai un problème très ennuyeux avec ma configuration Hyper-V et cela m'ennuie beaucoup, car je n'arrive pas à comprendre pourquoi.

Mon hôte Hyper-V est un Windows Server 2019 et possède trois adaptateurs réseau. Les adaptateurs 1 et 2 sont physiques et ont des configurations statiques.

L'adaptateur 3 a été configuré comme un commutateur extensible Hyper-V. (Externe) Cet adaptateur est connecté à un port trunk sur un commutateur Cisco, où plusieurs vlans ont été marqués. L'adaptateur hôte utilise le VLAN 777 et peut se connecter sans problème.

J'ai créé une nouvelle VM, dans laquelle j'ai installé une autre instance de Windows Server 2019. Cette VM utilise le même vSwitch mais configuré sur le VLAN 666.

Dans la VM, j'ai regardé les informations d'état de l'adaptateur :

  • X nombre de paquets envoyés depuis le démarrage du dispositif
  • 0 paquet a été reçu

Au début, je soupçonnais un étrange pare-feu de bloquer la connexion.

Pour des raisons de bon sens, j'ai désactivé TOUTES les règles/réglages/profils de pare-feu, car cet hôte est de toute façon dans un réseau local. J'ai fait cela pour l'hôte et la VM.

Rien n'a changé, toujours pas de paquets entrants.

J'ai vérifié le commutateur auquel il est connecté - Il affiche l'adresse MAC statique de la VM, ce qui confirme qu'il l'a enregistrée d'une manière ou d'une autre. Cependant, il semble qu'il ne puisse pas recevoir de paquets, ce qui rend le DHCP ou toute autre communication impossible.

  • Qu'est-ce qui pourrait bloquer cette connexion ?
  • Quels journaux pourrais-je activer ou regarder pour comprendre ce problème ?

Il n'y a pas de règles de blocage ou autre sur le commutateur. L'hôte le confirme, car l'adaptateur d'hôte virtuel fonctionne parfaitement.

C'est juste à l'intérieur de la VM.

Quelques notes techniques sur la VM :

  • Il a été configuré en utilisant ISO 17763.737.190906-2324.rs5_release_svc_refresh_SERVERESSENTIALS_OEM_x64FRE_de-de_1
  • Il est réglé sur Génération 2
  • Les fonctionnalités supplémentaires et la case à cocher dans la configuration VM de l'adaptateur réseau sont toutes décochées.

Mise à jour - Ce que j'ai vérifié jusqu'à présent :

  • Journal des événements dans la VM et sur l'hôte (Cependant, je ne savais pas ce qu'il fallait rechercher spécifiquement !)
  • J'ai utilisé un miroir d'adaptateur pour regarder la connexion dans Wireshark (adaptateur de la VM comme source avec le nouvel adaptateur d'hôte comme destination) -> Cela n'a rien donné mais j'ai remarqué que je ne peux pas voir les pings ICMP sortir, assez bizarrement.
  • Paramètres du pare-feu sur l'hôte et la machine virtuelle -> Sur les deux systèmes, ils ont été désactivés sur TOUS les profils pour résoudre le problème sans autres perturbations possibles.
  • J'ai activé la journalisation du pare-feu pour les paquets abandonnés et je les ai vérifiés, rien.
  • J'ai vérifié trois fois les paramètres de Hyper-V, il n'y a pas de fonctions spéciales activées, concernant la connexion réseau.
  • Changez la configuration du commutateur pour qu'il soit un port d'accès pour le vlan au lieu d'un Trunk -> Aucune différence.
  • Utiliser une adresse MAC dynamique pour l'adaptateur au lieu d'une adresse statique -> Aucune différence

0voto

HackXIt Points 21

J'ai trouvé et la réponse est assez triste.

Sur la carte réseau physique utilisée pour le vSwitch, un VLAN était configuré sur le pilote matériel. Celui-ci n'a pas été supprimé lors de la création du vSwitch et a réussi, d'une manière ou d'une autre, à bloquer tout le trafic entrant/sortant, puisque personne ne pouvait réellement communiquer, lorsque le matériel lui-même a modifié l'ID du VLAN.

Comment l'ai-je découvert ? J'ai branché la carte réseau plus près du commutateur et j'ai remarqué qu'elle ne recevait pas de trafic sur l'hôte. Après de nombreuses tentatives de ping sur la carte réseau de l'hôte, j'en suis venu à la conclusion que la faute devait se trouver sur la carte réseau de cette machine. J'ai changé de carte réseau et cela a fonctionné.

Après avoir vérifié à nouveau les paramètres matériels de l'adaptateur, j'ai remarqué que l'ID VLAN était codé en dur par l'utilitaire de configuration de l'adaptateur Intel ProSet.

Donc oui... J'ai effacé ça, maintenant tout fonctionne.

Je me suis donné une leçon de stupidité.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X