네트워킹 - VPC(3)

이기태·2024년 8월 19일

AWS

목록 보기

57/62

AWS Site-to-Site VPN (사이트 간 VPN)

특정 구조가 있는 기업 데이터 센터를 AWS와 비공개로 연결하기
- 기업은 고객 게이트웨이를 VPC는 VPN 게이트웨이를 갖춰야 한다.
- 공용 인터넷을 통해 사설 Site-to-Sote VPN을 연결한다.
  VPN 연결이라 암호화 되어있음.
이를 사용해 VPC 네트워크를 기업 데이터 센터 네트워크에 효과적으로 연결 한다.
위와 같이 VPN은 두 가지가 필요하다.
- VGW(Virtual Private Gateway, 가상 프라이빗 게이트웨이)
  - VPN 연결에서 AWS 측에 있는 VPN 집선기(데이터를 효율적으로 전달)
  - VGW가 생성되면 Site-to-Site VPN 연결을 생성하려는 VPC에 연결된다.
  - ASN(Autonomous System Number)을 지정할 수도 있다.
- CGW(Customer Gateway, 고객 게이트웨이)
  - VPN 연결 고객 측의 소프트웨어 애플리케이션 또는 물리적 장치
    VPN 연결에서 데이터 센터 측

Site-to-site VPN 연결

- CGW가 있는 기업 데이터 센터와 VGW를 갖춘 VPC가 있다.

온프레미스의 고객 게이트웨이를 어떻게 구축해야 하는가?
- 어떤 IP 주소를 사용해야 하는가?
  - 고객 게이트웨이가 공용이라면 인터넷 라우팅이 가능한 IP 주소가 고객 게이트웨이 장치에 있다.
    고객 게이트웨이의 Public IP를 사용해 VGW와 CGW를 연결하면 된다.
  - 고객 게이트웨이를 비공개로 남겨 사설 IP를 가질 수도 있다.
    이 경우 대부분 NAT-T를 활성화하는 NAT 장치 뒤에 있다.
    NAT 장치에 공용 IP가 있을 시 이 공용 IP를 CGW에 사용한다.
(중요) 서브넷의 VPC에서 라우트 전파를 활성화해야 Site-to-Site VPN 연결이 실제로 작동한다.
온프레미스에서 AWS로 EC2 인스턴스 상태를 진단할 때 보안 그룹 인바운드 ICMP 프로토콜이 활성화됐는지 확인해야 한다.
활성화하지 않으면 연결이 되지 않음.

AWS VPN CloudHub

VGW를 갖춘 VPC가 있고, 고객 네트워크와 데이터 센터마다 고객 게이트웨이가 마련되어 있다.
- CloudHub는 여러 VPN 연결을 통해 모든 사이트 간 안전한 소통을 보장한다.
- 비용이 적게 드는 Hub&Spoke 모델로 VPN만을 활용해 서로 다른 지역 사이 기본 및 보조 네트워크 연결성에 사용한다.
  VPC 내 VGW와 CGW 하나 사이에 Site-to-Site VPN을 생성하게 되는 것.
  이렇게 연결하면 고객 네트워크는 VPN 연결을 통해 서로 소통할 수 있게 된다.
- VPN 연결이므로 모든 트래픽이 공용 인터넷을 통한다.
  단, 암호화되어 있다.
설치 방법
- VGW 하나에 Site-to-Site VPN 연결을 여러 개 만들어 동적 라우팅을 활성화하고 라우팅 테이블을 구성하면 된다.

CGW, VGW, Site-to-Site VPN 실습

Site-to-Site VPN 연결을 구성하기 위해서는 온프레미스 호스팅이 된 CGW가 필요하다.

CGW
VPC > VPN > 고객 게이트웨이 > 고객 게이트웨이 생성
- IP 주소: CGW 기기의 외부 인터페이스에 사용되는 것으로 AWS가 온프레미스 인프라에 접근하게 해준다.
- 인증서 ARN: AWS에서 온프레미스 VPN 기기에 접속할 때 보안 연결을 설정하기 위한 것.
VGW
VPC > VPN > 가상 프라이빗 게이트웨이 > 가상 프라이빗 게이트웨이 생성
- ASN 번호: AWS에서 생성해주는 것.
생성한 CGW-VGW 연결
VPC > Site-to-Site VPN 연결 > VPN 연결 생성
- 타겟 게이트웨이 유형: 가상 프라이빗 게이트웨이
- 가상 프라이빗 게이트웨이: 이전에 생성한 VGW
- 고객 게이트웨이 ID: 이전에 생성한 CGW ID
- 이외 라우팅, IPv4, 터널링 등 설정 가능

Direct Connect(DX)

원격 네트워크로부터 VPC로의 전용 프라이빗 연결을 제공
DX를 사용할 때는 전용 연결을 생성하고 AWS Direct Connect Location을 사용한다.
VPC에는 가상 프라이빗 게이트웨이를 설치해야 온프레미스 데이터 센터와 AWS 간 연결이 가능
그럼 같은 연결 상에서 S3 등의 퍼블릭 리소스와 EC2 인스턴스 등의 프라이빗 리소스에 퍼블릭 및 프라이빗 VIF(가상 인터페이스)를 사용해 액세스할 수 있다.
IPv4, IPv6 모두 지원
사용 사례
- 대역폭 처리량이 증가할 때
  큰 데이터 세트를 처리할 때 속도가 빨라진다.
  -> 퍼블릭 인터넷을 거치지 않기 때문
  -> 그리고 프라이빗 연결을 사용하므로 비용이 절약된다.
- 퍼블릭 인터넷 연결에 문제가 발생할 때
  Direct Connect를 사용해 연결 상태를 유지할 수 있다.
  -> 프라이빗 연결이기 때문에 연결 상태를 유지 가능.
  -> 실시간 데이터 피드를 사용하는 애플리케이션에 유용
- 하이브리드 환경을 지원
  온프레미스 데이터 센터와 클라우드가 연결되어 있기 때문

Direct Connect 다이어그램

- 리전을 기업 데이터 센터에 연결하려면 AWS Direct Connect Location을 요청한다.(물리적 위치로)
- Direct Connect Location에는 Direct Connect 엔드포인트와 고객 또는 파트너 라우터가 있다.
고객/파트너 라우터는 고객이나 파트너 케이지에서 빌려와야 한다.
- 온프레미스 데이터 센터에는 방화벽이 있는 고객 라우터를 설치할 것이다.
- 먼저 프라이빗 가상 인터페이스(VIF)를 생성해 VPC로 프라이빗 리소스에 액세스한다.
그러러면 모든 로케이션을 연결하는 프라이빗 VIF를 생성해 가상 프라이빗 게이트웨이에 연결해야 한다.
이 가상 프라이빗 게이트웨이는 VPC에 연결되어 있다.
- 그리하여 프라이빗 VIF를 통해서 EC2 인스턴스가 있는 프라이빗 서브넷에 액세스할 수 있다.
- 이 모든 과정은 비공개로 처리되어 수동으로 연결해야 한다.
설치에 한 달이 걸릴 수도 있음.
- 그럼에도 퍼블릭 인터넷을 전혀 지나지 않고 비공개이기 때문에 장점이 있다.
- 단, Amazon Glacier나 S3같은 퍼블릭 서비스는 프라이빗 VIF가 아닌 퍼블릭 VIF를 설치해야 한다.
-> 결국 같은 경로를 지나지만 가상 프라이빗 게이트웨이로 연결되는것이 아니라 AWS로 직접 연결되는 것.

Direct Connect Gateway

만약 다른 리전에 있는 하나 이상의 VPC와 연결하고 싶은 경우 Direct Connect Gateway를 사용 한다.

- 리전이 2개인 예시
각각 다른 VPC와 CIDR가 있다.
- 온프레미스 데이터 센터를 양쪽 VPC에 연결한다 가정하자.
- Direct Connect 연결을 생성한 뒤 프라이빗 VIF를 사용해 Direct Connect Gateway에 연결한다.
- 이 게이트웨이에는 프라이빗 가상 인터페이스를 통해 가상 프라이빗 게이트웨이에 연결되어 있고 첫 번째와 두 번째 리전 모두 같은 구성으로 되어 있다.
+ 설정으로 여러 VPC와 여러 리전을 연결 가능.

Direct Connect 유형

전용 연결 용량: 초당 1Gbps, 10Gbps, 100Gbps
- 고객은 물리적 전용 이더넷 포트를 할당 받는다.
- 먼저 AWS에 요청을 보내면 AWS Direct Connect 파트너가 처리를 완료한다.
호스트 연결: 초당 50Mbps, 500Mbps ~ 10Gbps까지 다양하다.
- AWS Direct Connect 파트너를 통해 또다시 연결을 요청한다.
- 필요하면 언제든지 용량을 추가하거나 제거하면 되어 전용 연결보다 유연하다.
- 선택한 로케이션에서 초당 1,2,5,10Gbps 이용이 가능하다.
전용 연결이든 호스팅 연결이든 새 연결을 만드려면 리드 타임이 한 달보다 길어질 때도 있다.
예시
일주일 안에 빠르게 데이터를 전송하고 싶다 -> Direct Connect (X)
Direct Connect가 이미 설치 되었는가, 데이터 전송 기간이 한 달보다 긴지 짧은지 확인해야 한다.

Direct Connect - 암호화

기본적으로 Direct Connect에는 암호화 기능이 없다.
그럼에도 프라이빗 연결이기 때문에 보안을 유지할 수 있다.
암호화를 원할 경우
- Direct Connect와 함께 VPN을 설치해 IPsec으로 암호화된 프라이빗 연결이 가능하다.
암호화 과정
- Direct Connect 로케이션을 가져와 해당 연결에 VPN연결을 구축한다.

Direct Connect - 복원력(중요)

# 1. 핵심 워크로드의 복원력 높이기

- 여러 Direct Connect를 설치하는 것이 좋다.
- 기업 데이터 센터가 두 개 있고 Direct Connect Location도 둘로 구성
- 프라이빗 VIF가 하나 있는데 다른 데 또 있다면 하나의 연결을 여러 로케이션에 수립한 것이므로 Direct Connect 하나가 망가져도 다른 하나로 복원력이 강해진다.

# 2. 핵심 워크로드 복원력을 최대로 끌어올리기

- 각 Direct Connect Location에 독립적인 연결을 두 개씩 수립하면 복원력을 최대로 만들 수 있다.
- 여기에선 두 로케이션에 4개의 연결을 수립해 AWS에 연결
- 즉, 최대의 복우너력을 달성하려면 여러 독립적인 연결을 하나 이상의 로케이션에서 각기 다른 장치에 도달하도록 구성하면 된다.

Site-to-Site VPN & Direct Connect

# 회사 데이터 센터가 Direct Connect를 토앻 VPC에 연결한다 가정

- 이는 비용도 많이 들고 가끔은 Direct Connect 연결에 문제가 발생할 수도 있다.
- 이 경우 또 다른 Direct Connect로 보조 연결
-> 비용이 많이든다.
- Site-to-Site VPN을 백업 연결을 두어 기본 연결에 문제가 발생했을 때 이 연결을 사용하면 Site-to-Site VPN을 통해 퍼블릭 인터넷에 연결할 수 있어 안정성이 높아진다. -> 퍼블릭 인터넷에 항상 연결되어 있기 때문

Transit Gateway(환승 게이트웨이)

- 위와 같은 복잡한 네트워크 토폴로지를 해결하고자 Transit Gateway를 사용

전이적 피어링 연결이 VPC 수천 개와 온프레미스 데이터 센터, Site-to-Site VPN, Direct Connect, 허브&스포크 간 스타형 연결 사이에 생긴다.
Transit Gateway를 통해 VPC 여러 개를 연결할 수 있다.

- 여기서는 VPC를 모두 피어링할 필요가 없고, Transit Gateway를 통해 전이적으로 연결된다.
- 모든 VPC가 서로 통신할 수 있는데 Direct Connect Gateway를 Transit Gateway에 연결하면 Direct Connect 연결이 각기 다른 VPC에 직접 연결된다.
- Site-to-Site VPN과 VPN 연결을 선호한다면 고객 게이트웨이와 VPN 연결을 Transit Gateway에 연결할 수 있다.
즉, Transit Gateway 일부로 모든 VPC에 액세스하는 것이다.
Transit Gateway는 리전 리소스이고, 리전 간 작동한다.
Transit Gateway를 계정 간에 공유하려면 Resource Access Manager를 사용한다.
그리고 리전 간 Transit Gateway를 피어링할 수도 있다.
Transit Gateway에 라우팅 테이블을 생성해 어느 VPC가 누구와 통신할지 어떤 연결이 액세스할지 제한한다.
Transit Gateway내 모든 트래픽 경로를 제어해서 네트워크 보안을 제공
Direct Connect Gateway 및 VPN 연결과 함께 작동하고 AWS에서 유일하게 IP 멀티캐스트를 지원하는 서비스이다.
멀티캐스트: 한 번 전송으로 여러 대상에 동시에 전송

Transit Gateway: Site-to-Site VPN ECMP

Site-to-Site VPN 연결 대역폭을 ECMP를 사용해 늘리기
ECMP: Equal-cost multi-path routing, 등가 다중 경로 라우팅
여러 최적 경로를 통해 패킷을 전달하는 라우팅 전략
사용 사례
Site-to-Site VPN 연결을 많이 생성해서 AWS로의 연결 대역폭을 늘릴 때 사용한다.

- Transit Gateway에 VPC 4개가 연결되어 있다.
- 기업 데이터 센터는 Site-to-Site VPN으로 Transit Gateway에 연결된다.
- Site-to-Site VPN 연결을 구축할 때 각기 앞쪽과 뒤쪽을 향하는 터널 두 개가 있다.
- Site-to-Site VPN을 VPC에 직접 연결하면 두 터널 모두 연결 하나로 사용되지만
Transit Gateway를 사용할 때는 두 터널이 동시에 사용된다.
- Transit Gateway로 여러 Site-to-Site VPN을 만드는데 두 번재 Site-to-Site VPN을 생성해 Transit Gateway로 연결할 수 있기 때문에 총 터널이 4개가 생긴다.
- Site-to-Site VPN에 터널 4개가 있으면 연결 처리량이 증가한다.
기업 데이터 센터를 직접 VPC에 연결한 경우에는 사용할 수 없는 기능이다.

Transit Gateway: ECMP를 사용한 처리량

# 가상 프라이빗 게이트웨이에 VPN

- 가상 프라이빗 게이트웨이에 VPN을 연결하면 VPC 마다 터널 하나씩 생기고
- 연결 하나당 1.25Gbps를 제공한다.
- 이때 VPN 연결은 터널 두 개로 구성된다.
# Transit Gateway에 VPN

- VPN을 Transit Gateway로 연결하면 Site-to-Site VPN 하나가 여러 VPC에 생성된다.
동일한 Transit Gateway에 모두 전이적으로 연결되기 때문이다.
- Site-to-Site VPN 연결 하나는 ECMP로 인해 최대 2.5Gbps의 처리량을 제공한다.
해당 전략을 통해 터널 2개가 사용되기 때문
- Transit Gateway에 Site-to-Site VPN 연결을 더 추가할 수도 있다.
2~3개만 더해도 ECMP를 사용하면 처리량이 배로 된다. (5, 7.5Gbps ... )
- 이렇게 설정하면 데이터가 Transit Gateway를 통과할 때 1GB마다 요금이 청구된다.
성능 최적화 비용

Transit Gateway - 여러 계정에 Direct Connect 공유

- 기업 데이터 센터와 Direct Connect Location간 Direct Connect 연결을 생성
- Transit Gateway를 서로 다른 계정의 VPC 2개 모두에 생성한다.
- Direct Connect Location에 연결한 Direct Connect Gateway를 Transit Gateway에 연결하면 여러 계정과 VPC 사이에 Direct Connect 연결을 공유할 수 있게 된다.

VPC - Traffic Mirroring

VPC에서 네트워크 트래픽을 수집하고 검사하되 방해되지 않는 방식으로 실행하는 보안기능
관리 중인 보안 어플라이언스로 트래픽을 라우팅해야한다.
트래픽 수집
- Source - ENI
- Target - ENI | NLB
  
  - EC2 인스턴스와 ENI가 있고 ENI가 연결돼 문제없이 작동하며 EC2 인스턴스는 인터넷에 액세스 중이다.
  - 그리고 ENI에서 EC2 인스턴스로 인바운드/아웃바운드 트래픽이 많이 생긴다.
이때 트래픽을 분석하기위해선..
- 1. 로드 밸런서 설정
    - NLB 뒤에 보안 소프트웨어가 잇는 EC2 인스턴스의 ASG이 있다.
    - 소스 A의 기능을 방해하지 않으면서 소스 A에서 발생하는 트래픽을 모두 수집하고자 한다.
- 1. VPC 트래픽 미러링 설정
    - 모든 정보가 아닌 일부만 얻고 싶다면 선택적으로 필터를 사용할 수도 있다.
트래픽 미러링 기능을 통해 ENI나 소스 A로 전송되는 트래픽은 전부 NLB로도 보내진다.
소스 A, EC2 인스턴스는 여전히 잘 작동한다.
즉, NLB로 트래픽을 보내 트래픽 자체를 분석하게 된다.
또한 소스 하나가 아니라 여러 개 적용된다.
두 번째 EC2 인스턴스에 또 다른 ENI가 있다면 NLB로 트래픽을 미러링할 수 있다.
작동 방식
- 동일한 VPC에 소스와 대상이 있어야 한다.
  VPC 피어링을 활성화한 경우라면 다른 VPC에 걸쳐 있기도 하다.
사용 사례
- 콘텐츠 검사
- 위협 모니터링
- 네트워킹 문제 해결

IPv6

IPv4 주소 개수 = 43억개
IPv6 주소 개수 = 3.4* 10^38개의 고유 주소

AWS의 모든 IPv6 주소는 공개되고 인터넷 라우팅이 가능해진다.
x:x:x:x:x:x:x:x
ex: 2001:db8:3333:4444:5555:6666:7777:8888
VPC에서 IPv6
- IPv6의 공개 IP주소를 듀얼 스택 모드로 활성화할 수 있다.
  즉, VPC에서 생성된 EC2 인스턴스가 최소한 사설 내부 IPv4와 공용 IPv6를 확보하고, 인터넷 게이트웨이를 통해 IPv4/IPv6를 사용해 인터넷과 통신한다.

IPv6 트러블 슈팅

IPv4는 VPC와 서브넷에서 비활성화할 수 없다.
즉, IPv6의 주소가 아무리 많아도 IPv4 개수만큼 할당 가능함.
따라서 IPv6 지원 VPC가 있는데 서브넷에서 EC2 인스턴스를 생성할 수 없는 경우
- 1. 인스턴스가 IPv6을 얻지 못한것이 아니라 IPv6 주소 공간이 너무 넓기 때문
- 1. 서브넷에 사용 가능한 IPv4가 없기 때문
솔루션
서브넷에 IPv4 CIDR를 생성하는 것

IPv6 실습

VPC에서 IPv6 CIDR 생성
서브넷에 IPv6 CIDR 생성
그 다음 서브넷 설정 수정 -> IPv6 주소 자동할당 활성화 체크
EC2 인스턴스 > 네트워킹 > IP 주소 관리 > 인터페이스 eth0에 IPv6 주소 부여 > 저장
보안그룹 IPv6 범위의 CIDR도 추가

Egress-only Internet Gateway(송신 전용 인터넷 게이트웨이)

Egress-only IGW는 IPv6 트래픽에만 사용된다.
VPC 인스턴스에서 IPv6상 아웃바운드 연결을 허용하고 동시에 인터넷이 인스턴스로 IPv6 연결을 시작하지 못하게 막는다.
그러기 위해서 라우팅 테이블을 업데이트해야 한다.
예를들어

- 인터넷이 있고 VPC에는 공용/사설 서브넷이 있다면 IGW를 통해 EC2 인스턴스가 인터넷에 액세스하고 인터넷은 IPv6를 사용해 인스턴스로 연결을 시작할 수 있다.
- 여기서는 아웃바운드 연결만 가능하도록 해보자
- 사설 서브넷에 있는 EC2 인스턴스는 인터넷 게이트웨이가 없다.
- 여기에 Egress-only IGW를 생성하면 사설 서브넷의 EC2가 IPv6로 인터넷에 액세스한다.
- 하지만 인터넷에서 EC2로의 연결은 개시할 수 없다.

IPv6 라우팅

- IPv6가 있는 VPC에 공용/사설 서브넷이 있다.
둘다 Ipv4, IPv6를 가지고 있다.
- 인터넷에 액세스하는 웹 서버는 IGW를 통해 IPv4와 IPv6로 액세스한다.
- 공용 서브넷의 라우팅 테이블에서 첫 번째 줄은 로컬이다.
Ipv4와 IPv6 트래픽
- 그 외 0.0.0.0/0은 모든 IPv4, ::/0는 모든 IPv6
전부 IGW를 통해 웹 서버가 인터넷에 액세스하도록 허용한다.
- 공용 서브넷의 IPv6와 IPv4를 양방향으로 활성화하는 방법이다.
- 사설 서브넷도 Ipv4, IPv6가 있다.
서버가 인터넷에 액세스하되 액세스받지 못하게 하기위해서는 어떻게 할까
- IPv4는 NAT GW를 사용한다.
- IPv6는 Egress-only IGW를 사용한다.
- 사설 서브넷의 라우팅 테이블
첫 두 줄은 같다.
그러나 아래 두 줄의 대상이 NAT GW와 EIGW가 다르다.

이기태

이전 포스트

네트워킹 - VPC(2)

다음 포스트