Virtual WAN 라우팅 심층 분석

Azure Virtual WAN은 정교한 네트워킹 토폴로지를 쉽게 만들 수 있는 네트워킹 솔루션입니다. 여기에는 트래픽 보안 옵션을 포함하여 지점 및 사이트 간 VPN, 사이트 간 VPN, ExpressRoute 및 통합 SDWAN 어플라이언스를 통해 Azure VNet과 온-프레미스 위치 사이의 Azure 지역 간 라우팅이 포함됩니다. 대부분의 시나리오에서는 Virtual WAN 내부 라우팅의 작동 방식에 대한 깊은 지식이 필요하지 않지만 특정 상황에서는 Virtual WAN 라우팅 개념을 이해하는 것이 유용할 수 있습니다.

이 문서에서는 복잡한 네트워크에서 VNet과 분기를 상호 연결할 때 조직에 발생할 수 있는 일부 동작을 설명하는 샘플 Virtual WAN 시나리오를 살펴봅니다. 이 문서에 표시된 시나리오는 결코 설계 권장 사항이 아니며, 특정 Virtual WAN 기능을 설명하기 위해 설계된 샘플 토폴로지일 뿐입니다.

시나리오 1: 기본 라우팅 기본 설정을 사용하는 토폴로지

이 문서의 첫 번째 시나리오에서는 ExpressRoute, VPN 및 SDWAN 연결이라는 두 개의 Virtual WAN 허브를 사용하여 토폴로지를 분석합니다. 각 허브에는 직접 연결된 VNet(VNet 11 및 21)과 NVA를 통해 간접적으로 연결된 VNet(VNet 121, 122, 221 및 222)이 있습니다. VNet 12는 BGP를 통해 허브 1과 라우팅 정보를 교환하고(가상 허브와 BGP 피어링 참조), VNet 22에는 정적 경로가 구성되어 있으므로, 두 옵션 사이의 차이를 확인할 수 있습니다.

각 허브에서 VPN 및 SDWAN 어플라이언스 서버는 이중 용도로 사용됩니다. 한쪽에서는 자체 개별 접두사를 보급합니다(허브 1에서 VPN을 통해 10.4.1.0/24 보급, 허브 2에서 SDWAN을 통해 10.5.3.0/24 보급). 그리고 다른 한쪽에서는 동일 지역(허브 1의 10.4.2.0/24 및 허브 2의 10.5.2.0/24)에서 동일한 접두사를 ExpressRoute 회로로 보급합니다. 이 차이는 Virtual WAN 허브 라우팅 기본 설정의 작동 방식을 보여주기 위해 사용됩니다.

모든 VNet 및 분기 연결이 연결되고 기본 경로 테이블로 전파됩니다. 허브가 보호되지만(모든 허브에 Azure Firewall이 배포됨) 비공개 또는 인터넷 트래픽을 보호하도록 구성되지는 않습니다. 이렇게 하면 모든 연결이 None 경로 테이블에 전파되어 Default 경로 테이블에서 모든 비정적 경로가 제거되고 포털의 유효 경로 블레이드가 거의 비어 있기 때문에 이 문서의 목적에 부합되지 않습니다(Azure Firewall로 트래픽을 전송하는 정적 경로 제외).

기본적으로 Virtual WAN 허브는 지역 간 통신이 가능하도록 서로 정보를 교환합니다. Virtual WAN 경로 테이블에서 유효 경로를 검사할 수 있습니다. 예를 들어 다음 그림은 허브 1의 유효 경로를 보여 줍니다.

그런 다음, Virtual WAN이 이러한 유효 경로를 분기로 보급하고 가상 허브에 연결된 VNet에 삽입하므로, 사용자 정의 경로를 사용할 필요가 없습니다. 가상 허브에서 유효 경고를 검사할 때 “다음 홉 유형” “원본” 필드는 경로의 출처를 표시합니다. 예를 들어 “가상 네트워크 연결”의 다음 홉 유형은 접두사가 Virtual WAN에 직접 연결된 VNet(이전 스크린샷의 VNets 11 및 12)에 정의되었음을 나타냅니다.

VNet 12의 NVA는 다음 홉 유형 "HubBgpConnection"이 의미하는 대로 BGP를 통해 경로 10.1.20.0/22를 삽입합니다(가상 허브를 사용하는 BGP 피어링 참조). 이 요약 경로는 간접 스포크 VNet 121(10.1.21.0/24) 및 VNet 122(10.1.22.0/24)를 모두 다룹니다. 원격 허브의 VNet 및 분기는 hub2의 다음 홉에 표시되며, AS 경로에서 자율 시스템 번호 65520이 이러한 interhub 경로에 두 번 추가된 것을 알 수 있습니다.

허브 2에는 통합 SDWAN 네트워크 가상 어플라이언스가 있습니다. 이러한 통합을 위해 지원되는 NVA에 대한 자세한 내용은 Virtual WAN 허브의 NVA 정보를 참조하세요. SDWAN 분기 10.5.3.0/24의 경로에는 VPN_S2S_Gateway의 다음 홉이 포함됩니다. 이 유형의 다음 홉은 오늘날 Azure Virtual Network Gateway 또는 허브에 통합된 NVA에서 오는 경로를 나타낼 수 있습니다.

허브 2에서 간접 스포크 VNet 221(10.2.21.0/24) 및 VNet 222(10.2.22.0/24)에 대한 10.2.20.0/22 경로는 원본 defaultRouteTable에 표시된 대로 정적 경로로 설치됩니다. 허브 1의 유효 경로를 체크 인하면 여기에 해당 경로가 없습니다. 그 이유는 정적 경로가 BGP를 통해 전파되지 않고 모든 허브에 구성되어야 하기 때문입니다. 따라서 허브 1의 VNet과 분기 사이의 연결을 허브 2의 간접 스포크(VNets 221 및 222)에 제공하기 위해 허브 1에 정적 경로가 필요합니다.

정적 경로 허브 1을 추가하면 10.2.20.0/22 경로도 포함됩니다.

시나리오 2: Global Reach 및 허브 라우팅 기본 설정

허브 1이 회로 2(10.5.2.0/24)의 ExpressRoute 접두사를 알고 있고 허브 2가 회로 1(10.4.2.0/24)의 ExpressRoute 접두사를 알고 있더라도 원격 지역의 ExpressRoute 경로는 온-프레미스 ExpressRoute 링크로 다시 보급되지 않습니다. 따라서 ExpressRoute 위치가 서로 통신하려면 ExpressRoute Global Reach가 필요합니다.

가상 허브 라우팅 기본 설정에서 설명한 대로 Virtual WAN에서는 기본적으로 ExpressRoute에서 오는 경로를 선호합니다. 경로는 허브 1에서 ExpressRoute 회로 1로, ExpressRoute 회로 1에서 회로 2로, ExpressRoute 회로 2에서 허브 2로(및 그 반대로) 보급되기 때문에, 가상 허브에서는 현재 더 직접적인 내부 허브 링크보다 이 경로를 선호하게 됩니다. 허브 1의 유효 경로는 다음과 같습니다.

경로에서 볼 수 있듯이 ExpressRoute Global Reach는 이러한 경로의 선호도를 낮추기 위해 Azure로 경로를 다시 전송하기 전 ExpressRoute 자율 시스템 번호(12076)를 여러 번 추가합니다. 그러나 Virtual WAN 기본 허브 경로가 ExpressRoute보다 우선되므로 경로를 결정할 때 AS 경로 길이가 무시됩니다.

허브 2의 유효 경로는 다음과 비슷합니다.

가상 허브 라우팅 기본 설정에 설명된 대로 라우팅 기본 설정을 VPN 또는 AS 경로로 변경할 수 있습니다. 예를 들어 기본 설정을 VPN으로 설정할 수 있습니다.

VPN의 허브 라우팅 기본 설정에서 허브 1의 유효 경로는 다음과 같습니다.

이전 이미지는 10.4.2.0/24 경로에 이제 VPN_S2S_Gateway의 다음 홉이 포함되지만 ExpressRoute의 기본 라우팅 기본 설정에서는 ExpressRouteGateway인 것을 보여줍니다. 그러나 허브 2에서 10.5.2.0/24 경로는 대체 경로가 VPN 게이트웨이가 아닌 허브에 통합된 NVA에서 오기 때문에 계속 ExpressRoute의 다음 홉으로 표시됩니다.

그러나 허브 간 트래픽에는 여전히 ExpressRoute를 통해 들어오는 경로가 선호됩니다. 가상 허브 간의 보다 효율적인 직접 연결을 사용하려면 두 허브에서 경로 기본 설정을 "AS 경로"로 설정할 수 있습니다.

허브 1에서 원격 스포크와 분기의 경로에는 의도한 대로 Remote Hub의 다음 홉이 포함됩니다.

허브 2(192.168.2.0/23)의 IP 접두사는 계속 Global Reach 링크를 통해 연결할 수 있는 것으로 표시되지만 허브 2의 디바이스로 전송되는 트래픽이 없어야 하므로 트래픽에 영향을 주지 않습니다. 이 경로는 두 허브 모두 서로 간에 SDWAN 터널을 설정하는 NVA가 있는 경우 문제가 될 수 있습니다.

그러나 이제는 10.4.2.0/24가 VPN 게이트웨이보다 선호됩니다. 이러한 경우는 VPN을 통해 보급된 경로가 ExpressRoute를 통해 보급된 경로보다 짧은 AS 경로를 가질 때 발생할 수 있습니다. 선호도 감소를 위해 자율 시스템 번호(65501)를 VPN 경로에 추가하도록 온-프레미스 VPN 디바이스를 구성한 후 허브 1이 이제 ExpressRoute를 10.4.2.0/24의 다음 홉으로 선택합니다.

허브 2는 다른 허브의 VNet 및 분기가 이제 Remote Hub에 다음 홉으로 표시되는 유효 경로에 대해 비슷한 테이블을 보여 줍니다.

시나리오 3: ExpressRoute 회로를 두 허브에 교차 연결

Azure 지역과 ExpressRoute를 통해 연결된 온-프레미스 위치 사이에 직접 링크를 추가하려면 다음 토폴로지에 표시된 것처럼 “bow tie”라고도 부르는 토폴로지에 따라 단일 ExpressRoute 회로를 여러 Virtual WAN 허브에 연결하는 것이 바람직한 경우가 많습니다.

Virtual WAN에 두 회로가 두 허브에 모두 연결되었음이 표시됩니다.

ExpressRoute의 기본 허브 라우팅 기본 설정으로 돌아가면 원격 분기 및 허브 1의 VNet 경로에 다시 ExpressRoute가 다음 홉으로 표시됩니다. 이번에는 Global Reach가 아니라 ExpressRoute 회로가 하 허브에서 다른 허브로 수신하는 경로 보급을 다시 반송하기 때문입니다. 예를 들어 ExpressRoute 허브 라우팅 기본 설정이 적용된 허브 1의 유효 경로는 다음과 같습니다.

허브 라우팅 기본 설정을 다시 AS 경로로 변경하면 허브 1과 2 사이의 직접 연결을 사용하여 허브 간 경로가 최적 경로로 돌아갑니다.

다음 단계

Virtual WAN에 대한 자세한 내용은 다음을 참조하세요.

• Virtual WAN FAQ