AWS 기술 블로그
AWS Site-to-Site VPN 성능 최적화를 위한 적절한 옵션 선택하기
이 글은 AWS Networking & Content Delivery Blog에 게시된 AWS Site-to-Site VPN, choosing the right options to optimize performance by Scott Morrison and Shawji Varkey을 한국어 번역 및 편집하였습니다.
AWS Site-to-Site VPN은 온프레미스 사용자와 워크로드를 AWS에 연결하는 방법으로 성능, 확장성, 보안 및 고가용성 기능을 제공하는 완전 관리형 서비스입니다. Site-to-Site VPN을 사용하는 경우, 연결 당 두 개의 터널로 Amazon VPC(Virtual Private Cloud)에 연결하여 Redundancy를 높일 수 있습니다. AWS 리전에서 멀리 떨어져 있는 사이트의 성능을 더 높이려면 VPN에서 AWS Global Accelerator를 활성화하여 가장 가까운 AWS PoP(Point of Presence)를 통해 트래픽을 라우팅할 수 있습니다. 또한 Site-to-Site VPN을 사용하여 AWS Direct Connect를 통해 온프레미스에서 사설 IP VPN을 사용하는 AWS Transit Gateway에 연결할 수 있습니다.
Site-to-Site VPN은 IPsec(Internet Protocol Security) 프로토콜을 사용하여 암호화된 터널을 생성합니다. AWS는 2009년 8월 Site-to-Site VPN이 처음 출시된 이후 고객을 대신하여 보안, 성능 및 기능을 개선하기 위해 지속적으로 혁신해 왔습니다. 다른 부분들은 고객이 직접 통제하는 반면, 이러한 기본 인프라 및 서비스 아래에 있는 변경 사항은 고객에게 보이지 않는 개선입니다. 여기서는 Site-to-Site VPN으로 성능을 개선하는 데 사용할 수 있는 몇 가지 구성 옵션에 대해 설명합니다.
성능 기준선
Site-to-Site VPN FAQ 또는 할당량 페이지를 읽었다면, 터널 당 최대 성능이 최대 1.25Gbps(초당 기가비트) 및 140,000PPS(초당 패킷)인 것을 확인했을 수 있습니다. 이것은 우리의 경험을 기반으로 한 예상 최대값이지만, 실제 최대값은 여러 요인에 따라 달라집니다. Site-to-Site VPN의 특정 암호화 기능은 다른 암호화 기능보다 더 좋은 성능을 보입니다. 추가적으로 특정 네트워크 최적화도 터널 내부와 외부의 성능을 향상시킬 수 있습니다. 또한 IPsec 터널을 사용하여 통신하는 특정 응용 프로그램에 따라 성능이 다릅니다. 이러한 성능 추정치는 다양한 요인에 따라 가변적이므로, 특정 환경 및 워크로드로 성능 기준선을 테스트하여 최대 처리량이 얼마인지 파악하는 것이 좋습니다.
암호화 최적화
최신 암호화는 인증, 데이터 프라이버시 및 데이터 무결성을 결정하는 기능의 세 가지 기능을 제공합니다. IPsec 터널을 설정하기 위해 IKE(Internet Key Exchange) 프로토콜을 사용합니다. IKE에는 IKEv1과 IKEv2의 두 가지 버전이 있습니다. IKEv2는 IKEv1 대비 몇 가지 주요 성능 최적화를 제공하므로 IKEv2를 사용하는 것이 좋습니다. IKEv2는 IKEv1 대비 다음과 같은 여러 기능을 제공합니다.
- IKEv1에서는 트래픽이 양방향(전송 및 반환)에서 동일한 암호화 도메인에 속해야 하지만, IKEv2에서는 별도로 암호화할 수 있습니다.
- IKEv2는 IKEv1보다 빠른 속도를 제공합니다. NAT 통과에 대한 IKEv2의 기본 제공 지원으로 방화벽을 통과하고, 연결을 훨씬 빠르게 설정할 수 있습니다.
- IKEv2는 터널 당 필요한 보안 연결 수를 줄여서 여러 노드 또는 게이트웨이 간에 점점 더 많은 터널을 포함하도록 VPN이 성장함에 따라 필요한 대역폭을 줄입니다.
- IKEv2는 또한 인증을 위한 비대칭 키를 허용하여 보안 태세를 높입니다.
- 터널을 설정하기 위해 IKEv2는 4개의 메시지를 사용하고 IKEv1은 기본 모드에서 6개, 공격적 모드에서 3개를 사용합니다.
IKE는 두 단계로 나뉩니다. IKE 1단계에서는 ISAKMP(Internet Security Association and Key Management Protocol) 세션을 설정하여 보안 연결(SA)이라고 하는 관리 매개변수를 협상하고 키를 교환하며, IPsec 터널의 수명 기간 동안 연결 유지 메시지를 전달합니다.
해싱
IKE 1단계에서는 메시지 무결성을 확인하고, 데이터가 전송 중에 조작되지 않도록 하는 수단을 제공하는 데 사용되는 해싱 알고리즘을 협상합니다. AWS는 SHA-1(Secure Hashing Algorithm 1) 및 SHA-2(Secure Hashing Algorithm 2)를 지원하고, SHA-2 내에서 상용 리전에서 256, 384 및 512비트 다이제스트 크기를 지원합니다. 단, AWS GovCloud 리전은 SHA-1을 지원하지 않습니다. SHA 버전과 다이제스트 크기 간에 성능 차이가 있지만, 고객 게이트웨이 디바이스 지원 및 보안 요구 사항에 따라 SHA 알고리즘을 선택하는 것이 좋습니다. 특정 요구 사항이 없는 경우 성능 및 보안 특성으로 인해 SHA-384를 사용하는 것이 좋습니다.
인증
ISAKMP 협상 인증에는 PSK(사전 공유 키) 또는 ACM(Amazon Certificate Manager)의 인증서가 사용됩니다. 이 선택은 진행 중인 터널 성능에 영향을 미치지 않습니다. 그러나 보안 기준을 높이기 위해 가능하면 PSK를 통한 인증서 기반 인증을 사용하는 것이 좋습니다. 인증서 기반 인증은 고객 게이트웨이(CGW) IP 주소에서 발생할 수 있으며, PSK는 CGW 구성과 일치하는 IP 주소의 소스에 요구 사항을 추가합니다.
암호화
DH(Diffie-Hellman) 그룹은 암호화를 위해 키 자료가 생성되는 방식을 결정합니다. SHA와 마찬가지로 고객 게이트웨이 디바이스와의 호환성 및 보안 요구 사항에 따라 DH 그룹을 선택하는 것이 좋습니다. 특정 요구 사항이 없는 경우 보안 특성으로 인해 DH 그룹 20을 사용하는 것이 좋습니다.
DH 키 교환이 발생하면 해당 키를 사용하여 AES(Advanced Encryption Standard)로 암호화합니다. AES는 대칭 블록 암호입니다. 즉, 일련의 변환을 통해 128비트 데이터 블록을 반복적으로 암호화합니다. AES-128과 AES-256 간의 성능 차이는 최적화된 네트워크 부하에 대해 무시할 수 있는 수준인 반면 AES-256은 보안 관점에서 훨씬 더 우수합니다. AES-256은 256비트 키를 사용합니다. 즉, AES-128의 경우 2128개와 비교하여 2256개의 변형이 있습니다. 또한 AES-256은 AES-128의 10회 암호화와 비교하여 14회의 암호화를 사용합니다. 이러한 사실을 기반으로 고객 게이트웨이의 보안 요구 사항 및 호환성을 기반으로 선택해야 합니다. 그러나 AES-256을 권장합니다. AES 성능의 주요 차이점은 CBC(Cipher Block Chaining)와 GCM(Galois/Counter Mode) 사이에 있습니다. CBC 및 GCM은 AES에서 이러한 변환을 계산하기 위한 연결 방법입니다. CBC는 프로세서에서 직렬 방식으로 계산되어야 합니다. 따라서 다중 코어를 사용할 수 없습니다. 반면에 AES-GCM은 병렬로 암호화 및 해독할 수 있으므로 더 높은 처리량과 더 나은 성능을 허용합니다. AES128-GCM-16 및 AES256-GCM-16을 모두 지원합니다. 다시 한 번 보안 요구 사항 및 호환성을 기반으로 암호 제품군 중에서 선택하는 것이 좋지만, 요구 사항 내에서 지원되는 경우 AES256-GCM-16을 권장합니다.
IKE 1단계 협상이 완료되면, 데이터 전송을 위한 터널을 설정하는 IKE 2단계가 시작됩니다. IKE 2단계의 매개변수는 별도로 구성할 수 있지만 일반적으로 1단계와 동일한 조언을 제공합니다. IKE 2단계 키 교환은 ISAKMP 세션 내에서 발생하므로 1단계에서 교환된 키로 암호화됩니다. 2단계에서 교환된 DH 키는 PFS(Perfect Forward Secrecy)를 지원하는 데 사용됩니다. PFS는 각 세션에 대해 새 DH 키를 생성하여 키 손상으로부터 암호화된 데이터를 보호하는 방법입니다. 이렇게 하면 단일 키 노출의 영향이 줄어듭니다.
네트워크 최적화
여러 네트워킹 경로를 통해 데이터를 보낼 때 경로 전체에서 성능을 향상시키기 위해 조정할 수 있는 여러 변수가 있습니다. MTU(최대 전송 단위), TCP 혼잡 제어 및 ECMP는 여기에서 다룰 변수입니다. TCP 트래픽은 MTU 및 MSS(최대 세그먼트 크기)를 사용하여 피어 간의 네트워크 경로를 통해 효율적으로 전송할 수 있는 패킷 크기를 정의합니다. MTU는 전송된 패킷의 총 크기이고 MSS는 피어로 전송되는 데이터의 크기입니다. TCP 피어는 TCP 연결의 연결 설정 중에 이 두 변수를 협상합니다. IPsec 연결을 사용하면 트래픽이 두 피어 간에 전송되기 전에 암호화 및 캡슐화됩니다. 이 프로세스가 IP 프로토콜 범위 내에서 작동하려면 추가 헤더 정보가 원래 패킷 크기에 추가됩니다(그림 1 참조).
그림1. 원래 패킷 MTU 및 MSS가 캡슐화된 패킷 MTU 및 MSS에 어떻게 맞춰지는지 표시하는 이미지
일반적으로 대부분의 네트워크 경로는 기본적으로 1500바이트의 MTU 크기로 구성됩니다. 패킷의 40바이트를 사용하는 IP 및 TCP 헤더를 사용하면 실제 데이터 패킷에 대해 MSS가 1460바이트가 됩니다. IPsec 터널을 통해 동일한 트래픽을 전송하면 MTU 내에 유지하기 위한 데이터의 캡슐화 및 암호화로 인해 MSS 크기가 훨씬 더 줄어듭니다. IPsec에 사용할 수 있는 다양한 암호화 알고리즘을 통해 최적의 MTU 및 MSS 크기는 여기 설명서에 표시된 대로 다릅니다.
이러한 값을 고려하지 않으면 IPsec 터널을 사용하는 트래픽 흐름에 대해 조각화 또는 패킷 손실이 발생할 수 있습니다. 조각화는 추가 IPsec 패킷 정보가 있는 MTU(1500)를 수용하기 위해 IPsec 장치가 원본 데이터 패킷을 분할하거나 조각화해야 할 때 발생합니다. IPsec 장치가 패킷에서 “DF(조각화 금지)” 플래그를 재설정하도록 구성되지 않은 경우 패킷 삭제가 발생할 수 있습니다.
패킷 크기를 조정할 때 전체 경로에 대해 최적의 크기도 사용해야 합니다. 패킷 크기가 너무 작으면 네트워크 경로의 각 홉에서 각 패킷에 대해 처리가 수행되므로 데이터 전송 시간이 늘어납니다. 최적의 크기를 찾기 위해 PMTUD(Path MTU Discovery), TCP MTU Probing 또는 간단한 ping 명령과 같은 프로토콜을 사용할 수 있습니다.
AWS VPN은 현재 PMTUD 또는 점보 프레임을 지원하지 않습니다.
TCP MTU 프로브는 IETF RFC 4821에 설명된 패킷화 계층 경로 MTU 검색의 한 형태입니다. /proc/sys/net/ipv4/tcp_mtu_probing 파일에서sysctl의 일부로 net.ipv4.tcp_mtu_probing 변수를 설정하여 Linux에서 활성화 할 수 있습니다. 변수 tcp_base_mss와 함께 사용되며, 해당 값으로 설정된 MSS로 시작하여 패킷 손실이 발생하는 시점까지 MSS를 증가시켜 백오프합니다. 또한 tcp_mtu_probe_floor를 설정하여 기본값을 48바이트에서 변경하여 TCP MTU 검색이 활성화될 때 가능한 최소 MSS를 정의할 수 있습니다. 프로덕션 워크로드를 변경하기 전에 테스트 환경에서 TCP 프로브의 성능 영향을 평가해야 합니다.
ping 명령을 사용할 때 Don’t Fragment(Windows -f | Linux/Mac -D) 및 Send Buffer Size(Windows -l <bytes> | Linux/Mac -s <bytes>) 플래그를 사용해야 합니다. 이렇게 하면 전송된 ping 패킷이 조각나지 않고 최적의 패킷 크기를 찾기 위해 패킷 크기를 늘리거나 줄일 수 있습니다.
실패한 ping test:
C:\>ping www.example.com -f -l 1500 Pinging
www.example.com [192.0.2.1] with 1500 bytes of data:
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.성공한 ping test:
C:\>ping www.example.com -f -l 1472
Pinging www.example.com [192.0.2.1] with 1472 bytes of data:
Reply from 192.0.2.1: bytes=1472 time=1ms TTL=54
Reply from 192.0.2.1: bytes=1472 time=1ms TTL=54
Reply from 192.0.2.1: bytes=1472 time=2ms TTL=54
Reply from 192.0.2.1: bytes=1472 time=2ms TTL=54TCP 혼잡 제어
네트워크 경로 최적화가 소진되어도 고객은 여전히 네트워크 성능과 관련된 문제에 직면할 수 있습니다. 이러한 문제 중 일부는 VPN 연결에 걸리는 네트워크 경로의 왕복 시간(RTT) 때문일 수 있습니다. TCP 혼잡 제어는 단일 TCP 세션이 경로에 부하를 주지 않도록 방지하는 TCP의 속성입니다. 이는 주어진 시간에 수신자로부터 TCP ACK 메시지를 기다리면서 전송할 수 있는 패킷 수인 TCP 창 크기를 조정하여 수행합니다.
대부분의 최신 운영 체제는 현재 CUBIC을 기본 TCP 혼잡 제어 알고리즘으로 사용합니다. CUBIC은 TCP 트래픽의 더 빠른 수렴을 제공하기 위해 선형 규모(즉, 이름)가 아닌 큐빅 규모에서 성능을 향상시키도록 설계되었습니다. 이 방법은 일반적으로 대부분의 상황에서 잘 수행되지만 RTT가 약 30ms보다 높으면(고대역폭 네트워크 경로에서) 중복 ACK를 트리거하기 시작하여 CUBIC 알고리즘에 따라 Window 최대(Wmax) 값이 감소하기 시작합니다. 목적지와의 물리적 거리로 인해 RTT가 감소하지 않기 때문에 CUBIC 알고리즘은 계속해서 Wmax를 감소시켜, 트래픽의 전체 대역폭을 예상 처리량보다 훨씬 느리게 만듭니다.
이는 네트워크 경로에서 간단한 ping 테스트를 통해 추가로 확인할 수 있습니다. 네트워크 경로에 손실이 거의 없거나 전혀 없는 경우(약 1 x 10-6) TCP 혼잡 제어 알고리즘을 변경하면 트래픽 대역폭 성능이 크게 향상됩니다.
대역폭 성능을 크게 향상시킨 TCP 혼잡 알고리즘 중 하나는BBR(Bottleneck Bandwidth and Round-trip Propagation Time)입니다. BBR 혼잡 알고리즘은 트래픽의 소스와 대상 사이에서 RTT가 높을 때 더 높은 성능으로 수행됩니다. 이는 BBR이 패킷 손실을 트래픽의 혼잡 트리거로 사용하지 않기 때문입니다. 오히려 RTT를 사용하여 네트워크 성능을 유지합니다. 테스트 환경에서 성능을 평가하고 벤치마킹해야 합니다. 다음 명령은 Linux에서 TCP 혼잡 제어 알고리즘을 변경하는 데 사용됩니다.
sysctl -w net.core.default_qdisc=fqsysctl -w net.ipv4.tcp_congestion_control=bbr변경 사항을 다시 CUBIC으로 되돌리려면 다음 명령을 사용하십시오.
sysctl -w net.ipv4.tcp_congestion_control=cubicWindows OS는 현재 BBR을 TCP 혼잡 제어 알고리즘으로 사용하는 것을 지원하지 않습니다. TCP 혼잡 제어 알고리즘은 서버에 대해 국한됩니다. 트래픽 개선을 위해 소스와 대상이 일치하지 않아도 됩니다.
TCP 데이터 전송은 트래픽의 소스 서버에서 유지 관리하는 혼잡 윈도우에 따라 달라집니다. BBR은 사용 가능한 모든 대역폭을 소비하므로, 가치가 높거나 일시적인 워크로드에서는 드물게 사용해야 합니다.
TGW 성능
Transit Gateway는 2018년 11월에 출시되었으며, 현재 AWS에서 가장 널리 채택된 네트워킹 서비스 중 하나입니다. Transit Gateway를 통해 고객은 규모에 맞게 네트워킹 리소스 간의 통신을 생성할 수 있으므로 고객은 통신 뿐만 아니라 세분화 및 AWS 인프라 내 수천 개의 네트워킹 리소스 관리 용이성을 제공하는 아키텍처를 생성할 수 있습니다. 여기에는 Amazon VPN을 통한 연결이 포함되는데 터널이 ECMP(Equal Cost Multi Path,등가 다중 경로)를 활용할 수 있도록 하기 때문입니다.
ECMP를 통해 고객은 Active/Active 구성에서 Transit Gateway 또는 Cloud WAN 코어 네트워크에 연결된 Amazon VPN 터널을 사용할 수 있습니다. 이를 통해 고객은 여러 Amazon VPN 터널에서 여러 트래픽 흐름에 대한 전체 집계 대역폭을 늘릴 수 있습니다. 따라서 2개의 터널이 있는 단일 Amazon VPN으로 고객은 최대 약 2.5Gbps의 총 대역폭을 푸시할 수 있습니다. 추가 Amazon VPN 연결을 추가하여 이를 늘릴 수 있습니다. 흐름당 기준 트래픽은 여전히 약 1.25Gbps로 제한됩니다. 이 게시물에서 Transit Gateway를 사용한 대역폭 확장에 대해 자세히 알아볼 수 있습니다.
VGW(Virtual Private Gateway)에 대한 VPN 연결에서는 ECMP가 지원되지 않습니다. ECMP를 사용하려면, Transit Gateway 또는 Cloud WAN에서 활성화된 ECMP로 동적 라우팅을 위해 VPN 연결을 구성해야 합니다.
결론
본 게시물에서는 권장 SHA 알고리즘, DH 그룹 및 Cipher 제품군과 함께 IKEv2를 선택하여 수행할 수 있는 암호화 성능 향상과 보안 상태를 개선하는 방법을 다루었습니다. 또한 MTU 및 MSS 구성을 최적화하고, TCP 혼잡 제어 알고리즘을 변경하고, ECMP를 사용하여 개선할 수 있는 사항에 대해서도 다루었습니다. 테스트 환경에 로그인하여 지금 시작하고 이러한 설정을 직접 시도하고 다양한 구성으로 성능을 벤치마킹하여 가장 적합한 구성을 찾아보세요.