Dépannage des problèmes réseau de base dans Oracle Cloud Infrastructure

Introduction

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 sur plusieurs composants. Les outils du centre de commande réseau OCI tels que Network Visualizer, Network Path Analyzer et VCN Flow Logs fournissent des informations approfondies sur la disposition, le routage et le comportement des flux des ressources réseau. Ces outils permettent d'identifier rapidement les erreurs de configuration, les acheminements manquants et les échecs de communication sur les réseaux cloud virtuels, les sous-réseaux et les passerelles dans un environnement 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 efficacement les problèmes, 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 Network Visualizer pour explorer la disposition du réseau aux niveaux régional, VCN et de sous-réseau.
Analysez les chemins de flux de trafic à l'aide de l'outil Network Path Analyzer pour comprendre comment les paquets traversent le réseau et identifier les échecs.
Interprétez l'outil VCN Flow Logs pour inspecter les enregistrements de flux de trafic et détecter les problèmes de connectivité ou les comportements inhabituels.
Identifiez et résolvez les erreurs de configuration réseau, les routes manquantes et les échecs de communication.

Prérequis

Vous connaissez les composants de réseau OCI de base tels que le 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 réseau configurées.
Votre compte utilisateur a des stratégies Oracle Cloud Infrastructure Identity and Access Management (OCI IAM) requises pour gérer les composants VCN, ainsi que pour utiliser Network Visualizer, Network Path Analyzer et VCN Flow Logs.

Si vous souhaitez suivre certains des exemples à venir, exécutez les commandes suivantes dans votre machine virtuelle Oracle Linux de test (vM) 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 : afficher la configuration réseau à l'aide de Network Visualizer

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. Network Visualizer dans OCI offre une représentation graphique de votre topologie VCN. Bien qu'il ne résolve 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 cloud virtuels, sous-réseaux, passerelles, tables de routage, listes de sécurité) au même endroit. Il est ainsi plus facile de repérer tout ce qui ressemble à un routage manquant ou à un VCN qui n'est pas associé à une passerelle de routage dynamique (DRG). Dans les configurations complexes, cela peut vous faire économiser beaucoup de devinettes. 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 de Network Visualizer dans le diagramme suivant. Pour plus d'informations, reportez-vous à Visualiseur réseau.

Exemple

Nous utiliserons l'architecture suivante comme exemple.

Dans cet exemple de cas, deux problèmes sont apparus dans l'environnement. Nous verrons comment le visualiseur de réseau aide à les identifier et à les résoudre.

Problème 1 : VM-1 ne peut pas envoyer une commande ping à VM-2.
Problème 2 : VM-2 ne parvient pas à accéder à Internet.

Tour d'horizon de notre environnement réseau à l'aide de Network Visualizer dans la console OCI, qui doit refléter l'architecture.

Premier niveau : Topologie du réseau régional

Cette topologie inclut les passerelles de routage dynamiques, les réseaux cloud virtuels, les CPE et différents types de passerelles.

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

Il s'agit de la première vue que vous verrez une fois que vous aurez accédé à Network Visualizer. Décomposons-le.
1. Sélectionnez le compartiment dans lequel résident vos composants 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 enfant.
2. Notez les réseaux cloud virtuels dont vous disposez : VCN-1 et VCN-2, ainsi que le bloc d'adresses IPv4 pour chacun d'eux.
3. Notez les passerelles réseau, telles que :
  - DRG qui comporte plusieurs pièces jointes (réseaux cloud virtuels, RPC et IPSec).
  - Passerelle NAT dans VCN-2.
4. Vous verrez également un RPC (Remote Peering Connect) qui connecte les réseaux cloud virtuels de la région de Djeddah à une autre région (Riyad).
5. Il existe également une connexion IPSec au réseau sur site. Vous pouvez voir l'adresse IP publique du dispositif CPE du client (210.20.x.x) et le bloc d'adresses réseau sur site qui communiquera en privé avec nos réseaux cloud virtuels (172.16.16.10/32).

Cliquez sur VCN-2.
Maintenant, approfondissons la topologie VCN, en commençant par la carte de routage.

Deuxième niveau : Topologie VCN

Cette topologie inclut les sous-réseaux, les 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é réseau).

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

Passez à la vue de carte Sécurité du VCN.
Dans cette vue, VCN-2 se compose d'un sous-réseau privé.
En outre, les listes de sécurité et les groupes de sécurité réseau associés au sous-réseau privé sont visibles dans ce mode.

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

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

Cette topologie affiche les informations sur les ressources concernant les instances OCI Compute, les équilibreurs de charge OCI, le service OCI File Storage et les clusters OCI Kubernetes Engine (OKE) dans le sous-réseau, ainsi que les règles de sécurité utilisées par la ressource.

Nous sommes dans la vue de carte Inventaire du sous-réseau.
Nous n'avons 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.

Basculez vers la vue de carte Sécurité du sous-réseau.
Ce sous-réseau ne comporte qu'une seule instance de calcul (VM-2).
Nous voyons les listes de sécurité et les groupes de sécurité réseau que VM-2 utilise.

Récapitulatif:

Nous avons exploré l'aspect de 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 envoyer une commande ping à VM-2.

Dans le premier niveau : topologie de réseau régional, notez que VCN-1 n'est pas attaché au 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.

La connexion 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 parvient pas à accéder à 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 DRG, mais aucune route vers la passerelle NAT, ce qui empêche VM-2 d'avoir une 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. Supposons que le trafic sortant soit 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 elle ne révèle pas un problème clair, sa valeur réelle réside dans le fait de vous donner une vision holistique de votre environnement. Cette perspective d'ensemble vous aide à valider la configuration actuelle et vous donne un point de départ solide avant d'approfondir les problèmes plus complexes.

Tâche 2 : validation de la configuration 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 en place. De nombreux problèmes de connectivité se résument à quelque chose de simple : un routage manquant, 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 les enquêtes inutiles plus tard.

Exemple

Nous utiliserons l'architecture suivante comme exemple.

Pour commencer, décrivons les principaux composants de routage et de sécurité qui jouent un rôle central dans la validation de la configuration :

Règles de routage:
- Sur site:
  - RT-0 : Routage du périphérique CPE (ou multicloud) sur site, en cas de connexion FastConnect ou IPSec (voir le fournisseur : Cisco, Fortinet, etc.).
- Tables de routage OCI VCN : existent dans le VCN et sont utilisées pour envoyer du trafic à partir du VCN (par exemple, vers Internet, un réseau sur site ou un VCN appairé). Ces tables de routage comportent une règle qui se présente et agit comme les règles de routage réseau classiques auxquelles vous savez peut-être déjà.
  - RT-1-2-3 : tables de routage VCN affectées au niveau du sous-réseau, afin d'acheminer le trafic sortant.
  - RT-2a : tables de routage VCN affectées à l'attachement DRG VCN-2, qui est nécessaire pour les scénarios de routage de transit, dans cet exemple, elle est utilisée comme table de routage entrante pour acheminer le trafic provenant de DRG via le pare-feu pour inspection.
  - RT-2b : table de routage VCN attachée à la passerelle NAT, dans cet exemple, elle est utilisée en tant que table de routage entrante pour acheminer le trafic de réponse provenant d'Internet vers le pare-feu pour inspection.
- Tables de routage OCI DRG : existent dans le DRG et sont utilisées pour acheminer les paquets entrant dans le DRG via l'attachement.
  - RT-10-20-30 : tables de routage DRG pour les pièces jointes VCN, pour acheminer le trafic provenant du VCN.
  - RT-40-50 : tables de routage DRG pour les pièces jointes 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 site ou multicloud.
Règles de sécurité :
- Sur site:
  - FW-0 : contrôlez et limitez le flux de trafic vers et depuis OCI sur le dispositif CPE sur site (ou multicloud), en cas de connexion FastConnect ou IPSec (voir le fournisseur : Cisco, Fortinet, etc.).
- Listes de sécurité OCI VCN : agissez comme des pare-feu virtuels pour les ressources basées sur VCN, avec des règles entrantes et sortantes qui spécifient les types de trafic autorisés à entrer et à sortir. Les listes de sécurité sont configurées au niveau du sous-réseau, ce qui signifie que toutes les cartes d'interface réseau virtuelles d'un sous-réseau sont soumises au même ensemble 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.
Remarque : les groupes de sécurité réseau sont un autre type de pare-feu virtuel disponible 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 d'un même sous-réseau nécessitent des postures de sécurité différentes. Cependant, les groupes de sécurité réseau ne sont pas utilisés dans ce tutoriel. Pour plus d'informations, reportez-vous à Comparaison entre les listes de sécurité et les groupes de sécurité réseau.
- OCI Network Firewall ou pare-feu tiers : agit en tant que point d'inspection centralisé avec conservation de statut pour le trafic entre les sous-réseaux, les réseaux cloud virtuels et les réseaux externes, en appliquant des stratégies 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, dans lequel quatre problèmes sont apparus. En appliquant un peu de bon sens, nous déterminerons les configurations à vérifier et où, pour chaque scénario de dépannage.

Remarque :

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

Dans cet exemple, VM-2 agit comme un pare-feu tiers (FortiGate). Il est déjà configuré pour acheminer le trafic correctement.

Problème 1 : VM-1 ne peut pas envoyer de commande ping à VM-3 (différentes régions, le pare-feu ne doit PAS inspecter le trafic).
- Routage:
  - 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 sortantes) > SL-3 (Règles entrantes).
  - Réponse : SL-3 (Règles sortantes) > SL-1 (Règles entrantes).
Problème 2 : VM-1 ne parvient pas à atteindre Internet (le pare-feu VM-2 doit inspecter le trafic).
- Routage:
  - 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é (Security):
  - Demande : SL-1 (Règles sortantes) > SL-2 (Règles entrantes et sortantes) > FW-2 (Règles entrantes et sortantes).
  - Réponse : SL-2 (Règles entrantes et sortantes) > FW-2 (Règles entrantes et sortantes) > SL-1 (Règles entrantes).
Problème 3 : VM2 ne parvient pas à accéder à Internet.
- Routage:
  - Demande : RT-2.
  - Réponse : Aucun routage n'est requis.
- Sécurité (Security):
  - Demande : SL-2 (règles sortantes).
  - Réponse : SL-2 (règles entrantes).
Problème 4 : les services sur site ne peuvent pas envoyer de commande ping à VM-1 (le pare-feu doit inspecter le trafic).
- Routage:
  - Demande : RT-0 (CPE sur site) > 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é (Security):
  - Demande : FW-0 (Règles sortantes) > SL-2 (Règles entrantes et sortantes) > FW-2 (Règles entrantes et sortantes) > SL-1 (Règles entrantes).
  - Réponse : SL-1 (Règles sortantes) > SL-2 (Règles entrantes et sortantes) > FW-2 (Règles entrantes et sortantes) > FW-0 (Règles entrantes).

Il est essentiel de comprendre comment le trafic est géré et contrôlé sur l'ensemble du réseau. En suivant le trafic du chemin, vous pouvez identifier rapidement où les problèmes peuvent se produire et quels paramètres doivent être vérifiés lors de la résolution des incidents.

Tâche 3 : utiliser l'analyseur de chemin réseau

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

C'est là qu'intervient Network Path Analyzer. Considérez-le comme votre détective de réseau virtuel, conçu pour inspecter votre configuration de routage et de sécurité réseau OCI 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 chemin réseau prend en charge les scénarios suivants :

OCI vers OCI.
OCI vers sur site.
Sur site 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 allons utiliser 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, accédez à VM-2 et exécutez la commande suivante pour vérifier si le site Web est exécuté localement.
```
curl localhost
```
Accédez à la console OCI, accédez à VM-1 et exécutez la même commande pour tester la connectivité à VM-2.
```
curl 192.168.0.20
```
Vous verrez que la demande échoue. Dans les étapes suivantes, nous allons utiliser l'analyseur de chemin réseau pour examiner la cause.
Accédez à la console OCI.
1. Assurez-vous d'être dans la bonne région.
2. Cliquez sur le menu hamburger (≡) en haut à gauche.
3. Cliquez sur Fonctions de réseau.
4. Cliquez sur Analyseur de chemin réseau.
Cliquez sur Créer une analyse de parcours.
Maintenant, configurons les détails du flux réseau à tester.
1. Entrez Nom dans le champ test-vm1-to-vm2-port80.
2. Sélectionnez Protocole en tant que TCP.
Nous allons commencer par remplir les informations source, qui sont dans ce cas 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 d'interface réseau virtuelle qui générera le trafic (elle est déjà remplie automatiquement si la machine virtuelle n'a qu'une seule carte d'interface réseau virtuelle).
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 Afficher les options avancées,
2. Ici, vous pouvez spécifier le port source si nécessaire. Dans cet exemple, laissez-le défini sur Utiliser n'importe quel port.
Ensuite, nous allons remplir les informations de destination, qui sont dans ce cas 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 d'interface réseau virtuelle qui générera le trafic (elle est déjà remplie automatiquement si la machine virtuelle n'a qu'une seule carte d'interface réseau virtuelle).
5. Sélectionnez Adresse IPv4 source comme 192.168.0.20 (elle est également remplie automatiquement s'il n'existe qu'une seule adresse IPv4).
6. Entrez Destination port comme 80.
1. Pour analyser le trafic vers l'avant et vers l'arrière, conservez la direction comme directionnelle.
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 pour suivre la progression de l'analyse et attendez qu'elle soit terminée. Cette opération peut prendre une minute ou deux.
Analyse terminée. Commençons par vérifier le résultat du chemin aval.
1. L'analyse indique que VM-2 est inaccessible après deux sauts réussis.
2. La suppression a lieu entre le DRG et VM-2.
3. Pour plus d'informations, cliquez sur Afficher les informations du diagramme.
4. Ce tableau décompose le flux de routage et les vérifications de sécurité à chaque étape du chemin.
5. Si vous effectuez un zoom avant, vous verrez que le trafic est Refusé entre le DRG et VM-2.
1. Développez le même segment pour plus de détails.
2. Notez que l'acheminement 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 le permet. 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 consulter 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. Accédez à 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.
Remarque : 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 d'interface réseau virtuelles 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 hébergé sur VM-2.
3. Pour résoudre ce problème, cliquez sur Ajouter des règles entrantes.
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 protocole IP.
3. Définissez 80 sur Port de destination.
4. Cliquez sur Ajouter des règles entrantes.
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.
Analyse terminée. Vérifions le résultat du chemin aval.
1. Le statut indique désormais Reachable.
2. Hop 3 est maintenant réussi car nous avons ajouté une règle de sécurité autorisant le trafic HTTP.
3. Cliquez sur Visualiser les informations de schéma.
4. Vous pouvez constater que le statut de sécurité du saut 3 est désormais 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 allons utiliser Network Path Analyzer pour tracer et résoudre la cause première.

Problème : VM-2 ne peut pas installer le package telnet (OCI vers Internet).

Remarque : Telnet est un protocole réseau et un outil de ligne de commande utilisé pour accéder et gérer à distance des périphériques 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. Saisissez y et appuyez sur Entrée pour continuer.
3. L'installation a échoué. 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 rechercher 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 accès à Internet via une passerelle NAT ou un accès privé à Oracle Services Network via une passerelle de service pour atteindre le référentiel yum, ou que le trafic sortant est bloqué. Pour aller au fond de la question, nous allons passer à l'analyse de l'APN dans les prochaines étapes.
Accédez à la console OCI.
1. Assurez-vous d'être dans la bonne région.
2. Cliquez sur le menu hamburger (≡) en haut à gauche.
3. Cliquez sur Fonctions de réseau.
4. Cliquez sur Analyseur de chemin réseau.
Cliquez sur Créer une analyse de parcours.
Maintenant, configurons les détails du flux réseau à tester.
1. Entrez Nom dans le champ test-vm2-to-internet-port443.
2. Sélectionnez Protocole en tant que TCP.
Nous allons commencer par remplir les informations source, qui sont dans ce cas 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 d'interface réseau virtuelle qui générera le trafic (elle est déjà remplie automatiquement si la machine virtuelle n'a qu'une seule carte d'interface réseau virtuelle).
5. Sélectionnez Adresse IPv4 source comme 192.168.0.20 (elle est également remplie automatiquement s'il n'existe qu'une seule adresse IPv4).
1. Cliquez sur Afficher les options avancées,
2. Ici, vous pouvez spécifier le port source si nécessaire. Dans cet exemple, laissez-le défini sur Utiliser n'importe quel port.
Ensuite, nous allons remplir les informations de destination, qui dans ce cas est l'Internet, en particulier, les adresses IP publiques du référentiel yum (192.29.119.92 et 192.29.125.93), nous allons tester en utilisant un seul d'entre eux.
1. Sélectionnez Entrer l'adresse IP.
2. Entrez l'adresse IPv4 de destination 192.29.119.92.
3. Saisissez 443 dans le champ Port de destination, car l'accès au référentiel s'effectue via HTTPS.
1. Pour analyser le trafic vers l'avant et vers l'arrière, conservez la direction comme directionnelle.
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 pour suivre la progression de l'analyse et attendez qu'elle soit terminée. Cette opération peut prendre une minute ou deux.
Analyse terminée. Commençons par vérifier le résultat du chemin aval.
1. L'analyse montre que VM-2 ne parvient pas à 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 Afficher les informations du diagramme.
4. Ce tableau décompose le flux de routage et les vérifications de sécurité à chaque étape du chemin. Comme 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 routage 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 du trafic sur Internet. Pour résoudre ce problème, 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), en prendre note, car nous allons la vérifier 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. Accédez à VCN-2, où se trouve la machine virtuelle source.
2. Cliquez sur Acheminer.
3. Cliquez sur Table de routage par défaut pour VCN-2.
Remarque : 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 d'interface réseau virtuelles ou des adresses IP spécifiques, ainsi qu'à l'aide du routage par ressource. Cependant, cela n'est pas pertinent pour notre tutoriel. Pour plus d'informations, reportez-vous à 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 dans Type de cible.
2. Saisissez 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 essayez à nouveau d'installer telnet.
1. Exécutez la commande suivante .
```
sudo yum install telnet
```
2. L'installation est terminée (Complete !).
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.
Analyse terminée. Vérifions le résultat du chemin aval.
1. Le statut indique désormais Reachable.
2. Le saut 2 a maintenant réussi car nous avons ajouté une règle de routage envoyant du trafic à la passerelle NAT.
3. Cliquez sur Visualiser les informations de schéma.
4. Vous pouvez voir que le statut de routage du saut 2 est désormais Transféré (auparavant, il n'y avait aucun routage).
En vérifiant le chemin de retour, nous pouvons voir qu'il est également réussi.

Tâche 4 : analyser les journaux de flux VCN

Les journaux de flux VCN offrent une couche supplémentaire de visibilité sur le comportement du trafic. Ce service vous permet d'effectuer une analyse descendante du trafic réel sur chaque carte d'interface réseau virtuelle, en indiquant si elle a été acceptée ou rejetée en fonction de la liste de sécurité et des règles de groupe de sécurité réseau, ce qui vous aide à résoudre les problèmes de sécurité.

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

Exemple

Nous utiliserons l'architecture suivante comme exemple.

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

Nous avons rencontré un problème de réseau et nous allons utiliser les journaux de flux VCN 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.

Connectez-vous à VM-2 et exécutez la commande suivante pour vérifier si le site Web est exécuté 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 verrez que la demande échoue. Dans les étapes suivantes, nous allons utiliser les journaux de flux VCN-2 pour examiner la cause.
Maintenant, activons les journaux. Nous commencerons par créer un filtre de capture, qui est un ensemble de règles simple utilisé dans OCI pour déterminer le trafic réseau à capturer pour la journalisation ou mis en miroir vers les points d'accès de test virtuel (VTAP).
1. Connectez-vous à la console OCI et assurez-vous que vous êtes dans la bonne région.
2. Cliquez sur le menu hamburger (≡) en haut à gauche.
3. Cliquez sur Fonctions de réseau.
4. Cliquez sur Filtres de capture.
Cliquez sur Créer un filtre de saisie.
1. Entrez vcn-2-private-sn-logs dans le champ Nom.
2. Sélectionnez Filtre de capture de journal de flux dans le champ Type de filtre.
3. Définissez le taux d'échantillonnage sur 100 %. Cela définit le pourcentage de flux réseau à capturer, dans ce cas, nous voulons enregistrer tout le trafic.
1. Conservez les valeurs par défaut de tous les autres paramètres.
2. Cliquez sur Créer un filtre de saisie.
Une fois le filtre de capture créé, cliquez sur Copier pour copier son OCID, comme vous en aurez besoin dans les étapes suivantes.
Nous sommes maintenant prêts à activer les journaux.
1. Accédez à VCN-2.
2. Ouvrez le sous-réseau privé, où réside VM-2.
3. Cliquez sur Surveillance.
4. Faites défiler la page jusqu'à la section Logs.
5. Cliquez sur les trois points (•••) en regard de la catégorie Journaux de flux.
6. Cliquez sur Activation du journal.
1. Sélectionnez Groupe de journaux. Si vous n'en avez pas déjà un, créez un groupe de journaux.
2. Le champ Nom de journal est renseigné automatiquement.
3. Collez l'OCID de filtre de capture copié précédemment.
4. Cliquez sur Activation du journal.
Les journaux de flux sont désormais 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
```
Revenez à la section Logs et cliquez sur Log Name (Nom de 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 de journal pour appliquer des filtres avancés et réduire les résultats du journal.
1. Appliquez les filtres suivants pour qu'ils correspondent à notre connexion de test.
  - 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 la plage horaire dans Filtrer par heure si nécessaire ou conservez-la comme valeur par défaut 5 dernières minutes.
3. Cliquez sur Rechercher.
1. Vérifiez 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 afficher 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 connexion : comme 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 de REJECT. Cela confirme la cause première 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 avez deux options :
- Liste de sécurité : application au niveau du sous-réseau, ce qui signifie que toutes les cartes d'interface réseau virtuelles d'un sous-réseau sont soumises au même ensemble de listes de sécurité.
- GNS : appliqué au niveau de la ressource (niveau de la carte d'interface réseau virtuelle).
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. Accédez à 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 hébergé sur VM-2.
3. Pour résoudre ce problème, cliquez sur Ajouter des règles entrantes.
1. Entrez 10.0.0.0/16 en tant que CIDR source (il s'agit du CIDR pour VCN-1).
2. Sélectionnez TCP comme protocole IP.
3. Définissez 80 sur Port de destination.
4. Cliquez sur Ajouter des règles entrantes.
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 que précédemment pour effectuer une nouvelle recherche.
1. Appliquez les filtres suivants pour qu'ils correspondent à notre connexion de test.
  - 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 la plage horaire si nécessaire ou conservez-la comme valeur par défaut (5 dernières minutes).
3. Cliquez sur Rechercher.
1. Vérifiez 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 afficher 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 connexion : tels que l'adresse IP source, l'adresse IP de destination et le numéro de port.
3. Action : indique comment le trafic a été géré. Après avoir résolu le problème, vous devez maintenant voir que le trafic est ACCEPT.

Etapes suivantes

Nous avons exploré comment résoudre les problèmes de réseau fondamentaux dans OCI en examinant l'architecture, le routage 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 des cas d'utilisation plus réels.

Accusés de réception

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

Ressources de formation supplémentaires

Explorez d'autres ateliers sur le site docs.oracle.com/learn ou accédez à d'autres contenus d'apprentissage gratuits sur le canal Oracle Learning YouTube. En outre, visitez le site education.oracle.com/learning-explorer pour devenir un explorateur Oracle Learning.

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

Informations relatives au titre et au copyright

Troubleshoot Basic Network Issues in Oracle Cloud Infrastructure

G40742-01

Oracle et/ou ses affiliés.