일본 IDC 내 물리 서버와 한국 본사 네트워크 간 IPsec Site-to-Site VPN 구축 시 발생하는 MTU 설정 미흡 및 패킷 파편화 문제를 진단하고 최적화하는 실무 절차를 정리합니다.
1. 해외 거점 간 IPsec VPN 환경에서 MTU 및 MSS 문제의 발생 원인
한국 본사 또는 타 지역 오피스와 일본 데이터센터(IDC) 간에 전용 회선 대신 인터넷망을 이용한 IPsec Site-to-Site VPN을 구축하여 운영하는 사례가 늘고 있습니다. 보안성을 확보하면서도 경제적인 인프라 연동을 구현할 수 있다는 장점이 있지만, 실제 운영 과정에서 특정 웹 페이지가 로딩되지 않거나 대용량 파일 전송 및 SSH 접속이 중간에 끊어지는 현상이 발생하곤 합니다.
이러한 현상의 주요 원인 중 하나는 네트워크의 최대 전송 단위인 MTU(Maximum Transmission Unit) 설정 오류와 이에 따른 패킷 파편화(Fragmentation)입니다. 일반적인 이더넷(Ethernet) 환경의 기본 MTU 크기는 1500바이트로 설정되어 있습니다. 하지만 IPsec VPN 터널을 거치게 되면 데이터 패킷에 ESP(Encapsulating Security Payload) 헤더, IPsec 헤더, Outer IP 헤더, IV(Initialization Vector) 및 Tail 등의 암호화 관련 오버헤드가 추가됩니다.
결과적으로 원래 원본 패킷 크기에 추가적인 캡슐화 헤더가 붙으면서 전체 패킷 크기가 물리 회선의 기본 MTU를 초과하게 됩니다. 이 경우 중간 라우터에서 패킷을 여러 개로 쪼개는 파편화 작업이 일어나거나, DF(Don’t Fragment) 비트가 설정되어 있는 경우 패킷이 드랍되어 인프라 통신 장애로 이어지게 됩니다.
2. MTU 미스매치와 DF Bit가 네트워크 성능에 미치는 영향
네트워크 패킷에 DF 비트가 활성화된 상태에서 경로 상의 특정 구간 MTU보다 큰 패킷이 전달되면, 해당 라우터는 ICMP Type 3 Code 4(Destination Unreachable, Fragmentation Needed and DF set) 메시지를 송신자에게 반환합니다. 수신 측 또는 송신 측에서 이 ICMP 메시지를 정상적으로 수신하면 패킷 크기를 줄여 다시 전송하는 PMTUD(Path MTU Discovery) 프로세스가 동작하게 됩니다.
그러나 많은 기업용 보안 장비나 IDC 방화벽 환경에서는 보안 정책상의 이유로 ICMP 패킷을 차단하는 경우가 존재합니다. ICMP 차단으로 인해 ICMP Fragmentation Needed 메시지가 손실되면, 송신자는 패킷이 전송되지 못한 원인을 알지 못한 채 응답을 계속 기다리는 스피닝 상태 또는 타임아웃 상태에 빠지게 됩니다. 이를 네트워크 기술 용어로 블랙홀(Black Hole) 현상이라고 부릅니다.
파편화가 시스템에 미치는 주요 리스크
- CPU 자원 소모 증가: 라우터 및 서버가 패킷을 분할하고 수신 측에서 재조합(Reassembly)하는 과정에서 암호화 처리와 맞물려 CPU 하드웨어 자원을 지속적으로 소모합니다.
- 패킷 손실률 증대: 분할된 여러 패킷 조각 중 단 하나라도 손실될 경우 전체 TCP 패킷을 재전송해야 하므로 지연 시간(Latency)이 급증합니다.
- TCP 윈도우 스루풋 저하: 잦은 패킷 재전송으로 인해 TCP의 Congestion Window 크기가 축소되어 전체 대역폭 활용 효율이 급격히 떨어집니다.
3. PMTUD(Path MTU Discovery) 진단 및 최적 MTU/MSS 산출 방법
일본 IDC 서버와 한국 오피스 간 IPsec 터널에서 적절한 MTU 크기를 산출하려면 실제 경로 상에서의 병목 구간을 진단해야 합니다. Ping 도구의 DF 비트 고정 옵션과 패킷 크기 설정 옵션을 조합하여 파편화 없이 통신 가능한 최대 패킷 사양을 파악할 수 있습니다.
진단 명령어 구성 및 응답 분석
Linux 환경에서는 ping 명령어에 -M do 옵션을 부여하여 DF 비트를 설정할 수 있으며, Windows 환경에서는 ping -f -l [크기] [목적지IP] 형태를 사용합니다. 패킷 크기를 1472바이트부터 시작하여 ICMP 응답이도착할 때까지 점진적으로 감소시키며 테스트를 진행합니다.
ICMP 패킷의 헤더 크기는 IP 헤더 20바이트와 ICMP 헤더 8바이트를 합쳐 총 28바이트를 차지합니다. 따라서 ping 명령어의 데이터 필드 크기가 1448바이트에서 파편화 없이 통신에 성공했다면, 해당 구간의 실제 IP MTU는 1448 + 28 = 1476바이트로 산출됩니다.
IPsec 오버헤드를 고려한 MSS(Maximum Segment Size) 계산
TCP 통신에서는 세그먼트의 최대 크기인 MSS를 MTU에 기초하여 결정합니다. IPsec 암호화 알고리즘(AES-GCM, AES-CBC 등) 및 인증 방식(SHA-256 등)에 따라 추가되는 오버헤드 크기가 달라집니다.
일반적으로 IPsec ESP 암호화 사용 시 60~72바이트 수준의 오버헤드가 추가됩니다. 따라서 물리적 MTU가 1500바이트인 환경에서의 안전한 IPsec Tunnel MTU는 약 1420~1440바이트 수준으로 산정되며, TCP MSS 클램핑 값은 1380~1400바이트 수준으로 조정하는 것이 표준적인 가이드라인입니다.
4. 일본 IDC 서버 및 네트워크 장비에서의 MTU/MSS 최적화 설정 절차
산출된 최적 값을 토대로 IDC 내 서버 OS 및 보안 장비, 라우터 단에서 적절한 정책을 적용해야 합니다. 호스트 레벨과 네트워크 장비 레벨 모두에서 이중 조치를 취하는 것이 가장 안정적입니다.
서버 OS 차원의 네트워크 인터페이스 MTU 변경
Linux 시스템에서는 ip link set dev [인터페이스명] mtu [크기] 명령을 적용하거나, /etc/netplan/ 또는 /etc/sysconfig/network-scripts/의 네트워크 설정 파일에 MTU 항목을 명시하여 영구 반영합니다. Windows Server 환경에서는 netsh interface ipv4 set subinterface 명령을 통해 MTU 값을 조율할 수 있습니다.
라우터 및 방화벽에서의 TCP MSS Clamping 설정
개별 서버의 MTU 설정 변경 외에도, 네트워크 경계에 위치한 방화벽이나 라우터에서 SYN 패킷을 가로채 MSS 값을 강제로 변경해 주는 TCP MSS Clamping 기능(iptables의 TCPMSS target 설정 등)을 적용할 수 있습니다. 이를 활용하면 내부 서버들의 개별 설정을 변경하지 않고도 IPsec 터널을 통과하는 모든 TCP 세션을 자동으로 최적화할 수 있습니다.
HARU IDC의 경우 고객사가 원격지 간 터널링을 안정적으로 운영할 수 있도록 인프라 네트워크 단의 PMTUD 허용 상태 및 상위 게이트웨이의 MTU 특성을 사전 점검하여 기술 지원을 제공하고 있습니다.
5. VPN 네트워크 성능 및 파편화 방지 검증 체크리스트
IPsec VPN 설정을 완료한 후에는 실제 업무 서비스 트래픽이 정상적으로 파편화 없이 전달되는지 다각도로 검증하는 절차가 필요합니다.
| 점검 항목 | 검증 방법 및 도구 | 판정 기준 및 정상 상태 | 비고 및 조치사항 |
|---|---|---|---|
| DF Bit 설정 핑 테스트 | ping -f -l [Size] (Win) / ping -M do -s [Size] (Linux) | 파편화 오류 없이 ICMP Reply 수신 확인 | 응답 실패 시 MSS/MTU 크기 8~16바이트 추가 감소 |
| ICMP Type 3 차단 여부 | 경로 상의 ICMP Unreachable 패킷 덤프 확인 | PMTUD용 ICMP 패킷이 방화벽에서 Drop되지 않음 | 방화벽 정책에서 Type 3 Code 4 허용 규칙 추가 |
| TCP MSS Clamping 동적 적용 | tcpdump / Wireshark로 SYN 패킷의 MSS Option 수집 | 설정한 MSS 범위 내에서 TCP Handshake 체결 | 게이트웨이 장비의 MSS 수정 룰 적용 우선순위 확인 |
| 대용량 파일 전송 스루풋 | SCP / SFTP / iPerf3 기반의 파일 전송 테스트 | 속도 저하나 세션 끊김 없이 지속적인 전송 유지 | 재전송 비율(Retransmission Rate) 최소화 유지 확인 |
| IPsec SA 보안 연동 상태 | 보안 장비의 IPsec Tunnel Phase 2 상태 모니터링 | Inbound/Outbound 오류 패킷 및 파편화 카운트 0 유지 | 암호화 캡슐화 처리부 하드웨어 가속 여부 점검 |
6. 안정적인 해외 인프라 운영을 위한 네트워크 종합 관리 방안
국가 간 네트워크 연결은 지리적 거리와 복잡한 transit 개입으로 인해 단일 경로 설정만으로 지속적인 안정성을 유지하기 어렵습니다. 따라서 단순한 MTU/MSS 조율에 그치지 않고 통합적인 인프라 모니터링 및 복구 체계를 구축해야 합니다.
정기적인 네트워크 지표 모니터링
IPsec 터널 내부 트래픽의 재전송률, 패킷 손실률, 인터페이스 에러 카운터, RTT(Round Trip Time) 변화 추이를 Prometheus, Zabbix 등의 모니터링 도구로 실시간 수집해야 합니다. 지연 시간이 갑자기 증가하거나 패킷 재전송이 급증하는 경우, 중간 라우팅 경로의 변동이나 MTU 미스매치로 인한 파편화 현상이 재발했을 가능성을 의심해야 합니다.
물리 서버 인프라와의 시너지 구상
퍼블릭 클라우드 환경에서는 클라우드 사업자의 가상 네트워크 스위치 레이어에서 MTU가 제약되는 경우가 많습니다. 반면 HARU IDC와 같은 전용 서버 호스팅 환경에서는 물리적 NIC 옵션 및 가상화 Hypervisor 수준에서 네트워크 설정을 유연하게 통제할 수 있어 기업의 복잡한 VPN 및 네트워크 토폴로지에 맞춘 정교한 최적화가 가능합니다.
기업의 중요 데이터를 한국 본사와 일본 서버 간에 안전하게 이관하고 저지연 연동을 구현하기 위해서는 초기 인프라 설계 단계부터 IPsec VPN의 암호화 overhead, 네트워크 레벨의 MTU 최적화, 그리고 ICMP 통신 정책을 통합적으로 고려하는 접근이 필요합니다.
기업용 VPN 구성이 필요하신가요?
고정 IP, 관리자 접근 제한, 원격 업무 환경에 맞는 VPN 구성을 안내해드립니다.