이전 블로그 게시물( 1부 및 2부 )에서는 Azure VMware Solution(AVS) 배포를 포함한 허브 앤 스포크 토폴로지의 기본 구성 요소 배포에 대해 다루었습니다.
첫 번째 게시물에서는 허브 앤 스포크 환경의 모형을 구축하고 구성했습니다. 두 번째 게시물에서는 AVS 환경을 AVS 트랜짓 가상 네트워크(vNet) 에 연결 하고 AVS 워크로드에 기본 경로를 알렸습니다. 이 기본 경로는 아직 저희 어플라이언스를 사용하지 않고 , 인터넷에 연결하기 위해 hub-vna배포된 어플라이언스를 사용했습니다.avs-transit-vnet
avs-transit-vnet이 단계에서는 전체 h&s 토폴로지를 통합 하고 hub-nvaVM을 사용하여 다음을 포함한 모든 필수 필터링을 관리합니다.
- 스포크 투 스포크
- 스포크 투 온프레미스(또는 그 반대)
- 인터넷 브레이크아웃
AVS가 스포크처럼 동작하기를 원하므로 이 규칙을 AVS에도 적용할 것입니다 avs-transit-vnet.
이 블로그 게시물에 설명된 구성 요소와 네트워크 설계는 데모 목적으로만 제공됩니다. 프로덕션 환경에서 사용하기 위한 것이 아니며 Azure 모범 사례를 나타내는 것도 아닙니다. 모의 및 학습 목적으로만 있는 그대로 제공됩니다.
7단계 – AVS에 허브 기본 경로 광고
먼저, 에 적용되는 새 UDR에 몇 가지 경로를 추가해야 합니다 nva-subnet. 추가된 경로는 hub-nva를 통해 AVS 관련 트래픽을 전파할 수 있도록 합니다 avs-bgp-vm. 랩 설정에서는 두 개의 접두사에 대해 이 작업을 수행합니다.
- AVS 관리:10.100.100.0/22
- AVS 작업 부하:10.100.110.0/24
또한 어플라이언스 를 통해 기본 경로를 추가하려면 bgp-subnet내부 에 적용된 UDR을 업데이트해야 합니다 .avs-transit-vnethub-nva
경로 분석(s7)
NIC 에 적용 가능한 새로운 경로를 확인할 수 있습니다 hub-nva.
az network nic show-effective-route-table \
--ids /subscriptions/<sub-id>/resourceGroups/nva-testing-RG/providers/Microsoft.Network/networkInterfaces/hub-nva-nic \
-o table
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
Default Active 0.0.0.0/0 Internet
...
User Active 10.100.110.0/24 VirtualAppliance 10.100.203.68 # <--- AVS workload
User Active 10.100.100.0/22 VirtualAppliance 10.100.203.68 # <--- AVS management
AVS 이동 중 UDRbgp-subnet
스포크-투-스포크와 인터넷 브레이크아웃에 의존하고자 하므로 , 내부 에 적용된 UDR을 변경하여 통과를 보장 hub-nva해야 합니다 .bgp-subnetavs-transit-vnethub-nva
그리고 효과적인 경로에 대한 결과는 다음과 같습니다.
az network nic show-effective-route-table \
--ids /subscriptions/<sub-id>/resourceGroups/nva-testing-RG/providers/Microsoft.Network/networkInterfaces/avs-bgp-nic \
-o table
Source State Address Prefix Next Hop Type Next Hop IP
--------------------- ------- ----------------- --------------------- -------------
Default Active 10.100.203.0/24 VnetLocal
Default Active 10.100.200.0/24 VNetPeering
VirtualNetworkGateway Active 10.100.100.64/26 VirtualNetworkGateway 10.24.132.60
VirtualNetworkGateway Active 10.100.109.0/24 VirtualNetworkGateway 10.24.132.60
VirtualNetworkGateway Active 10.100.101.0/25 VirtualNetworkGateway 10.24.132.60
VirtualNetworkGateway Active 10.100.100.0/26 VirtualNetworkGateway 10.24.132.60
VirtualNetworkGateway Active 10.100.110.0/24 VirtualNetworkGateway 10.24.132.60
VirtualNetworkGateway Active 10.100.111.0/24 VirtualNetworkGateway 10.24.132.60
VirtualNetworkGateway Active 10.100.113.0/24 VirtualNetworkGateway 10.24.132.60
VirtualNetworkGateway Active 10.100.114.0/24 VirtualNetworkGateway 10.24.132.60
VirtualNetworkGateway Active 10.100.100.192/32 VirtualNetworkGateway 10.24.132.60
VirtualNetworkGateway Active 10.100.103.0/26 VirtualNetworkGateway 10.24.132.60
VirtualNetworkGateway Active 10.100.101.128/25 VirtualNetworkGateway 10.24.132.60
VirtualNetworkGateway Active 10.100.102.0/25 VirtualNetworkGateway 10.24.132.60
VirtualNetworkGateway Invalid 0.0.0.0/0 VirtualNetworkGateway 10.100.203.68
User Active 0.0.0.0/0 VirtualAppliance 10.100.200.68 # <--- Default route via hub-nva
마지막 줄에서 기본 경로가 이제 hub-nvaVM( 10.100.200.68)을 통해 이동하고 있음을 알 수 있습니다.
테스트(s7)
이 단계에서 AVS를 오가는 트래픽은 와 hub-nva를 통과합니다 avs-bgp-vm. 각 라우팅 어플라이언스를 스누핑하거나 traceroute스포크 VM으로의 의 결과를 확인하여 이를 쉽게 확인할 수 있습니다.
ubuntu@avs-vm-100-10:~$ mtr 10.100.201.4 --report
HOST: avs-vm-100-10 Loss% Snt Last Avg Best Wrst StDev
1.|-- _gateway 0.0% 10 0.2 0.2 0.1 0.2 0.0
2.|-- 100.64.176.0 0.0% 10 0.2 0.2 0.2 0.3 0.0
3.|-- 100.72.18.17 0.0% 10 0.8 0.8 0.7 1.1 0.1
4.|-- 10.100.100.237 0.0% 10 1.1 1.2 1.1 1.4 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.1 3.1 2.7 5.6 0.9 # <--- avs-bgp-vm
7.|-- 10.100.200.68 0.0% 10 4.5 4.8 3.4 7.6 1.6 # <--- hub-nva
8.|-- 10.100.201.4 0.0% 10 4.1 6.6 4.1 9.3 1.8 # <--- spoke-vm
여기서 우리는 홉 6 과 7avs-bgp-vm 에서 ( 10.100.203.68)와 hub-nva( ) 의 IP 주소를 볼 수 있습니다 10.100.200.68. 인터넷 대상에서도 동일한 동작을 재현할 수 있습니다.
안타깝게도 온프레미스(VPN) 리소스에서는 두 avs-transit-vnet리소스 모두 사용할 수 없습니다. 해당 대상에 대해 광고된 경로가 없기 때문입니다.
8단계 – 온프레미스의 AVS
이전 단계에서 발견한 대로 온프레미스 리소스에는 두 AVS 리소스 중 어느 하나와도 통신하기 위해 광고된 경로가 없습니다 avs-transit-vnet.
현재 단계에서는 다음을 추가하여 이러한 부족함을 완화할 것입니다.
- UDR의 새로운 경로 avs-transit-vnet와 AVS 리소스 GatewaySubnet.
- 랩 설정에서 경로를 단순화하기 위해 Azure 리소스(AVS 리소스 포함)의 글로벌 접두사를 단일 경로로 광고합니다.10.100.0.0/16
- 이 UDR은 VPN 게이트웨이에서 리소스에 대한 네트워크 경로를 찾는 데 사용됩니다.
- VPN 구성에서 사용자 지정 경로를 사용하면 VPN 클라이언트가 대상 리소스에 대한 네트워크 트래픽이 VPN을 통과해야 함을 지정할 수 있습니다.
- UDR의 경우 모든 리소스에 대한 글로벌 접두사를 사용하여 설정에서 사용자 지정 경로 알림을 간소화합니다.10.100.0.0/16
테스트(s8)
VPN 클라이언트에서 10.100.0.0/16VPN 경로에 사용자 지정 경로( )가 추가된 것을 쉽게 볼 수 있습니다.
AVS 기반 VM을 사용하여 P2S VPN 클라이언트의 연결을 확인하면 다음과 같습니다.
ubuntu@vpn-client:~$ ping 10.100.110.10 -c3
# output
PING 10.100.110.10 (10.100.110.10) 56(84) bytes of data.
64 bytes from 10.100.110.10: icmp_seq=1 ttl=57 time=52.3 ms
64 bytes from 10.100.110.10: icmp_seq=2 ttl=57 time=30.1 ms
64 bytes from 10.100.110.10: icmp_seq=3 ttl=57 time=52.9 ms
--- 10.100.110.10 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 30.097/45.119/52.947/10.625 ms
경로 분석(s8)
이 온프레미스 에서 AVS 로의 교환에서는 다음 라우팅 구성 요소가 사용됩니다.
- VPN 클라이언트 측에서 사용자 지정 경로는 Azure 글로벌 접두사 및/또는 AVS 리소스와 일치하는 리소스에 대한 경로를 광고합니다.
- VPN 게이트웨이는 연결된 UDR을hub-nva 사용하여 다음 홉으로 사용합니다 .
- AVS 기반 리소스에 대한 경로를 찾기 위해 UDR hub-nva을 다음 홉으로 사용합니다 .avs-bgp-vm
- vNET 피어링은 리소스 간 통신을 가능하게 합니다 hub-vnet.avs-transit-vnet
- 에서 avs-transit-vnetAVS 리소스에 대한 경로는 AVS에 연결된 Express Route Gateway 에서 직접 광고되고 AVS BGP 경로를 전파합니다.
반대 방향으로:
- Azure Route 서버avs-gbp-vm 와 조합하면 AVS 기반 워크로드에 대한 기본( ) 경로가 제공됩니다 .0.0.0.0/0
- 6a) 기본 경로는 BGP를 통해 발표됩니다.avs-transit-vnet
- 6b) Azure Route Server는 Azure SDN에서 경로 광고를 전파하고 경로는 Express Route 회로를 통해 AVS 워크로드에 광고될 수 있습니다.
- vNET 피어링은 리소스 간 통신을 가능하게 합니다 hub-vnet.avs-transit-vnet
- 에서 hub-vnetVPN 기반 워크로드로의 경로는 VPN 게이트웨이 에서 직접 광고됩니다 .
9단계 – 허브 vNet의 Azure 서버
hub-nvaBGP 기능과 Azure Route Server를 함께 사용하면 Azure에서 사용되는 네트워크 접두사를 VPN 가상 네트워크 게이트웨이 에 광고하고 . 의 경로 테이블을 유지 관리하지 않아도 됩니다 GatewaySubnet.
이전 설정과 비교해서 다음이 제거되었습니다 .
- VPN 구성의 사용자 지정 경로
- GatewaySubnet 에 연결된 UDR
그리고 우리는 이렇게 덧붙였습니다 .
- 새로운 Azure Route 서버
- hub-nva(랩의 글로벌 Azure 접두사를 사용했지만 이는 더 구체적인 공지일 수 있음) 에서 광고된 BGP 경로
- Azure Route Serverhub-nva 간의 BGP 피어링
경로 분석(s9)
Azure Route Server 에서 BGP 피어가 예상 경로를 주입하고 있는 것을 확인할 수 있습니다.
$routes = @{
RouteServerName = 'HubRouterServer'
ResourceGroupName = 'nva-testing-RG'
PeerName = 'hub-rs-bgp-connection'
}
Get-AzRouteServerPeerLearnedRoute @routes | ft
# output
LocalAddress Network NextHop SourcePeer Origin AsPath Weight
------------ ------- ------- ---------- ------ ------ ------
10.100.200.36 10.100.0.0/16 10.100.200.68 10.100.200.68 EBgp 65001 32768
10.100.200.37 10.100.0.0/16 10.100.200.68 10.100.200.68 EBgp 65001 32768
VPN 게이트웨이 에서도 광고된 경로를 볼 수 있습니다.
az network vnet-gateway list-learned-routes -n hub-vpn-gateway -g nva-testing-RG -o table
# output
Network NextHop Origin SourcePeer AsPath Weight
----------------- ------------- -------- ------------- -------- --------
10.100.200.0/24 Network 10.100.200.5 32768
10.100.201.0/24 Network 10.100.200.5 32768
10.100.202.0/24 Network 10.100.200.5 32768
10.100.204.0/25 Network 10.100.200.5 32768
10.100.204.128/25 10.100.200.4 IBgp 10.100.200.4 32768
10.100.204.128/25 10.100.200.4 IBgp 10.100.200.36 32768
10.100.204.128/25 10.100.200.4 IBgp 10.100.200.37 32768
10.100.0.0/16 10.100.200.68 IBgp 10.100.200.36 65001 32768 # <--- BGP route from hub-nva
10.100.0.0/16 10.100.200.68 IBgp 10.100.200.37 65001 32768 # <--- BGP route from hub-nva
10.100.200.0/24 Network 10.100.200.4 32768
10.100.201.0/24 Network 10.100.200.4 32768
10.100.202.0/24 Network 10.100.200.4 32768
10.100.204.128/25 Network 10.100.200.4 32768
10.100.204.0/25 10.100.200.5 IBgp 10.100.200.5 32768
10.100.204.0/25 10.100.200.5 IBgp 10.100.200.36 32768
10.100.204.0/25 10.100.200.5 IBgp 10.100.200.37 32768
10.100.0.0/16 10.100.200.68 IBgp 10.100.200.36 65001 32768 # <--- BGP route from hub-nva
10.100.0.0/16 10.100.200.68 IBgp 10.100.200.37 65001 32768 # <--- BGP route from hub-nva
VPN 클라이언트에서도 vNET 피어링 간의 경로를 사용할 수 있습니다.
테스트(s9)
VPN 클라이언트에서 AVS 기반 VM에 도달하면 토폴로지의 구성 요소를 볼 수 있습니다.
ubuntu@vpn-client:~$ mtr 10.100.110.10 -r
# output
Start: 2023-02-09T17:21:35+0100
HOST: vpn-client Loss% Snt Last Avg Best Wrst StDev
1.|-- vpn-client 0.0% 10 0.5 0.5 0.3 1.0 0.3
2.|-- 10.100.200.68 0.0% 10 21.0 53.3 20.6 307.4 89.7
3.|-- 10.100.203.68 0.0% 10 25.4 44.5 21.6 207.4 57.8
4.|-- 10.100.203.4 0.0% 10 36.0 42.4 21.9 120.7 29.9
5.|-- 10.100.100.233 0.0% 10 54.0 32.0 23.8 59.9 13.5
6.|-- 10.100.100.65 0.0% 10 49.3 39.8 24.6 55.8 12.5
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.|-- 10.100.110.10 0.0% 10 60.5 37.4 22.7 64.9 18.2
mtr다음 다이어그램에서 추적 의 홉 번호를 일치시켰습니다 (홉 세트는 AVS 네트워크 스택의 일부이며 여기에 문서화되지 않음을 고려):
Azure Route Server를 통한 AVS 연결에 대한 추가 정보
Azure Route Server에 대해 자세히 알아보려면 다음 게시물을 꼭 읽어보세요.
- Azure Route Server: 캡슐화할지 말지, 그것이 문제 이며 BGP 슈퍼히어로에 합류할 Azure Firewall의 조력자 Jose Moreno
- Cynthia Treger의 Azure Route Server, VxLAN(또는 IPSec) 및 BGP를 갖춘 NVA Routing 2.0
- Azure 설명서의 Azure Route Server
3부 – 결론
이 시리즈의 마지막 3개 게시물에서는 Azure VMware 솔루션 배포에 허브 및 스포크 토폴로지를 도입하는 맥락에서 Azure 네트워킹과 관련된 많은 주제를 다루었습니다 .
Azure 제품(예: Azure Route Server)의 성능과 기능(예: UDR의 경로 전파)을 보여주기 위해 이 모형 설정을 단계별로 만들었습니다.
마지막 단계에서는 hub-nvaAVS 환경, 스포크 vNet 및 온프레미스 리소스에서 트래픽을 라우팅하고 필터링할 수 있는 중앙 VM을 갖춘 작업 설정이 있습니다.
참고 : 이 게시물에 설명된 설정은 구성 요소의 고가용성 및 중복성 부족으로 인해 프로덕션 환경에서 사용하기에 적합하지 않습니다. Azure 네트워킹 제품과 기능의 성능을 보여주기 위한 모형일 뿐입니다.
이 시리즈를 즐겁게 읽으시고 Azure 네트워킹에 대해 새로운 것을 배우셨기를 바랍니다. 앞으로 이 시리즈를 확장하여 다음과 같은 새로운 주제와 사용 사례를 담은 게시물이 더 많이 올라올 예정입니다.
- 구성 요소의 높은 가용성 및 중복성
- hub-nvaBGP 를 사용한 동적 라우팅avs-spoke-nva
'IT이야기 > Azure' 카테고리의 다른 글
| 공개 미리 보기 – Azure Arc 지원 VMware vSphere – 2부 (0) | 2025.04.15 |
|---|---|
| 공개 미리 보기 – Azure Arc 지원 VMware vSphere – 1부 (0) | 2025.04.15 |
| 허브 앤 스포크 토폴로지의 Azure VMware 솔루션 모형 – 2부 (0) | 2025.04.15 |
| 허브 앤 스포크 토폴로지의 Azure VMware 솔루션 모형 – 1부 (0) | 2025.04.15 |
| Azure VMware Solution NSX-T 배포 시 타사 방화벽 NVA 사용 (0) | 2025.04.15 |
