마지막 Transit Gateway 시작!


 

Scenario 3. AWS Transit Gateway 구현 (중앙 허브 라우팅)

 

# Scenario 3을 수행하기 전 check

* 검증 한계: AWS TGW 서비스 자체를 활용한 로컬 DB 직접 연결은 하드웨어 제약으로 인해 불가함.

* 불가 사유: TGW는 엔터프라이즈 전용 서비스로, 일반 PC 환경에서는 BGP 피어링 및 물리적 터널 종단이 불가함.

* 대체 검증: 실제 TGW 서비스 대신 EC2(Hub) + Tailscale 조합으로 대체하여 '중앙 집중형 라우팅' 로직을 검증함.

* 실무 포인트: TGW의 핵심인 'Hub-and-Spoke' 설계 원리와 VPC 라우팅 테이블 제어 방식은 EC2 기반 라우터를 통해 100% 동일하게 재현 및 실무 검증 가능함.

 

- 목적 : 다수의 서브넷/VPC 트래픽을 특정 HubEC2(Tailscale Subnet Router) 로 모아, 온프레미스(Local DB)와 통신하는 중앙 집중형 확장 구조를 검증함.

 

- 검증 가설 : "개별 노드에 VPN을 설치하지 않아도, Private 서브넷의 Route Table을 수정하여 트래픽을 Hub 노드로 리다이렉션하면 외부 네트워크와 통합 통신이 가능하다."


- 검증 항목 :

  • EC2의 서브넷 라우터(Subnet Router) 설정 및 트래픽 중계 여부 확인
  • 중앙 집중형 라우팅 테이블 설정을 통한 다수 네트워크 간의 통신 통합성 확인

- 방법 :

  • AWS Console 작업
    1. Hub 인스턴스 생성: 퍼블릭 서브넷 내에 가상 라우터 역할을 수행할 중계용 EC2를 배치함.
                                       보안그룹 설정 시 백엔드 API 인스턴스에서 오는 요청을 받도록 인바운드 규칙 추가.
    보안그룹 인바운드 규칙 설정
    2. 소스/대상 확인(Source/Dest. Check) 중지: 인스턴스 네트워킹 설정에서 이 옵션을 반드시 '중지'해야 본인이 최종 목적지가 아닌 외부 패킷(백엔드→로컬DB)을 드랍하지 않고 전달할 수 있음.
    중계용 EC2 인스턴스는 소스/대상 확인 설정을 "중지"함
    3. VPC 라우팅 테이블(Route Table) 업데이트: 백엔드 API 서버가 속한 서브넷의 이정표를 수정함. 로컬 DB 사설 대역(192.168.x.x)으로 가는 Target을 '중계용 Hub EC2의 인스턴스 ID'로 지정하여 트래픽을 강제로 허브로 밀어넣음.
    Backend 서버용 라우팅 테이블 (DB 요청은 중계 EC2로)
    중계용 라우팅 테이블은 기존 public 테이블과 동일
    4. 백엔드 API 서버 DB connection 변경 : 백엔드 API 서버가 속한 서브넷의 talescale 을 정지 / DB 커넥션을 시나리오 1의 talescale 10.x IP가 아닌 로컬 사설 IP 192.x 로 .env 파일 변경

  • Local(Tailscale) 연동 구현
    1. 중계 서버(Hub EC2) IP Forwarding 활성화 : 리눅스 커널이 패킷을 가로채서 로컬로 넘겨주도록 허용함.
      ** 단순히 ip_forward만 켜면 보안 그룹 설정이 완벽해도 패킷이 증발할 수 있음. 리눅스 커널은 들어온 경로와 나가는 경로가 다른 패킷을 비정상으로 보고 차단하기 때문인데, rp_filter 설정을 0으로 바꿔줘야만 중계 서버(Hub EC2)가 패킷을 버리지 않고 정상적으로 로컬 DB까지 전달함 ** 
    echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.conf
    echo 'net.ipv4.conf.all.rp_filter = 0' | sudo tee -a /etc/sysctl.conf
    echo 'net.ipv4.conf.default.rp_filter = 0' | sudo tee -a /etc/sysctl.conf
    sudo sysctl -p

    2. Subnet Router 선언: Hub EC2에서 taliscale 설치 후 "tailscale up --advertise-routes=10.0.0.0/16 --accept-routes" 명령을 실행함.
    3. 로컬 PC 사설 대역 광고: 로컬 PC(온프레미스)에서도 자신의 대역을 등록함.
        "tailscale up --advertise-routes=192.168.0.0/24"
    4. Tailscale 관리자 페이지에서 승인 : Admin Console에서 중계용 EC2(10.0.0.0/16)와 로컬 PC(192.168.0.0/24)의 경로를 각각 'Approve' 처리함.
    5. 온프레미스 보안 설정: 로컬 PC 방화벽에서 AWS VPC 대역(10.0.0.0/16)에 대한 인바운드(TCP 3306, ICMP)를 허용함.
    6. 기술 매핑: 실제 TGW 서비스 대신 Tailscale이 깔린 EC2를 '가상 라우터'로 변신시켜 트래픽을 중계하는 기능을 동일하게 구현함.
    ** 설정 미반영 시 해결법: tailscale up 옵션을 변경했는데도 ip route나 관리자 콘솔에 즉시 반영되지 않는다면, tailscale down 후 다시 tailscale up 명령어를 실행하여 세션을 초기화함. ** 

- AWS 아키텍처 : 

 

 - 검증 결과:

  • 통합 라우팅 확인: 복잡한 개별 Peering 없이, 중앙 허브(TGW 역할을 하는 EC2) 설정을 통해 다수의 가상 네트워크 대역에서 단일 로컬 DB에 접근 가능한 통합 라우팅 체계를 확인함.

backend public IP로 db 연결 시 중계서버를 거쳐 응답이 옴

 


 

[총평]


이번 기술 검증을 통해, 물리적인 VPN 장비가 없는 로컬 환경에서도 Tailscale과 같은 Mesh VPN을 활용하면 실제 기업의 Site-to-Site VPN이나 Direct Connect 환경을 충분히 시뮬레이션할 수 있음을 확인함.

+ Recent posts