GlobalLogistics musi wstawić urządzenie NVA (wirtualne urządzenie) innej firmy do swojego tranzytu Virtual WAN, aby przeprowadzić głęboką inspekcję pakietów dla ruchu typu spoke-to-spoke. Planują użyć NVA z marketplace, które wymaga stałego prywatnego adresu IP. Jak powinni zintegrować NVA, aby ruch tranzytowy huba przepływał przez nie?

Poprawna odpowiedź to wdrożenie NVA jako zestawu skalowania maszyn wirtualnych (VMSS) w sieci wirtualnej (VNet) połączonej z Virtual WAN, dodanie statycznej trasy w tabeli tras huba wskazującej na prywatny adres IP NVA i skojarzenie tej tabeli tras ze spoke'ami. To podejście umożliwia przekierowanie ruchu spoke-to-spoke przez NVA w celu głębokiej inspekcji pakietów, wykorzystując możliwości routingu Virtual WAN. Niepoprawne opcje: Wdrożenie NVA w sieci VNet typu spoke i włączenie peeringu VNet między spoke'ami nie jest optymalne dla tranzytu Virtual WAN, ponieważ ruch nie będzie centralnie zarządzany przez hub i nie wykorzysta jego możliwości routingu. Wdrożenie NVA jako zarządzanej aplikacji w Azure Security Center nie jest właściwym mechanizmem do integracji NVA innej firmy dla tranzytu ruchu w Virtual WAN. Azure Security Center skupia się na zarządzaniu bezpieczeństwem, a nie na routingu ruchu przez NVA. Włączenie Azure Route Server w hubie i konfiguracja NVA do używania BGP przez publiczny internet jest nieefektywne i mniej bezpieczne niż bezpośrednie połączenie. Route Server służy do wymiany tras BGP wewnątrz huba, a nie do routingu przez publiczny internet.