동일한 보안 그룹(예: Group-A)에서 서로 통신해야 하는 여러 인스턴스, 특히 포트 4369를 실행하고 있습니다.
각 인스턴스에는 서로 다른 탄력적 IP가 있습니다.
보안 그룹은 TCP:4369 소스:sg-XXXXX(그룹-A)를 통한 인바운드 트래픽을 허용하도록 구성됩니다.
그러나 인스턴스는 내부 IP(10.xxx.xxx.xx) 또는 Amazon Public DNS: ec2-ELASTIC-IP.compute-1.amazonaws.com을 통해서만 서로 통신할 수 있습니다(분명히 Amazon은 이를 내부 IP로 변환합니다). .
탄력적 IP를 사용하면 작동하지 않습니다. 탄력적 IP를 가리키는 자체 FQDN을 사용하면 작동하지 않습니다.
인바운드 규칙의 소스를 sg-XXXXX(그룹-A)에서 0.0.0.0으로 변경하면 자체 FQDN 및 탄력적 IP와 함께 작동합니다. 그러나 우리는 보안 문제 때문에 이것을 사용하지 않을 것입니다. 인바운드 규칙을 제거하면 내부 IP를 사용해도 아무것도 작동하지 않습니다.
그렇다면 내 FQDN을 사용하려면 어떻게 해야 합니까? (worker-1.company.com -> 탄력적 IP) 이는 훨씬 더 읽기 쉽고 관리하기 쉽습니다.
답변1
설명하신 동작은 정상입니다. 탄력적 IP를 통해 인스턴스 간에 통신할 때 sg-xxxxxxxx 소스에 의존하는 보안 그룹 구성의 목적으로 보안 그룹 내 시스템의 ID를 실제로 설정할 수 없기 때문입니다. 주소를 변환하면 (아마도) 중간 하드웨어를 통해 트래픽이 전송되고 트래픽이 더 이상 시작된 것으로 간주되지 않기 때문입니다.곧장인스턴스에서.
해결책은 특정 IP 주소를 가리키는 A 레코드 대신 공용 DNS 레코드를 가리키는 CNAME 레코드를 사용하여 DNS에서 호스트 이름을 지정하는 것입니다.
company.com DNS 영역에서:
worker-1 IN CNAME xx-xx-xx-xx.compute-1.amazonaws.com.
이제 Worker-1.company.com은 내부에서 쿼리하면 개인 IP로 확인되고 외부에서는 공용 IP로 확인됩니다.
답변2
완벽하지는 않지만 FQDN에서 각 인스턴스의 호스트 파일에 있는 개인 IP로 명시적인 매핑을 추가할 수 있습니다. 따라서 코드는 FQDN을 사용하지만 네트워킹은 실제로 개인 통신을 사용합니다(어쨌든 더 안전합니다).
이는 작고 상대적으로 고정된 인스턴스 세트가 있는 경우 합리적인 옵션입니다. 가능하다면 이 프로세스를 자동화해야 합니다.
Amazon의 DNS인 Route 53을 서비스로 사용할 수도 있습니다. FQDN을 인스턴스의 퍼블릭 DNS 이름에 매핑합니다. EC2 내부에서는 개인 IP에 매핑됩니다. Route 53 API를 사용하여 이를 자동화해야 합니다.