☰

다른 계정의 VPC에 대한 VPC 피어링 연결을 통해 통신할 수 없는 이유는 무엇입니까?

tag-icon • tag-icon networking routing amazon-ec2
다른 계정의 VPC에 대한 VPC 피어링 연결을 통해 통신할 수 없는 이유는 무엇입니까?

저는 공개 웹 서버를 호스팅하는 유료 계정인 Amazon AWS 계정이 두 개 있습니다("유급의' 아래) 및 무료 등급 계정('무료" 아래). 각 인스턴스에는 자체 VPC에서 Amazon Linux를 실행하는 두 개의 EC2 인스턴스가 있으며, 각 인스턴스에는 서로 겹치지 않는 단일 서브넷이 있습니다. 저는 git bare 저장소에 액세스하는 것을 포함하여 계정 간에 파일을 쉽게 전송할 수 있기를 원했습니다.유급의~에서무료. 그래서 저는 VPC 피어링 연결에 대해 읽었으며 가이드를 올바르게 따라 VPC 간의 피어링 연결을 생성 및 수락한 다음 보안 그룹을 수정하고 각 VPC의 경로를 설정하여 다른 VPC의 서브넷에 액세스했다고 생각합니다.

다음은 기본 설정입니다.유급의계정:

VPC: 유료 VPC

피어링 연결 및 경로: 유료 피어링 연결 및 경로

보안 그룹: 유료 보안 그룹

그리고 여기에는 동일한 정보가 있습니다.무료계정:

VPC: 무료 VPC

피어링 연결 및 경로: 무료 피어링 연결 및 경로

보안 그룹: 무료 보안 그룹

내가 찾은 것은유급의계정에서 무료 계정의 인스턴스를 성공적으로 ping할 수 있습니다.

$ ip -f inet addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc pfifo_fast state UP qlen 1000
    inet 10.0.0.12/24 brd 10.0.0.255 scope global eth0
       valid_lft forever preferred_lft forever
$ ping 172.31.30.44
PING 172.31.30.44 (172.31.30.44) 56(84) bytes of data.
64 bytes from 172.31.30.44: icmp_seq=1 ttl=255 time=0.722 ms

하지만 다음에서 ping을 보낼 수 없습니다.무료에 계정유급의계정:

$ ip -f inet addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc pfifo_fast state UP group default qlen 1000
    inet 172.31.30.44/20 brd 172.31.31.255 scope global dynamic eth0
       valid_lft 3259sec preferred_lft 3259sec
$ ping 10.0.0.12
PING 10.0.0.12 (10.0.0.12) 56(84) bytes of data.
^C
--- 10.0.0.12 ping statistics ---
14 packets transmitted, 0 received, 100% packet loss, time 13308ms

이 구성으로 인해 호스트에 ping을 허용하지 않는 이유를 설명할 수 있는 사람이 있습니까?유급의호스트의 계정무료계정?

추가 정보를 제공해야 합니까(그렇다면 무엇)?

답변1

댓글에서이 답변네트워크 ACL에 관한 관련 없는 질문에 대해유급의계정의 VPC에서 AWS 네트워크 ACL의 사용을 linux iptables 명령으로 대체했다고 언급했습니다. 10년 전 이 서비스를 설정할 당시에는 내 서브넷 외부의 개인 주소와 통신하고 싶다고는 예상하지 못했습니다. 그래서 172.16.0.0/12에서 인바운드 연결을 끊었습니다. 그래서 내가 다가갈 수 있었던 거야무료~에서유급의, 그러나 그 반대는 아닙니다. 해당 iptables 블록을 제거하면 문제가 해결됩니다.

정말 당황스럽네요!

관련 정보