Pourquoi ne puis-je pas utiliser une adresse IP secondaire pour me connecter à mon instance Amazon EC2 Linux ?

Lecture de 8 minute(s)
0

Je souhaite savoir pourquoi je n’arrive pas à me connecter à mon instance Linux Amazon Elastic Compute Cloud (Amazon EC2) lorsque j'utilise une adresse IP secondaire.

Brève description

Avant d'utiliser une adresse IP secondaire pour vous connecter à l’instance via le SSH, vérifiez que l’instance remplit les conditions préalables suivantes :

Si l’instance remplit ces conditions préalables, suivez les étapes suivantes pour résoudre les problèmes de connexion via le SSH :

  1. Connectez-vous via le SSH en activant la messagerie verbeuse pour détecter l'erreur.
  2. Examinez les journaux système pour rechercher les erreurs.
  3. Vérifiez le fichier de configuration réseau.

Remarque : il est recommandé de conserver les sauvegardes d’instances et de données. Avant de résoudre le problème, créez une AMI ou créez des instantanés de volumes Amazon Elastic Block Store (Amazon EBS).

Résolution

**Remarque :**si des erreurs se produisent lorsque vous exécutez des commandes de l'interface de la ligne de commande AWS (AWS CLI), assurez-vous que vous utilisez la version AWS CLI la plus récente. Vérifiez également les conditions préalables générales de connexion avant de commencer.

Connectez-vous via le SSH à la messagerie verbeuse activée pour détecter des erreurs

Pour des instructions détaillées, consultez la section Comment résoudre les problèmes de connexion à mon instance Amazon EC2 Linux via le SSH ?

Vérifier le fichier de configuration réseau et les journaux système pour détecter des erreurs

Si le problème persiste, vérifiez les journaux système de l'instance. Utilisez l'une des méthodes suivantes pour accéder aux journaux et peaufiner le dépannage de l’instance.

Méthode 1 : Connectez-vous à l’instance via une adresse IP principale

1.Accédez à l’instance via le SSH en utilisant une adresse IP principale. Lorsque vous obtenez l'accès, vérifiez l'état du réseau et la configuration de l'interface réseau secondaire. Pour ce faire, exécutez les commandes suivantes.

Vérifiez la sortie ifconfig et assurez-vous que l'interface réseau secondaire de l’instance est activée :

$ ifconfig -a

Vous pouvez également exécuter la commande suivante :

$ ip a show < network interface name> up
Example Command:
$ ip a show eth1 up

Remarque : dans cet exemple, le nom de l'interface réseau secondaire est eth1. Remplacez-le par le nom de l’interface réseau secondaire.

2.Examinez le fichier de configuration de l'interface réseau secondaire et validez tous les paramètres. Vous pouvez, par exemple, vérifier les adresses MAC, les adresses IP secondaires et les noms des interfaces secondaires. Si vous constatez des écarts, modifiez le fichier et mettez-le à jour avec les bonnes informations. Exécutez l'une des commandes suivantes :

Linux, RHEL, CentOS :

$ sudo cat /etc/sysconfig/network-scripts/ifcfg-eth1

Ubuntu

sudo cat /etc/network/interfaces.d/51-eth1.cfg  
or  
sudo cat /etc/netplan/51-eth1.yaml

3.Exécutez la commande suivante pour redémarrer les services réseau :

$ sudo service network restart

Si le problème persiste, vérifiez les journaux système et les journaux liés à l'authentification pour la période pendant laquelle vous avez tenté d'accéder au réseau.

Méthode 2 : Utilisez Amazon EC2 Serial Console pour accéder à l’instance

Si vous ne parvenez pas accéder à l’instance via l’adresse IP principale sur SSH, alors utilisez Amazon EC2 Serial Console pour Linux. Amazon EC2 Serial Console peut servir à résoudre les problèmes liés aux types d'instances nitro et matériel nu pris en charge. Avant d'utiliser Amazon EC2 Serial Console, vérifiez Amazon EC2 Serial Console pour les instances Linux, puis configurez l'accès à Amazon EC2 Serial Console.

Méthode 3 : Utilisez une instance de secours pour accéder au fichier de configuration réseau ainsi qu’aux journaux

Important : avant d'utiliser cette méthode, notez les limitations suivantes :

Procédez comme suit pour accéder au fichier de configuration réseau via une instance de secours :

1.Ouvrez la console Amazon EC2.

2.Choisissez Instances dans le volet de navigation, puis sélectionnez l'instance à laquelle vous souhaitez vous connecter.

3.Choisissez État de l'instance, puis choisissez Arrêter l'instance.

4.Choisissez Arrêter, puis notez l'ID de l'instance.

**Remarque :**si vous n'utilisez pas la nouvelle expérience Amazon EC2, sélectionnez l'instance à laquelle vous souhaitez vous connecter. Choisissez Actions, État de l'instance, Arrêter, puis Arrêter à nouveau.

5.Dissociez les volumes EBS racine de l'instance arrêtée. Notez le nom de périphérique du volume EBS racine. Le nom de l'appareil est obligatoire lorsque vous reconnectez le volume après une enquête.

6.Lancez une nouvelle instance EC2 dans la même zone de disponibilité (AZ) que l'instance d'origine. La nouvelle instance devient votre instance de secours.

Remarque : il est recommandé d’utiliser une instance Amazon Linux 2 comme instance de secours. Cette solution ne permet pas à l'instance de secours de redémarrer à partir du volume EBS associé, car l'UUID ou le nom du volume EBS sont identiques.

7.Une fois l'instance de secours lancée, choisissez Volumes dans le volet de navigation. Sélectionnez ensuite le volume racine dissocié de l'instance altérée.

Remarque : si l’instance est dotée de codes AWS Marketplace et n'est pas une instance Amazon Linux, arrêtez l'instance de secours avant d'associer le volume EBS racine. Une instance peut disposer de codes AWS Marketplace si vous la lancez à partir d'une AMI RHEL ou CentOS officielle, par exemple.

8.Choisissez Actions, puis choisissez Associer un volume.

9.Sélectionnez Instances dans le volet de navigation, puis sélectionnez l'instance de secours.

10.Choisissez État de l'instance, puis choisissez Démarrer l'instance.

Remarque : si vous n'utilisez pas la nouvelle expérience Amazon EC2, sélectionnez l'instance à laquelle vous souhaitez vous connecter, puis choisissez Actions. Choisissez État de l'instance, puis choisissez Démarrer.

11.Connectez-vous à l'instance de secours via le SSH.

12.Exécutez la commande suivante pour vérifier que le volume EBS est correctement associé à l'instance de secours. Dans la commande suivante, le volume associé est /dev/sdf.

$ lsblk

Ci-dessous, un exemple de sortie de la commande :

NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
xvda    202:0    0   20G  0 disk
└─xvda1 202:1    0   20G  0 part /
xvdf    202:80   0  100G  0 disk

13. Exécutez les commandes suivantes pour créer un répertoire de points de montage, puis montez le volume associé sur l'instance de secours. Dans l'exemple suivant, le répertoire du point de montage est /test.

$ sudo su
$ mkdir /test
$ mount /dev/xvdf1 /test

Remarque : lorsque vous montez le périphérique /dev/xvdf1, si des problèmes liés aux UUID dupliqués se produisent, modifiez la commande précédente et exécutez-la à nouveau :

$ mount -o nouuid /dev/xvdf1 /test
$ df -h
$ cd /test

14.Localisez les erreurs dans les journaux système et dans les journaux liés à l'authentification. Vous pouvez utiliser l’horodatage pour vérifier dans les journaux les heures de tentatives d’accès :

Amazon Linux, RHEL, CentOS :

$ sudo cat /test/var/log/messages

Amazon Linux, RHEL, CentOS (problèmes liés à l'authentification) :

$ sudo cat /test/var/log/secure

Ubuntu, Debian (journaux système) :

$ sudo cat /test/var/log/syslog

Ubuntu, Debian (problèmes liés à l'authentification) :

$ sudo cat /test/var/log/auth.log

15.Vérifiez le fichier d'interface réseau secondaire donné dans la Méthode 1 du présent article. Après avoir vérifié les configurations et corrigé les erreurs, démontez puis dissociez le volume racine EBS de l'instance de secours.

$ umount /test

16.Associez le volume à l'instance d'origine. Le nom du périphérique est /dev/xvda.

Informations connexes

Connectez-vous à l’instance Linux via un client SSH

AWS OFFICIEL
AWS OFFICIELA mis à jour il y a 8 mois