Route map, Policy Based Routing과 다중 인터페이스를 이용한 NAT

PBR이란?

정책 또는 필터를 기반으로 데이터 패킷을 포워딩하고 라우팅하는 기법이다. 기존의 라우팅에서는 라우팅 프로토콜에 따라 정해진 경로들 로드밸런싱되거나 최단경로를 이용하여 포워딩되던 트래픽을 라우팅 테이블이 선택하지 않은 다른 홉의 특정 경로를 이용하여 트래픽을 포워딩하도록 할 수 있다.

 

왜 사용하고 어떤 점이 좋나

PBR을 이용하면 트래픽을 분류하고 분류과정을 통해 트래픽별로 표시가되기 때문에 향후 분석 과정에서 네트워크 보안의 가시성을 확보하고 더 향상된 기능 제어를 할 수 있게 된다. 또, 애플리케이션을 개별적으로 처리하기 때문에 성능 저하나 가용성의 저하없이 효과적으로 트래픽의 우선순위를 지정하고 구분할 수 있다.

아래는 그에 대한 예시다.

 

1. 두 개 이상의 링크를 사용할 수 있을 때 중요 애플리케이션에 따라 링크를 다르게 할당할 수 있다. 빠른 링크에는 회사 트래픽을 할당하고 느린 링크에는 일반적인 인터넷 탐색 트래픽을 할당하는 것처럼 말이다.
   
   
2. 심층 검사와 분석을 위해 관리자가 해당 트래픽을 다른 디바이스로 라우팅할 수 있다.

Cisco Route map

cisco에서는 Route map 이라는 것을 이용하여 이를 구현한다. Route map은 match와 action으로 구성되어 있고 “match” 에 경로를 적용한다던지 다양한 지표를 이용해서 다양한 환경에 적용할 수 있다. Route map의 대표적인 사용법은 PBR과 라우팅 재분배, 또는 NAT이다. Route map을 이용해 다양한 설정을 할 수 있다.

 

Route map의 구조는 간단하다. Route map은 acl과 마찬가지로 규칙들의 집합이며 각각의 규칙들은 크게 action type, match, set 이 3가지의 항목으로 구성되어 있다. action type은 permit/deny를 구성하는 부분으로 “match” 되었을 때 어떤 일을 할지 규정한다. match는 이 규칙이 어떤 상황에서 트리거 되어야하는지 작성하는 부분이다. 규칙이 match에 의해 트리거 되었고 deny가 아닌 permit일 때 set이 작동하게 된다. set을 통해 next-hop이나 파라미터를 변경하게 된다. 또, 규칙을 작성할 때 match를 생략할 수 있는데 이렇게 되면 모든 트래픽에 해당 규칙이 적용된다.

 

route-map 안의 규칙들은 이들을 구분할 수 있는 RULE ID가 있으며 시스코에서는 이  RULE ID를 10씩 증가시키면서 사용하는 것을 권장한다. 이게 무슨 뜻이냐면 route-map을 acl처럼 사용할 수 있다는 것이다. 같은 이름의 route-map을 여러개 만들 수 있다. 즉 acl 처럼 route-map 규칙을 여러개 작성하고 우선순위를 지정할 수 있다는 것이다. 따라서 route-map도 acl 처럼 같은 match를 가지는 여러 개의 규칙 중 RULE ID가 가장 낮은 규칙을 실행하며 실행된 규칙이 있다면 아래의 규칙들은 모두 무시된다. 이는 아래 PBR 실습에서 자세하게 보여주도록 하겠다. 

 

match source-protocol ospf 1 eigrp 65535
match tag 20

match를 설정할 때 알아야할 점이 하나 더 있다. 바로 and와 or이다. 하나의 규칙에서 여러 줄의 match를 생성하거나 한 줄에 여러 개의 조건을 한번에 적을 수 있다. 위의 코드를 봤을 때 이 두 줄은 서로 다른 의미를 가진다. match 하나에 여러 개의 조건을 적는 것은 or를 뜻한다. 즉 적혀 있는 조건 중 하나라도 맞다면 규칙은 실행된다. 여러 줄로 적게되면 and의 뜻을 가진다. 따라서 모든 match 줄에 일치하여야 규칙이 실행된다.

 

NAT with Route map

지금까지 PBR과 Route map에 대해 알아보았고 PBR 설정으로 들어가기 전에 Route map을 이용한 nat 설정에 대해 먼저 알아보고 PBR을 구축해보겠다. 

일반적으로 많이 발생하는 상황은 아닌거 같지만 이렇게 두 개 이상의 ISP와 연결된 라우터가 있다고 가정해보자 우리가 흔히 알고 있는 acl만을 이용한 nat를 이용해 두 인터페이스 모두에 nat를 구성하고 싶지만 구성할 수 없다는 사실을 알 수 있다. 하나의 인터페이스에 대한 룰만 적용되고 나머지는 덮어씌워진다. 심지어 같은 내용의 다른 acl을 여러 개 생성해 적용한다 하더라도 작동하지 않는 것을 확인할 수 있다. 이 때 route map을 이용하여 두 인터페이스에 모두 nat를 적용할 수 있다. 

 

access-list 10 permit 192.168.10.0 0.0.0.255 


route-map nat1 permit 10
match ip address 10
match interface s0/0

route-map nat2 permit 10
match ip address 10
match interface s0/1

ip nat inside source route-map nat1 interface s0/0 overload
ip nat inside source route-map nat1 interface s0/1 overload

위 명령어를 통해서 구축할 수  있다.  구성이 정상적으로 확인 되었는지 확인하기 위해 R2와 R3에서 debug ip packet 명령어를 통해 확인해보도록 하겠다. 

 

먼저 client에서 R3로 ping을 보내본다. 

 

R3에서 확인해보면 210.110.20.1의 IP로 NAT된 것을 확인할 수 있다. 

 

이번엔 R2로 PING을 보내본다. 

아까와는 다르게 210.110.10.1의 IP로 NAT가 된 것을 확인할 수 있다. 쨘

PBR configuration

앞의 토폴로지에서 더 나아가 이번에는 PBR을 이용해 SSH 같은 관리 트래픽은 R2를 이용해서 통신하고 그 외의 나머지 트래픽은 R3를 통해 통신할 수 있도록 해보겠다. 

ip access-list extended SSH
 permit tcp 192.168.10.0 0.0.0.255 any eq 22
 
route-map PBR permit 10
 match ip address SSH
 set ip next-hop 210.110.10.2 
 
route-map PBR permit 20
 set ip next-hop 210.110.20.2
 
int f0/0
 ip policy route-map PBR

PBR의 설정은 간단하다. 위 내용은 SSH ACL에 맞는 트래픽이 있다면 next-hop을  R2인 210.110.10.2로 그 외의 모든 트래픽은 R3인 210.110.20.2로 보내라는 뜻이다. 그 후 적용할 인터페이스에 ip policy route-map [] 명령어를 통해서 적용하면 된다.  위처럼 route-map은 acl 처럼 같은 이름의 route-map을 두고 여러개의 규칙을 두어서 우선순위를 적용시킬 수 있다. 

 

다시 본론으로 돌아와서 그렇다면 정말로 pbr에 의해 트래픽이 나누어졌을까? 어떻게 확인할까? 앞에서 했던 nat 설정에 의해서 서버에서 접속 기록이나 세션 기록을 확인한다면 ssh 트래픽은 210.110.10.1로 웹 접속은 210.110.20.1로 로그가 남아있을 것이다. 확인해보겠다. 

 

우선 클라이언트에서 ssh를 통해 접속하면 210.110.10.1의 IP로 확인되는 것을 볼 수 있다. OSPF에 의해서 라우팅 되는 것일 수도 있으니 웹 접속 로그를 확인해보겠다. 

 

cat /var/log/apache2/access.log 를 확인해보았다. 쨘!!! 정상적으로 210.110.20.1로 access 했고 PBR이 정상적으로 작동했다는 것을 알 수 있다.