소개
이 문서에서는 정책 기반 VPN 터널 내의 암호화 ACL(Access Control List) 카운터의 동작을 설명합니다.
사전 요구 사항
요구 사항
Cisco에서는 다음 항목에 대한 지식을 권장합니다.
- Cisco IOS® /Cisco IOS® XE 플랫폼의 정책 기반 사이트 대 사이트 VPN
- Cisco IOS/Cisco IOS XE Platform의 액세스 제어 목록
사용되는 구성 요소
이 문서의 정보는 다음 소프트웨어 및 하드웨어 버전을 기반으로 합니다.
- Cisco C8kv, 버전 17.12.04(MD)
이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다. 이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다. 현재 네트워크가 작동 중인 경우 모든 명령의 잠재적인 영향을 미리 숙지하시기 바랍니다.
토폴로지
토폴로지
시나리오
서로 다른 두 가지 시나리오를 검토함으로써 서로 다른 피어에서 트래픽이 시작되고 터널이 재설정될 때 ACL 적중 횟수가 어떻게 영향을 받는지 파악하는 데 목적이 있습니다.
-
시나리오 1: VPN 터널이 비활성 상태일 때 라우터 1에서 시작된 트래픽
이 시나리오에서는 VPN 터널이 초기에 중단되고 트래픽이 Router1에서 시작될 때 ACL 적중 횟수의 변경 사항을 분석합니다. 이 분석을 통해 초기 설정 및 암호화 ACL 카운터가 첫 번째 트래픽 흐름 시도에 어떻게 반응하는지 알 수 있습니다.
-
시나리오 2: VPN 터널이 활성 상태일 때 라우터 2에서 시작된 트래픽
이 시나리오에서는 VPN 터널이 이미 설정되어 있고 Router2에서 시작된 트래픽에 대해 살펴봅니다. 이 시나리오에서는 터널이 활성 상태이고 다른 피어에서 트래픽이 유입될 때 ACL 카운터가 어떻게 동작하는지 알아봅니다.
이러한 시나리오를 비교하여 다양한 조건에서 VPN 터널의 ACL 카운터 역학을 포괄적으로 이해할 수 있습니다.
설정
피어로 지정된 2개의 Cisco C8kv 라우터 간에 정책 기반 Site-to-Site VPN 터널을 구성했습니다. 라우터1의 이름은 "csr1"이고 라우터2의 이름은 "csr2"입니다.
Router1의 암호화 컨피그레이션
csr1#sh ip int br
Interface IP-Address OK? Method Status Protocol
GigabitEthernet1 10.106.62.62 YES NVRAM up up
GigabitEthernet2 10.106.67.27 YES NVRAM up up
csr1#sh run | sec crypto map
crypto map nigarapa_map 100 ipsec-isakmp
set peer 10.106.44.144
set transform-set new_ts
set ikev2-profile new_profile
match address new_acl
csr1#sh ip access-lists new_acl
Extended IP access list new_acl
10 permit ip 10.106.67.0 0.0.0.255 10.106.45.0 0.0.0.255 log
20 permit ip 10.106.67.0 0.0.0.255 10.106.46.0 0.0.0.255
30 permit ip 10.106.67.0 0.0.0.255 10.106.63.0 0.0.0.255 log
csr1#sh run int GigabitEthernet1
Building configuration...
Current configuration : 162 bytes
!
interface GigabitEthernet1
ip address 10.106.62.62 255.255.255.0
ip nat outside
negotiation auto
no mop enabled
no mop sysid
crypto map nigarapa_map
end
라우터2의 암호화 컨피그레이션
csr2#sh ip int br
Interface IP-Address OK? Method Status Protocol
GigabitEthernet1 10.106.44.144 YES NVRAM up up
GigabitEthernet2 10.106.45.145 YES NVRAM up up
GigabitEthernet3 10.106.46.146 YES NVRAM up up
GigabitEthernet4 10.106.63.13 YES NVRAM up up
csr2#sh run | sec crypto map
crypto map nigarapa_map 100 ipsec-isakmp
set peer 10.106.62.62
set transform-set new_ts
set ikev2-profile new_profile
match address new_acl
csr2#sh ip access-lists new_acl
Extended IP access list new_acl
10 permit ip 10.106.45.0 0.0.0.255 10.106.67.0 0.0.0.255
20 permit ip 10.106.46.0 0.0.0.255 10.106.67.0 0.0.0.255
30 permit ip 10.106.63.0 0.0.0.255 10.106.67.0 0.0.0.255
csr2#sh run int GigabitEthernet1
Building configuration...
Current configuration : 163 bytes
!
interface GigabitEthernet1
ip address 10.106.44.144 255.255.255.0
ip nat outside
negotiation auto
no mop enabled
no mop sysid
crypto map nigarapa_map
end
VPN 터널 내 Crypto Access Control List 카운터의 동작 분석
처음에는 두 디바이스 모두 각각의 암호화 액세스 목록에서 ACL 적중 횟수가 0입니다.
두 피어 디바이스의 각 암호화 액세스 목록에서 Access Control List 적중 횟수가 0입니다.
시나리오 1: VPN 터널이 비활성 상태일 때 라우터 1에서 시작된 트래픽
초기 상태:
Router1(IP: 10.106.67.27) 및 라우터2(IP: 10.106.45.145는 현재 비활성 상태입니다.
수행한 작업:
트래픽은 Router2와의 통신을 설정하기 위해 Router1에서 시작됩니다.
관찰:
- ACL 카운터 동작:
a. Router1에서 트래픽을 시작하면 Router1의 ACL(Access Control List) 카운터가 눈에 띄게 증가합니다. 이 증가는 터널이 설정하려고 시도하는 순간에 한 번만 발생합니다.
b. ACL 카운터의 증가는 이 시나리오의 Router1인 시작 라우터에서만 관찰됩니다. 이 단계에서 라우터2는 ACL 카운터의 변경 사항을 반영하지 않습니다.
- 터널 설정:
a. 트래픽 시작에 해당하는 초기 증가 후 첫 번째와 라우터 2 간의 터널이 성공적으로 설정됩니다.
b. 터널 설정 후, Router1의 ACL 카운터가 안정화되며 더 이상 증가하지 않습니다. 이는 ACL 규칙이 일치했으며 현재 설정된 터널을 통해 트래픽을 지속적으로 허용하고 있음을 나타냅니다.
- 터널 재시작:
Router1의 ACL 카운터는 터널이 삭제되어 다시 설정해야 하는 경우에만 또 다른 증가를 경험합니다. 이는 ACL 규칙이 터널이 활성화된 후 지속적인 데이터 전송이 아니라 터널 설정을 시도하는 초기 트래픽 시작에 의해 트리거된다는 것을 의미합니다.
요약하면, 이 시나리오에서는 Router1의 ACL 카운터가 터널 생성을 위한 초기 트래픽 시도에 민감하지만 VPN 터널이 가동되고 작동하면 고정 상태로 유지된다는 것을 보여줍니다.
시나리오 1
시나리오 2: VPN 터널이 활성 상태일 때 라우터2에서 시작된 트래픽
초기 상태:
Router1(IP: 10.106.67.27) 및 라우터2(IP: 10.106.45.145)이 현재 활성 상태이며 작동 중입니다.
수행한 작업:
- 터널이 가동되는 동안 Router2에서 Router1으로 트래픽이 시작됩니다.
- 그런 다음 터널이 의도적으로 지워지거나 재설정됩니다.
- 터널이 지워지면 Router2가 트래픽을 다시 시작하여 연결을 다시 설정합니다.
관찰:
- 초기 트래픽 시작:
a. 터널이 이미 설정된 상태에서 라우터2에서 처음으로 트래픽이 시작되면 ACL(Access Control List) 카운터가 즉시 변경되지 않습니다.
b. 이는 이미 설정된 터널 내에서 진행 중인 트래픽이 ACL 카운터 증분을 트리거하지 않음을 나타냅니다.
- 터널 지우기 및 다시 시작:
a. 터널을 지우면 첫 번째 라우터와 라우터 2 간의 설정된 연결이 일시적으로 중단됩니다. 따라서 후속 트래픽에 대한 재설정 프로세스가 필요합니다.
b. 터널이 지워진 후 Router2에서 트래픽이 다시 시작되면 Router2의 ACL 카운터에서 관찰할 수 있는 증가분이 있습니다. 이 증가분은 터널 생성을 용이하게 하기 위해 ACL 규칙이 한 번 더 관련되어 있음을 나타냅니다.
- ACL 카운터 특이성:
ACL 카운터의 증분은 트래픽을 시작하는 쪽에서만 발생하며, 이 경우 Router2입니다. 이 동작은 시작 쪽에서 트래픽 시작 프로세스를 모니터링하고 제어하는 ACL의 역할을 강조하는 반면, 이 단계에서 Router1의 ACL 카운터는 영향을 받지 않습니다.
요약하면, 이 시나리오에서는 VPN 터널을 다시 설정할 때 Router2의 ACL 카운터가 트래픽 시작에 응답함을 보여줍니다. 활성 터널 내에서 정기적인 트래픽 흐름에 따라 카운터가 증가하지는 않지만, 터널 재설정이 필요한 경우에는 그에 대응하여 터널 시작 이벤트를 정밀하게 추적할 수 있습니다.
시나리오 2
결론:
암호화 ACL 카운터의 동작은 VPN 터널의 시작 단계 동안에만 히트 수를 등록한다는 것을 나타냅니다.
개시자별 증가: 터널이 Router1에서 시작되면 히트 수가 Router1에서만 증가합니다. 마찬가지로, 시작이 Router2에서 발생하면 히트 수는 Router2에서만 증가합니다. 이렇게 하면 소스에서 트래픽 시작 프로세스를 모니터링하는 데 ACL의 역할이 강조됩니다.
안정성 구축 후: 터널이 성공적으로 설정되면 두 피어의 ACL 카운터는 변경되지 않았으므로 더 이상 적중이 발생하지 않음을 나타냅니다. 이러한 안정성은 터널이 지워지거나 재설정될 때까지 지속되며 트래픽 초기화가 다시 시도됩니다.
이 동작은 터널 생성의 초기 단계를 추적 및 제어하는 액세스 제어 목록의 기능을 강조하여 설정된 터널 내의 후속 데이터 흐름이 적중 횟수에 영향을 미치지 않도록 합니다.
핵심 요점:
ACL 카운터 동작: ACL 카운터는 터널 시작 프로세스 중에 개시자 측에서만 등록합니다. 이는 카운터가 터널 설정을 트리거하는 초기 트래픽을 모니터링하도록 설계되었음을 나타냅니다.
설정 후 정적 카운터: 터널이 활성화되고 설정되면 ACL 카운터는 변경되지 않습니다. 터널이 재설정되고 다시 시작해야 하는 경우가 아니면 추가 작업을 반영하지 않으므로 초기 트래픽 이벤트에 중점을 둡니다.
트래픽 시작 특이성: ACL 적중 횟수는 터널을 시작하는 피어에 따라 다릅니다. 이러한 특이성으로 VPN 연결을 시작하는 측에 대한 정확한 추적을 보장하므로 정확한 모니터링 및 제어가 가능합니다.