Dépanner les problèmes de réseau de base dans Oracle Cloud Infrastructure

Présentation

Dans Oracle Cloud Infrastructure (OCI), le diagnostic des problèmes de connectivité réseau nécessite une visibilité sur la configuration et le flux du trafic entre plusieurs composants. Les outils du centre de contrôle de réseau OCI tels que Network Visualizer, Network Path Analyzer et les journaux de flux VCN fournissent des informations détaillées sur la disposition, le routage et le comportement des flux des ressources de réseau. Ces outils permettent d'identifier rapidement les configurations incorrectes, les routes manquantes et les échecs de communication entre les réseaux en nuage virtuels, les sous-réseaux et les passerelles dans un environnement de réseau OCI.

Dans ce tutoriel, nous allons nous concentrer sur les techniques de dépannage fondamentales pour les problèmes de connectivité courants. Bien qu'il démontre comment utiliser efficacement ces outils pour simplifier le dépannage et résoudre les problèmes efficacement, l'objectif est également de développer une compréhension plus large de la façon d'aborder et d'analyser les défis de connectivité, et pas seulement comment utiliser les outils eux-mêmes.

Objectifs

Utilisez l'outil Visualiseur de réseau pour explorer la disposition du réseau au niveau régional, du VCN et du sous-réseau.
Analyser les chemins de flux de trafic à l'aide de l'outil Analyseur de chemins de réseau pour comprendre comment les paquets traversent le réseau et identifier les défaillances.
Interpréter l'outil Journaux de flux de VCN pour inspecter les enregistrements de flux de trafic et détecter les problèmes de connectivité ou le comportement inhabituel.
Identifier et dépanner les erreurs de configuration réseau, les routes manquantes et les défaillances de communication.

Conditions requises

Vous connaissez les composants de réseau OCI de base tels que VCN, les sous-réseaux, les passerelles, les listes de sécurité et les tables de routage.
Vous avez accès à une location OCI avec des ressources de réseau configurées.
Votre compte d'utilisateur a requis des politiques Oracle Cloud Infrastructure Identity and Access Management (OCI IAM) pour gérer les composants de VCN, ainsi que pour utiliser Network Visualizer, Network Path Analyzer et Journaux de flux de VCN.

Si vous souhaitez suivre certains des exemples à venir, exécutez les commandes suivantes dans votre machine virtuelle Oracle Linux (vM) de test pour créer un site Web Apache simple.

sudo dnf install httpd --assumeyes
sudo systemctl enable httpd
sudo systemctl start httpd
sudo firewall-offline-cmd --add-service=http
sudo systemctl restart firewalld
sudo vi /var/www/html/index.html

'<!doctype html><html><body><h1>Test Apache Website.. it's reachable!</h1></body></html>'

Tâche 1 : Voir la configuration du réseau à l'aide du visualiseur de réseau

Avant de commencer à creuser dans ce qui est cassé, il est utile de prendre du recul et d'obtenir une vue claire de votre environnement réseau. Le visualiseur de réseau dans OCI offre une représentation graphique de la topologie de votre réseau VCN. Bien qu'il ne corrige pas directement les problèmes, il fournit une vue claire et consolidée de l'ensemble de votre architecture réseau dans un compartiment spécifique que vous choisissez.

Ce contexte visuel montre comment tout est connecté (réseaux en nuage virtuels, sous-réseaux, passerelles, tables de routage, listes de sécurité) en un seul endroit. Cela facilite la détection de tout ce qui semble distant, comme une route manquante ou un réseau VCN qui n'est pas associé à une passerelle de routage dynamique (DRG). Dans les configurations complexes, cela peut vous faire économiser beaucoup de conjectures. Ce n'est pas toujours une solution, mais c'est un premier pas solide qui peut vous orienter dans la bonne direction avant d'entrer dans les détails.

Pour ce tutoriel, nous avons résumé le fonctionnement du visualiseur de réseau dans le diagramme suivant. Pour plus d'informations, voir Visualiseur de réseau.

Exemple

Nous utiliserons l'architecture suivante comme exemple.

Dans cet exemple, deux problèmes sont apparus dans l'environnement. Nous verrons comment Network Visualizer aide à les identifier et à les résoudre.

Problème 1 : VM-1 ne peut pas effectuer une commande ping sur VM-2.
Problème 2 : VM-2 ne peut pas atteindre Internet.

Voici une présentation rapide de notre environnement réseau à l'aide du visualiseur de réseau dans la console OCI, qui doit refléter l'architecture.

Premier niveau : Topologie du réseau régional

Cette topologie comprend les passerelles de routage dynamique, les réseaux en nuage virtuels, les équipements locaux d'abonné et différents types de passerelle.

Connectez-vous à la console OCI.
1. Assurez-vous d'être dans la bonne région.
2. Cliquez sur le menu hamburger (≡) dans le coin supérieur gauche.
3. Cliquez sur Réseau.
4. Cliquez sur Visualiseur de réseau.

Il s'agit de la première vue que vous verrez lorsque vous accéderez à Network Visualizer. Détruisons-la.
1. Sélectionnez le compartiment dans lequel résident vos composants de réseau. Si vous ne savez pas où se trouvent vos ressources, sélectionnez le compartiment parent (ou le compartiment racine) et sélectionnez Inclure les compartiments enfants.
2. Notez les réseaux en nuage virtuels que vous avez : VCN-1 et VCN-2, et le bloc d'adresse IPv4 pour chacun.
3. Notez les passerelles réseau, telles que :
  - Une passerelle DRG qui comporte plusieurs attachements (réseaux en nuage virtuels, connexion d'appairage distant et IPSec).
  - Une passerelle NAT dans VCN-2.
4. Vous verrez également une connexion d'appairage distant (RPC) qui connecte les réseaux en nuage virtuels de la région de Jeddah à une autre région (Riyadh).
5. Il existe également une connexion IPSec au réseau sur place. Vous pouvez voir l'adresse IP publique de l'appareil CPE du client (210.20.x.x) et le bloc d'adresses réseau sur place qui communiqueront en privé avec nos réseaux en nuage virtuels (172.16.16.10/32).

Cliquez sur VCN-2.
Examinons maintenant la topologie de réseau VCN, en commençant par la carte de routage.

Deuxième niveau : Topologie de VCN

Cette topologie inclut les sous-réseaux, les réseaux VLAN et les passerelles vers d'autres ressources. En plus des règles de sécurité utilisées par le sous-réseau (liste de sécurité ou groupe de sécurité de réseau).

Nous sommes dans la vue de carte de routage du VCN.
VCN-2 se compose d'un sous-réseau privé.
Nous pouvons voir dans la table de routage du sous-réseau une règle qui envoie le trafic destiné à VCN-1 à la passerelle DRG en tant que saut suivant.

Passez à la vue de mappage Sécurité du VCN.
Nous pouvons également voir dans cette vue que VCN-2 se compose d'un sous-réseau privé.
De plus, les listes de sécurité et les groupes de sécurité de réseau associés au sous-réseau privé sont visibles dans ce mode.

Cliquez sur le sous-réseau privé.
Examinons maintenant la topologie du sous-réseau, en commençant par la carte d'inventaire.

Troisième niveau : Topologie de sous-réseau

Cette topologie présente les informations sur les ressources concernant les instances de calcul OCI, les équilibreurs de charge OCI, le service de stockage de fichiers OCI et les grappes OCI Kubernetes Engine (OKE) du sous-réseau, ainsi que les règles de sécurité utilisées par la ressource.

Nous sommes dans la vue de carte Stocks du sous-réseau.
Il n'y a qu'une seule instance de calcul dans ce sous-réseau (VM-2), cliquez dessus.
Vous pouvez voir des informations sur la machine virtuelle, telles que le compartiment, les adresses IP, etc.

Passez à la vue de mappage Sécurité du sous-réseau.
Nous n'avons qu'une seule instance de calcul dans ce sous-réseau (VM-2).
Nous voyons les listes de sécurité et les groupes de sécurité de réseau que VM-2 utilise.

Sommaire :

Nous avons exploré à quoi ressemble notre environnement réseau et les composants impliqués, quelles sont selon vous les causes profondes du problème que nous avons mentionné précédemment?

Problème 1 : VM-1 ne peut pas effectuer une commande ping sur VM-2.

Dans Premier niveau : Topologie de réseau régional, notez que VCN-1 n'est pas attaché à la passerelle DRG. Par conséquent, pour que le flux de communication se produise entre VM-1 et VM-2, nous devons attacher VCN-1 et ajouter la règle de routage requise pour activer le flux de trafic.

L'attachement de VCN-1 et l'ajout de la règle de routage suivante (destination : VCN-2, saut suivant : DRG) doivent résoudre le problème. Cela suppose que le routage dans VCN-2 est déjà configuré correctement et que le type ICMP 8 est autorisé dans les deux listes de sécurité.
Problème 2 : VM-2 ne peut pas atteindre Internet.

Dans la topologie de deuxième niveau : VCN, notez que le sous-réseau privé de VCN-2 n'a qu'une seule route vers la passerelle DRG, mais aucune route vers la passerelle NAT, ce qui fait que VM-2 n'a pas de connectivité Internet.

L'ajout de la règle de routage suivante (destination : 0.0.0.0/0, saut suivant : Passerelle NAT) doit résoudre le problème. En supposant que le trafic sortant est déjà autorisé dans la liste de sécurité.

Network Visualizer peut vous aider à repérer les problèmes évidents causés par des erreurs de configuration, comme nous l'avons vu dans l'exemple. Mais même si cela ne révèle pas un problème clair, sa vraie valeur réside dans le fait de vous donner une vision holistique de votre environnement. Cette perspective vous aide à valider la configuration actuelle et vous donne un point de départ solide avant de creuser plus profondément dans des problèmes plus complexes.

Tâche 2 : Valider la configuration du réseau

Après avoir obtenu une vue claire de votre environnement réseau et des composants dont vous disposez, l'étape essentielle suivante consiste à valider la configuration réelle en place. De nombreux problèmes de connectivité se résument à quelque chose de simple : une route manquante, des règles de sécurité trop strictes ou un sous-réseau qui est simplement lié à la mauvaise table de routage ou liste de sécurité.

Avant de passer à un dépannage plus approfondi, comme la vérification des journaux ou l'exécution des captures de paquets, il est important de s'assurer que tout est configuré comme prévu. Cette étape peut souvent révéler la cause première tôt et vous aider à éviter une enquête inutile plus tard.

Exemple

Nous utiliserons l'architecture suivante comme exemple.

Pour commencer, présentons les composants de routage et de sécurité de base qui jouent un rôle central dans la validation de la configuration :

Règles d'acheminement :
- Sur place :
  - RT-0 : Acheminement de l'appareil local d'abonné (CPE) sur place (ou multinuage), en cas de connexion FastConnect ou IPSec (voir le fournisseur : Cisco, Fortinet, etc.).
- Tables de routage du VCN OCI : Existe dans le VCN et sert à envoyer le trafic hors du VCN (par exemple, vers Internet, vers un réseau sur place ou vers un VCN appairé). Ces tables de routage ont des règles qui ressemblent aux règles de routage de réseau classiques que vous connaissez peut-être déjà.
  - RT-1-2-3 : Tables de routage de VCN affectées au niveau du sous-réseau afin d'acheminer le trafic sortant.
  - RT-2a : Tables de routage de VCN affectées à l'attachement DRG VCN-2, nécessaire pour les scénarios de routage de transit. Dans cet exemple, il est utilisé en tant que table de routage de trafic entrant pour acheminer le trafic provenant de la passerelle DRG au moyen du pare-feu aux fins d'inspection.
  - RT-2b : Table de routage de VCN attachée à la passerelle NAT. Dans cet exemple, elle est utilisée comme table de routage de trafic entrant pour acheminer le trafic de réponse provenant d'Internet vers le pare-feu à des fins d'inspection.
- Tables de routage DRG pour OCI : Elles existent et servent à acheminer les paquets entrant dans cette dernière au moyen de l'attachement.
  - RT-10-20-30 : Tables de routage DRG pour les attachements de VCN, pour acheminer le trafic provenant du VCN.
  - RT-40-50 : Tables de routage DRG pour les attachements RPC, pour acheminer le trafic provenant de l'autre région.
  - RT-60 : DRG RT pour l'attachement IPSec, pour acheminer le trafic provenant d'un réseau sur place ou multinuage.
Règles de sécurité :
- Sur place :
  - FW-0 : Contrôlez et limitez le flux de trafic vers et depuis OCI sur l'appareil CPE sur place (ou multinuage), en cas de connexion FastConnect ou IPSec (voir le fournisseur : Cisco, Fortinet, etc.).
- Listes de sécurité du VCN OCI : Agissez en tant que pare-feu virtuels pour les ressources basées sur le VCN, avec des règles de trafic entrant et sortant qui spécifient les types de trafic autorisés. Les listes de sécurité sont configurées au niveau du sous-réseau, ce qui signifie que toutes les cartes vNIC d'un sous-réseau sont soumises au même jeu de listes de sécurité.
  - SL-1-2-3 : Listes de sécurité affectées au niveau du sous-réseau, afin de contrôler le trafic entrant et sortant sur chaque sous-réseau.
Note : Les groupes de sécurité de réseau sont un autre type de pare-feu virtuels disponibles dans OCI. Ils fonctionnent de la même manière que les listes de sécurité, mais offrent un contrôle plus granulaire, car ils sont appliqués au niveau de la ressource. Cela est utile lorsque deux ressources dans le même sous-réseau nécessitent des postures de sécurité différentes. Toutefois, les groupes de sécurité de réseau ne sont pas utilisés dans ce tutoriel. Pour plus d'informations, voir Comparaison des listes de sécurité et des groupes de sécurité de réseau.
- Pare-feu de réseau OCI ou un pare-feu de tierce partie : Agit en tant que point d'inspection centralisé et avec état du trafic entre les sous-réseaux, les réseaux en nuage virtuels et les réseaux externes, en appliquant des politiques de sécurité avancées au-delà des règles de liste de sécurité de base.
  - FW-2 : Contrôle et inspecte tout le trafic Nord-Sud et Est-Ouest dans un environnement réseau OCI.

Nous comprenons comment le routage et la sécurité sont appliqués dans l'environnement. Examinons de plus près l'exemple de cas suivant, où quatre problèmes sont survenus. En appliquant un peu de bon sens, nous déterminerons quelles configurations vérifier et où, pour chaque scénario de dépannage.

Note :

Si des groupes de sécurité de réseau sont utilisés, vérifiez les configurations appliquées à chaque carte VNIC associée à chaque machine virtuelle.

Dans cet exemple, VM-2 agit en tant que pare-feu de tierce partie (FortiGate). Il est déjà configuré pour acheminer le trafic correctement.

Problème 1 : VM-1 ne peut pas envoyer de message ping à VM-3 (différentes régions, le pare-feu ne doit PAS inspecter le trafic).
- Acheminement :
  - Demande : RT-1 > RT-10 > RT-40.
  - Réponse : RT-3 > RT-30 > RT-50.
- Sécurité : ICMP type 8 doit être autorisé à effectuer une commande ping réussie.
  - Demande : SL-1 (Règles de trafic sortant) > SL-3 (Règles de trafic entrant).
  - Réponse : SL-3 (Règles de trafic sortant) > SL-1 (Règles de trafic entrant).
Problème 2 : VM-1 ne peut pas atteindre Internet (le pare-feu VM-2 doit inspecter le trafic).
- Acheminement :
  - Demande : RT-1 > RT-10 > RT-2a > Routage interne FW-2 > RT-2.
  - Réponse : RT-2b > Routage FW-2 > RT-2 > RT-20.
- Sécurité :
  - Demande : SL-1 (Règles de trafic sortant) > SL-2 (Règles de trafic entrant et sortant) > FW-2 (Règles de trafic entrant et sortant).
  - Réponse : SL-2 (Règles de trafic entrant et sortant) > FW-2 (Règles de trafic entrant et sortant) > SL-1 (Règles de trafic entrant).
Problème 3 : VM2 ne peut pas atteindre Internet.
- Acheminement :
  - Demande : RT-2.
  - Réponse : Aucun routage n'est requis.
- Sécurité :
  - Demande : SL-2 (Règles de trafic sortant).
  - Réponse : SL-2 (Règles de trafic entrant).
Problème 4 : Les clients sur place ne peuvent pas envoyer de message ping à VM-1 (le pare-feu doit inspecter le trafic).
- Acheminement :
  - Demande : RT-0 (équipement local d'abonné sur place) > RT-60 > RT-2a > Routage interne FW-2 > RT-2 > RT-20.
  - Réponse : RT-1 > RT-10 > RT-2a > Routage interne FW-2 > RT-2 > RT-20.
- Sécurité :
  - Demande : FW-0 (Règles de trafic sortant) > SL-2 (Règles de trafic entrant et sortant) > FW-2 (Règles de trafic entrant et sortant) > SL-1 (Règles de trafic entrant).
  - Réponse : SL-1 (Règles de trafic sortant) > SL-2 (Règles de trafic entrant et sortant) > FW-2 (Règles de trafic entrant et sortant) > FW-0 (Règles de trafic entrant).

Il est essentiel de comprendre comment le trafic est géré et contrôlé sur l'ensemble du réseau. En suivant le chemin que le trafic doit emprunter, vous pouvez identifier rapidement où des problèmes peuvent se produire et quels paramètres doivent être examinés lors du dépannage.

Tâche 3 : Utiliser l'analyseur de chemins réseau

Vous avez examiné la configuration globale du réseau et vérifié manuellement la configuration des règles d'acheminement et de sécurité. Cependant, le problème persiste, peut-être avez-vous négligé certains détails de configuration, alors quelle est la prochaine étape?

C'est là qu'intervient Network Path Analyzer. Considérez-le comme un détective de réseau virtuel, conçu pour inspecter l'acheminement de votre réseau OCI et la configuration de la sécurité en temps réel. Il les collecte et les analyse pour déterminer comment les chemins entre la source et la destination fonctionneront ou échoueront. Aucun trafic réel n'est envoyé, mais la configuration est examinée et utilisée pour confirmer l'accessibilité.

Au lieu d'effectuer des tests de connectivité manuels tels que ping ou telnet à partir de machines virtuelles ou de bases de données individuelles, Network Path Analyzer vous permet de vérifier la configuration des chemins de communication directement dans la console OCI, offrant une approche de dépannage plus efficace et centralisée.

L'analyseur de chemins réseau prend en charge les scénarios suivants :

OCI vers OCI.
OCI vers réseau sur place.
Réseau sur place vers OCI.
Internet vers OCI.
OCI vers Internet.

Exemple 1

Nous utiliserons l'architecture suivante comme exemple.

Nous avons rencontré un problème de réseau et nous utiliserons Network Path Analyzer pour tracer et résoudre la cause première.

Problème : VM-1 ne peut pas accéder à un site Web hébergé sur VM-2 (OCI vers OCI).

Connectez-vous à la console OCI, allez à VM-2 et exécutez la commande suivante pour vérifier si le site Web s'exécute localement.
```
curl localhost
```
Allez à la console OCI, naviguez jusqu'à VM-1 et exécutez la même commande pour tester la connectivité à VM-2.
```
curl 192.168.0.20
```
Vous constaterez que la demande échoue. Dans les étapes suivantes, nous allons utiliser Network Path Analyzer pour examiner la cause.
Allez à la console OCI.
1. Assurez-vous d'être dans la bonne région.
2. Cliquez sur le menu hamburger (≡) dans le coin supérieur gauche.
3. Cliquez sur Réseau.
4. Cliquez sur Network Path Analyzer.
Cliquez sur Créer une analyse de chemins.
Maintenant, configurons les détails du flux réseau à tester.
1. Entrez Name (Nom) comme test-vm1-to-vm2-port80.
2. Sélectionnez Protocole comme TCP.
Nous allons commencer par remplir les informations de la source, qui dans ce cas est VM-1.
1. Sélectionnez Rechercher une ressource OCI.
2. Sélectionnez Type de source comme instance de calcul (VNIC).
3. Sélectionnez VM-1 dans la liste.
4. Sélectionnez la carte VNIC qui générera le trafic (elle est déjà remplie automatiquement si la machine virtuelle n'a qu'une seule carte VNIC).
5. Sélectionnez Adresse IPv4 source 10.0.0.10 (elle est également remplie automatiquement s'il n'y a qu'une seule adresse IPv4).
1. Cliquez sur Voir les options avancées.
2. Ici, vous pouvez spécifier le port source si nécessaire; pour cet exemple, laissez-le réglé à Utiliser n'importe quel port.
Ensuite, nous remplirons les informations de destination, qui dans ce cas est VM-2.
1. Sélectionnez Rechercher une ressource OCI.
2. Sélectionnez Type de source comme instance de calcul (VNIC).
3. Sélectionnez VM-2 dans la liste.
4. Sélectionnez la carte VNIC qui générera le trafic (elle est déjà remplie automatiquement si la machine virtuelle n'a qu'une seule carte VNIC).
5. Sélectionnez Adresse IPv4 source comme 192.168.0.20 (elle est également remplie automatiquement s'il n'y a qu'une seule adresse IPv4).
6. Entrez Port de destination comme 80.
1. Pour analyser à la fois le trafic aval et le trafic inverse, conservez la direction comme bidirectionnelle.
2. Cliquez sur exécuter l'analyse.
1. Les détails de connexion sont affichés lors de l'exécution de l'analyse.
2. Faites défiler vers le bas jusqu'à suivre la progression de l'analyse et attendez qu'elle se termine, ce qui peut prendre une minute ou deux.
L'analyse est terminée. Commençons par vérifier le résultat du chemin d'accès aval.
1. L'analyse indique que VM-2 est inaccessible après deux sauts réussis.
2. La suppression a lieu entre la passerelle DRG et VM-2.
3. Pour plus d'informations, cliquez sur Voir les informations sur le diagramme.
4. Ce tableau décompose le flux de routage et les contrôles de sécurité à chaque étape du chemin.
5. Si vous effectuez un zoom avant, vous verrez que le trafic est refusé entre la passerelle DRG et VM-2.
1. Développez le même segment pour plus de détails.
2. Notez que la acheminement de la gamme d'opérations a réussi.
3. Toutefois, le trafic est refusé en raison d'une règle de sécurité manquante :
  1. (3.a) Le trafic sortant est autorisé, aucun problème ici.
  2. (3.b) Le trafic entrant est refusé parce qu'aucune règle ne l'autorise. La liste de sécurité associée au sous-réseau VM-2 est affichée (Liste de sécurité par défaut pour VCN-2), notez-la, car nous allons la réviser dans les étapes suivantes. À ce stade, nous avons identifié la source du problème.
1. Le chemin de retour n'est pas analysé, car la vérification du chemin de transfert a échoué.
2. Cliquez sur enregistrer l'analyse.
3. Vous pouvez revoir et réexécuter l'analyse à tout moment. Nous l'exécuterons à nouveau plus tard dans ce tutoriel après avoir résolu le problème.
1. Naviguez jusqu'à VCN-2, où se trouve la machine virtuelle de destination.
2. Cliquez sur Sécurité.
3. Cliquez sur Liste de sécurité par défaut pour VCN-2.
Note : Les listes de sécurité fonctionnent au niveau du sous-réseau, ce qui signifie que tout trafic autorisé par ces règles s'applique à toutes les cartes vNIC de ce sous-réseau.
1. Cliquez sur Règles de sécurité.
2. Le tableau indique le trafic autorisé. Tout le reste, y compris HTTP, est refusé par défaut car il n'y a pas de règle pour l'autoriser. C'est pourquoi VM-1 ne peut pas accéder au site Web hébergé sur VM-2.
3. Pour corriger cela, cliquez sur Ajouter des règles de trafic entrant.
1. Entrez 10.0.0.0/16 dans le champ CIDR source (il s'agit du CIDR pour VCN-1).
2. Sélectionnez TCP pour le protocole IP.
3. Réglez 80 à Port de destination.
4. Cliquez sur Ajouter des règles de trafic entrant.
Connectez-vous à VM-1 et exécutez la même commande pour tester la connectivité à VM-2.
```
curl 192.168.0.20
```
Vous devriez maintenant voir que le site est accessible.
Revenez à l'analyse pour effectuer une autre exécution et vérifiez que le problème est résolu.
Cliquez sur Analyser.
Attendez la fin de l'analyse.
L'analyse est terminée. Examinons le résultat Transférer le chemin.
1. Le statut indique maintenant Accès possible.
2. Hop 3 est maintenant réussi parce que nous avons ajouté une règle de sécurité permettant le trafic HTTP.
3. Cliquez sur Voir les informations sur le diagramme.
4. Vous pouvez voir que le statut de sécurité du saut 3 est maintenant Autorisé (auparavant, il était Refusé).
En vérifiant le chemin de retour, nous pouvons voir qu'il est également réussi.

Exemple 2

Nous utiliserons l'architecture suivante comme exemple.

Nous avons rencontré un problème de réseau et nous utiliserons Network Path Analyzer pour tracer et résoudre la cause première.

Problème : VM-2 ne peut pas installer l'ensemble telnet (OCI vers Internet).

Note : Telnet est un protocole réseau et un outil de ligne de commande utilisé pour accéder à distance et gérer des appareils sur un réseau. Il est également utilisé pour les tests réseau de base (par exemple, vérifier si un port est ouvert).

Vérifiez si nous pouvons installer telnet sur VM-2.
1. Connectez-vous à VM-2 et exécutez la commande suivante pour installer telnet.
```
sudo yum install telnet
```
2. Entrez y et appuyez sur Entrée pour continuer.
3. Échec de l'installation. VM-2 a tenté de se connecter au référentiel YUM régional (yum.me-jeddah-1.oci.oraclecloud.com) mais n'a pas pu l'atteindre.
1. Exécutez la commande ci-dessous pour trouver l'adresse IP du référentiel yum.
```
dig yum.me-jeddah-1.oci.oraclecloud.com
```
2. Notez les adresses IP. VM-2 ne peut pas accéder à ces adresses IP publiques, ce qui indique qu'il n'a pas d'accès Internet au moyen d'une passerelle NAT ou d'un accès privé à Oracle Services Network au moyen d'une passerelle de service pour accéder au référentiel yum, ou que le trafic sortant est bloqué. Pour aller au fond du problème, nous allons aller de l'avant avec l'analyse NPA dans les prochaines étapes.
Allez à la console OCI.
1. Assurez-vous d'être dans la bonne région.
2. Cliquez sur le menu hamburger (≡) dans le coin supérieur gauche.
3. Cliquez sur Réseau.
4. Cliquez sur Network Path Analyzer.
Cliquez sur Créer une analyse de chemins.
Maintenant, configurons les détails du flux réseau à tester.
1. Entrez Name (Nom) comme test-vm2-to-internet-port443.
2. Sélectionnez Protocole comme TCP.
Nous allons commencer par remplir les informations de la source, qui dans ce cas est VM-2.
1. Sélectionnez Rechercher une ressource OCI.
2. Sélectionnez Type de source comme instance de calcul (VNIC).
3. Sélectionnez VM-2 dans la liste.
4. Sélectionnez la carte VNIC qui générera le trafic (elle est déjà remplie automatiquement si la machine virtuelle n'a qu'une seule carte VNIC).
5. Sélectionnez Adresse IPv4 source comme 192.168.0.20 (elle est également remplie automatiquement s'il n'y a qu'une seule adresse IPv4).
1. Cliquez sur Voir les options avancées.
2. Ici, vous pouvez spécifier le port source si nécessaire; pour cet exemple, laissez-le réglé à Utiliser n'importe quel port.
Ensuite, nous remplirons les informations de destination, qui dans ce cas est Internet, en particulier les adresses IP publiques du référentiel yum (192.29.119.92 et 192.29.125.93), nous testerons en utilisant un seul d'entre eux.
1. Sélectionnez Entrer une adresse IP.
2. Entrez l'adresse IPv4 de destination 192.29.119.92.
3. Entrez Port de destination 443, car l'accès au référentiel se fait par HTTPS.
1. Pour analyser à la fois le trafic aval et le trafic inverse, conservez la direction comme bidirectionnelle.
2. Cliquez sur exécuter l'analyse.
1. Les détails de connexion sont affichés lors de l'exécution de l'analyse.
2. Faites défiler vers le bas jusqu'à suivre la progression de l'analyse et attendez qu'elle se termine, ce qui peut prendre une minute ou deux.
L'analyse est terminée. Commençons par vérifier le résultat du chemin d'accès aval.
1. L'analyse montre que VM-2 n'est pas en mesure d'accéder à Internet.
2. Ce segment met en évidence une configuration manquante qui empêche le trafic de quitter VCN-2.
3. Pour plus d'informations, cliquez sur Voir les informations sur le diagramme.
4. Ce tableau décompose le flux de routage et les contrôles de sécurité à chaque étape du chemin. Comme on l'a remarqué, le flux est direct car il n'y a pas de sauts intermédiaires entre les deux.
5. Si vous effectuez un zoom avant, vous verrez qu'aucun itinéraire n'est défini pour ce trafic.
1. Développez le même segment pour plus d'informations.
2. Aucun routage n'est configuré pour envoyer le trafic sur Internet. Pour corriger cela, nous devons ajouter une règle à la table de routage du sous-réseau VM-2 (Table de routage par défaut pour VCN-2), notez-la, car nous allons la réviser dans les tâches suivantes. À ce stade, nous avons identifié la source du problème.
3. Notez que la sécurité est autorisée.
  1. (3.a) Le trafic sortant est autorisé, aucun problème ici.
  2. (3.b) Le trafic entrant n'est pas pertinent dans ce cas, car le scénario se concentre uniquement sur le trafic sortant.
1. Le chemin de retour n'est pas analysé, car la vérification du chemin de transfert a échoué.
2. Cliquez sur enregistrer l'analyse.
3. Vous pouvez revoir et réexécuter l'analyse à tout moment. Nous l'exécuterons à nouveau plus tard dans ce tutoriel après avoir résolu le problème.
1. Naviguez jusqu'à VCN-2, où se trouve la machine virtuelle source.
2. Cliquez sur Gamme d'opérations.
3. Cliquez sur Table de routage par défaut pour VCN-2.
Note : Les tables de routage fonctionnent au niveau du sous-réseau, ce qui signifie que toutes les règles définies dans la table s'appliquent à toutes les ressources de ce sous-réseau. Les tables de routage peuvent également être associées à des cartes vNIC ou à des adresses IP spécifiques à l'aide du routage par ressource. Cependant, cela n'est pas pertinent pour notre tutoriel. Pour plus d'informations, voir Routage par ressource.
1. Cliquez sur Règles de routage.
2. Actuellement, une seule règle de routage est configurée pour acheminer le trafic vers VCN-1.
3. Pour activer l'accès Internet, cliquez sur Ajouter des règles de routage.
1. Sélectionnez Passerelle NAT comme Type de cible.
2. Entrez 0.0.0.0/0 dans Bloc CIDR de destination.
3. Sélectionnez Passerelle NAT créée précédemment.
4. Cliquez sur Ajouter des règles de routage.
Connectez-vous à VM-2 et réessayez d'installer telnet.
1. Exécutez la commande suivante .
```
sudo yum install telnet
```
2. L'installation est terminée.
Revenez à l'analyse pour effectuer une autre exécution et vérifiez que le problème est résolu.
Cliquez sur Analyser.
Attendez la fin de l'analyse.
L'analyse est terminée. Examinons le résultat Transférer le chemin.
1. Le statut indique maintenant Accès possible.
2. Le saut 2 est maintenant réussi, car nous avons ajouté une règle de routage envoyant du trafic vers la passerelle NAT.
3. Cliquez sur Voir les informations sur le diagramme.
4. Vous pouvez voir que le statut de routage du saut 2 est maintenant Transféré (auparavant, il s'agissait de Aucune route).
En vérifiant le chemin de retour, nous pouvons voir qu'il est également réussi.

Tâche 4 : Analyser les journaux de flux de VCN

Les journaux de flux de VCN offrent une couche supplémentaire de visibilité sur le comportement du trafic. Ce service vous permet de forer dans le trafic réel qui frappe chaque carte VNIC, en indiquant si elle a été acceptée ou rejetée en fonction des listes de sécurité et des règles de groupe de sécurité de réseau, ce qui vous aide à résoudre les problèmes liés à la sécurité.

Au-delà du dépannage, les journaux de flux de VCN sont essentiels pour surveiller l'activité du réseau, capturer les adresses IP source/destination, les ports, les protocoles et les horodatages, fournissant ainsi la télémétrie détaillée nécessaire aux vérifications et aux enquêtes de sécurité.

Exemple

Nous utiliserons l'architecture suivante comme exemple.

Note : Dans cet exemple, nous ne nous concentrons que sur la journalisation au point Y (Oui), où se trouve la destination. Toutefois, vous pouvez appliquer les mêmes étapes pour activer et analyser les journaux au point X (la source du trafic) afin d'obtenir une visibilité supplémentaire sur le flux global du trafic.

Nous avons rencontré un problème de réseau et nous utiliserons les journaux de flux de VCN pour tracer et résoudre la cause fondamentale.

Problème : VM-1 ne peut pas accéder à un site Web hébergé sur la machine virtuelle-2.

Connectez-vous à VM-2 et exécutez la commande suivante pour vérifier si le site Web s'exécute localement.
```
curl localhost
```
Connectez-vous à VM-1 et exécutez la même commande pour tester la connectivité à VM-2.
```
curl 192.168.0.20
```
Vous constaterez que la demande échoue. Dans les étapes suivantes, nous utiliserons les journaux de flux VCN-2 pour examiner la cause.
Maintenant, activons les journaux. Nous allons commencer par créer un filtre de saisie, qui est un jeu de règles simple utilisé dans OCI pour déterminer quel trafic réseau doit être saisi pour la journalisation ou mis en miroir vers des points d'accès de test virtuel (VTAP).
1. Connectez-vous à la console OCI et assurez-vous d'être dans la bonne région.
2. Cliquez sur le menu hamburger (≡) dans le coin supérieur gauche.
3. Cliquez sur Réseau.
4. Cliquez sur Filtres de saisie.
Cliquez sur Créer un filtre de saisie.
1. Entrez vcn-2-private-sn-logs dans le champ Nom.
2. Sélectionnez Filtre de saisie de journal de flux comme type de filtre.
3. Réglez le taux d'échantillonnage à 100 %. Cela définit le pourcentage de flux réseau à capturer, dans ce cas, nous voulons enregistrer tout le trafic.
1. Laissez les valeurs par défaut pour tous les autres paramètres.
2. Cliquez sur Créer un filtre de saisie.
Une fois le filtre de saisie créé, cliquez sur Copier pour copier son OCID, car vous en aurez besoin dans les étapes suivantes.
Maintenant, nous sommes prêts à activer les journaux.
1. Naviguez jusqu'à VCN-2.
2. Ouvrez Sous-réseau privé, où réside VM-2.
3. Cliquez sur Surveillance.
4. Faites défiler vers le bas jusqu'à la section Journaux.
5. Cliquez sur les trois points (••••) à côté de la catégorie Journaux de flux.
6. Cliquez sur Activer le journal.
1. Sélectionner un groupe de journaux. Si vous n'en avez pas déjà un, créez un nouveau groupe de journaux.
2. Le champ Nom du journal est rempli automatiquement.
3. Collez l'OCID du filtre de saisie copié précédemment.
4. Cliquez sur Activer le journal.
Les journaux de flux sont maintenant actifs.
Répétez le même test pour générer du trafic en exécutant la commande suivante dans VM-1.
```
curl 192.168.0.20
```
Retournez à la section Journaux et cliquez sur Nom du journal créé précédemment.
1. Faites défiler vers le bas et vous verrez des journaux indiquant le trafic entrant ou sortant du réseau.
2. Cliquez sur Actions.
3. Cliquez sur Explorer avec la recherche dans les journaux pour appliquer des filtres avancés et restreindre les résultats des journaux.
1. Appliquez les filtres suivants pour correspondre à notre connexion de test.
  - Adresse IP source (VM-1) : data.sourceAddress = '10.0.0.10'.
  - Adresse IP de destination (VM-2) : data.destinationAddress = '192.168.0.20'.
  - Port de destination (HTTP) : data.destinationPort = 80.
2. Ajustez l'intervalle de temps sous Filtrer par heure, si nécessaire, ou laissez-le comme valeur par défaut 5 dernières minutes.
3. Cliquez sur Rechercher.
1. Sert à consulter les résultats qui correspondent à vos critères de recherche.
2. Développez les détails de l'enregistrement.
Pour cet enregistrement particulier, vous pouvez voir des informations détaillées sur ce flux de trafic. Les champs clés à noter sont les suivants :
1. Horodatage : Date et heure exactes auxquelles le trafic a atteint le sous-réseau.
2. Détails de la connexion : Par exemple, l'adresse IP source, l'adresse IP de destination et le numéro de port.
3. Action : Indique comment le trafic a été traité; dans ce cas, il s'agissait d'un REJET. Cela confirme la cause fondamentale du problème. Aucune règle de sécurité n'est en place pour autoriser le trafic HTTP vers VM-2.
Pour permettre au trafic HTTP d'atteindre VM-2, vous disposez de deux options :
- Liste de sécurité : Appliquée au niveau du sous-réseau, ce qui signifie que toutes les cartes vNIC d'un sous-réseau sont soumises au même jeu de listes de sécurité.
- Groupe de sécurité de réseau : Appliqué au niveau de la ressource (niveau de la carte VNIC).
Ici, nous allons l'autoriser à partir de la liste de sécurité par défaut qui est déjà associée au sous-réseau VM-2.
1. Naviguez jusqu'à VCN-2, où se trouve la machine virtuelle de destination.
2. Cliquez sur Sécurité.
3. Cliquez sur Liste de sécurité par défaut pour VCN-2.
1. Cliquez sur Règles de sécurité.
2. Le tableau indique le trafic autorisé. Tout le reste, y compris HTTP, est refusé par défaut car il n'y a pas de règle pour l'autoriser. C'est pourquoi VM-1 ne peut pas accéder au site Web hébergé sur VM-2.
3. Pour corriger cela, cliquez sur Ajouter des règles de trafic entrant.
1. Entrez 10.0.0.0/16 comme CIDR source (il s'agit du CIDR pour VCN-1).
2. Sélectionnez TCP comme protocole IP.
3. Réglez 80 à Port de destination.
4. Cliquez sur Ajouter des règles de trafic entrant.
Connectez-vous à VM-1 et exécutez la même commande pour tester la connectivité à VM-2.
```
curl 192.168.0.20
```
Vous devriez maintenant voir que le site est accessible.
Revenez aux journaux et répétez les mêmes étapes qu'auparavant pour effectuer une nouvelle recherche.
1. Appliquez les filtres suivants pour correspondre à notre connexion de test.
  - Adresse IP source (VM-1) : data.sourceAddress = '10.0.0.10'.
  - Adresse IP de destination (VM-2) : data.destinationAddress = '192.168.0.20'.
  - Port de destination (HTTP) : data.destinationPort = 80.
2. Ajustez l'intervalle de temps si nécessaire, ou laissez-le comme valeur par défaut (5 dernières minutes).
3. Cliquez sur Rechercher.
1. Sert à consulter les résultats qui correspondent à vos critères de recherche.
2. Développez les détails de l'enregistrement.
Pour cet enregistrement particulier, vous pouvez voir des informations détaillées sur ce flux de trafic. Les champs clés à noter sont les suivants :
1. Horodatage : Date et heure exactes auxquelles le trafic a atteint le sous-réseau.
2. Détails de la connexion : Adresse IP source, adresse IP de destination et numéro de port.
3. Action : Indique comment le trafic a été traité. Après avoir résolu le problème, vous devez maintenant voir que le trafic est ACCEPT.

Étapes suivantes

Nous avons exploré comment dépanner les problèmes fondamentaux de réseau dans OCI en examinant l'architecture, l'acheminement et les configurations de sécurité. Ces vérifications de base permettent de résoudre les problèmes de connectivité les plus courants. Le prochain tutoriel se concentrera sur des scénarios avancés et d'autres cas d'utilisation du monde réel.

Remerciements

Auteurs - Anas Abdallah (spécialiste du réseau en nuage), Sachin Sharma (spécialiste du réseau en nuage)

Ressources d'apprentissage supplémentaires

Explorez d'autres laboratoires sur le site docs.oracle.com/learn ou accédez à plus de contenu d'apprentissage gratuit sur le canal Oracle Learning YouTube. De plus, visitez education.oracle.com/learning-explorer pour devenir un explorateur Oracle Learning.

Pour obtenir la documentation sur le produit, visitez Oracle Help Center.

Titre et informations sur les droits d'auteur

Troubleshoot Basic Network Issues in Oracle Cloud Infrastructure

G40741-01

Oracle et/ou ses sociétés affiliées.