EC2 Elastic IP는 인스턴스의 사설 VPN 주소가 아닙니다

인스턴스에는 사설 주소가 있고 Elastic IP가 여기에 연결되며, 그 공용 /32에 대한 경로가 두 가지가 같은 것이 되기를 바라며 VPN에 추가됩니다. 그러나 같아지지 않습니다. Elastic IP는 게스트 외부에서 인터넷 게이트웨이가 인터넷 경로를 타는 트래픽에 수행하는 변환입니다. 게스트의 운영 체제는 그 주소가 인터페이스에 구성된 것을 절대 보지 못합니다. 터널 인터페이스에 추가해도 상위 변환이 재현되지 않으며 같은 시스템에 두 번째의 상충하는 정체성이 생깁니다.

두 주소, 하나의 인스턴스

인스턴스의 네트워크 인터페이스는 VPC 내부의 사설 주소를 가지며, 그것이 게스트가 아는 주소입니다. Elastic IP는 같은 인터페이스에 연결되어 있지만 매핑의 공용 쪽에 있습니다.

인터넷을 통해 인스턴스에 도달하는 모든 것은 사설 주소로 변환되어 도착합니다. 인스턴스가 인터넷으로 보내는 모든 것은 Elastic IP를 출발지로 하여 나가며, 이 역시 그 변환 때문입니다.

게스트 내부에는 주소가 하나 있습니다. 외부에는 둘이 있습니다. 이 비대칭이 이 분야의 혼란 대부분을 설명합니다. 게스트는 게이트웨이가 무엇을 변환하는지 구성할 수 없습니다. 실제로 가진 주소에서만 응답할 수 있습니다.

인터넷 게이트웨이가 실제로 하는 일

AWS의 AWS의 인터넷 게이트웨이 문서에서는 이 배치를 설명합니다. 인스턴스는 자신의 사설 IPv4 주소를 인지하고 있으며, 게이트웨이는 인터넷 경로의 트래픽에 대해 해당하는 공용 IPv4 또는 Elastic IP 변환을 제공합니다.

이것은 네트워크 주소 변환이며 별칭이 아닙니다. 매핑은 게이트웨이가 유지하고 연결에 묶여 있으며, 그것을 통과하는 패킷에만 적용됩니다. 연결을 제거하면 게스트가 아무것도 눈치채지 못한 채 공용 정체성이 사라집니다.

그래서 공용 /32로 지정된 사설 VPN 패킷은 게스트의 로컬 주소로 가는 사설 패킷으로 재해석되지 않습니다. 패킷은 일치하는 경로를 따르고, 그 경로가 패킷을 인터넷 게이트웨이로 보내며, 게이트웨이의 동작은 경로가 양방향으로 허용되는지에 달려 있습니다.

터널 인터페이스 방법이 실패하는 이유

Elastic IP를 터널 인터페이스에 할당하면 게스트는 공용 주소를 로컬로 취급해야 합니다. 이제 두 가지가 같은 주소를 주장합니다. 인터넷 경로에서의 게이트웨이 변환과 터널 내부의 로컬 인터페이스입니다. 반환 트래픽에는 어느 것이 적용되는지에 대한 일관된 답이 없습니다.

작동하는 것처럼 보여도 그 설계는 진짜 질문을 숨겼습니다. 클라이언트는 터널을 통해 사설 주소에 도달하거나 인터넷을 통해 공용 엔드포인트에 도달하며, 두 경로는 보안 그룹, 로깅, 실패 방식이 서로 다릅니다.

주소는 결코 문제가 아니었습니다. 경로 선택이 문제였습니다.

세 가지 목표, 세 가지 설계

목표가 공용 VPN 엔드포인트라면 Elastic IP가 올바른 도구입니다. 원격 피어가 인터넷을 통해 연결하고 암호화된 전송이 인스턴스에서 종료됩니다. 그다음 내부 애플리케이션 트래픽은 사설 주소를 사용합니다.

목표가 애플리케이션에 대한 사설 접근이라면 목적지는 사설 주소 또는 그것으로 확인되는 사설 DNS 이름이며, VPN 경로, 보안 그룹, 반환 경로가 모두 일치해야 합니다. 그 설계에는 Elastic IP가 전혀 등장하지 않습니다.

목표가 VPN 사용자를 위한 안정적인 공용 이그레스 정체성이라면 그것은 이그레스 측의 NAT 설계이며 클라이언트 터널의 주소가 아닙니다. 비슷하게 들리는 세 목표는 세 가지 다른 다이어그램을 만들고, 그중 Elastic IP를 새 위치에 두는 것은 하나뿐입니다.

선택한 경로를 검증하십시오

사설 접근의 경우 VPN 경로가 사설 접두사를 포함하는지, VPC 라우팅 테이블이 트래픽을 터널로 되돌리는지, 보안 그룹이 클라이언트 출발지를 허용하는지, 클라이언트 자체 방화벽이 응답을 허용하는지 확인하십시오. 그런 다음 ping 대신 실제 요청 하나를 시험하십시오.

공용 접근의 경우 클라이언트의 인터넷 이그레스, 공용 진입점의 라우팅과 보안 정책을 확인하십시오. VPN 클라이언트가 터널을 통해 공용 엔드포인트에 도달할 수 있는지는 터널의 이그레스와 방화벽 규칙에 달려 있으며 Elastic IP 연결과는 무관합니다.

공용 호스트 이름이 양쪽에서 작동해야 한다면 VPN 클라이언트에는 사설 주소로, 나머지 모두에는 공용 주소로 응답하는 DNS 설계를 사용하고, 인증서는 주소가 아니라 이름에 대해 유효하게 유지하십시오. 작업 순서는 목표를 이름 붙이고, 그에 속한 주소를 고르고, 경로와 정책과 요청 하나를 검증하는 것입니다.