본문 바로가기
Azure/Network

Azure VPN Gateway - BGP 활성화 결과 (Part 2)

by Shuaaaa 2023. 9. 21.

이전글 ▶ Part 1 = BGP 그 자체에 대한 설명 (feat. AS)

이번글 ▶ Part 2 = Azure VPN Gateway 상에서 BGP를 활성화 하였을 때와 활성화를 안했을 때의 테스트 내역 공유

 

이전글에서 BGP는 본인이 속한 AS의 라우팅 정보를 다른 AS에게 공유하는 프로토콜이라고 설명 드렸습니다.

그렇다면... 

- BGP를 활성화 하여 Site 1과 Site 2를 VPN 연결을 한다면,

- Site 1과 Site 2의 라우팅 정보는 BGP를 통해 공유되겠죠?

 

실제로 Azure에서 BGP 활성화 하여 VPN Connection을 만들 때,

어떻게 옵션 설정하였고 어떤 라우팅 정보가 공유 되었는지 확인해봅시다.

 

먼저, 이번 테스트는 MS 공식문서를 참고하여 진행하였습니다. 아래 링크에서 나온대로 그대로 구현하였습니다.

https://learn.microsoft.com/ko-kr/azure/vpn-gateway/bgp-howto

 

Main Scenario는 다음과 같습니다. 

저는 일단 필요한 리소스와 환경 구축을 다 한 다음, 선택적으로 BGP를 하나씩 킨 후 각각의 결과 공유하도록 하겠습니다.

Main Scenario

 

리소스 & 환경 구축

링크와는 살짝 다르게, 제가 구성한 사항에 대해서 설명드리겠습니다.

저는 일단 리소스 생성할때 BGP는 모두 활성화 하지 않았습니다.

1. Southeast Asia 에서 1개의 VNet, Korea Central 에서 2개의 VNet을 생성합니다.

- Address Space가 겹치지 않도록 합니다.

- default, GatewaySubnet, 총 2개의 Subnet을 구성합니다.

2. 각 VNet 위에 Virtual Network Gateway 생성합니다. (각 40분 정도 소요)

- (2023.09.21 기준, Basic Tier가 Azure Portal에서 선택이 안되서 Powershell로 해야합니다.)

- azuresea-vgw, azurekc-vgw, onpremkc-vgw

3. 각 Site (VNet)에 해당하는 Local Network Gateway를 생상합니다. (각 5분 정도 소요)

- azuresea-lgw: azuresea IP대역

- azurekc-lgw: azurekc IP대역

- onpremkc-lgw: 10.0.0.0/16만 입력

4. 각 VNet default Subnet위에 Linux VM 만듭니다. (각 2분 소요)

5. 위와 같이 Connection이 생성되도록 구성합니다.

- azuresea-vgw & azurekc-lgw VNet 연결

- azurekc-vgw & azuresea-lgw VNet 연결

- onpremkc-vgw & azurekc-lgw S2S 연결 

- azurekc-vgw & onpremkc-lgw S2S 연결

 

Test 1: No BGP Enabled

BGP가 2개의 Tunnel에서 활성화 되지 않았을 때, Linux VM NIC에서 경로테이블을 확인했을 때 위와 같이 나옵니다.

여기서의 핵심은, 각 VM에서는 저희가 설정한 Local Gateway 대로 경로테이블에 그대로 반영되었음을 알 수 있습니다.

만약 BGP가 활성화 되었었다면, azuresea-vm이 onprem-kc의 대역대 까지 알 수 있어서, 주소 접두사에 10.0.0.0/16 & 10.10.0.0/16 내용이 있어야 합니다.

 

이제 각 Tunnel에 대해서 BGP를 하나씩 활성화 하도록 하겠습니다.

 

Test 2: 우측 터널 BGP 활성화

VPN 연결에서 BGP를 활성화 하기 위해서, vgw, lgw, connection 모두 BGP 옵션 활성화 해야합니다.

(시간이 어느정도 소요됩니다.)

위와 비교했을때, azuresea의 유효경로는 변경된게 없습니다.

좌측 터널은 BGP 활성화하지 않았기 때문에, 우측의 유효 경로가 azuresea까지 전달되지 않았기 때문이죠

 

우측 BGP 활성화된 터널때문에 azurekc와 onpremkc의 경로테이블이 자동으로 추가되었습니다.

azurekc에서는 10.10.0.0/16의 정보가 자동으로 추가되었죠. (onprem-kc에서 저희가 이 정보는 넣지 않았습니다.)

 

흥미로운 부분은 onpremkc의 경로 테이블 입니다.

azuresea의 10.2.0.0/16 정보가 자동으로 추가되었습니다. (azuresea는 onpremkc의 정보가 없는데 말이죠.)

이 부분은, azurekc가 BGP를 통하여 자신의 경로테이블을 모두 전달하기 때문에 onpremkc가 본 정보를 가지고 있습니다.

 

Test3: 양쪽 터널 BGP 활성화

실질적으로 azurekc와 onpremkc의 경로 테이블은 변경 사항 없습니다.

azuresea의 경로 테이블에 onpremkc의 정보가 모두 업데이트 되었습니다. (10.0.0.0/16 & 10.10.0.0/16)

모든 터널이 BGP로 연결 되었을때, 모든 Site가 서로서로 통신 가능합니다!

(Test1, Test2 시나리오에서는 Non-transitive한 구성입니다. 즉, azuresea to onpremkc, onpremkc to azuresea 통신 불가능합니다.)

 

경로 테이블에서 .../32로 끝나는 대역은 상대 Gateway Subnet에 대한 정보라서 이번 실습에서는 .../16의 대역만 참고하시면 됩니다.

 

결론

 

MS Learn에서 나온 그래로 구성해봤고,

실제 BGP 활성화 했을때 어떻게 다른지 알아보았습니다.

 

Part 1에서 나온 이론적인 부분이 Part 2의 실제 예시로 많은 도움이 되길 바랍니다.

 

감사합니다!

 

 

 

 

댓글