[#3-8]BGP의 빠른 Take-over(2/2)+security

직전 포스팅에서 자꾸 길을 잃느라 양도 많아지고 할것도 많아져서 시작하게된 BGP의 빠른 Take-over 2탄입니다. 

 

사실 개념과 컨셉은 이미 설명을 드렸고, 이번에는 설정이 불가능할줄 알았던 Tunnel interface에 BFD를 적용해보고, 

GRE의 Keepalive보다 정밀한 컨트롤이 가능한지 확인해보고자 합니다. 

 

또 이것만 하면 심심하니까, BGP를 Range로 설정해보고, 약간의 Securiry 설정을 진행하고자 합니다. 

그럼 언제나와 같이 구성도 부터 시작하겠습니다. 

 

0. 구성도

 

 

Underlay 구성도와 Overlay의 구성도를 각각 구별지었으며, Overlay의 경우 Default VRF입니다. 

(참고로 제가 항상 사용하는 구성도 Tool은 draw.io라고 하는 툴입니다. 아주 유용하니, 한번 사용해보시길 강추 드립니다) 

 

각각의 Link와 Loopback interface는 OSPF 설정이 되어있고, VRF 별 Process 번호는 다르지만, 모두 Area 0입니다. 

 

1. Config

제가 아직 블로그에 익숙치 않다보니, 뭐 Config를 숨기고 확장하는 식의 UI구성을 잘 못합니다.

이번에는 장비 댓수도 많고, 단계별로 Config를 하다보니, 너무 가독성이 떨어지는것같아, 

전체 Config를 첨부와 같이 업로드 하였으니, 누구든지 자유롭게 사용해주시면 됩니다. 

BGP bfd실습 2탄.xlsx

0.01MB

2. Lab 

Underlay의 구성만 완료되었을 때의 라우팅 테이블을 확인해보도록 하겠습니다. 

 

중요한것은 양쪽에서 GRE tunnel의 Endpoint로 사용할 Loopback interface에 대한 라우팅이 있어야만 합니다. 

A_site vrf에서 T1을 만들기 위해 Router4의 Loopback IP가 Router1에서 식별되어야 하며, 그 반대도 마찬가지 입니다.

B_site vrf에서 T2을 만들기 위해 Router7의 Loopback IP가 Router1에서 식별되어야 하며, 그 반대도 마찬가지 입니다.

 

Router 1 routing table 

 

 

Router 4 routing table 

 

 

 

 

Router 7 routing table 

 

보시는 바와 같이 Router1에서 Router4,7의 Loopback이 보이며, 반대 방향도 마찬가지입니다. 

 

이는 Overlay Tunnel의 End point로 사용될 예정입니다. 

 

    ======================================================

 

여기서 한가지 설명을 드리고 싶은 부분이 있습니다. 

Tunnel의 VRF를 어떻게 설정할 것인지와 Tunnel을 구성하는 Underlay의 Source VRF를 어떤 vrf로 사용할지는 Command가 다릅니다. 

 

둘의 차이를 구분할 수 있도록 일부러 Tunnel1을 구성하는 Underlay routing과 Tunnel2를 구성하는 Underlay routing vrf를 구분했습니다. config 파일을 보시면 관련 Command가 있으니 참고해주세요 

 

=====================================================

 

본론으로 돌아와서, Tunnel1,2는 Underlay와는 상관없는 Default VRF로 구성하겠습니다. 

첨부된 Config 문서의 2번 Section을 봐주시면 됩니다. 

 

 

Config 적용 결과 Router1에서 Router4 그리고 Router7 Tunnel IP로 정상적으로 Ping이 되고 있습니다. 

아마 Config를 보시면서 특이한점을 하나 발견하실 수 있을텐데, 

바로 Keepalive설정을 넣어놓지 않았습니다. 

 

GRE의 특성 상 Physical interface와는 다르게, 음. . 반대편의 Health check를 하지 않습니다. 

이건 좀 더 자세히 설명하려면 L1/2 Layer쪽으로 자세히 들어가야되는데, 지난 포스팅에는 포함되어있지 않으니, 

추후 다른 포스팅으로 공유드리도록 하겠습니다. (  꼭 기록해두고 다음에 포스팅 하겠습니다) 

 

그러면 GRE는 어떻게 상대를 인식하고 Link status와 Protocol을 Up이라고 표현할까요 ? 

정답은 인식하지 않습니다. 

아마 한번이라도 Tunnel을 만들어보신 분이라면 알겠지만 'int tunnel x'를 하기만 해도 Tunnel은 Up됩니다. 

(다만, Tunnel destination 에 대한 라우팅이 없어지면 Down으로 감지) 

그래서 GRE에서 상대방이 정상적으로 살아있다고 판단하기 위한 기능이 있는데 그건 바로 Keepalive기능입니다. 

 

GRE는 IP protocol기반의 통신으로, TCP와 같은 ACK 이 없습니다. 따지자면 TCP보단 UDP에 가깝다고 할 수 있습니다. 

그렇다면 Keepalive는 어떻게 동작하는지 간단하게 설명하자면, 

' '내가 리턴받을 패킷을 Encapsulation'하여 상대한테 보내고, 돌아온 패킷에 내가 적어서 보낸 내용이 있으면 살아있다고 판단'합니다. 

 

GRE protocol과 L3를 이용한 health check방식이며, 이 Keepalive가 설정되어있지 않으면,

본인 기준 특이사항(Source interface status/ Destination Routing)이 없다면 Tunnel은 항상 Up입니다. 

 

제가 Config에 Keepalive설정을 하지않은 이유는 아래 3단계로 BGP의 Take-over time(Convergency time)을 비교해보기 위함 입니다.

 

1. Tunnel (Keepalive X) 

2. Tunnel (Keepalive O, 10초 3번) 

3. Tunnel (BFD O, Keepalive X) 

 

그럼 Config문서의 Section 3, BGP 기본 Config를 넣은 상태로 시작해보겠습니다. 

 

1. Tunnel (Keepalive X) 

 

정상적으로 Neighbor가 연결되었고, 1번 시나리오일 때, Take-over time을 보겠습니다.

중간 경로인 Router2에서 e0/1 인터페이스를 Down시키면서 시작하겠습니다. 

 

음.. 25초 ,, 제 생각보다 너무빠른 시간에 Take-over가 되었는데, 

생각해보니 중간 링크를 끊으면, OSPF가 끊기면서  Destination에 대한 라우팅이 없어졌기때문에 Tunnel이 Down될 수 밖에 없네요.

Router1에 아래 Static routing을 하나 더 넣어보겠습니다. 

 

ip route vrf A_site 10.10.4.1 255.255.255.255 10.10.12.2 

 

이는 Tunnel end point로 통신은 안되지만, Router1에서 Tunnel destination에 대한 경로를 계속 지속해줌으로써,

Tunnel은 Up상태를 유지하되 통신이 불가능한 상황을 만들고자 함입니다. 

이제 다시 한번 1.을 진행해보겠습니다. 

 

 

자.. 시간만 보았을때, BGP의 Default Keepalive인 60 180초에 따라 거의 근사한 수치로 Neighbor Down을 감지했습니다. 

 

2. Tunnel (Keepalive O, 10초 3번) 

그럼 이어서 Keepalive를 설정한 다음 2번 시나리오를 진행을 해보겠습니다. 

 

참고로 Keepalive설정은 단방향 체크 이기 때문에, Tunnel에 대한 Status를 확인하고 싶은 장비라면 모두 설정을 해줘야합니다. 

그렇지 않다면, 아래와 같이 End-to-End 통신이 안되는 경우에도 Tunnel이 살아있는것을 보실 수 있습니다. 

 

 

Config는 아래와 같고, Router1에서만 Status변경을 확인하고자, Router4에서는 적용하지 않았습니다. 

 

[Router1]

int tunnel 1 

 keepalive 10 3 

 

다만 , , 제 시뮬레이터 환경에서, GRE를 잘 인식을 못해가지고, 시나리오 2번은 확인하지 못했습니다. 

제가 예상하는 상황은 BGP Hold time expired되기 전에, Keepalive expired가 먼저되면서 Tunnel이 다운되고,

Local address가 Down되었으니 연관된 BGP Session이 끊길것으로, total 30초 이내로 BGP가 끊어질 겁니다. 

 

 

3. Tunnel (BFD O, Keepalive X) 

 

이제 3번 시나리오를 진행해보겠습니다. 

아시다시피 BFD는 양쪽 모두에 설정해줘야하며, 아래 Config를 적용해보겠습니다. 

 

[Router1,4]

int tunnel 1 

 bfd i 300 i 300 m 3

 

router bgp [asn]

 neighbor [peer ip] fall-over bfd

 

이 상태에서 진행해보도록 하겠습니다. 

똑같이 Router2에서 E0/1을 끊으면서 시작하겠습니다.

 

 

보이시나요? 

실제 Physical interface와 같이, 1초 이내로 BGP로 얻어온 경로를 모두 Routing table에서 삭제하고, 경로 전환이 이뤄집니다. 

저는 사실 Virtual interace라서 BFD설정이 안먹힐 줄 알았는데, Tunnel 자체에도 Mac-address가 있기때문에, 

정상적으로 BFD reply가 오고, Down을 감지하는것으로 보입니다. 

 

 

 

 

이제 BFD를 활용한 빠른 Take-over는 여기까지 하고, 

Security에 대한 간단한 설명을 해보겠습니다. 

 

BGP에서 활용할 수 있는, 제가 알고 있는 보안성 강화방법은 우선 2가지 입니다. 

 

1. Password를 활용한 Peer 인증 절차 추가 

2. Peer에 대한 Hop count limit 

 

OSPF 세션서 설명했던것같은데, Peer와 내가 같은 Key를 가지고 있는 상태에서만 Neighborship이 가능하도록 하는 보안 정책입니다. 

 

command자체는 간단합니다. 

 

neighbor [peer ip] password [WORD]

 

제가 패킷 캡쳐 단위로 해당 패킷을 본것은 아니지만, 이런 가정을 해봅시다.

만약에 TCP 세션이 맺힌 상태에서, BGP neighborship이 맺히기전 Active 상태일때, 송부하는 패킷에 Key값이 평문으로 들어있으면 그것도 문제이지 않습니까 ?? (정확히는 MD5로 암호화가 되지만, 요즘 MD5는 복호가 굉장히 쉽기에 평문과 마찬가지죠)

 

이럴때 지난번에 설명드린, Router에서 서버로만 동작하는 방식을 섞어서 쓴다면,

내가 가진 Key는 노출하지않으면서 Neighbor 연결을 시도하는 Peer쪽의 암호화에 대한 검증을 진행하게 되며, 더 보안성이 올라간다고 볼 수 있겠습니다. 

 

neighbor peer ip transport connection-mode passive  

 

근데 생각해보면 위 Command는 TCP세션에 대해 연결요청을 기다리는것이지,

BGP process를 기다리는 매커니즘이 아닌것같아서 삭제하겠습니다. 

 

아무튼 Password를 활용한 Peer인증과 함께 추가적인 보안 설정은 바로 Hop count limit 입니다. 

 

언제 어떻게 경로가 바뀔지 모르는 인터넷 환경은 배제하고, 통제 가능한 도메인 내부에서나 Virtual Tunnel등과 같은 Hop count가 일정한 상황에서 사용 가능한 방법입니다. 

 

바로 Maximum hop count 를 활용한 Hop 상한선 제한입니다. 

나는 저 Peer가 몇 Hop떨어져있는지 알고, 뭐 Link fail이 난다고 가정해도 몇홉안에는 들어오는걸 알아, 할때 사용하는것이죠. 

다만 널리 사용하는 'ebgp-multihop' command의 경우에는 eBGP에서만 사용할 수 있기에, 

iBGP에서도 사용할 수 있는 Command를 공유하고자 합니다.  아래와 같습니다. 

 

neighbour [peer ip] ttl-security hops [1-255]

 

이는 Peer가 iBGP던 eBGP던 상관 없이, Peer까지 가는 Maximum hop count를 보는겁니다. 

다만, 이게 ,, Asymetric한 상황 즉, Local -> Peer 3홉 , Peer-> Local 4홉 인 상황에서, 

자신의 Maximum hop count만 맞추면 되는지는 잘 모르겠습니다. 

현재 구성된 시뮬레이션 환경이 이와 맞지않아서, 실습은 건너뛰고, 이런 방법이 있다~ 정도로 이해해주시면 감사하겠습니다. 

(TTL-Security가 설정된 BGP Packet은 IP Layer에 TTL이 설정된 TTL로 바뀌는지는 좀 궁금하긴한데, 덤프를 뜰 수 있는 상황이 아니라 좀 답답하긴하네요 ) .. 

 

 

=======================================================================

 

3. 맺으며. . 

BGP하나로도 이렇게 설명할게 아주 많습니다. 

제가 지금까지 한 9개의 BGP 포스팅을 진행했고 그때마다 한가지 개념만 설명한것도 아닌데, 

아직 더 있습니다. . 

 

다만 무식하게 모든걸 전부다 알겠다하는 방법보다는, 실제로 적용가능한 수준(기술)을 인지하자는 측면으로 같이 공부하시죠. 

추가로 알게되는 내용이 있다면 언제든지 공유드리도록 하겠습니다. ! 

 

감사합니다.