IPsec 정적 가상 터널 인터페이스 (Static VTI)

IPsec VTI(Virtual Tunnel Interface) 는 사이트 간 IPsec VPN을 구성하는 더 새로운 방법입니다. VPN을 구성하는 더 단순한 방법으로, 터널 인터페이스를 사용하며, 어떤 트래픽을 암호화할지 정의하기 위해 더 이상 까다로운 access-list와 crypto-map을 사용할 필요가 없습니다.

1. 구성

예제를 살펴봅시다. 다음 토폴로지를 사용합니다.

R1과 R2는 사이트 간 IPsec VPN에 사용될 두 라우터입니다. 터널과 종단점을 수동으로 구성할 것이므로, 이는 정적 가상 터널 인터페이스(static virtual tunnel interface) 가 됩니다. H1과 H2는 터널을 테스트하는 데 사용됩니다.

R1부터 시작합시다.

1.1. R1

IPsec phase 1 구성부터 시작합니다.

R1(config)# crypto isakmp policy 1
R1(config-isakmp)# encryption aes
R1(config-isakmp)# authentication pre-share
R1(config-isakmp)# group 2

원격 이웃(R2)을 구성합니다.

R1(config-isakmp)# crypto isakmp key MY_PASSWORD address 192.168.12.2

이제 phase 2를 구성할 수 있습니다.

R1(config)# crypto ipsec transform-set MY_TRANSFORM_SET esp-aes esp-sha-hmac
R1(cfg-crypto-trans)# mode tunnel
R1(config)# crypto ipsec profile IPSEC_PROFILE
R1(ipsec-profile)# set transform-set MY_TRANSFORM_SET

이 부분이 훨씬 단순합니다. transform-set과 crypto IPsec profile만 만들면 됩니다. crypto IPsec profile은 transform-set을 참조합니다. 더 이상 crypto-map을 만들고 외부 인터페이스에 적용할 필요가 없습니다.

이제 모든 것을 터널 인터페이스에 결합합니다.

R1(config)# interface Tunnel 0
R1(config-if)# ip address 12.12.12.1 255.255.255.0
R1(config-if)# tunnel source 192.168.12.1
R1(config-if)# tunnel destination 192.168.12.2
R1(config-if)# tunnel mode ipsec ipv4
R1(config-if)# tunnel protection ipsec profile IPSEC_PROFILE

터널 인터페이스의 구성은 일반 GRE 터널과 비슷합니다. 소스와 목적지 IP 주소를 설정합니다. 그러나 터널 모드는 IPsec IPv4이며 IPsec 프로파일을 추가해야 합니다.

마지막으로, 다른 쪽의 서브넷을 가리키는 라우트가 있는지 확인합니다. 목적지는 터널 인터페이스입니다.

R1(config)# ip route 192.168.2.0 255.255.255.0 Tunnel0

필요한 것은 그게 전부입니다.

1.2. R2

R2의 구성은 IP 주소를 제외하고 정확히 동일합니다.

R2(config)# crypto isakmp policy 1
R2(config-isakmp)# encryption aes
R2(config-isakmp)# authentication pre-share
R2(config-isakmp)# group 2
R2(config-isakmp)# crypto isakmp key MY_PASSWORD address 192.168.12.1

R2(config)# crypto ipsec transform-set MY_TRANSFORM_SET esp-aes esp-sha-hmac
R2(cfg-crypto-trans)# mode tunnel

R2(config)# crypto ipsec profile IPSEC_PROFILE
R2(ipsec-profile)# set transform-set MY_TRANSFORM_SET

R2(config)# interface Tunnel0
R2(config-if)# ip address 12.12.12.2 255.255.255.0
R2(config-if)# tunnel source 192.168.12.2
R2(config-if)# tunnel destination 192.168.12.1
R2(config-if)# tunnel mode ipsec ipv4
R2(config-if)# tunnel protection ipsec profile IPSEC_PROFILE

R2(config)# ip route 192.168.1.0 255.255.255.0 Tunnel0

그게 전부입니다.

2. 검증

이것이 작동하는지 봅시다! 빠른 핑부터 시작합니다.

H1# ping 192.168.2.200
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.2.200, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 18/24/37 ms

이 핑은 유망합니다. R1과 R2의 정적 라우트가 터널 인터페이스를 가리킨다는 것을 기억하세요. 그래서 적어도 작동하고 있을 가능성이 높다는 것을 알려줍니다. 터널 인터페이스를 더 자세히 살펴봅시다.

R1# show interfaces Tunnel 0
Tunnel0 is up, line protocol is up
  Hardware is Tunnel
  Internet address is 12.12.12.1/24
  MTU 17878 bytes, BW 100 Kbit/sec, DLY 50000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation TUNNEL, loopback not set
  Keepalive not set
  Tunnel linestate evaluation up
  Tunnel source 192.168.12.1, destination 192.168.12.2
  Tunnel protocol/transport IPSEC/IP
  Tunnel TTL 255
  Tunnel transport MTU 1438 bytes
  Tunnel transmit bandwidth 8000 (kbps)
  Tunnel receive bandwidth 8000 (kbps)
  Tunnel protection via IPSec (profile "IPSEC_PROFILE")

위 출력은 유용합니다. 터널 인터페이스가 가동 중이고, IPsec을 사용하고 있으며, IPsec 프로파일을 보여줍니다. IPsec 세션을 더 자세히 살펴봅시다.

R1# show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id status
192.168.12.2    192.168.12.1    QM_IDLE           1001 ACTIVE

Phase 1은 QM_IDLE 상태로 정상적으로 올라와 있습니다. Phase 2 SA도 확인합니다.

R1# show crypto ipsec sa

interface: Tunnel0
    Crypto map tag: Tunnel0-head-0, local addr 192.168.12.1

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
   remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
   current_peer 192.168.12.2 port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 5, #pkts encrypt: 5, #pkts digest: 5
    #pkts decaps: 5, #pkts decrypt: 5, #pkts verify: 5
    ...
     inbound esp sas:
      spi: 0xABCD1234(...)
        transform: esp-aes esp-sha-hmac ,
        in use settings ={Tunnel, }

여기서 눈여겨볼 포인트는 두 가지입니다.

• local/remote ident가 0.0.0.0/0.0.0.0, 즉 모든 트래픽을 보호하는 SA가 만들어졌다는 점입니다. crypto map + ACL 방식과 달리 “보호할 트래픽”을 따로 정의하지 않고, 터널 인터페이스를 통해 나가는 모든 트래픽이 자동으로 IPsec에 의해 암호화됩니다.
• inbound esp sas에 transform-set과 Tunnel 모드가 그대로 보입니다. 외부 IP 헤더는 192.168.12.1 ↔ 192.168.12.2, 그 내부는 ESP로 암호화됩니다.

라우팅도 간단합니다. R1에서 show ip route를 보면 원격 LAN이 터널 인터페이스로 향합니다.

R1# show ip route | include Tunnel0
S    192.168.2.0/24 is directly connected, Tunnel0

터널에 라우팅 프로토콜(OSPF/EIGRP 등)을 돌려서 사이트 간 라우트를 자동으로 교환해도 됩니다. GRE over IPsec과의 가장 큰 차이는 GRE 헤더가 빠진다는 점입니다. 동일한 페이로드라면 오버헤드가 더 작습니다.

참고: 이 구성은 R1과 R2가 192.168.12.0/24로 직접 연결된 경우를 가정하고 있지만, 실제 환경에서는 중간에 다른 라우터가 있어도 됩니다. 중요한 것은 tunnel source와 tunnel destination에 지정한 IP가 라우팅 테이블상 서로 도달 가능하기만 하면 된다는 점입니다. 예를 들어 R1–R_mid–R3 구조라면 R1에서 tunnel destination을 R3의 공인 IP로 주고, 그 주소에 대한 underlay 라우트가 R_mid를 경유하도록만 해 주면 됩니다.

참고: 플랫폼/IOS 버전에 따라 tunnel mode ipsec ipv4를 쓰면 터널이 올라오지 않고, tunnel protection ipsec profile ...만 남겨야 통신이 되는 경우가 보고됩니다(예: 일부 GNS3의 C7200 이미지). 이때 내부적으로는 GRE over IPsec 조합으로 동작하는 것과 유사하며, ESP로 암호화된 트래픽이 WAN으로 나가는지 패킷 캡처로 확인하면 됩니다. 운영용 ISR/ASR 최신 IOS-XE에서는 이 조합이 문제 없이 동작합니다.

3. Crypto Map vs VTI — 왜 갈아타야 하는가

sVTI는 단순히 “최신 방식”이 아니라, 기존 crypto map 기반 IPsec의 구조적 한계를 해결하기 위해 등장했습니다. 둘의 차이를 구체적으로 비교하면:

전형적 Crypto Map 실패 사례

! R1 (잘못 설정 — 넓게 잡음)
access-list 101 permit ip 10.0.0.0 0.255.255.255 10.0.0.0 0.255.255.255

! R2 (좁게 잡음)
access-list 101 permit ip 10.1.0.0 0.0.255.255 10.2.0.0 0.0.255.255

IKE phase 1은 성공(피어 인증 완료), phase 2도 일부 트래픽은 통과 → 하지만 ACL 범위 불일치로 특정 흐름만 암호화 안 됨. show crypto ipsec sa로 SA는 정상 보이고 debug crypto ipsec에서야 “proxy_ID mismatch” 로그가 잡히는데, 초심자가 이걸 찾기까지 수시간 걸림. VTI에선 이런 구조적 실수 자체가 불가능.

언제 Crypto Map이 아직 유효한가

• 상대측이 Crypto Map 전용: 일부 ASA 구형, 타 벤더 일부
• VRF 분리 정책이 복잡한 경우: 초기 VRF-aware IPsec에서 VTI가 덜 성숙했던 시기 흔적
• 감사 요구로 ACL 기반 “어떤 트래픽이 암호화되는가”를 명시적으로 문서화해야 할 때

위 특수한 경우가 아니라면 신규 배치는 **VTI(IKEv2 + sVTI 또는 DVTI)**가 정답입니다.

4. 결론

• IPsec sVTI는 기존의 crypto map + crypto ACL 방식이 가진 불편함(보호 대상 ACL을 양쪽에서 대칭으로 맞추기, 물리 인터페이스에 crypto map을 일일이 적용하기 등)을 제거하고, 터널 인터페이스 한 개 = 하나의 사이트 간 VPN 이라는 단순한 모델을 제공합니다.
• 구성의 핵심은 세 가지입니다. (1) ISAKMP 정책 + PSK로 phase 1 파라미터, (2) transform-set을 참조하는 crypto ipsec profile, (3) interface Tunnel N에 tunnel mode ipsec ipv4 + tunnel protection ipsec profile .... 이 이후로는 터널 인터페이스를 일반 라우팅 가능한 L3 인터페이스처럼 취급할 수 있습니다.
• 터널 인터페이스 위에 정적 라우트나 동적 라우팅 프로토콜(OSPF/EIGRP)을 그대로 얹을 수 있고, 보호 대상은 “터널로 향하는 모든 트래픽”이라는 단순한 규칙으로 결정됩니다. 즉, 라우팅이 정책이 됩니다.
• GRE over IPsec과 비교했을 때 sVTI는 GRE 헤더 오버헤드가 없고 구성도 더 간결하지만, 그 대가로 IP 멀티캐스트/브로드캐스트가 기본적으로 캡슐화되지 않습니다. 라우팅 프로토콜 중 hello가 유니캐스트로 갈 수 있는 것(예: BGP, ip ospf network point-to-point로 설정한 OSPF)은 sVTI 위에서도 잘 돌아가지만, EIGRP hello 멀티캐스트 등이 필요하다면 GRE over IPsec이 더 적합할 수 있습니다.
• 언제나 정적으로 피어가 정해져 있는 사이트 대 사이트 VPN이라면 sVTI가 현대적 기본값입니다. 피어가 동적이거나 hub-and-spoke 규모가 크다면 이후 다루는 DMVPN/FlexVPN 계열로 확장하는 것을 권장합니다.

출처: networklessons.com - IPSec Static Virtual Tunnel Interface

태그: IPSec, Security