AWS Site-to-Site VPN 터널 이슈 해결하기

이전글에서 IPSec SIte-to-Site VPN & Dead Peer Detection(DPD)에 대한 기술적으로 심층적인 분석을 진행했습니다. 

IPSec SIte-to-Site VPN & Dead Peer Detection(DPD) 심층 분석 (Deep Dive)

 

 

이번 시간에는 여러 고객 사례를 기반으로 Site-to-Site VPN 구성후 발생한 이슈를 기반으로 해결 방안에 대해 논의하고자 합니다. 

이해를 돕기 위해서 이전글을 확인하고 오시는 것을 추천드립니다. 

 

본 글에서는 AWS SIte-to-Site VPN 구성 사례를 기반으로 설명하며, 서로 터널이 연결된 상태에서 발생하는 오류에 대한 다양한 해결책에 대해 확인합니다. 터널 연결 자체가 구성이 불가한 경우에 대해서는 각 벤더사나 MSP에 문의하시기 바랍니다. 

 

 

터널 순단을 막는 첫 번째 방법 DPD 설정 확인하기 

VPC 피어가 연속된 3개의 연속된 DPD에 응답하지 않았을 때 피어가 죽은 것으로 간주하고 터널이 닫힙니다. CGW에서 DPD가 켜져 있을 경우 다음 사항에 해당하는 상황인지 확인해야 합니다. 

• 고객 게이트웨이(CGW)가 DPD 메시지를 수신하고 이에 적절히 응답하도록 설정되어야 합니다. 이는 VPN 터널의 지속적인 연결 상태를 확인하는 데 필수적입니다.
• AWS 측에서 전송하는 DPD 메시지에 대해 CGW가 응답할 수 있어야 합니다. 만약 CGW가 과부하 상태이거나 리소스 부족으로 인해 DPD 메시지에 응답하지 못한다면, 터널이 비정상적으로 종료될 수 있습니다.
• 방화벽의 침입 방지 시스템(IPS)이 활성화되어 있는 경우, DPD 메시지의 빈도가 제한되거나 차단될 수 있습니다. 이는 DPD 메시지가 정상적으로 전달되지 않게 하여 터널 종료를 유발할 수 있으므로, 방화벽 설정을 검토하여 DPD 트래픽이 원활하게 흐를 수 있도록 해야 합니다.
•  인터넷 연결 상태가 불안정하거나 패킷 손실이 발생하면 DPD 메시지가 손실되어 터널이 종료될 수 있습니다. 

유휴 제한 시간 문제 해결 방법

1. 지속적인 트래픽 생성: 로컬 네트워크와 AWS Virtual Private Cloud(VPC) 간에 지속적인 트래픽을 유지하여 터널이 활성 상태를 유지하도록 합니다. 이를 위해, 로컬 네트워크에서 VPC 내의 인스턴스로 5초 간격으로 ICMP 요청을 보내는 스크립트를 설정할 수 있습니다. 이러한 주기적인 패킷 전송은 터널의 유휴 상태를 방지하여 연결이 끊어지는 것을 막아줍니다.
2. 링크 상태 추적 기능 활용: 사용 중인 네트워크 장비가 링크 상태를 모니터링하는 기능을 지원한다면, 해당 기능을 활성화하여 터널의 상태를 지속적으로 확인할 수 있습니다. 이러한 기능은 터널의 상태 변화를 실시간으로 감지하여, 필요시 재연결을 시도하거나 경고를 발송하는 등의 조치를 취할 수 있습니다.

정책기반 VPN 연결 문제 해결

AWS Site-to-Site VPN은 라우트 기반 VPN 솔루션으로, 한 번에 하나의 인바운드 및 하나의 아웃바운드 보안 연결(Security Association, SA)을 지원합니다. 이는 각 터널에 대해 단일 SA 쌍만을 허용함을 의미합니다. 따라서, 고객 게이트웨이 디바이스가 정책 기반 VPN을 사용하고 있으며, 여러 SA 쌍을 설정하려고 시도할 경우, 새로운 SA가 생성될 때 기존의 SA가 종료되어 연결이 불안정해질 수 있습니다.

정책 기반 VPN은 트래픽 선택기를 기반으로 SA를 설정합니다. 각 트래픽 선택기는 소스 및 대상 네트워크의 조합으로 정의되며, 이러한 조합마다 별도의 SA가 생성됩니다. AWS VPN 엔드포인트는 단일 SA 쌍만을 지원하므로, 여러 트래픽 선택기를 사용하여 다수의 SA를 생성하려는 시도는 AWS VPN 엔드포인트의 제한에 부딪히게 됩니다.

 

이러한 문제를 방지하기 위해, 고객 게이트웨이 디바이스의 정책을 단일 SA로 제한하는 것이 중요합니다.

 

AWS Management Console을 사용하여 VPN 연결을 수정합니다. 

• 로컬 IPv4 네트워크의 CIDR(Classless Inter-Domain Routing)을 다음과 같이 설정하도록 고객 게이트웨이를 구성합니다.
• 원격 IPv4 네트워크의 CIDR을 다음과 같이 설정합니다.

이후 고객 게이트웨이 디바이스의 구성도 일치해야 합니다. 

만약에 벤더 장비에서 이러한 연결을 지원하지 않는 경우에는 연결 양쪽에서 사용 사례에 해당하는 전체 대역을 기준으로 설정합니다.

즉 VPC 대역, IDC 대역을 입력하여 구성합니다. 

 

이렇게 구성하면 모든 내부 트래픽이 단일 SA를 통해 VPC로 전달되며, 추가적인 SA를 생성하지 않으므로 연결의 안정성을 유지할 수 있습니다.

 

속도 느려짐과 간헐적 끊김 현상

AWS Site-to-Site VPN이 제공하는 최대 대역폭은 1.2Gbps 입니다. 송수신되는 트래픽을 확인하여 혼잡상태가 발생하지는 않는지 확인해야 합니다. 

이를 확인하기 위해서는 Amazon CloudWatch 콘솔에서 TunnelDataIn 및 TunnelDataOut 메트릭을 확인하여 처리량이 1.2 Gbps 한계를 초과하는지 모니터링합니다. 

 

1. CloudWatch 콘솔 접속:
   • AWS Management Console에 로그인한 후, 상단의 서비스 메뉴에서 'CloudWatch'를 선택합니다.
2. 지표(Metrics) 선택:
   • 왼쪽 탐색 창에서 '지표(Metrics)'를 클릭합니다.
   • '모든 지표(All metrics)'를 선택한 후, 'VPN' 네임스페이스를 선택합니다.
   • 'VPN 터널 지표'를 선택하여 사용 가능한 지표 목록을 확인합니다.
3. TunnelDataIn 및 TunnelDataOut 지표 선택:
   • 목록에서 모니터링하려는 VPN 터널의 TunnelDataIn과 TunnelDataOut 지표를 각각 선택합니다.
4. 통계 및 기간 설정:
   • 선택한 지표의 통계를 '합계(Sum)'로 설정합니다.
   • 기간(Period)을 5분으로 설정하여 5분 간격의 데이터 포인트를 확인합니다.
5. 처리량 계산:
   • 각 데이터 포인트에서 다음 공식을 사용하여 처리량을 계산합니다

처리량(Mbps) = (((TunnelDataIn + TunnelDataOut) / 300) * 8) / 1,000,000

• 여기서 TunnelDataIn과 TunnelDataOut은 각각 5분(300초) 동안의 바이트 수입니다.
• 계산 결과가 1.2 Gbps(1,200 Mbps)를 초과하는지 확인합니다.

 

지속적으로 1.2 Gbps를 초과하는 처리량이 발생하는 경우, 두 개의 BGP 터널을 ECMP와 Transit Gateway를 사용하여 구성하는 것을 고려해야 합니다.

 

소스 및 대상 시스템을 격리하여 각각 변경할 때마다 문제가 지속되는지 확인합니다. 이를 통해 특정 시스템의 운영 체제 구성이나 기타 문제가 원인인지 파악할 수 있습니다. 

 

UDP 대역폭 테스트: iperf3 도구를 사용하여 양방향으로 UDP 대역폭을 테스트합니다. 예를 들어:

서버: sudo iperf -s -u [-p 5001]

클라이언트: sudo iperf3 -i 1 -u -p 33344 -b 1.2G -c <프라이빗 IP> -V

 

TCP 처리량 테스트: iperf3를 사용하여 양방향으로 TCP 처리량을 테스트합니다. 다양한 TCP 수신 윈도우 크기를 사용하여 소스 및 대상 메모리 버퍼를 테스트해 보세요. 예를 들어:

서버: iperf3 -s [-p 5001]

클라이언트:
sudo iperf3 -c <프라이빗 IP> -P 10 -w 128K -V
sudo iperf3 -c <프라이빗 IP> -P 10 -w 512K -V
sudo iperf3 -c <프라이빗 IP> -P 10 -w 1024K -V

이때, 사용 중인 Amazon EC2 인스턴스의 대역폭 크레딧이 충분한지 확인하거나, 더 큰 인스턴스 크기를 사용하여 다시 테스트합니다. 

 

본 테스트 과정에 있어서 경로상의 병목의 여부를 파악하는 것이 중요합니다. 예를 들어 내부 통신 구간이 10 Gbps로 구성되어 있을 거라고 생각했지만 일부 구간이 1 Gbps 구간이 존재하는 경우 병목이 발생할 수 있습니다. 또한 네트워크 통신의 혼잡이 병목의 원인이 될 수 있기에 평상시 네트워크 트래픽이 어느 정도인지 파악하고 테스트해야 정확한 결과를 얻을 수 있습니다.

 

IPsec 터널을 통해 트래픽을 전송할 때, 추가되는 헤더로 인해 패킷 크기가 증가하여 경로상의 MTU를 초과할 수 있습니다. 이를 방지하기 위해 TCP MSS(Maximum Segment Size)를 조정하여 패킷이 단편화되지 않도록 설정하는 것이 중요합니다.

일반적으로 이더넷의 기본 MTU는 1500Byte이지만 ESP(Encapsulating Security Payload) 터널 모드에서는 약 73바이트의 오버헤드가 추가될 수 있습니다.

이에 따라 다음과 같은 계산 공식을 사용할 수 있습니다.

• MSS = 경로상의 최소 MTU - IP 헤더 크기(20Byte) - TCP 헤더 크기(20Byte) - IPsec 오버헤드

예를 들어, 경로상의 최소 MTU가 1500Byte이고, IPsec 오버헤드가 73Byte인 경우이면 다음과 같이 MSS가 계산됩니다. 

• MSS = 1500 - 20 - 20 - 73 = 1387Byte

본 계산된 결과를 토대로 MSS가 1387Byte를 넘지 않도록 구성해야 합니다. 

 

ICMP를 사용하여 현재 구성된 MSS 크기를 확인하기 위해서는 다음 명령어를 활용할 수 있습니다. 

 

Linux/Unix 시스템에서의 방법:

ping 명령어 사용: ping 명령어에 -s 옵션을 사용하여 패킷의 데이터 부분 크기를 지정하고, -M do 옵션을 통해 패킷이 단편화되지 않도록 설정합니다.

ping -s [데이터 크기] -M do [대상 IP 주소]

예를 들어, 1472Byte의 데이터를 전송하려면 다음과 같이 입력합니다:

ping -s 1472 -M do [대상 IP 주소]

여기서 1472Byte는 IP 헤더(20Byte)와 ICMP 헤더(8Byte)를 포함하여 계산된 값입니다. 

 

Windows 시스템에서의 방법:

ping -f -l [데이터 크기] [대상 IP 주소]

여기서 -f 옵션은 'Don't Fragment' 플래그를 설정하여 패킷이 단편화되지 않도록 하고, -l 옵션은 데이터 크기를 지정합니다.

 

 

터널 구성후 UP 상태이지만 데이터 통신이 불가한 경우

AWS Site-to-Site VPN 구성이후 ICMP 통신 테스트는 정상이지만 실제 데이터 전송에 있어서 TIMEOUT과 같은 오류가 발생하는 경우 PMTUD(Path MTU Discovery)를 고려해야 합니다. 

 

Path MTU Discovery, PMTUD는 네트워크 경로 상에서 패킷이 단편화 없이 전달될 수 있는 MTU를 동적으로 결정하는 기술입니다. 이를 통해 송신자는 패킷 크기를 조정하여 네트워크 효율성을 높이고, 단편화로 인한 성능 저하를 방지할 수 있습니다.

 

작동 원리:

1. 초기 패킷 전송: 송신자는 DF(Don't Fragment) 플래그가 설정된 패킷을 수신자에게 전송합니다. 이 플래그는 패킷이 경로 상에서 단편화되지 않도록 지시합니다.
2. ICMP 메시지 수신: 경로 중간의 라우터나 장치가 해당 패킷을 처리할 수 없을 정도로 MTU가 작다면, 해당 장치는 송신자에게 ICMP "Fragmentation Needed" 메시지를 반환합니다. 이 메시지에는 허용 가능한 최대 패킷 크기 정보가 포함되어 있습니다.
3. 패킷 크기 조정: 송신자는 수신한 ICMP 메시지의 정보를 바탕으로 패킷 크기를 조정하여 다시 전송합니다. 이 과정을 반복하여 경로 상의 최소 MTU를 발견하게 됩니다.

위에서 "IPsec 터널을 통해 트래픽을 전송할 때, 추가되는 헤더로 인해 패킷 크기가 증가하여 경로상의 MTU를 초과할 수 있다"라고 이야기했습니다. 이때 ICMP Reply 메시지를 통해 해당 오류로 인해 패킷 사이즈를 조정하여 전달해야 하지만, 일부 사이트의 경우 ICMP를 보안상의 이유로 차단되어 ICMP "Fragmentation Needed" 메시지를 송신자에게 전달하지 못하게 됩니다.

이로 인해 송신자는 패킷 크기를 조정해야 한다는 사실을 인지하지 못하고, 계속해서 큰 크기의 패킷을 전송하게 되어 패킷 손실과 연결 지연 등의 문제가 발생하고 이를 PMTUD 블랙홀이라고 지칭합니다. 

 

IPv6 환경에서는 패킷 단편화를 지원하지 않기 때문에 ICMPv6의 "Packet Too Big" 메시지를 수신받지 못해 지속적인 패킷 손실이 발생할 수 있습니다. 

 

이러한 문제를 해결하기 위해서 다음과 같은 해결 방안을 제시합니다. 

• ICMP 메시지 허용: 방화벽이나 보안 장치의 설정을 조정하여 ICMP "Fragmentation Needed" 메시지가 송신자에게 전달될 수 있도록 허용합니다.
• MSS 클램핑(MSS Clamping): 라우터나 방화벽에서 TCP 세션 설정 시 최대 세그먼트 크기(MSS)를 조정하여 경로상의 최소 MTU에 맞게 패킷 크기를 제한하는 방법입니다. 
• PLPMTUD 사용: ICMP 메시지에 의존하지 않는 패킷화 계층 경로 MTU 발견(Packetization Layer Path MTU Discovery, PLPMTUD)을 구현하여 이러한 문제를 회피할 수 있습니다.

 

터널 교체 발생 

AWS Site-to-Site VPN의 터널이 교체되는 상황은 크게 2가지가 있습니다. 

1. DPD 설정에 의해 기존 SA가 끊어지는 경우 
2. AWS 관리에 의해 터널이 교체되는 경우 

안정적인 Site-to-Site VPN 구성을 위해 기본으로 권장되는 2개의 터널을 구성하는 것이 가장 좋습니다. 특히 AWS 터널 교체에 대한 내용은 고객이 직접 정할 수 없는 상황이기 때문에 "AWS Site-to-Site VPN 터널 엔드포인트 교체"에서 수명 주기 제어 내용을 확인하시기 바랍니다. 

 

일반적으로 2개의 터널 상태가 UP 상태로 유지되고 있는 상태에서는 터널 교체 작업이 일어나면 다른 터널로 자동으로 트래픽이 전달됩니다. 이때 잠깐의 순단이 발생할 수 있지만 전체적인 가용성이 유지되게 됩니다. 

 

AWS Site-to-Site VPN 연결은 고가용성을 위해 두 개의 중복 터널을 제공합니다. AWS는 이 중 하나를 기본 송신 경로로 선택하며, 이 선택은 상황에 따라 변경될 수 있습니다. 따라서, 두 터널을 모두 구성하고 비대칭 라우팅을 허용하는 것이 권장됩니다.

그러나 터널 교체 작업 이후 트래픽이 전송되지 않고 송신 측에서 재전송만 이루어지는 경우, 수신 측으로부터 데이터를 받지 못하는 상황이 발생할 수 있습니다. 이러한 문제는 벤더 장비의 우선순위 라우팅 기능이 활성화되어 있을 때 발생할 수 있습니다. 특히, 한 터널의 장애로 인해 페일오버가 발생한 후, 정상화된 이전 터널로 트래픽을 다시 전달하려는 경우에 이러한 현상이 나타날 수 있습니다.

따라서, 이러한 문제를 방지하기 위해 벤더 장비의 우선순위 라우팅 기능을 비활성화하는 것이 좋습니다. 이를 통해 트래픽이 두 터널 중 어느 하나로 원활하게 전송될 수 있으며, 비대칭 라우팅을 허용하여 고가용성을 유지할 수 있습니다.