[AWS VPC] 23. 라우팅 테이블 - Edge Associations

ㅇ Edge Associations?

    > 기존의 라우팅 테이블에서는 서브넷에서 나가는 경로를 지정하는 데에 사용되었는데, Edge Associations를 통해 모든 수신 및 발신 트래픽을 IGW 또는 VGW에서 특정 인스턴스의 ENI로 라우팅 할 수 있도록 하는 서비스

    > 예를 들어, 방화벽 기능을 수행하는 인스턴스가 존재하고 모든 서비스는 해당 방화벽을 거쳐서 IGW 밖으로 나가거나 들어오는 기능을 수행하고 싶을 때,

      IGW 밖으로 나가는 신호는 라우팅 테이블로 제어하고, IGW 안으로 들어오는 신호는 Edge Associations를 통해 제어가 가능

 

ㅇ 소스/대상 확인 변경

    > 최종 경로에 해당하는 인스턴스는 "소스/대상 확인 변경"을 비활성화 시켜주어야 함

 

    > 최종 경로 인스턴스 선택 후, [작업] - [네트워킹] - [소스/대상 확인 변경] 선택

 

    > 비활성화 상태로 변경

 

ㅇ Edge Associations 사용

    > 다음과 같이 구성

        * 각각의 Subnet은 별도의 라우팅 테이블을 소유하고, 하단부 VPC(CIDR: 11.0.0.0/16)는 Edge Associations를 위한 라우팅 테이블을 추가로 필요

          즉, 이번 실습에서는 총 4개의 라우팅 테이블(VPC 1: 1개 / VPC 2: 3개) 필요

        * 각각의 인스턴스를 포함하고 있는 라우팅 테이블은 인터넷 게이트웨이와 연결되어 있어야함

 

    > bastion에서 public2의 공인 IP로 ping 명령어를 수행했을 경우, 정상적으로 패킷이 오가는 것을 확인 가능

ping (public2 공인 IP 주소)

tcpdump src (bastion 공인 IP 주소)

 

    > 아무 서브넷도 연결되어 있지 않는 라우팅 테이블의 [Edge Associations] - [Edidt edge associations] 선택

 

    > 해당 VPC에 있는 인터넷 게이트웨이 선택

 

    > 비어있던 Edge Assocations에 인터넷 게이트웨이가 채워져있는 것을 확인 가능

 

    > 이후 [라우팅] 탭에서 라우팅 설정

        * public2로 들어온 패킷을 public1으로 전송(CIDR: 11.0.2.0/24(public2) -> 대상: eni-???(public1))

    > 위의 설정을 마치고 나면 public2로의 접속이 불가능해짐

        * 접속을 위한 SSH가 public2가 아닌, public1으로 전송되기 때문

    > 다시 bastion에서 public2의 공인IP로 ping 명령어를 실행하면, 전송은 되지만 응답은 못받음

        bastion > public2를 수행했지만, Edge Associations로 인해 bastion > public1이 진해되었음을 예측 가능

 

    > 이를 확인하기 위해 public1로 들어오는 SSH 명령어 확인하면, 정상적으로 패킷을 받아오는 것을 알 수 있음

tcpdump | grep -v ssh

 

ㅇ 결과

    > bastion에서 public2로 보내는 신호를 Edge Associations를 통해 public2가 아닌, public1로 전송이 가능해짐

        (IGW에서 들어오는 트래픽을 특정 Instance로 지정 가능)