아마존 EC2 리눅스 인스턴스로 연결할 때 보조 IP 주소를 사용하지 못하는 이유는 무엇인가요?

6분 분량

보조 IP 주소를 사용할 때 Amazon Elastic Compute Cloud(Amazon EC2) 리눅스 인스턴스로 연결하지 못하는 이유를 알고 싶습니다.

간략한 설명

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

사설 서브넷에서 인스턴스를 실행하는 경우 SSH를 통해 보조 사설 IP 주소로 연결하세요. 보조 IPv4 주소는 네트워크 인터페이스용 서브넷 IPv4 CIDR 블록 범위에서 선택하세요.
공용 서브넷에서 인스턴스를 실행하는 경우 탄력적 IP 주소를 인스턴스 보조 사설 IP 주소로 할당하세요.
EC2 인스턴스 운영 체제가 보조 사설 IP 주소를 인식하는지 확인하세요. 아마존 리눅스의 경우 보조 사설 IPv4 주소를 인식하려면 인스턴스의 운영 체제 구성을 참조하세요. 우분투의 경우 우분투 EC2 인스턴스에서 보조 네트워크 인터페이스를 작동하려면 어떻게 해야 하나요?를 참조하세요. 기타 리눅스 배포판의 경우 해당 배포판의 네트워크 구성 설명서를 참조하세요.

인스턴스가 이러한 사전 요구 사항을 충족하는 경우 다음 단계에 따라 SSH를 사용하여 연결 문제를 해결하세요.

상세 메시지 기능을 켠 상태에서 SSH를 사용하여 연결한 후 오류를 확인하세요.
시스템 로그를 검토하여 오류를 찾습니다.
네트워크 구성 파일을 검토합니다.

참고: 인스턴스 및 데이터는 백업하여 유지하는 것이 좋습니다. 문제 해결을 시도하기 전 AMI를 생성하거나 또는 Amazon Elastic Block Store(Amazon EBS) 볼륨 스냅샷을 생성해둡니다.

해결 방법

참고: AWS Command Line Interface(AWS CLI) 명령 실행 시 오류가 발생하는 경우 사용하는 AWS CLI가 최신 버전인지 확인하세요. 또한 시작하기에 앞서 일반 연결 관련 사전 요구 사항을 검토하세요.

상세 메시지 기능을 켠 상태에서 SSH를 통해 연결한 후 오류를 확인합니다.

자세한 지침은 SSH로 아마존 EC2 리눅스 인스턴스에 연결 시 발생하는 문제는 어떻게 해결해야 하나요?를 참조하세요.

네트워크 구성 파일 및 시스템 로그를 검토하여 오류를 검토하세요.

문제가 해결되지 않을 시 인스턴스의 시스템 로그를 검토하세요. 다음 중 하나의 방법을 사용하여 로그에 액세스한 후 인스턴스와 관련된 추가 문제를 해결하세요.

방법 1 기본 IP 주소로 인스턴스에 연결

SSH로 기본 IP 주소를 사용하여 인스턴스에 액세스합니다. 액세스 후에 보조 네트워크 인터페이스 네트워크 상태와 구성 사항을 확인합니다. 이 작업을 수행하려면 다음 명령을 실행합니다.

ifconfig 출력을 통해 인스턴스의 보조 네트워크 인터페이스가 작동 상태인지 확인합니다.

$ ifconfig -a

다음 명령을 실행합니다.

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

참고: 이 예시의 보조 네트워크 인터페이스는 eth1입니다. 해당 이름을 보조 네트워크 인터페이스 이름으로 변경하세요.

보조 네트워크 인터페이스 구성 파일을 검토하고 모든 매개변수를 검토합니다. 예를 들어, 모든 MAC 주소, 보조 IP 주소, 보조 인터페이스 이름을 확인합니다. 일치하지 않는 부분이 발견되면 올바른 세부 정보로 업데이트하여 해당 파일을 편집합니다. 다음 명령 중 하나를 실행합니다.

리눅스, RHEL, CentOS.

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

우분투

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

다음 명령을 실행하여 네트워크 서비스를 다시 시작합니다.

$ sudo service network restart

문제가 해결되지 않을 경우 시스템 로그 및 인증 관련 로그에서 액세스가 시도된 기간을 검토합니다.

방법 2 아마존 EC2 시리얼 콘솔을 통해 인스턴스로 액세스

SSH를 통해 기본 IP 주소로 인스턴스에 액세스할 수 없는 경우 리눅스용 아마존 EC2 직렬 콘솔을 사용합니다. 지원 되는 니트로 형 및 베어 메탈 인스턴스 유형 문제를 해결하기 위해 아마존 EC2 직렬 콘솔을 사용할 수 있습니다. 아마존 EC2 직렬 콘솔을 사용하기 전 리눅스 인스턴스용 아마존 EC2 직렬 콘솔 검토 및 아마존 EC2 직렬 콘솔 엑세스 구성을 시행합니다.

방법 3 복구 인스턴스를 통해 네트워크 구성 파일과 로그에 액세스

**중요:**이 방법을 시도하기 전 다음 제한 사항에 유의하세요.

인스턴스를 중지할 경우 인스턴스 스토어 볼륨의 모든 데이터가 삭제됩니다. 따라서 보관하고자 하는 인스턴스 스토어 볼륨의 모든 데이터를 백업해두어야 합니다. 자세한 내용은 인스턴스의 루트 디바이스 유형 결정를 참조하세요.
인스턴스가 Amazon EC2 Auto Scaling 그룹의 일부인지 확인합니다. Amazon EMR, AWS CloudFormation 또는 AWS Elastic Beanstalk로 실행한 인스턴스의 경우 AWS Auto Scaling 그룹에 속합니다. 이 사용 사례의 경우에서 인스턴스를 중지하면 인스턴스가 종료될 수 있습니다. 인스턴스 종료는 오토 스케일링 그룹의 인스턴스 축소 보호 설정에 따라 달라집니다. 인스턴스가 오토 스케일링 그룹에 속한 경우 문제 해결 단계를 시작하기 전 인스턴스를 오토 스케일링 그룹에서 일시적으로 제거해야 합니다.
인스턴스 중지 후 재시작할 경우 인스턴스가 공인 IP 주소를 변경합니다. 공인 IP 주소 대신 탄력적 IP 주소를 사용하여 외부 트래픽을 인스턴스로 라우팅하는 것이 가장 좋습니다.
인스턴스 종료 동작이 **Terminate(종료)**로 설정되어 있는지 확인합니다. 즉 운영 체제의 shutdown(종료) 또는 power off(전원 끄기) 명령을 사용할 경우 인스턴스가 종료됩니다. 이를 방지하려면 인스턴스 종료 동작을 변경합니다.

다음 단계를 적용하여 복구 인스턴스를 사용하여 네트워크 구성 파일에 액세스합니다.

아마존 EC2 콘솔을 여세요.

2. 탐색 창에서 인스턴스를 선택한 다음 연결하려는 인스턴스를 선택합니다.

인스턴스 상태를 선택한 다음 인스턴스 중지를 선택합니다.
중지를 선택한 다음 인스턴스 ID를 기록해 둡니다.

참고: 만약 새로운 아마존 EC2 환경을 사용하지 않는 경우 연결하려는 인스턴스를 선택하세요. 작업, 인스턴스 상태, 중지를 선택한 다음 다시 중지를 선택합니다.

중지된 인스턴스에서 루트 EBS 볼륨을 분리합니다. 루트 EBS 볼륨의 디바이스 이름을 기록해 둡니다. 검사가 끝난 후 볼륨을 다시 연결할 때 디바이스 이름이 필요합니다.
원본 인스턴스와 동일한 가용 영역 (AZ)에서 새 EC2 인스턴스를 실행합니다. 이제 새 인스턴스를 복구 인스턴스로 사용할 수 있습니다.

참고: 아마존 리눅스 2 인스턴스를 복구 인스턴스로 사용하는 것이 가장 좋습니다. 이렇게 하면 EBS 볼륨 UUID 또는 이름이 동일하므로 연결된 EBS 볼륨에서 복구 인스턴스를 부팅할 수 없습니다.

복구 인스턴스를 실행한 후 탐색 창에서 볼륨을 선택합니다. 그런 다음 손상 인스턴스의 분리된 루트 볼륨을 선택합니다.

참고: AWS 마켓플레이스 코드가 있고 아마존 리눅스 인스턴스가 아닌 경우 인스턴스를 루트 EBS 볼륨을 연결하기 전에 복구 인스턴스를 중지해야합니다. 예를 들어 공식 RHEL 또는 CentOS AMI에서 인스턴스를 실행한 경우 인스턴스에 AWS 마켓플레이스 코드가 있을 수 있습니다.

작업을 선택한 다음 볼륨 연결을 선택합니다.
탐색 창에서 인스턴스를 선택한 다음 복구 인스턴스를 선택합니다.
인스턴스 상태를 선택한 다음 인스턴스 시작을 선택합니다.

**참고:**새로운 아마존 EC2 환경을 사용하지 않는 경우 연결할 인스턴스를 선택한 다음 작업을 선택합니다. 인스턴스 상태를 선택한 다음 시작을 선택합니다.

SSH를 통해 복구 인스턴스에 연결합니다.
다음 명령을 실행하여 복구 인스턴스에 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

다음 명령을 실행하여 마운트 포인트 디렉토리를 생성한 후 연결된 볼륨을 복구 인스턴스로 마운트합니다. 다음 예시의 마운트 포인트 디렉터리는 /test입니다.

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

참고: /dev/xvdf1 디바이스를 마운트할 때 UUID 중복과 관련된 문제가 발생할 경우 이전 명령을 수정한 후 명령을 다시 실행합니다.

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

시스템 로그 및 인증 관련 로그에서 오류를 찾습니다. 타임스탬프를 사용하여 액세스 시도 시간 관련 로그를 확인할 수 있습니다.

아마존 리눅스, RHEL, CentOS:

$ sudo cat /test/var/log/messages

아마존 리눅스, RHEL, CentOS(인증 관련 문제):

$ sudo cat /test/var/log/secure

우분투, 데비안(시스템 로그):

$ sudo cat /test/var/log/syslog

우분투, 데비안(인증 관련 문제):

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

이 문서의 방법 1이 제시한 보조 네트워크 인터페이스 파일을 검토하세요. 구성을 검토하고 오류를 해결을 완료한 후에는 EBS 루트 볼륨을 마운트 해제하고 복구 인스턴스에서 분리합니다.

$ umount /test

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