보조 IP 주소를 사용하여 EC2 Linux 인스턴스에 연결할 때 발생하는 문제를 해결하려면 어떻게 해야 하나요?

최종 업데이트 날짜: 2021년 4월 28일

보조 IP 주소를 사용하여 SSH를 통해 인스턴스에 연결하려면 인스턴스가 다음 사전 요구 사항을 충족하는지 확인합니다.

• 프라이빗 서브넷에서 인스턴스를 시작한 경우 보조 프라이빗 IP 주소를 사용하여 SSH를 통해 연결합니다. 네트워크 인터페이스에 대한 서브넷의 IPv4 CIDR 블록 범위에서 보조 IPv4 주소를 선택해야 합니다.
• 퍼블릭 서브넷에서 인스턴스를 시작한 경우 인스턴스에 연결된 보조 프라이빗 IP 주소에 탄력적인 IP 주소를 할당합니다.
• EC2 인스턴스의 운영 체제가 보조 프라이빗 IP 주소를 인식하는지 확인합니다.
  Amazon Linux의 경우 보조 프라이빗 IPv4 주소를 인식하도록 인스턴스에 운영 체제 구성을 참조하세요.
  Ubuntu의 경우 Ubuntu EC2 인스턴스에서 보조 네트워크 인터페이스가 작동하게 하려면 어떻게 합니까?를 참조하세요.
  다른 Linux 배포의 경우 해당 배포에 대한 네트워크 구성 설명서를 참조하세요.

인스턴스가 이러한 사전 요구 사항을 충족하는 경우 다음을 수행하여 SSH를 통한 연결 문제를 해결합니다.

1. 자세한 메시지 표시와 함께 SSH를 통해 연결하여 오류를 식별합니다.
2. 시스템 로그를 검토하여 오류를 찾습니다.

참고: 시작하기 전에 일반 연결 사전 요구 사항을 검토하세요.

자세한 지침은 SSH를 사용하여 Amazon EC2 Linux 인스턴스에 연결할 때 발생하는 문제를 해결하려면 어떻게 해야 합니까?를 참조하세요.

위의 단계를 수행해도 문제가 해결되지 않으면 인스턴스의 시스템 로그를 검토하세요. 인스턴스의 로그에 액세스하는 방법은 두 가지입니다.

방법 1: EC2 직렬 콘솔 사용

Linux용 EC2 직렬 콘솔을 활성화한 경우 이 콘솔을 사용하여 지원되는 Nitro 기반 인스턴스 유형의 문제를 해결할 수 있습니다. 직렬 콘솔을 사용하면 부팅 문제, 네트워크 구성 및 SSH 구성 문제를 해결할 수 있습니다. 직렬 콘솔은 작동 중인 네트워크 연결 없이 인스턴스에 연결됩니다. Amazon EC2 콘솔 또는 AWS 명령줄 인터페이스(AWS CLI)를 사용하여 직렬 콘솔에 액세스할 수 있습니다.

직렬 콘솔을 사용하기 전에 계정 수준에서 액세스 권한을 부여하고 IAM 사용자에게 액세스 권한을 부여하는 AWS Identity and Access Management(IAM) 정책을 생성해야 합니다. 또한 직렬 콘솔을 사용하는 모든 인스턴스에는 암호 기반 사용자가 한 명 이상 포함되어야 합니다. 인스턴스에 연결할 수 없고 직렬 콘솔에 대한 액세스를 구성하지 않은 경우 방법 2의 지침을 따릅니다. Linux용 EC2 직렬 콘솔 구성에 대한 자세한 내용은 EC2 직렬 콘솔에 대한 액세스 구성을 참조하세요.

참고: AWS CLI 명령을 실행할 때 오류가 발생하는 경우 최신 버전의 AWS CLI를 사용하고 있는지 확인하세요.

방법 2: 복구 인스턴스를 사용하여 로그에 액세스

경고: 이 절차를 시작하기 전에 다음을 주의하세요.

• 인스턴스를 중지하면 인스턴스 스토어 볼륨에 있는 데이터가 모두 지워집니다. 보관할 인스턴스 스토어 볼륨에 데이터를 모두 백업해야 합니다. 자세한 내용은 인스턴스의 루트 디바이스 유형 확인을 참조하세요.
• 인스턴스를 중지한 다음 다시 시작하면 인스턴스의 퍼블릭 IP 주소가 변경됩니다. 모범 사례로서 외부 트래픽을 인스턴스로 라우팅할 때는 퍼블릭 IP 주소 대신 탄력적 IP 주소를 사용하는 것이 좋습니다.

1.    Amazon EC2 콘솔을 엽니다.

2.    탐색 창에서 [인스턴스(Instances)]를 선택한 다음, 연결하려는 인스턴스를 선택합니다.

3.    [인스턴스 상태(Instance State)], [인스턴스 중지(Stop Instance)], [중지(Stop)]를 차례로 선택합니다. 인스턴스 ID(Instance ID)를 기록해 둡니다.

참고: 새 EC2 경험을 사용하지 않는 경우 연결하려는 인스턴스를 선택합니다. 그런 다음 [작업(Actions)], [인스턴스 상태(Instance State)], [중지(Stop)], [중지(Stop)]를 선택합니다.

4.    중지된 인스턴스에서 루트 Amazon Elastic Block Store(Amazon EBS) 볼륨을 분리합니다. 루트 EBS 볼륨의 디바이스 이름을 기록해 둡니다. 디바이스 이름은 문제 해결 후 볼륨을 다시 연결할 때 필요합니다.

5.    원래 인스턴스와 동일한 가용 영역에서 새 EC2 인스턴스를 시작합니다. 새 인스턴스가 "복구" 인스턴스가 됩니다.

참고: Amazon Linux 2 인스턴스를 복구 인스턴스로 사용하는 것이 가장 좋습니다. Amazon Linux 2 인스턴스를 사용하면 EBS 볼륨의 UID 또는 이름이 동일하기 때문에 복구 인스턴스가 연결된 EBS 볼륨에서 부팅되지 않습니다.

6.    복구 인스턴스를 시작한 후에 탐색 창에서 [볼륨(Volumes)]을 선택한 다음 손상된 인스턴스의 분리된 루트 볼륨을 선택합니다.

참고: 손상된 인스턴스의 루트 볼륨에 Marketplace 코드가 있고 복구 인스턴스가 Amazon Linux가 아닌 경우, 루트 EBS 볼륨을 연결하기 전에 복구 인스턴스를 중지하세요. 예를 들어 공식 RHEL 또는 CentOS AMI에서 인스턴스를 시작한 경우 인스턴스에 Marketplace 코드가 있을 수 있습니다.

7.    [작업(Actions)], [볼륨 연결(Attach Volume)]을 선택합니다.

8.    탐색 창에서 [인스턴스(Instances)]를 선택한 다음 복구 인스턴스를 선택합니다.

9.    [인스턴스 상태(Instance state)], [인스턴스 시작(Start instance)]을 선택합니다.

참고: 새 EC2 Experience 콘솔을 사용하지 않는 경우 연결하려는 인스턴스를 선택한 다음 [작업(Action)], [인스턴스 상태(Instance State)], [시작(Start)]을 선택합니다.

11.    SSH를 통해 복구 인스턴스에 연결합니다.

12.    다음 명령을 실행하여 EBS 볼륨이 복구 인스턴스에 성공적으로 연결되었는지 확인합니다. 다음 명령에서 볼륨은 /dev/sdf로 연결됩니다.

$ lsblk

다음은 명령 출력에 대한 예입니다.

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.    다음 명령을 사용하여 마운트 지점 디렉터리를 만든 다음, 연결된 볼륨을 복구 인스턴스에 마운트합니다. 다음 예제에서 마운트 지점 디렉터리는 /test입니다.

$ sudo su
$ mkdir /test
$ mount /dev/xvdf1 /test
$ df -h
$ cd /test

14.    시스템 로그와 액세스 시도 시간에 타임스탬프가 지정된 인증 관련 로그에서 오류를 찾습니다.

Amazon Linux, RHEL 및 CentOS

$ sudo cat /test/var/log/messages

Amazon Linux, RHEL, CentOS(인증 관련 문제)

$ sudo cat /test/var/log/secure

Ubuntu, Debian(시스템 로그)

$ sudo cat /test/var/log/syslog

Ubuntu, Debian(인증 관련 문제)

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

15.    구성을 검토하고 오류를 해결한 후 EBS 루트 볼륨을 마운트 해제하고 복구 인스턴스에서 분리합니다.

$ umount /test

16.    볼륨을 원본 인스턴스에 연결합니다. 디바이스 이름은 /dev/xvda입니다.