Cisco IOS를 통한 정책 라우팅 및 ESP 및 ISAKMP 패킷에 미치는 영향

Size: px

Start display at page:

Download "Cisco IOS를 통한 정책 라우팅 및 ESP 및 ISAKMP 패킷에 미치는 영향"

지헌 빙
2 years ago
Views:

1 Cisco IOS 를통한정책라우팅및 ESP 및 ISAKMP 패킷에미치는영향 목차 소개사전요구사항요구사항사용되는구성요소배경정보라우터에서로컬로생성된트래픽토폴로지구성디버깅라우터를통한전송트래픽토폴로지구성디버깅동작차이점요약컨피그레이션예토폴로지구성테스트중위험요소로컬로생성된트래픽 PBR 이없는컨피그레이션예요약다음을확인합니다. 문제해결관련정보 소개 이문서에서는 Cisco IOS 를사용할때 ESP(Encapsulating Security Payload) 및 ISAKMP(Internet Security Association and Key Management Protocol) 패킷에적용되는 PBR(Policy Based Routing) 및로컬 PBR 의영향에대해설명합니다. 기고자 : Cisco TAC 엔지니어 Michal Garcarz

2 사전요구사항 요구사항 Cisco 에서는이러한주제에대한기본적인지식을얻을것을권장합니다. Cisco IOS Cisco IOS의 VPN 컨피그레이션 사용되는구성요소 이문서의정보는 Cisco IOS 버전 15.x 를기반으로합니다. 이문서의정보는특정랩환경의디바이스를토대로작성되었습니다. 이문서에사용된모든디바이스는초기화된 ( 기본 ) 컨피그레이션으로시작되었습니다. 현재네트워크가작동중인경우, 모든명령어의잠재적인영향을미리숙지하시기바랍니다. 배경정보 IPsec 터널설정전에라우터는 ISAKMP 교환을시작합니다. 이러한패킷은라우터에서생성되므로패킷은로컬에서생성된트래픽으로처리되며로컬 PBR 결정이적용됩니다. 또한라우터 (EIGRP(Enhanced Interior Gateway Routing Protocol), NHRP(Next Hop Resolution Protocol), BGP(Border Gateway Protocol) 또는 ICMP(Internet Control Message Protocol) ping) 에서생성된패킷은로컬에서생성된트래픽으로간주되며로컬 PBR 결정이적용됩니다. 라우터에서전달되고통과트래픽이라고하는터널을통해전송되는트래픽은로컬에서생성된트래픽으로간주되지않으며, 원하는라우팅정책을라우터의인그레스인터페이스에적용해야합니다. 이트래픽이터널을통과하는트래픽에미치는영향은로컬에서생성된트래픽이 PBR 을따르지만통과트래픽은그렇지않다는것입니다. 이문서에서는이러한행동의차이에대한결과를설명합니다. ESP 가캡슐화되어야하는트랜짓트래픽의경우 PBR 이 ESP 캡슐화전후에패킷의이그레스인터페이스를결정하므로라우팅엔트리를포함할필요가없습니다.ESP 가캡슐화되어야하는로컬에서생성된트래픽의경우, 로컬 PBR 은캡슐화하기전에패킷에대해서만이그레스인터페이스를결정하고라우팅은캡슐화된후패킷에대한이그레스인터페이스를결정하므로라우팅엔트리를포함해야합니다. 이문서에는 ISP 링크가두개인라우터하나가사용되는일반적인컨피그레이션예가포함되어있습니다. 인터넷에액세스하기위해하나의링크가사용되고, 두번째링크는 VPN 에사용됩니다. 링크장애가발생할경우트래픽은다른 ISP(Internet Service Provider) 링크로다시라우팅됩니다. 또한위험이있습니다. PBR 은 CEF(Cisco Express Forwarding) 에서수행되는반면로컬 PBR 은프로세스스위칭입니다. 라우터에서로컬로생성된트래픽

이섹션에서는라우터 (R)1 에서시작된트래픽의동작에대해설명합니다. 이트래픽은 R1 에서캡슐화된 ESP 입니다. 토폴로지 IPsec LAN-to-LAN 터널은 R1과 R3 사이에구축됩니다. 흥미로운트래픽은 R1 Lo0(192.168.100.1) 과 R3 Lo0(192.168.200.1) 사이입니다. R3 라우터에는 R2에대한기본경로가있습니다.

3 이섹션에서는라우터 (R)1 에서시작된트래픽의동작에대해설명합니다. 이트래픽은 R1 에서캡슐화된 ESP 입니다. 토폴로지 IPsec LAN-to-LAN 터널은 R1과 R3 사이에구축됩니다. 흥미로운트래픽은 R1 Lo0( ) 과 R3 Lo0( ) 사이입니다. R3 라우터에는 R2에대한기본경로가있습니다. R1에는라우팅항목이없으며, 직접연결된네트워크만있습니다. 구성 R1 에는모든트래픽에대한로컬 PBR 이있습니다. interface Loopback0 ip address ! interface Ethernet0/0 ip address crypto map CM track 10 ip sla 10 ip sla 10 icmp-echo source-ip route-map LOCALPBR permit 10 set ip next-hop verify-availability track 10 ip local policy route-map LOCALPBR 디버깅 R1 에서로컬로생성된모든트래픽은 UP 이면 R2 로전송됩니다. 터널을가동할때무엇이발생하는지확인하려면라우터자체에서흥미로운트래픽을전송합니다. R1#debug ip packet R1#ping source lo0 주의 :debug ip packet 명령은많은양의디버그를생성할수있으며 CPU 사용량에큰영향을미칩니다. 주의해서사용하십시오.

4 이디버그를사용하면디버그에의해처리되는트래픽의양을제한하기위해 access-list 를사용할수도있습니다.debug ip packet 명령은프로세스스위치드트래픽만표시합니다. R1 의디버그는다음과같습니다. IP: s= (local), d= (Ethernet0/0), len 100, local feature, Policy Routing(3), rtype 2, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE IP: s= (local), d= (Ethernet0/0), len 100, sending IP: s= , d= , pak EF6E8F28 consumed in output feature, packet consumed, IPSec output classification(30), rtype 2, forus FALSE, sendself FALSE, mtu 0, IP: s= (local), d= (Ethernet0/0), len 192, local feature, Policy Routing(3), rtype 2, forus FALSE, sendself FALSE, mtu 0, IP: s= (local), d= (Ethernet0/0), len 192, sending IP: s= (local), d= (Ethernet0/0), len 192, output feature, IPSec output classification(30), rtype 2, forus FALSE, sendself FALSE, mtu 0, IP: s= (local), d= (Ethernet0/0), len 192, output feature, IPSec: to crypto engine(64), rtype 2, forus FALSE, sendself FALSE, mtu 0, IP: s= (local), d= (Ethernet0/0), len 192, output feature, Post-encryption output features(65), rtype 2, forus FALSE, sendself FALSE, mtu 0, IP: s= (local), d= (Ethernet0/0), len 192, post-encap feature, (1), rtype 2, forus FALSE, sendself FALSE, mtu 0, IP: s= (local), d= (Ethernet0/0), len 192, post-encap feature, FastEther Channel(3), rtype 2, forus FALSE, sendself FALSE, mtu 0, IP: s= (local), d= (Ethernet0/0), len 192, sending full packet 다음과같은상황이발생합니다. 흥미로운트래픽 ( > ) 은로컬 PBR 과일치하며이그레스인터페이스 (E0/0) 가결정됩니다. 이작업은암호화코드를트리거하여 ISAKMP 를시작합니다. 또한이패킷은이그레스인터페이스 (E0/0) 를결정하는로컬 PBR 에의해정책라우팅됩니다. ISAKMP 트래픽이전송되고터널이협상됩니다. 다시 ping 하면어떻게됩니까? R1#show crypto session Crypto session current status Interface: Ethernet0/0 Session status: UP-ACTIVE Peer: port 500 IKEv1 SA: local /500 remote /500 Active IPSEC FLOW: permit ip host host Active SAs: 2, origin: crypto map R1#ping source lo0 repeat 1 IP: s= (local), d= (Ethernet0/0), len 100, local feature, Policy Routing(3), rtype 2, forus FALSE, sendself FALSE, mtu 0, IP: s= (local), d= (Ethernet0/0), len 100, sending IP: s= (local), d= (Ethernet0/0), len 100, output feature, IPSec output classification(30), rtype 2, forus FALSE, sendself FALSE, mtu 0, IP: s= , d= , pak EEB40198 consumed in output feature,

5 packet consumed, IPSec: to crypto engine(64), rtype 2, forus FALSE, sendself FALSE, mtu 0, IP: s= (local), d= (Ethernet0/0), len 172, output feature, IPSec output classification(30), rtype 1, forus FALSE, sendself FALSE, mtu 0, IP: s= (local), d= (Ethernet0/0), len 172, output feature, IPSec: to crypto engine(64), rtype 1, forus FALSE, sendself FALSE, mtu 0, IP: s= (local), d= (Ethernet0/0), len 172, output feature, Post-encryption output features(65), rtype 1, forus FALSE, sendself FALSE, mtu 0, IP: s= (local), d= (Ethernet0/0), g= , len 172, forward IP: s= (local), d= (Ethernet0/0), len 172, post-encap feature, (1), rtype 0, forus FALSE, sendself FALSE, mtu 0, IP: s= (local), d= (Ethernet0/0), len 172, post-encap feature, FastEther Channel(3), rtype 0, forus FALSE, sendself FALSE, mtu 0, IP: s= (local), d= (Ethernet0/0), len 172, encapsulation failed. Success rate is 0 percent (0/1) 다음과같은상황이발생합니다. 로컬에서생성된흥미로운트래픽 > 은로컬로라우팅되며이그레스인터페이스가결정됩니다 (E0/0). 패킷은 E0/0 의 IPsec 출력기능에의해소비되고캡슐화됩니다. 이그레스인터페이스를확인하기위해캡슐화된패킷 ( ~ ) 이라우팅을위해확인되지만 R1 의라우팅테이블에는아무것도없으므로캡슐화가실패합니다. 이시나리오에서는터널이 UP 이지만트래픽은전송되지않습니다. ESP 캡슐화후 Cisco IOS 가이그레스인터페이스를확인하기위해라우팅테이블을검사하기때문입니다. 라우터를통한전송트래픽 이섹션에서는라우터를통해들어오는통과트래픽의동작, 즉해당라우터에의해캡슐화된 ESP 에대해설명합니다. 토폴로지 L2L 터널은 R1 과 R3 사이에구축됩니다.

6 흥미로운트래픽은 R4( ) 과 R3 lo0( ) 사이입니다. R3 라우터에는 R2에대한기본경로가있습니다. R4 라우터에는 R1에대한기본경로가있습니다. R1에는라우팅이없습니다. 구성 라우터가암호화를위해패킷을수신하는경우 ( 로컬에서생성된트래픽대신트랜짓트래픽 ) 를표시하기위해이전토폴로지가수정됩니다. 현재 R4 에서수신되는흥미로운트래픽은 R1 에서정책라우팅되고 (E0/1 의 PBR 에의해 ) 모든트래픽에대한로컬정책라우팅도있습니다. interface Ethernet0/1 ip address ip policy route-map PBR route-map LOCALPBR permit 10 set ip next-hop verify-availability track 10! route-map PBR permit 10 set ip next-hop verify-availability track 10 ip local policy route-map LOCALPBR 디버깅 R1 에서터널을시작할때 (R4 에서흥미로운트래픽을수신한후 ) 어떤일이발생하는지확인하려면다음을입력합니다. R1#debug ip packet R4#ping R1 의디버그는다음과같습니다. IP: s= (Ethernet0/1), d= (Ethernet0/0), len 100, input feature, Policy Routing(68), rtype 2, forus FALSE, sendself FALSE, mtu 0, IP: s= (Ethernet0/1), d= (Ethernet0/0), len 100, input feature, MCI Check(73), rtype 2, forus FALSE, sendself FALSE, mtu 0, IP: s= , d= , pak EEB4A9D8 consumed in output feature, packet consumed, IPSec output classification(30), rtype 2, forus FALSE, sendself FALSE, mtu 0, IP: s= (local), d= (Ethernet0/0), len 192, local feature, Policy Routing(3), rtype 2, forus FALSE, sendself FALSE, mtu 0, IP: s= (local), d= (Ethernet0/0), len 192, sending IP: s= (local), d= (Ethernet0/0), len 192, output feature, IPSec output classification(30), rtype 2, forus FALSE, sendself FALSE, mtu 0,

7 IP: s= (local), d= (Ethernet0/0), len 192, output feature, IPSec: to crypto engine(64), rtype 2, forus FALSE, sendself FALSE, mtu 0, IP: s= (local), d= (Ethernet0/0), len 192, output feature, Post-encryption output features(65), rtype 2, forus FALSE, sendself FALSE, mtu 0, IP: s= (local), d= (Ethernet0/0), len 192, post-encap feature, (1), rtype 2, forus FALSE, sendself FALSE, mtu 0, IP: s= (local), d= (Ethernet0/0), len 192, post-encap feature, FastEther Channel(3), rtype 2, forus FALSE, sendself FALSE, mtu 0, IP: s= (local), d= (Ethernet0/0), len 192, sending full packet 다음과같은상황이발생합니다. 흥미로운트래픽은 E0/0 에서 PBR 에도달하고암호화코드를트리거하여 ISAKMP 패킷을전송합니다. 해당 ISAKMP 패킷은로컬에서정책라우팅되며이그레스인터페이스는로컬 PBR 에의해결정됩니다. 터널이구축됩니다. 다음은 R4 에서 에대한 ping 입니다. R4#ping R1 의디버그는다음과같습니다. IP: s= (Ethernet0/1), d= (Ethernet0/0), len 100, input feature, Policy Routing(68), rtype 2, forus FALSE, sendself FALSE, mtu 0, IP: s= (Ethernet0/1), d= (Ethernet0/0), len 100, input feature, MCI Check(73), rtype 2, forus FALSE, sendself FALSE, mtu 0, IP: s= (Ethernet0/1), d= (Ethernet0/0), len 100, output feature, IPSec output classification(30), rtype 2, forus FALSE, sendself FALSE, mtu 0, IP: s= , d= , pak EF consumed in output feature, packet consumed, IPSec: to crypto engine(64), rtype 2, forus FALSE, sendself FALSE, mtu 0, IP: s= (Ethernet0/1), d= (Ethernet0/0), len 172, input feature, Policy Routing(68), rtype 2, forus FALSE, sendself FALSE, mtu 0, IP: s= (Ethernet0/1), d= (Ethernet0/0), len 172, input feature, MCI Check(73), rtype 2, forus FALSE, sendself FALSE, mtu 0, IP: s= (Ethernet0/1), d= (Ethernet0/0), len 172, output feature, IPSec output classification(30), rtype 2, forus FALSE, sendself FALSE, mtu 0, IP: s= (Ethernet0/1), d= (Ethernet0/0), len 172, output feature, IPSec: to crypto engine(64), rtype 2, forus FALSE, sendself FALSE, mtu 0, IP: s= (Ethernet0/1), d= (Ethernet0/0), len 172, output feature, Post-encryption output features(65), rtype 2, forus FALSE, sendself FALSE, mtu 0, IP: s= (Ethernet0/1), d= (Ethernet0/0), g= , len 172, forward IP: s= (Ethernet0/1), d= (Ethernet0/0), len 172, post-encap feature, (1), rtype 0, forus FALSE, sendself FALSE, mtu 0, IP: s= (Ethernet0/1), d= (Ethernet0/0), len 172, post-encap feature, FastEther Channel(3), rtype 0, forus FALSE, sendself FALSE, mtu 0, IP: s= (Ethernet0/1), d= (Ethernet0/0), len 172,

8 sending full packet 다음과같은상황이발생합니다. 흥미로운트래픽은 E0/0 에서 PBR 에도달하며, 해당 PBR 은이그레스인터페이스 (E0/0) 를결정합니다. E0/0 에서패킷은 IPSec 에서소비되고캡슐화됩니다. 캡슐화된패킷이동일한 PBR 규칙에대해확인되고이그레스인터페이스가결정되면패킷이올바르게전송되고수신됩니다. 동작차이점요약 로컬에서생성된트래픽의경우 ISAKMP( 캡슐화되지않은트래픽 ) 에대한이그레스인터페이스는로컬 PBR 에의해결정됩니다. 로컬로생성된트래픽의경우 ESP(post-encapsulated traffic) 에대한이그레스인터페이스는라우팅테이블에의해결정됩니다 ( 로컬 PBR 은선택되지않음 ). 통과트래픽의경우 ESP(post-encapsulated traffic) 에대한이그레스인터페이스는인터페이스 PBR( 두번, 캡슐화전후 ) 에의해결정됩니다. 컨피그레이션예 다음은 VPN 을사용하는 PBR 및로컬 PBR 과관련된문제를보여주는실제컨피그레이션예입니다.R2(CE) 에는 2 개의 ISP 링크가있습니다.R6 라우터에는 CE 및 ISP 링크가하나씩있습니다.R2 에서 R3 으로연결되는첫번째링크는 R2 의기본경로로사용됩니다. R4 로연결되는두번째링크는 R6 로연결되는 VPN 트래픽에만사용됩니다. ISP 링크장애가발생하면트래픽이다른링크로다시라우팅됩니다. 토폴로지

구성 192.168.1.0/24 에서 192.168.2.0/24 사이의트래픽은보호됩니다.

9 구성 /24 에서 /24 사이의트래픽은보호됩니다.ISP 에서고객에게할당한공용주소로간주되는 /8 주소를광고하기위해인터넷클라우드에서 OSPF(Open Shortest Path

10 First) 가사용됩니다. 실제환경에서는 OSPF 대신 BGP 가사용됩니다. R2 및 R6 의컨피그레이션은암호화맵을기반으로합니다.R2 에서 PBR 은 E0/0 에서 VPN 트래픽이 UP 인경우 R4 로전송하기위해사용됩니다. route-map PBR permit 10 match ip address cmap set ip next-hop verify-availability track 20 ip access-list extended cmap permit ip crypto map cmap 10 ipsec-isakmp set peer set transform-set TS match address cmap interface Ethernet0/0 ip address ip nat inside ip virtual-reassembly in ip policy route-map PBR 여기에서는로컬 PBR 이필요하지않습니다. 인터페이스 PBR 은흥미로운트래픽을 으로라우팅합니다. 이렇게하면 R3 을통해원격피어포인트에라우팅하는경우에도올바른인터페이스 (R4 로링크 ) 에서 ISAKMP 를시작하도록암호화코드가트리거됩니다. R6 에서는 VPN 에대해두개의피어가사용됩니다. crypto map cmap 10 ipsec-isakmp set peer !primary set peer set transform-set TS match address cmap R2 는 R3 및 R4 를 ping 하기위해 IP SLA( 서비스수준계약 ) 를사용합니다. 기본경로는 R3 입니다. R3 가실패할경우 R4 를선택합니다. ip sla 10 icmp-echo ip sla schedule 10 life forever start-time now ip sla 20 icmp-echo ip sla schedule 20 life forever start-time now track 10 ip sla 10 track 20 ip sla 20 ip route track 10 ip route 또한 R2 는모든내부사용자에게인터넷액세스를허용합니다.ISP 에서 R3 로연결되는경우이중화를구현하려면경로맵이필요합니다.R3 이 UP 이고기본경로가 R3 을가리키는경우 E0/1 인터페이스에대한트래픽내부의 PAT(Port Address Translations), R3 이다운되고 R4 가기본경로로사용되는경우 PAT to interface E0/2) ip access-list extended pat deny ip

11 deny udp any any eq isakmp deny udp any eq isakmp any permit ip any any route-map RMAP2 permit 10 match ip address pat match interface Ethernet0/2! route-map RMAP1 permit 10 match ip address pat match interface Ethernet0/1 ip nat inside source route-map RMAP1 interface Ethernet0/1 overload ip nat inside source route-map RMAP2 interface Ethernet0/2 overload interface Ethernet0/0 ip address ip nat inside ip virtual-reassembly in ip policy route-map PBR interface Ethernet0/1 ip address ip nat outside ip virtual-reassembly in crypto map cmap interface Ethernet0/2 ip address ip nat outside ip virtual-reassembly in crypto map cmap ISAKMP 와마찬가지로 VPN 트래픽도변환에서제외해야합니다.ISAKMP 트래픽이변환에서제외되지않으면 R3 로이동하는외부인터페이스에 PAT 됩니다. R2#show ip nat translation Pro Inside global Inside local Outside local Outside global udp : : : :500 *Jun 8 09:09:37.779: IP: s= (local), d= , len 196, local feature, NAT(2), rtype 0, forus FALSE, sendself FALSE, mtu 0, *Jun 8 09:09:37.779: IP: s= (local), d= (Ethernet0/1), len 196, sending output feature, Post-routing NAT Outside(24), rtype 1, forus FALSE, sendself FALSE, mtu 0, output feature, Common Flow Table(27), rtype 1, forus FALSE, sendself FALSE, mtu 0, output feature, Stateful Inspection(28), rtype 1, forus FALSE, sendself FALSE, mtu 0, output feature, IPSec output classification(34), rtype 1, forus FALSE, sendself FALSE, mtu 0, output feature, NAT ALG proxy(59), rtype 1, forus FALSE, sendself FALSE, mtu 0, output feature, IPSec: to crypto engine(75), rtype 1, forus FALSE, sendself FALSE, mtu 0,

12 output feature, Post-encryption output features(76), rtype 1, forus FALSE, sendself FALSE, mtu 0, pre-encap feature, IPSec Output Encap(1), rtype 1, forus FALSE, sendself FALSE, mtu 0, pre-encap feature, Crypto Engine(3), rtype 1, forus FALSE, sendself FALSE, mtu 0, sending full packet 테스트중 이컨피그레이션에서는완벽한이중화가제공됩니다.VPN 은 R4 링크를사용하고나머지트래픽은 R3 으로라우팅됩니다. R4 장애가발생한경우 VPN 트래픽은 R3 링크로설정됩니다 (PBR 의경로맵이일치하지않고기본라우팅이사용됨 ). ISP 에서 R4 로향하는트래픽이중단되기전에 R6 은피어 에서오는트래픽을확인합니다. R6#show crypto session Crypto session current status Interface: Ethernet0/0 Session status: UP-ACTIVE Peer: port 500 IKEv1 SA: local /500 remote /500 Active IPSEC FLOW: permit ip / / Active SAs: 2, origin: crypto map R2 가 VPN 트래픽에 ISP 에서 R3 을사용한후 R6 는피어 의트래픽을확인합니다. R6#show crypto session Crypto session current status Interface: Ethernet0/0 Session status: UP-ACTIVE Peer: port 500 IKEv1 SA: local /500 remote /500 Active IPSEC FLOW: permit ip / / Active SAs: 2, origin: crypto map 반대시나리오에서는 R3 에대한링크가중단되더라도모든것이정상적으로작동합니다.VPN 트래픽은여전히 R4 에대한링크를사용합니다. NAT(Network Address Translation) 는외부주소를할당하기위해 /24 에서 PAT 로수행됩니다.R3 가중단되기전에다음번들로 : R2#show ip nat translations Pro Inside global Inside local Outside local Outside global icmp : : : :1 R3가다운된후에도 R4에대한링크를사용하는새로운변환 ( ) 과함께기존번역이계속존 재합니다. R2#show ip nat translations Pro Inside global Inside local Outside local Outside global icmp : : : :0 icmp : : : :1

13 위험요소 모든것이잘된다면, 그함정들은어디에있습니까? 자세한내용은 로컬로생성된트래픽 다음은 R2 자체에서 VPN 트래픽을시작해야하는시나리오입니다. 이시나리오에서는 R2 가 R4 를통해 ISAKMP 트래픽을전송하고터널이 UP 되도록하려면 R2 에서로컬 PBR 을구성해야합니다. 그러나이그레스인터페이스는라우팅테이블을사용하여결정되며, 기본값은 R3 을가리키며, 해당패킷은 VPN 을위한전송에사용되는 R4 대신 R3 로전송됩니다. 이를확인하려면다음을입력합니다. ip access-list extended isakmp permit udp any any eq isakmp permit udp any eq isakmp any permit icmp any any route-map LOCAL-PBR permit 10 match ip address isakmp set ip next-hop verify-availability track 20 ip local policy route-map LOCAL-PBR 이예에서로컬로생성된 ICMP(Internet Control Message Protocol) 는 R4 를통해강제로생성됩니다. 이기능이없으면 에서 으로로컬로생성된트래픽은라우팅테이블을사용하여처리되고터널은 R3 로설정됩니다. 이구성을적용한후에는어떻게됩니까? ~ 의 ICMP 패킷은 R4 로이동하고 R4 에대한링크를사용하여터널이시작됩니다. 터널은다음과같이설정됩니다. R2#ping source e0/0 repeat 10 Type escape sequence to abort. Sending 10, 100-byte ICMP Echos to , timeout is 2 seconds: Packet sent with a source address of !!!!!!!!! Success rate is 90 percent (9/10), round-trip min/avg/max = 4/4/5 ms R2#show crypto session detail Crypto session current status Code: C - IKE Configuration mode, D - Dead Peer Detection K - Keepalives, N - NAT-traversal, T - ctcp encapsulation X - IKE Extended Authentication, F - IKE Fragmentation Interface: Ethernet0/1 Session status: DOWN Peer: port 500 fvrf: (none) ivrf: (none) Desc: (none) Phase1_id: (none) IPSEC FLOW: permit ip / / Active SAs: 0, origin: crypto map Inbound: #pkts dec"ed 0 drop 0 life (KB/Sec) 0/0 Outbound: #pkts enc"ed 0 drop 0 life (KB/Sec) 0/0

14 Interface: Ethernet0/2 Uptime: 00:00:06 Session status: UP-ACTIVE Peer: port 500 fvrf: (none) ivrf: (none) Phase1_id: Desc: (none) IKEv1 SA: local /500 remote /500 Active Capabilities:(none) connid:1009 lifetime:23:59:53 IKEv1 SA: local /500 remote /500 Inactive Capabilities:(none) connid:1008 lifetime:0 IPSEC FLOW: permit ip / / Active SAs: 2, origin: crypto map Inbound: #pkts dec"ed 9 drop 0 life (KB/Sec) /3593 Outbound: #pkts enc"ed 9 drop 0 life (KB/Sec) /3593 모든것이올바르게작동하는것같습니다. 트래픽은올바른링크 E0/2 를사용하여 R4 로전송됩니다. R6 도 R4 의링크 IP 주소인 에서트래픽을수신함을보여줍니다. R6#show crypto session detail Crypto session current status Code: C - IKE Configuration mode, D - Dead Peer Detection K - Keepalives, N - NAT-traversal, T - ctcp encapsulation X - IKE Extended Authentication, F - IKE Fragmentation Interface: Ethernet0/0 Uptime: 14:50:38 Session status: UP-ACTIVE Peer: port 500 fvrf: (none) ivrf: (none) Phase1_id: Desc: (none) IKEv1 SA: local /500 remote /500 Active Capabilities:(none) connid:1009 lifetime:23:57:13 IPSEC FLOW: permit ip / / Active SAs: 2, origin: crypto map Inbound: #pkts dec"ed 1034 drop 0 life (KB/Sec) /3433 Outbound: #pkts enc"ed 1029 drop 0 life (KB/Sec) /3433 그러나실제로여기는 ESP 패킷에대한비대칭라우팅이있습니다.ESP 패킷은소스로 과함께전송되지만 R3 에대한링크에배치됩니다. 암호화된응답은 R4 를통해반환됩니다. 이는 R3 및 R4 에서카운터를확인하여확인할수있습니다. 100 개의패킷을전송하기전에 E0/0 의 R3 카운터 : R3#show int e0/0 i pack 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 739 packets input, bytes, 0 no buffer 0 input packets with dribble condition detected 1918 packets output, bytes, 0 underruns 100 개의패킷을전송한후에도동일한카운터가있습니다. R3#show int e0/0 i pack 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec

15 839 packets input, bytes, 0 no buffer 0 input packets with dribble condition detected 1920 packets output, bytes, 0 underruns 수신패킷수는 100(R2 로연결되는링크에서 ) 증가했지만나가는패킷은 2 개만증가했으므로 R3 는암호화된 ICMP 에코만확인합니다. 100 개의패킷을전송하기전에 R4 에서응답을확인합니다. R4#show int e0/0 i packet 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 1000 bits/sec, 1 packets/sec 793 packets input, bytes, 0 no buffer 0 input packets with dribble condition detected 1751 packets output, bytes, 0 underruns 100 개의패킷을전송한후 : R4#show int e0/0 i packet 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 793 packets input, bytes, 0 no buffer 0 input packets with dribble condition detected 1853 packets output, bytes, 0 underruns R2 로전송된패킷수는 102( 암호화된 ICMP 응답 ) 로증가했으며, 수신된패킷은 0 씩증가했습니다. 따라서 R4 는암호화된 ICMP 응답만확인합니다. 물론패킷캡처가이를확인합니다. 왜이런일이발생할까요? 그답은기사의첫부분에있다. 다음은이러한 ICMP 패킷의흐름입니다. 1. 로컬 PBR로인해 에서 으로 ICMP가 E0/2(R4로연결 ) 에배치됩니다. 2. ISAKMP 세션은 으로구축되며 E0/2 링크를예상대로연결합니다. 3. 캡슐화후 ICMP 패킷의경우라우터는 R3를가리키는라우팅테이블을사용하여수행되는이그레스인터페이스를확인해야합니다. 따라서소스 (R4로링크 ) 가있는암호화된패킷이 R3를통해전송되는것입니다. 4. R6은 ISAKMP 세션과일치하는 에서 ESP 패킷을수신하고, 패킷을해독하고, ESP 응답을 으로전송합니다. 5. 라우팅때문에 R5는 R4를통해 에응답을다시전송합니다. 6. R2는이를수신하고해독하며패킷이수락됩니다. 따라서로컬에서생성된트래픽에특히주의해야합니다. 많은네트워크에서 urpf(unicast Reverse Path Forwarding) 가사용되고 R3 의 E0/0 에서 에서소싱된트래픽이삭제될수있습니다. 이경우 ping 이작동하지않습니다. 이문제에대한해결책이있습니까? 라우터가로컬에서생성된트래픽을전송트래픽으로처리하도록할수있습니다. 이를위해로컬 PBR 은트래픽을전송트래픽처럼라우팅되는가짜루프백인터페이스로전달해야합니다. 이는권장되지않습니다. 참고 :PBR 과함께 NAT 를사용할때는특히주의해야합니다 (PAT 액세스목록의 ISKMP 트래픽에대한이전섹션참조 ).

16 PBR 이없는컨피그레이션예 또다른해결방법이있습니다. 이전예와동일한토폴로지를사용하면 PBR 또는로컬 PBR 을사용하지않고도모든요구사항을충족할수있습니다. 이시나리오에서는라우팅만사용됩니다.R2 에하나이상의라우팅항목만추가되고모든 PBR/ 로컬 PBR 컨피그레이션이제거됩니다. ip route track 20 총 R2 에는다음과같은라우팅구성이있습니다. ip route track 10 ip route ip route track 20 첫번째라우팅항목은 R3 에대한링크가 UP 인경우 R3 에대한기본라우팅입니다. 두번째라우팅항목은 R3 에대한링크가다운된경우 R4 에대한백업기본경로입니다. 세번째항목은 R4 링크상태에따라원격 VPN 네트워크로가는트래픽이전송되는방법을결정합니다 (R4 링크가 UP 인경우원격 VPN 네트워크로가는트래픽은 R4 를통해전송됩니다 ). 이컨피그레이션에서는정책라우팅이필요하지않습니다. 결점은무엇입니까? 더이상 PBR 을사용하여세분화된제어가없습니다. 소스주소를확인할수없습니다. 이경우소스와상관없이 /24 에대한모든트래픽은 UP 일때 R4 로전송됩니다. 이전예에서는 PBR 과특정소스에의해제어되었습니다 /24 이선택됩니다. 어떤시나리오에서이솔루션이너무간단합니까? 여러 LAN 네트워크 (R2 뒷면 ) 의경우이러한네트워크중일부가안전한방식으로 ( 암호화 ) 또는다른안전하지않은방식으로 /24 에도달해야하는경우 ( 암호화되지않음 ) 안전하지않은네트워크의트래픽은여전히 R2 의 E0/2 인터페이스에있으며 crypto-map 에도달하지않습니다. 따라서 R4 로연결되는링크를통해암호화되지않은상태로전송됩니다. 이때기본요구사항은암호화된트래픽에만 R4 를사용하는것이었습니다. 이러한시나리오와요구사항은드물기때문에이솔루션이자주사용됩니다. 요약 VPN 및 NAT 와함께 PBR 및로컬 PBR 기능을사용하는것은복잡할수있으며패킷플로우에대한심층적인이해가필요합니다. 여기에제시된것과같은시나리오에서는두개의개별라우터를사용하는것이좋습니다. 각라우터에는 ISP 링크가하나씩있습니다.ISP 장애가발생할경우트래픽을쉽게재라우팅할수있습니다.PBR 은필요하지않으며전체설계가훨씬간단합니다. PBR 을사용할필요는없지만대신고정부동라우팅을사용하는보안침해솔루션도있습니다. 다음을확인합니다. 현재이구성에대해사용가능한확인절차가없습니다.

17 문제해결 현재이컨피그레이션에사용할수있는특정문제해결정보가없습니다. 관련정보 기술지원및문서 Cisco Systems Cisco IOS 15.3 M&T- Cisco Systems

GRE(Generic Routing Encapsulation) GRE는 Cisco에서개발한터널링프로토콜으로써특정네트워크망에서새로운 IP 헤더를인캡슐레이션하여패켓을전송하는 VPN 기능을제공한다. GRE 터널링을이용하여패켓을전송하면, 데이터를암호화하지않기때문에보안적으로는취

제 16 장 GRE 터널 블로그 : net123.tistory.com - 1 - 저자김정우 GRE(Generic Routing Encapsulation) GRE는 Cisco에서개발한터널링프로토콜으로써특정네트워크망에서새로운 IP 헤더를인캡슐레이션하여패켓을전송하는 VPN 기능을제공한다. GRE 터널링을이용하여패켓을전송하면, 데이터를암호화하지않기때문에보안적으로는취약하지만,