Microsoft AZ-700: Sieci hybrydowe — Przewodnik do nauki
Część Microsoft Azure Network Engineer AZ-700 — Przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów Microsoft, albo rozwiąż testy na czas na ExamRoll.io.
Routing tranzytowy, wymuszone tunelowanie, inspekcja i umiejscowienie urządzeń zabezpieczających
Projektowanie tranzytu między wieloma sieciami VNet, środowiskiem on-premise i urządzeniami do inspekcji wymaga jasnego egzekwowania granic routingu i NAT. Wymuszanie ruchu przez Azure Firewall lub urządzenia wirtualne wymaga tras zdefiniowanych przez użytkownika (UDR), które wskazują na prywatny adres IP zapory, lub użycia routingu w hubie Virtual WAN w celu centralizacji inspekcji. Jeśli potrzebujesz w pełni transparentnego proxy lub inspekcji TLS, umieść urządzenie w dedykowanej podsieci inspekcyjnej i upewnij się, że podsieć bramy oraz jednostki SKU zapory obsługują tranzyt dla oczekiwanej przepustowości. Zwróć uwagę na zachowanie SNAT i wybór jednostek SKU publicznych adresów IP: Standard Public IPs i NAT Gateway są zalecane dla przewidywalnego wychodzącego SNAT i reguł bezpieczeństwa; NAT Gateway w parze z zestawem publicznych adresów IP w warstwie Standard odciąża SNAT i pozwala uniknąć rozrostu publicznych adresów IP przypisywanych do poszczególnych maszyn wirtualnych. Jedną z pułapek jest routing asymetryczny, który występuje, gdy trasy on-premise i UDR w Azure powodują, że ruch powrotny omija docelowe urządzenie; upewnij się, że wszystkie sieci szprychowe (spokes) ogłaszają wymagane prefiksy przez BGP lub posiadają UDR, które kierują ruch do punktu inspekcji. Wydajność a koszt: topologia hub-and-spoke z Azure Firewall Premium lub wysokowydajnymi urządzeniami firm trzecich zwiększa ochronę i centralne zarządzanie, ale podnosi koszty i ryzyko awarii pojedynczego huba, chyba że wdrożysz redundantne huby w konfiguracji aktywny-aktywny i sparujesz bramy między regionami.
Problem praktyczny: Scenariusz użycia
Scenariusz: Firma Contoso Ltd posiada dwa lokalne centra danych (w Seattle i Amsterdamie) oraz istniejące środowisko Azure z trzema sieciami VNet (VNet-Prod, VNet-Shared, VNet-Dev) w jednej centralnej sieci VNet (VNet-Hub). Obecnie używają bramy VPN Gateway VpnGw1 dla połączenia z Seattle oraz połączenia site-to-site z hubem Azure Virtual WAN dla Amsterdamu. W sieci VNet-Shared używane są prywatne punkty końcowe (private endpoints) dla usługi Azure SQL.
Wyzwanie: Contoso potrzebuje odpornej, skalowalnej łączności hybrydowej z dynamicznym routingiem (BGP) między oboma centrami danych a Azure, niezawodnego wsparcia P2S dla użytkowników macOS, rozwiązywania nazw DNS prywatnych punktów końcowych ze środowiska on-premise oraz scentralizowanej inspekcji ruchu wychodzącego z sieci szprychowych przez Azure Firewall.
Zalecane podejście:
- Wdróż nową bramę VPN Gateway VpnGw3 opartą na trasach w sieci VNet-Hub, skonfigurowaną w trybie aktywny-aktywny z włączonym BGP (jawnie ustaw ASN bramy) i zaktualizuj obiekty Local Network Gateway, podając adresy IP peerów BGP i numery ASN ze środowiska on-premise; zmigruj połączenie S2S z Seattle do nowej bramy, aby zapewnić wyższą przepustowość i większe limity tras.
- Skonsoliduj połączenie z Amsterdamem w hubie, ustanawiając połączenie ExpressRoute lub migrując hub VWAN do peeringu z VNet-Hub; zapewnij wymianę tras BGP między oboma centrami danych, aby uniknąć tras statycznych i umożliwić automatyczne przełączanie awaryjne.
- Skonfiguruj P2S przy użyciu protokołu OpenVPN z uwierzytelnianiem Azure AD na bramie VpnGw3, aby wspierać klientów macOS (z IKEv2 jako opcją zapasową), i dobierz rozmiar puli klientów zgodnie z limitami VpnGw3; opublikuj warunkowy serwer przesyłający (conditional forwarder) na lokalnym serwerze DNS, aby przekierowywał zapytania dla stref privatelink.* do usługi Azure DNS Private Resolver wdrożonej w VNet-Shared i połączonej z prywatnymi strefami DNS dla prywatnych punktów końcowych.
- Wdróż Azure Firewall (w wersji Standard lub Premium, jeśli wymagana jest inspekcja TLS) w VNet-Hub w konfiguracji aktywny-aktywny i utwórz UDR dla podsieci szprychowych, które kierują ruch 0.0.0.0/0 na prywatny adres IP zapory; dołącz do zapory usługę NAT Gateway z publicznymi adresami IP w warstwie Standard lub użyj publicznego adresu IP zapory do jawnego SNAT i logowania do centralnego Log Analytics.
Uzasadnienie: Użycie VpnGw3 z BGP zapewnia dynamiczną propagację tras i przepustowość dla odporności obejmującej wiele lokalizacji; OpenVPN+Azure AD bezpiecznie wspiera użytkowników macOS; przekierowywanie DNS do Azure DNS Private Resolver zapewnia rozwiązywanie nazw prywatnych punktów końcowych ze środowiska on-premise; centralizacja inspekcji w hubie z Azure Firewall przy użyciu UDR pozwala uniknąć routingu asymetrycznego i upraszcza zarządzanie politykami, wymieniając wyższy koszt na scentralizowane bezpieczeństwo i obserwowalność.
← Projektowanie Azure Virtual Network · Wszystkie domeny · Azure DNS i rozwiązywanie nazw →
Przećwicz te pytania → · Testy na czas na ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Zdaj egzamin →