이전 블로그 게시물 에서는 허브 앤 스포크 토폴로지에서 Azure VMware Solution(AVS) 환경의 모의 구축을 시작하기 위한 기본 환경을 배포하는 방법을 살펴보았습니다. 마지막 섹션 에서는 VPN과 스포크 VM 간의 트래픽을 조회할 때 매트릭스 결함을 발견했습니다. 이 블로그 게시물에서는 이 문제를 해결하는 방법을 살펴보겠습니다 .
또한 AVS 배포에서 Express Route 회로를 연결하기 위한 AVS 전송 vNet의 첫 번째 구성 요소를 소개하고 VMware 워크로드에 기본 BGP 경로를 주입하는 방법 도 소개합니다 .
이 블로그 게시물에 설명된 구성 요소와 네트워크 설계는 데모 목적으로만 제공됩니다. 프로덕션 환경에서 사용하기 위한 것이 아니며 Azure 모범 사례를 나타내는 것도 아닙니다. 모의 및 학습 목적으로만 있는 그대로 제공됩니다.
실험실 환경과 이미 다룬 3가지 첫 단계에 대한 자세한 내용은 1부를 참조하세요 .
4단계 – GatewaySubnet의 사용자 정의 경로
비대칭 라우팅 문제를 완화하기 위해 GatewaySubnetVPN 클라이언트에서 들어오는 트래픽이 NVA 어플라이언스로 라우팅되도록 사용자 정의 경로를 추가합니다 .
사용자 정의 경로(UDR)는 GatewaySubnet아래와 같이 구성됩니다.
- 10.100.201.0/24(일명 spoke1-vnet)를 통해nva-vm.nic[0].ipaddress
- 10.100.202.0/24(일명 spoke2-vnet)를 통해nva-vm.nic[0].ipaddress
Azure Portal에서는 다음과 같습니다.
물론, 사용된 IP 주소 계획에 따라 여러 경로를 공통 접두사 아래에 단순화하고 그룹화하는 것이 가능합니다.
경로 분석(s4)
이 지점에서 우리는 VPN 클라이언트-스포크와 스포크-VPN 대상지 모두가 hub-nva어플라이언스를 통과하는 것을 볼 수 있습니다.
예: VPN 클라이언트에서 ping 세션이 진행되는 동안 에코 요청 과 에코 응답이spoke-1-vm 모두 : 를 통해서만 전송되는 것을 볼 수 있습니다 .hub-nva
ubuntu@hub-nva:~$ sudo tcpdump -nni eth0 icmp
# output
IP 10.100.204.2 > 10.100.201.4: ICMP echo request, id 1002, seq 1, length 64
IP 10.100.200.68 > 10.100.201.4: ICMP echo request, id 1002, seq 1, length 64
IP 10.100.201.4 > 10.100.200.68: ICMP echo reply, id 1002, seq 1, length 64
IP 10.100.201.4 > 10.100.204.2: ICMP echo reply, id 1002, seq 1, length 64
이제 모든 네트워크 트래픽이 .를 통과합니다 hub-nva. 즉, 비대칭 라우팅 문제가 해결되었습니다.
Azure UDR에 대한 추가 정보
Azure의 UDR에 대해 자세히 알아보려면 다음 게시물을 꼭 읽어보세요.
- Azure 설명서의 사용자 정의 경로
- Azure 설명서에서 Azure가 경로를 선택하는 방법
- Jose Moreno의 Azure Routes에 물리지 마세요
5단계 – AVS 전송 vNet 소개
Azure VMware 솔루션(AVS)은 Express Route 회로 기반 외부 연결을 제공합니다. 이를 위해서는 AVS 환경 외부로 Express Route 회로를 '연결'해야 합니다. 가장 일반적인 방법은 AVS Express Route 회로를 기존 온프레미스 Express Route 회로에 매핑하고 Express Route Global Reach를 통해 두 회로 간의 연결을 제공하는 것 입니다 . 즉, 전이적 연결(transitive connection)을 구현합니다.
하지만 이 설정은 AVS 배포를 허브-스포크 토폴로지의 스포크로 간주할 수 있는 방법을 제공하지 않습니다. AVS와 온프레미스 간의 네트워크 트래픽이 .를 우회하기 때문입니다 hub-nva. 이 문제를 해결하기 위해 AVS 배포에서 Express Route 회로를 연결하고 AVS와 온프레미스 간의 트래픽이 .를 통해 라우팅되도록 트랜짓 vNet을hub-nva 도입합니다 .
여기에서는 avs-transit-vnetAVS 배포에서 Express Route 회로를 착륙시키기 위해 Express Route Gateway가 필요합니다.
경로 분석(s5)
vNet 생성이 완료되고 AVS ER 회로 설정이 완료되면 이 단계에서 AVS 기반 VM과 통신할 수 있는 가능성이 있는지 확인하기 위해 효과적인 경로를 살펴볼 수 있습니다.
az network nic show-effective-route-table \
--ids /subscriptions/<sub-id>/resourceGroups/nva-testing-RG/providers/Microsoft.Network/networkInterfaces/hub-nva-nic \
-o table
# output
Source State Address Prefix Next Hop Type Next Hop IP
--------------------- ------- ---------------- --------------------- -------------
Default Active 10.100.200.0/24 VnetLocal
Default Active 10.100.202.0/24 VNetPeering
Default Active 10.100.201.0/24 VNetPeering
Default Active 10.100.203.0/24 VNetPeering
VirtualNetworkGateway Active 10.100.204.0/24 VirtualNetworkGateway 20.160.147.74
물론, 경로가 없으면 연결도 없습니다.
ubuntu@hub-nva:~$ ping 10.100.100.2 -c3
# output
PING 10.100.100.2 (10.100.100.2) 56(84) bytes of data.
--- 10.100.100.2 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2029ms
AVS 연결 설정 에 따라 Express Route 연결에서 발표된 경로를 사용하여 인터넷이나 다른 Azure 리소스에 도달하는 경우 발표된 경로가 없기 때문에 AVS 외부 리소스와 통신할 수 없습니다.
AVS 연결에 대한 추가 정보
AVS 연결에 대해 자세히 알아보려면 다음 게시물을 꼭 읽어보세요.
- Azure 설명서의 Azure VMware 솔루션 네트워킹 및 상호 연결 개념
- Azure 설명서의 Azure VMware Solution 네트워크 설계 고려 사항
- Jose Moreno의 Azure VMware 솔루션 네트워킹 부두
6단계 – AVS에 기본 경로 광고
현재 단계에서는 AVS에 기본 경로(0.0.0.0/0)를 공지할 예정입니다. 이 블로그 게시물 시리즈의 핵심 주제대로, 단계별로 진행하며 가장 간단한 해결책인 AVS에서 기본 경로 공지부터 시작할 것입니다 avs-transit-vnet. 그리고 허브 앤 스포크 토폴로지의 이전 구성 요소는 일시적으로 무시하겠습니다.
첫째, AVS 트랜짓 토폴로지 에 몇 가지 추가 구성 요소를 추가해야 합니다 .
- VM avs-bgp-vm에서:
- BGP 경로 발표 시작
- AVS에서 들어오는 트래픽을 라우팅합니다.
- Azure SDN에서 경로 공지를 전파하기 위한 Azure Route Server( ARS )
- 이 ARS 구성 요소는 가상 네트워크 게이트웨이를avs-bgp-vm 통해 BGP 피어에서 AVS로 들어오는 경로를 제공하고 피어링 됩니다 .
- . 에서 광고하는 기본 경로를 재정의하는 경로 테이블 ( UDR) avs-bgp-vm입니다. 그렇지 않으면 VM은 자신을 전체 vNET의 기본 경로로 광고하고, VM에서 보낸 트래픽을 포함하여 인터넷으로 향하는 트래픽을 계속 전송합니다 .
avs-transit-vnet앞서 언급했듯이 이는 첫 번째이자 임시 단계입니다. AVS 배포를 위해 인터넷 연결이 이루어진 이 설정을 검증하면 다음 단계를 이해하고 준비하는 데 도움이 됩니다.
AVS 인터넷 연결 설정
Azure VMware 솔루션은 인터넷 연결을 위한 세 가지 옵션을 제공합니다.
이 블로그 게시물 시리즈에서는 AVS가 Express Route 회로를 통해 발표된 기본 경로에서 인터넷 연결을 받도록 구성되어 있다고 생각해 보겠습니다 .
경로 분석(s6)
새로운 구성 요소와 연결 생성이 완료되면 다음과 같은 효과적인 경로를 살펴보고 결과를 확인할 수 있습니다.
배포된 Azure Route Server 에서 BGP 피어를 볼 수 있습니다.
az network routeserver peering show -g nva-testing-RG \
-n avs-rs-bgp-connection --routeserver AVSTransitRouterServer \
-o table
# output
Name PeerAsn PeerIp ProvisioningState ResourceGroup
--------------------- --------- ------------- ------------------- ---------------
avs-rs-bgp-connection 65002 10.100.203.68 Succeeded nva-testing-RG
그리고 BGP 피어가 광고한 학습된 경로를 확인 해야 합니다 .
az network routeserver peering list-learned-routes \
-g nva-testing-RG -n avs-rs-bgp-connection \
--routeserver AVSTransitRouterServer -o table
# output
Issue: no route displayed there!
명령 list-learned-routes이 예상대로 작동하지 않습니다. 현재 이 문제를 조사 중입니다. 그동안 PowerShell 명령을 사용하여 Get-AzRouteServerPeerLearnedRoute경로를 표시하겠습니다.
PowerShell을 사용하면 광고된 경로가 표시됩니다.
$routes = @{
RouteServerName = 'AVSTransitRouterServer'
ResourceGroupName = 'nva-testing-RG'
PeerName = 'avs-rs-bgp-connection'
}
Get-AzRouteServerPeerLearnedRoute @routes | ft
LocalAddress Network NextHop SourcePeer Origin AsPath Weight
------------ ------- ------- ---------- ------ ------ ------
10.100.203.36 0.0.0.0/0 10.100.203.68 10.100.203.68 EBgp 65002 32768
10.100.203.37 0.0.0.0/0 10.100.203.68 10.100.203.68 EBgp 65002 32768
avs-bgp-vm이 (가) 자신을 기본 경로의 다음 홉으로 광고하고 있음 을 알 수 있습니다 . 이는 예상되는 동작입니다.
테스트(s6)
AVS에 호스팅된 VM에서 다음을 통해 인터넷에 접속할 수 있습니다 avs-bgp-vm.
ubuntu@avs-vm-100-10:~$ mtr 1.1.1.1 --report
HOST: avs-vm-100-10 Loss% Snt Last Avg Best Wrst StDev
1.|-- _gateway 0.0% 10 0.1 0.2 0.1 0.2 0.0
2.|-- 100.64.176.0 0.0% 10 0.2 0.3 0.2 0.3 0.0
3.|-- 100.72.18.17 0.0% 10 0.9 0.8 0.7 0.9 0.1
4.|-- 10.100.100.233 0.0% 10 1.0 1.0 0.9 1.1 0.1
5.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
6.|-- 10.100.203.68 0.0% 10 3.2 4.0 2.6 7.3 2.0 # <--- avs-bgp-vm
7.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
8.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
9.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
10.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
11.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
12.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
13.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
14.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
15.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
16.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
17.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
18.|-- one.one.one.one 0.0% 10 5.7 4.9 3.9 9.6 1.7
이전 경로 추적 보고서에서는 이 시나리오에서 예상한 대로 라우터나 NVA처럼 작동하는 10.100.203.68IP가 있습니까 ?avs-bgp-vm
하지만 분명히 이는 h&s 토폴로지의 나머지 부분에 대한 표준 스포크 동작과는 다릅니다. 이 단계는 앞으로 필요한 일부 구성 요소를 준비하기 위한 것일 뿐입니다.
Azure Route Server를 통한 AVS 연결에 대한 추가 정보
Azure에서 Azure Route Server를 통한 AVS 연결에 대해 자세히 알아보려면 다음 게시물을 꼭 읽어보세요.
- Azure 설명서의 Azure Route Server를 사용하여 Azure VMware 솔루션에 경로 주입
- Azure 설명서에서 모든 네트워크 트래픽을 검사하기 위한 Azure Virtual Network의 네트워크 가상 어플라이언스
2부 – 결론
두 번째 부분에서는 VPN Gateway에 적용 가능한 새로운 경로 테이블을 구성하여 비대칭 라우팅 문제를 완화하는 방법을 살펴보았고 , Azure Route Server 의 도움으로 Azure VMware Solution 배포 에 BGP 경로를 광고하기 위한 네트워크 구성 요소를 생성했습니다 .
다음 (그리고 아마도 마지막) 부분에서는 이 AVS 전송 토폴로지를 허브 앤 스포크 토폴로지에서 일반 스포크로 구성하는 방법을 살펴보겠습니다. 또한 Azure Route Server를 활용하여 온프레미스 연결 구성을 간소화하는 방법도 다룹니다 .
'IT이야기 > Azure' 카테고리의 다른 글
| 공개 미리 보기 – Azure Arc 지원 VMware vSphere – 1부 (0) | 2025.04.15 |
|---|---|
| 허브 앤 스포크 토폴로지의 Azure VMware 솔루션 모형 – 3부 (0) | 2025.04.15 |
| 허브 앤 스포크 토폴로지의 Azure VMware 솔루션 모형 – 1부 (0) | 2025.04.15 |
| Azure VMware Solution NSX-T 배포 시 타사 방화벽 NVA 사용 (0) | 2025.04.15 |
| Azure Data Explorer 및 Grafana를 사용하여 Azure VMware 솔루션 모니터링 (0) | 2025.04.15 |
