Share Your AWS re:Post Experience - Quick 3 Question Survey
Help us improve AWS re:Post! We're interested in understanding how you use re:Post and its impact on your AWS journey. Please take a moment to complete our brief 3-question survey.
Pourquoi ne puis-je pas utiliser une adresse IP secondaire pour me connecter à mon instance Amazon EC2 Linux ?
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 vous avez lancé l’instance dans un sous-réseau privé, alors utilisez l'adresse IP privée secondaire pour vous connecter via le SSH. Veillez à choisir l'adresse IPv4 secondaire dans la plage de blocs CIDR IPv4 du sous-réseau pour l'interface réseau.
- Si vous avez lancé les instances dans un sous-réseau public, alors attribuez une adresse IP Elastic à l'adresse IP privée secondaire de l’instance.
- Vérifiez que le système d'exploitation de l’instance EC2 reconnaît l'adresse IP privée secondaire. Pour Amazon Linux, consultez la section Configurer le système d'exploitation de votre instance pour reconnaître les adresses IPv4 privées secondaires. Pour Ubuntu, consultez la section Comment faire fonctionner l’interface réseau secondaire dans mon instance EC2 Ubuntu ? Pour les autres distributions Linux, consultez la documentation de configuration réseau de votre distribution.
Si l’instance remplit ces conditions préalables, suivez les étapes suivantes pour résoudre les problèmes de connexion via le SSH :
- Connectez-vous via le SSH en activant la messagerie verbeuse pour détecter l'erreur.
- Examinez les journaux système pour rechercher les erreurs.
- 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 :
- Si vous arrêtez une instance, vous effacerez les données sur les volumes de stockage d'instance. Vous devez sauvegarder les données sur le volume de stockage d'instance que vous souhaitez conserver. Pour plus d'informations, consultez la section Déterminer le type de périphérique racine de l’instance.
- Vérifiez si l’instance fait partie d'un groupe Amazon EC2 Auto Scaling. Si vous lancez l'instance avec Amazon EMR, AWS CloudFormation ou AWS Elastic Beanstalk, alors l’instance fait probablement partie d'un groupe AWS Auto Scaling. Dans ce cas d'utilisation, si vous interrompez l'instance, celle-ci peut s'arrêter définitivement. L'arrêt définitif d'une instance dépend des paramètres de protection mis à l'échelle de l'instance pour votre groupe Auto Scaling. Si votre instance fait partie d'un groupe Auto Scaling, alors supprimez temporairement l'instance du groupe Auto Scaling avant de suivre les étapes de résolution.
- Si vous arrêtez et redémarrez une instance, alors elle change d'adresse IP publique. Une bonne pratique consiste à utiliser une adresse IP Elastic au lieu d'une adresse IP publique pour acheminer le trafic externe vers votre instance.
- Vérifiez si l'arrêt de l'instance est défini sur le mode Terminer. Cela signifie que l'instance s’arrête si vous utilisez les commandes d'arrêt ou de mise hors tension du système d'exploitation. Pour éviter cela, modifiez le mode d'arrêt de l'instance.
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

Contenus pertinents
- demandé il y a 2 anslg...
- demandé il y a 2 moislg...
- demandé il y a un anlg...
- demandé il y a 3 moislg...
- demandé il y a un anlg...
- AWS OFFICIELA mis à jour il y a 4 ans
- AWS OFFICIELA mis à jour il y a 3 ans
- AWS OFFICIELA mis à jour il y a 2 ans
- AWS OFFICIELA mis à jour il y a un an