개요
Azure에서 VMware 워크로드를 실행하기 위해 Azure VMware Solution을 사용하는 경우 , 안전하고 효율적인 방식으로 다른 Azure 리소스와 연결하는 방법이 궁금할 수 있습니다. 한 가지 방법은 허브 앤 스포크 네트워크 토폴로지를 사용하는 것입니다. 허브 앤 스포크 토폴로지는 여러 스포크 가상 네트워크 의 게이트웨이 역할을 하는 중앙 가상 네트워크( 허브 ) 로 구성된 디자인 패턴입니다 . 이 블로그 게시물에서는 Azure VMware Solution을 허브 앤 스포크 토폴로지와 함께 사용하는 방법과 이러한 접근 방식의 문제점을 살펴보겠습니다.
Azure VMware Solution과 허브 앤 스포크 토폴로지를 사용하면 보안 강화 및 클라우드 호스팅 워크로드 격리 등 여러 이점을 얻을 수 있습니다. 하지만 복잡성, 지연 시간, 대역폭 제한, 라우팅 복잡성, 방화벽 규칙 관리 등과 같은 몇 가지 과제도 고려해야 합니다. 따라서 특정 요구 사항에 따라 네트워크 설계를 신중하게 계획하는 것이 중요합니다.
Azure 공식 설명서에는 Azure VMware Solution의 네트워크 연결과 관련된 시나리오가 이미 제공되어 있습니다. 여기에서 확인할 수 있습니다 . 이 블로그 게시물 시리즈에서는 Azure Virtual Network의 네트워크 가상 어플라이언스에서 매우 가까운 모의 시나리오를 단계별로 재현하여 모든 네트워크 트래픽을 검사해 보겠습니다 .
이 블로그 게시물에 설명된 구성 요소 및 네트워크 설계는 데모 목적으로만 제공됩니다. 프로덕션 환경에서 사용하기 위한 것이 아니며 Azure 모범 사례를 나타내는 것도 아닙니다. 모의 및 학습 목적으로만 있는 그대로 제공됩니다.
재료
이 블로그 게시물 시리즈를 설명하기 위해 여기에 설명된 프로세스의 각 단계를 재현하기 위해 Terraform 코드를 호스팅하는 GitHub 저장소를 만들었습니다 .
이 Terraform 콘텐츠를 사용하면 Azure에서 동일한 환경을 배포하는 반복 가능한 방법이 제공되지만 이 블로그 게시물에 설명된 모든 단계는 Azure Portal이나 Azure CLI를 사용하여 재현할 수도 있습니다.
Azure VMware 솔루션 배포
Azure VMware Solution의 배포 및 구성은 이 블로그 게시물의 범위를 벗어납니다. AVS 환경은 이미 배포 및 구성되어 있다고 가정합니다. 허브 앤 스포크 토폴로지의 필수 설정은 이 시리즈의 다른 섹션에서 다루겠습니다.
0단계 – 기본 설정
첫 번째 단계로, 다음과 같은 매우 기본적인 구성 요소를 사용하여 실험실 설정을 시작하겠습니다.
- 허브 vNET:hub-vnet
- VM(NVA가 될 예정)
- 가상 네트워크 게이트웨이
- 비용이 많이 드는 Express Route 회로를 사용할 수 없이 온프레미스 동작을 시뮬레이션하기 위해 VPN을 선택합니다.
- 2개의 스포크 vNET: spoke1-vnet및spoke2-vnet
- 각각에 스포크 VM이 있음
- P2S VPN 서브넷은 온프레미스 기반 워크로드로 작동합니다.
경로 분석
이러한 설정이 구축되면 구성 요소 간 라우팅 구성을 살펴볼 수 있습니다.
유효 경로 hub-nva.nic[0]:
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
VirtualNetworkGateway Active 10.100.204.0/24 VirtualNetworkGateway 20.16.121.157
Default Active 0.0.0.0/0 Internet
UI에서:
유효 경로 spoke-1-vm.nic[0]:
az network nic show-effective-route-table \
--ids /subscriptions/<sub-id>/resourceGroups/nva-testing-RG/providers/Microsoft.Network/networkInterfaces/spoke-1-vnet-vm-nic \
-o table
# output
Source State Address Prefix Next Hop Type Next Hop IP
-------- ------ - ---------------- -------------- - ------------ -
Default Active 10.100.201.0/24 VnetLocal
Default Active 0.0.0.0/0 Internet
UI에서:
다이어그램과 경로 목록에서 이미 추측할 수 있듯이, 서로 다른 vNet 간의 통신은 불가능합니다. 예를 들어, from에서 hub-nvato로 spoke-1-vm:
ubuntu@hub-nva:~$ ping 10.100.201.4 -c3
# output
PING 10.100.201.4 (10.100.201.4) 56(84) bytes of data.
-- - 10.100.201.4 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2036ms
스포크 간 통신을 시도하면 결과는 똑같습니다. 즉, vNet 간에 연결이 없습니다.
Azure 라우팅에 대한 추가 정보
Azure의 네트워크 및 라우팅에 대해 자세히 알아보려면 다음의 훌륭한 블로그 게시물을 꼭 읽어보세요.
- Azure 네트워킹은 Jose Moreno의 온프레미스 네트워크와 다릅니다.
- Cynthia Treger의 NIC 라우팅 및 Azure 경로
1단계 – 스포크 피어링
spoke1-vnet이 단계에서는 및 간의 피어링을 추가하여 spoke2-vnet통신 hub-vnet을 활성화합니다.
경로 분석(s1)
이러한 설정이 구축되면 구성 요소 간 라우팅 구성을 살펴볼 수 있습니다.
유효 경로 hub-nva.nic[0]:
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.201.0/24 VNetPeering
Default Active 10.100.202.0/24 VNetPeering
VirtualNetworkGateway Active 10.100.204.0/24 VirtualNetworkGateway 20.16.121.157
Default Active 0.0.0.0/0 Internet
유효 경로 spoke-1-vm.nic[0]:
az network nic show-effective-route-table \
--ids /subscriptions/<sub-id>/resourceGroups/nva-testing-RG/providers/Microsoft.Network/networkInterfaces/spoke-1-vnet-vm-nic \
-o table
# output
Source State Address Prefix Next Hop Type Next Hop IP
-------------------- - ------ - ---------------- -------------------- - ------------ -
Default Active 10.100.201.0/24 VnetLocal
Default Active 10.100.200.0/24 VNetPeering
VirtualNetworkGateway Active 10.100.204.0/24 VirtualNetworkGateway 20.16.121.157
Default Active 0.0.0.0/0 Internet
이제 hub-vnet의 VM은 피어링된 네트워크의 VM을 ping할 수 있습니다. 예: from hub-nvato spoke-1-vm:
ubuntu@hub-nva:~$ ping 10.100.201.4 -c3
# output
PING 10.100.201.4 (10.100.201.4) 56(84) bytes of data.
64 bytes from 10.100.201.4: icmp_seq=1 ttl=64 time=1.74 ms
64 bytes from 10.100.201.4: icmp_seq=2 ttl=64 time=1.14 ms
64 bytes from 10.100.201.4: icmp_seq=3 ttl=64 time=0.975 ms
-- - 10.100.201.4 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 0.975/1.284/1.744/0.331 ms
하지만 다른 스포크에 있는 VM은 서로 통신할 수 없습니다. 예를 들어, from spoke-1-vmto spoke-2-vm:
ubuntu@spoke-1-vm:~$ ping 10.100.202.4 -c3
# output
PING 10.100.202.4 (10.100.202.4) 56(84) bytes of data.
-- - 10.100.202.4 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2029ms
VPN 클라이언트에서 이제 모든 네트워크로 가는 경로를 볼 수 있습니다.
- 10.100.202.0/24:spoke2-vnet
- 10.100.201.0/24:spoke1-vnet
- 10.100.200.0/24:hub-vnet
- 10.100.204.0/24:VPN client range
Azure Peering에 대한 추가 정보
Azure의 네트워크 피어링에 대해 자세히 알아보려면 다음 게시물을 꼭 읽어보세요.
- VNet 피어링 설정, Jose Moreno의 친숙한 낯선 사람들
- Azure 설명서의 가상 네트워크 피어링
2단계 – 스포크의 사용자 정의 경로/GW 전파가 참임
이 단계에서는 스포크 간 통신을 활성화하기 위해 spoke1-vnetUDR 을 추가합니다 .spoke2-vnet
각 스포크 서브넷에 대해 다음 구성을 사용하여 UDR을 추가합니다.
- 0.0.0.0/0을 통해nva-vm.nic[0].ipaddress
- disable_bgp_route_propagation = false
UI에서 보면 다음과 같습니다.
hub-nva다음 홉 주소는 hub-vnet의 VM NIC 의 IP 주소입니다 .
또한 다음 게이트웨이 경로 전파 구성을 설정했습니다.
게이트웨이 경로 전파 설정 과 관련하여 Azure UI와 Terraform 간에 문구 차이가 있을 수 있습니다 . Azure UI에서는 이 옵션을 Propagate gateway route.(으)로, Terraform, Bicep, ARM과 같은 API 기반 도구에서는 이 옵션을 disableBgpRoutePropagation(ARM/Bicep) 또는 disable_bgp_route_propagation(Terraform)으로 부릅니다.
이는 부울 값과 관련된 경우 혼동될 수 있습니다. 이 경우, Gatewayfalse 구성 요소 의 경로가 UDR과 연결된 서브넷으로 전파됨을 의미합니다.
경로 분석(s2)
유효 경로 spoke-1-vm.nic[0]:
az network nic show-effective-route-table --ids /subscriptions/<sub-id>/resourceGroups/nva-testing-RG/providers/Microsoft.Network/networkInterfaces/spoke-1-vnet-vm-nic -o table
# output
Source State Address Prefix Next Hop Type Next Hop IP
--------------------- ------- ---------------- --------------------- -------------
Default Active 10.100.201.0/24 VnetLocal
Default Active 10.100.200.0/24 VNetPeering
VirtualNetworkGateway Active 10.100.204.0/24 VirtualNetworkGateway 20.16.121.157
Default Invalid 0.0.0.0/0 Internet
User Active 0.0.0.0/0 VirtualAppliance 10.100.200.68 # <--- via hub-nva
다른 스포크에 있는 VM은 서로 통신할 수 있습니다. 예를 들어, from spoke-1-vmto spoke-2-vm:
ubuntu@spoke-1-vnet-vm:~$ ping 10.100.202.4 -c3
# output
PING 10.100.202.4 (10.100.202.4) 56(84) bytes of data.
64 bytes from 10.100.202.4: icmp_seq=1 ttl=63 time=4.05 ms
64 bytes from 10.100.202.4: icmp_seq=2 ttl=63 time=1.59 ms
64 bytes from 10.100.202.4: icmp_seq=3 ttl=63 time=2.18 ms
-- - 10.100.202.4 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2001ms
rtt min/avg/max/mdev = 1.587/2.604/4.049/1.049 ms
VM 에서 hub-nva다음을 통해 트래픽이 이동하는 것을 볼 수 있습니다.
IP 10.100.201.4 > 10.100.202.4: ICMP echo request, id 8, seq 1, length 64
IP 10.100.200.68 > 10.100.202.4: ICMP echo request, id 8, seq 1, length 64
IP 10.100.202.4 > 10.100.200.68: ICMP echo reply, id 8, seq 1, length 64
IP 10.100.202.4 > 10.100.201.4: ICMP echo reply, id 8, seq 1, length 6
VPN 연결을 통해 다음과 같은 스포크 리소스에 접근할 수 있습니다.
ubuntu@vpn-client:~$ ping 10.100.201.4 -c3
# output
PING 10.100.201.4 (10.100.201.4) 56(84) bytes of data.
64 bytes from 10.100.201.4: icmp_seq=1 ttl=63 time=24.1 ms
64 bytes from 10.100.201.4: icmp_seq=2 ttl=63 time=22.7 ms
64 bytes from 10.100.201.4: icmp_seq=3 ttl=63 time=24.9 ms
하지만 VM에서 보면 hub-nva이 네트워크 트래픽에 맞는 것이 없습니다. 즉, 스포크 VM의 유효 경로 테이블에서 알 수 있듯이 트래픽은 스포크 VM에서 VPN 게이트웨이로 직접 이동하고, 그 반대의 경우도 마찬가지입니다.
다음 단계에서는 트래픽이 VM을 통과하도록 강제하여 이 문제를 완화하려고 노력할 것입니다 hub-nva.
Azure UDR에 대한 추가 정보
Azure의 UDR에 대해 자세히 알아보려면 다음 게시물을 꼭 읽어보세요.
- Azure 설명서의 사용자 정의 경로
- Azure 설명서에서 Azure가 경로를 선택하는 방법
- Jose Moreno의 Azure Routes에 물리지 마세요
3단계 – 스포크의 사용자 정의 경로/GW 전파가 거짓입니다.
이 단계에서는 NVA 장치를 우회하여 VPN과 관련된 네트워크 트래픽에 대해 이전 단계에서 발생했던 문제를 완화하기 시작할 것입니다.
가장 먼저 시도해 볼 수 있는 방법은 이전 단계에서 생성한 UDR에서 게이트웨이 경로 전파를 비활성화하는 것입니다 .
각 스포크 서브넷에 대해 다음 구성을 사용하여 UDR을 추가합니다.
- 0.0.0.0/0을 통해nva-vm.nic[0].ipaddress
- disable_bgp_route_propagation = true
UI에서 보면 다음과 같습니다.
앞서 언급했듯이 자동화 도구를 사용하여 이 구성 값을 설정하는 경우, 용어가 혼동될 수 있습니다. Azure UI에서는 이 옵션을 .(으)로, Terraform, Bicep, ARM과 같은 API 기반 도구에서는 이 옵션을 (ARM/Bicep) 또는 (Terraform) Propagate gateway route으로 부릅니다 .disableBgpRoutePropagationdisable_bgp_route_propagation
이 경우, Gatewaytrue 구성 요소 의 경로가 UDR과 연결된 서브넷으로 전파되지 않음을 의미합니다.
경로 분석(s3)
유효 경로 spoke-1-vm.nic[0]:
az network nic show-effective-route-table \
--ids /subscriptions/<sub-id>/resourceGroups/nva-testing-RG/providers/Microsoft.Network/networkInterfaces/spoke-1-vnet-vm-nic \
-o table
# output
Source State Address Prefix Next Hop Type Next Hop IP
-------- ------ - ---------------- ---------------- ------------ -
Default Active 10.100.201.0/24 VnetLocal
Default Active 10.100.200.0/24 VNetPeering
Default Invalid 0.0.0.0/0 Internet
User Active 0.0.0.0/0 VirtualAppliance 10.100.200.68 # <--- via hub-nva
새로운 UDR 설정에 따르면, VPN 서브넷 경로는 더 이상 spoke-1-vmNIC의 유효 경로에 직접 게시되지 않습니다. spoke-1-vmVPN 기반 리소스와 통신해야 하는 경우, 기본 0/0경로가 사용되며 hub-nvaVM을 통과합니다.
VPN 클라이언트에서 ping을 시도하면 spoke-1-vm작동합니다.
ubuntu@vpn-client:~$ ping 10.100.201.4 -c3
# output
PING 10.100.201.4 (10.100.201.4) 56(84) bytes of data.
64 bytes from 10.100.201.4: icmp_seq=1 ttl=62 time=23.6 ms
64 bytes from 10.100.201.4: icmp_seq=2 ttl=62 time=48.0 ms
64 bytes from 10.100.201.4: icmp_seq=3 ttl=62 time=64.1 ms
-- - 10.100.201.4 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2001ms
rtt min/avg/max/mdev = 23.609/45.235/64.094/16.643 ms
… 하지만 매트릭스에는 결함이 있습니다.
보시다시피, spoke-1-vmVPN에서 들어오는 트래픽만 를 통과합니다 hub-nva. 반대로, VPN 클라이언트에서 들어오는 트래픽은 스포크 VM으로 직접 이동하므로 비대칭 네트워크 패턴이 발생합니다.
예를 들어, VPN 클라이언트에서 ping을 수행할 때 tcpdump를 수행할 때만 echo 응답이 전송되는 것을 spoke-1-vm볼 수 있습니다 .hub-nva
ubuntu@hub-nva:~$ sudo tcpdump -nni eth0 icmp
# output
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
에코 요청이 없습니다. VPN 클라이언트의 흐름이 hub-nva를 통과하지 않습니다.
게이트웨이 경로 전파에 대한 추가 정보
Gateway 경로 전파 기능 에 대한 자세한 내용을 알고 싶으시다면 다음 게시물을 참조하세요.
- Azure 설명서의 Border Gateway Protocol
- Jose Moreno가 Azure에서 가상 네트워크 게이트웨이 라우팅을 설명합니다.
- Cynthia Treger가 작성한 가상 네트워크 게이트웨이(ER 또는 VPN) 추가의 연결성 영향
1부 – 결론
이전 단계에서는 Azure 내에서 허브 앤 스포크 토폴로지를 초기화하는 방법을 살펴보았습니다. 현재 단계에서는 Azure 호스팅 스포크 vNet이 허브 vNet을 전송 네트워크로 사용하고 있으며, UDR(사용자 정의 경로)에 구성된 기본 경로를 활용합니다.
VPN 연결(온프레미스 워크로드로 작동)과 관련하여 비대칭 라우팅 문제가 발생하고 있음을 확인했습니다. VPN 클라이언트에서 Azure 호스팅 VM으로 향하는 트래픽이 허브 vNet에 배포된 NVA VM을 통과하지 못하고 있습니다.
알림으로써, 이 게시물에 설명된 단계를 재현하려면 다음 GitHub 저장소의 콘텐츠를 활용할 수 있습니다: hub-and-spoke-avs-transit-step-by-step .
다음 게시물에서는 새로운 사용자 정의 경로 구성을 활용하여 이 문제를 완화하는 방법을 살펴보겠습니다. 또한 Azure VMware Solution(AVS)을 이 허브 앤 스포크 토폴로지에 연결하는 방법도 소개합니다.
'IT이야기 > Azure' 카테고리의 다른 글
| 허브 앤 스포크 토폴로지의 Azure VMware 솔루션 모형 – 3부 (0) | 2025.04.15 |
|---|---|
| 허브 앤 스포크 토폴로지의 Azure VMware 솔루션 모형 – 2부 (0) | 2025.04.15 |
| Azure VMware Solution NSX-T 배포 시 타사 방화벽 NVA 사용 (0) | 2025.04.15 |
| Azure Data Explorer 및 Grafana를 사용하여 Azure VMware 솔루션 모니터링 (0) | 2025.04.15 |
| VMware HCX: MON으로의 복귀 (0) | 2025.04.15 |