Dépannage des problèmes de routage avec Azure vSockets

Vue d'ensemble

Cet article couvre les problèmes liés au routage concernant les vSockets déployés dans les réseaux virtuels Microsoft Azure (VNets). Il se concentre sur la manière dont le modèle de réseau défini par logiciel d'Azure affecte le flux de trafic entre les interfaces LAN de vSocket, les sous-réseaux, les VNets pairés et les réseaux externes. Une mauvaise compréhension des itinéraires système d'Azure, des itinéraires effectifs ou du comportement de l'acheminement IP peut entraîner un routage asymétrique, des paquets perdus ou des ressources inaccessibles.

Symptômes

Les problèmes de routage avec Azure vSockets se manifestent généralement par les symptômes observables suivants :

  • Le trafic ne parvient pas aux VM internes, soit dans le même sous-réseau que le LAN, soit dans un sous-réseau ou VNET différent.
  • Le trafic sortant des ressources internes n'atteint pas sa destination.
  • Les déploiements en haute disponibilité (HA) échouent à acheminer le trafic par le vSocket actif.

Causes possibles

  • Les itinéraires système Azure remplacent les chemins de trafic attendus.
  • Les itinéraires définis par l'utilisateur sont manquants ou mal configurés.
  • Le transfert IP est désactivé sur l'interface réseau LAN de vSocket.
  • Configuration incorrecte de l'IP flottante dans les déploiements HA.
  • Les règles du Groupe de Sécurité Réseau (NSG) bloquent le trafic entrant ou sortant.
  • Mauvaise interprétation du comportement de routage intra-sous-réseau d'Azure.

Dépannage des problèmes

IMPORTANT : Avant de procéder au dépannage, vérifiez tous les prérequis pour le déploiement de vSocket Azure. Voir Déployer des vSockets Azure depuis le Marketplace.

Utilisez les étapes ci-dessous pour isoler les problèmes de routage par symptôme. 

Définir la topologie interne

Pour mieux comprendre le flux de paquets et le comportement de routage au sein d'Azure, définissez d'abord la topologie du réseau entre les VNet(s) Azure, l'interface LAN de vSocket, et les sous-réseaux internes et VM.

Référez-vous au schéma de topologie ci-dessous pour vous guider.

Dépannage du trafic n'atteignant pas les ressources internes

  1. Vérifiez que les sous-réseaux internes sont correctement définis dans CMA sous Configuration du Site > Réseaux. Les sous-réseaux non natifs doivent avoir la passerelle définie sur la première adresse IP disponible du sous-réseau LAN (natif).
  2. Examinez la table de routage LAN :
    • Confirmez qu'un itinéraire 0.0.0.0/0 est configuré avec le prochain saut défini sur l'adresse IP LAN, ou, en déploiement HA, sur l'adresse IP flottante.
    • Si seuls des préfixes spécifiques doivent être joignables via le vSocket, définissez des itinéraires explicites pour ces préfixes avec la même configuration de prochain saut.
    • Vérifiez que tous les sous-réseaux internes requis sont présents dans la table de routage.
    • Si des itinéraires ou sous-réseaux sont manquants, voir Résoudre les itinéraires manquants ou incorrects
  3. Vérifiez les itinéraires effectifs pour l'interface LAN.
    • Sélectionnez l'interface LAN, puis accédez à Aide > Itinéraires effectifs.
    • Les itinéraires effectifs incluent à la fois les itinéraires système (par défaut) et les itinéraires définis par l'utilisateur (UDR).
    • Identifiez quel itinéraire a la priorité pour le préfixe de destination. Les itinéraires non préférés afficheront le statut "invalid".
    • Si un itinéraire système (par défaut) remplace l'itinéraire défini par l'utilisateur, voir Résoudre les itinéraires manquants ou incorrects
  4. Valider les règles du Groupe de Sécurité Réseau :
    • Confirmez que des règles d'autorisation explicites existent pour le trafic entrant et sortant.
    • Accordez une attention particulière à la priorité et à la direction des règles.
    • Sélectionnez l'interface LAN et vérifiez les règles de sécurité effectives. Assurez-vous que toutes les règles NSG associées autorisent le trafic attendu.
    • Si une règle NSG bloque le trafic, voir Résolution des blocages de trafic liés au NSG
  5. Vérifiez l'état du transfert IP sur l'interface réseau LAN du vSocket. Ce paramètre doit être activé pour permettre au LAN vSocket de recevoir du trafic destiné à d'autres destinations.
  6. Exécutez des captures PCAP sur le LAN via l'interface WebUI du vSocket tout en générant du trafic actif. Continuez avec les étapes suivantes pour les analyser.

Analyser les captures PCAP internes

  1. Examinez les captures de paquets prises depuis le LAN du vSocket.
  2. Confirmez le comportement de routage Azure suivant :

    • Lorsque le trafic quitte l'interface LAN vSocket, la MAC de destination sera le routeur virtuel Azure (12:34:56:78:9a:bc). Cela se produit parce qu'Azure achemine tout le trafic via son routeur virtuel interne, même lorsque les appareils sont dans le même sous-réseau.

    • Les paquets de retour affichent généralement la MAC source de la VM interne. Azure supprime la MAC du routeur avant de livrer le paquet au vSocket.

Contrairement aux réseaux de couche-2 traditionnels, Azure n'autorise pas la communication directe hôte-à-hôte dans un sous-réseau. Tout le trafic passe par le routeur virtuel Azure. Ce comportement peut faire apparaître les captures de paquets comme asymétriques.

Dépannage du routage vers les sous-réseaux non natifs

Si le trafic ne peut atteindre les ressources dans les sous-réseaux non natifs :

  1. Suivez les étapes expliquées dans Dépannage du trafic n'atteignant pas les ressources internes.
  2. Vérifiez que le sous-réseau non natif existe dans CMA. Assurez-vous que la passerelle est définie sur la première adresse IP disponible du sous-réseau LAN (natif).
  3. Confirmez que le sous-réseau non natif apparaît dans la table de routage LAN du vSocket

Dépannage du routage VNet-à-VNet

Lors du routage entre VNets pairés, vérifiez ce qui suit :

  1. Assurez-vous que le peering VNET et les tables de routage sont configurés comme expliqué dans Comment utiliser un vSocket dans l'environnement Azure Multiple VNets
  2. Suivez les étapes expliquées dans Dépannage du trafic n'atteignant pas les ressources internes.
  3. Vérifiez que le sous-réseau de destination (dans le VNet en étoile) existe dans CMA. Assurez-vous que la passerelle est définie sur la première adresse IP disponible du sous-réseau LAN (natif).
  4. Vérifiez les itinéraires effectifs sur l'interface LAN du vSocket. Il doit inclure le sous-réseau de destination avec le prochain saut défini sur le peering VNET.
  5. Vérifiez les itinéraires effectifs sur l'interface de la VM interne. Il doit inclure le sous-réseau natif avec le prochain saut défini sur le peering VNET, ainsi qu'un itinéraire 0.0.0.0/0 avec le prochain saut défini sur l'adresse IP LAN, ou, en déploiement HA, sur l'adresse IP flottante.

Dépannage des problèmes de routage HA

Dans les déploiements HA, vérifiez les éléments suivants :

  1. Accédez à l'interface LAN du vSocket MASTER, Paramètres > Configurations IP, et confirmez que l'IP flottante est configurée comme une adresse IP secondaire.
  2. Assurez-vous que la table de routage LAN sur le vSocket inclut l'IP flottante comme itinéraire 0.0.0.0/0 prochain saut. Sinon, voir Résoudre les problèmes d'IP flottante HA
  3. Assurez-vous que pendant le basculement, l'IP flottante est migrée vers le nouveau vSocket MASTER comme prévu lors des changements de rôle.

Pour plus d'informations sur le dépannage des environnements HA, voir Dépannage Azure HA vSocket

Résoudre les problèmes découverts

Appliquez la résolution appropriée en fonction de la cause identifiée lors du dépannage.

Résoudre les itinéraires manquants ou incorrects

  1. Créez ou mettez à jour les itinéraires définis par l'utilisateur dans la table de routage LAN pour remplacer les itinéraires système Azure lorsque nécessaire.
  2. Associez la table de routage au sous-réseau correct.
  3. Sélectionnez l'interface LAN, puis accédez à Aide > Itinéraires effectifs. Revalidez que le chemin attendu est maintenant préféré.

Résolution des blocages de trafic liés au NSG

  1. Ajoutez des règles d'autorisation explicites pour les protocoles, ports et préfixes source/destination requis.
  2. Assurez-vous que les règles d'autorisation ont une priorité plus élevée que les règles de refus.
  3. Re-testez le flux de trafic après les mises à jour des règles.
  4. Sélectionnez l'interface LAN, puis accédez à Aide > Règles de sécurité effectives. Revalidez que les règles d'autorisation attendues sont maintenant préférées.

Résolution des problèmes d'IP flottante HA

  1. Suivez les étapes de Dépannage Azure HA vSocket pour résoudre l'assignation de adresse IP flottante au vSocket MASTER.
  2. Mettez à jour la table de routage LAN si nécessaire pour référencer le prochain saut comme l'IP flottante.
  3. Effectuez un test de basculement contrôlé pour valider le comportement.

Soulever des cas au support Cato

Faites escalader au support Cato si le comportement de routage reste incohérent après la validation de la configuration. Fournissez les informations suivantes pour accélérer l'analyse de la cause racine.

  • Description de la topologie interne.
  • Captures d'écran des tables de routage de sous-réseau.
  • Captures d'écran des itinéraires effectifs.
  • Règles entrantes et sortantes du Groupe de Sécurité Réseau.
  • Confirmation de l'état du transfert IP sur l'interface LAN de vSocket.
  • Captures de paquets depuis le vSocket et les VM affectées.

Cet article vous a-t-il été utile ?

Utilisateurs qui ont trouvé cela utile : 0 sur 0

0 commentaire