Microsoft AZ-700: Azure Virtual WAN i Hub-Spoke — Przewodnik do nauki

By Laurynas Brazys · 1 August 2026 · #microsoft #az-700 #certification #exam-prep #study-guide

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.

Virtual WAN a klasyczny model hub-and-spoke: wybór odpowiedniego modelu tranzytowego

Projektowanie globalnego tranzytu wymaga wyboru między Azure Virtual WAN (vWAN) a tradycyjnym modelem hub-and-spoke zbudowanym z sieci VNet, urządzeń NVA i peeringu. Virtual WAN zapewnia globalną sieć szkieletową zarządzaną przez Microsoft z vHubami, które natywnie obsługują łączność VPN, ExpressRoute i P2S oraz wspierają automatyczną propagację tras, skalowanie site-to-site i integracje z partnerami SD-WAN. Dla organizacji potrzebujących wielu połączeń oddziałów, globalnego routingu i prostego modelu operacyjnego, vWAN redukuje pracę związaną z orkiestracją i poprawia odporność. W przeciwieństwie do tego, ręczny model hub-and-spoke (VNet z Azure Firewall lub NVA innej firmy w centralnym hubie i połączone z nim sieci spoke) daje maksymalną kontrolę nad przepływem pakietów, niestandardowe funkcje NVA i często niższy koszt w stanie ustalonym dla małych wdrożeń. Kluczowe kompromisy to przepustowość i przewidywalność w porównaniu ze szczegółową kontrolą: vHuby w vWAN abstrahują wiele szczegółów i oferują niemal globalną skalę, ale wiążą się z dodatkowymi kosztami usługi zarządzanej i mniejszą elastycznością w dostosowywaniu ścieżki pakietów. Częste pułapki obejmują założenie, że vWAN automatycznie zapewnia przechodni peering do sieci VNet, które nie są jawnie połączone; każda sieć spoke lub VNet musi być połączona i skojarzona z tablicami routingu huba. Innym częstym błędem jest zaniedbywanie ograniczeń dotyczących ładu i nazewnictwa podsieci (na przykład wymaganej nazwy AzureFirewallSubnet dla Azure Firewall), co powoduje błędy w automatycznych wdrożeniach, jeśli nie są przestrzegane.

Zabezpieczony wirtualny hub, integracja Azure Firewall i NVA

Model zabezpieczonego wirtualnego huba (secured virtual hub) nakłada warstwę inspekcji i polityk na vWAN poprzez integrację Azure Firewall (lub NVA innej firmy) i Firewall Manager w celu centralizacji zabezpieczeń, NAT i routingu dla sieci spoke i lokalizacji on-premise. Azure Firewall powinien być wdrożony w dedykowanej podsieci AzureFirewallSubnet, a wybór między jednostkami SKU Azure Firewall powinien być oparty na funkcjach. Starannie zaplanuj tablice routingu: tablice routingu huba kontrolują przepływy do sieci spoke, lokalizacji VPN, P2S i internetu. Aby wymusić tunelowanie ruchu do NVA, należy skojarzyć połączenie sieci spoke z tablicą routingu huba, która kieruje ruch 0.0.0.0/0 do NVA/Firewall. Weź pod uwagę wysoką dostępność i przepustowość: Azure Firewall jest usługą strefową i obsługuje automatyczne skalowanie w jednostkach SKU Standard i Premium, ale wersja Premium jest wymagana do inspekcji TLS i IDPS. Unikaj umieszczania Application Gateway lub punktów końcowych Private Link w podsieciach współdzielonych z infrastrukturą zapory sieciowej; wymagają one własnych podsieci. Uważaj na wyczerpanie portów NAT i SNAT przy dużych przepływach wychodzących; zaimplementuj pulę SNAT, Azure Firewall z regułami DNAT lub użyj NAT Gateway w odpowiednich przypadkach.

Azure Firewall Standard a Premium: Standard obsługuje stanową zaporę sieciową, filtrowanie FQDN, podstawowy SNAT/DNAT; Premium dodaje inspekcję TLS, IDPS, filtrowanie URL i wykluczenia tagów w pełni kwalifikowanych nazw domen (FQDN).
Load Balancer Basic a Standard: Standard obsługuje nadmiarowość strefową, sondy kondycji zaplecza i jest wymagany dla usługi Private Link z ILB; Basic nie ma odporności strefowej i ma mniej rygorystyczne reguły bezpieczeństwa.
Jednostki SKU VPN Gateway: VpnGw1/2/3 (rosnąca przepustowość i liczba jednoczesnych tuneli); używaj wyższych poziomów dla większej liczby tuneli S2S lub wyższej zagregowanej przepustowości.

Wzorce łączności prywatnej: Private Link, Private Endpoints i service endpoints

Private Link i prywatne punkty końcowe (private endpoints) zapewniają najwyższej klasy dostęp do PaaS bez kierowania ruchu przez internet; punkty końcowe usługi (service endpoints) zabezpieczają dostęp do usług, ale ruch wychodzący nadal przechodzi przez publiczną sieć szkieletową usługi. Użyj prywatnego punktu końcowego, gdy potrzebujesz prywatnych adresów IP dla poszczególnych zasobów i integracji z DNS; użyj punktów końcowych usługi, gdy potrzebujesz prostszej kontroli dostępu na poziomie podsieci i akceptujesz kierowanie ruchu wychodzącego przez sieć szkieletową usługi. Ważne szczegóły operacyjne obejmują rozpoznawanie nazw DNS: prywatne punkty końcowe wymagają aktualizacji lokalnego serwera DNS lub stref Azure DNS Private Zones, aby klienci mogli rozpoznawać prywatny adres IP; warunkowe przesyłanie dalej (conditional forwarders) do lokalnych serwerów DNS jest powszechne w sieciach połączonych przez S2S. Scenariusze usługi Private Link obejmujące wiele subskrypcji są obsługiwane, jeśli zasoby znajdują się w tym samym tenancie Azure AD; wdróż usługę Private Link za Standard internal Load Balancer (ILB), aby zapewnić skalowalność i nadmiarowość strefową. Częstą pułapką jest użycie Basic ILB lub nieprawidłowej jednostki SKU, co ogranicza kondycję i skalowalność zaplecza. Dla usługi Private Link obsługującej dużą liczbę połączeń, użyj Standard ILB, zaplecza opartego na zestawach skalowania i rozważ użycie wielu kart sieciowych punktu końcowego na instancję zaplecza. Rozważ również ochronę przed atakami DDoS: włącz DDoS Protection Standard dla publicznie dostępnych kart sieciowych i zaplanuj skalowanie portów SNAT oraz użycie NAT Gateway tam, gdzie pochodzi wiele połączeń wychodzących.

Tabele routingu huba vWAN i praktyczne projektowanie tras

vWAN używa tabel routingu huba do kierowania ruchem między połączonymi sieciami spoke, lokalizacjami on-premise i internetem. Każde połączenie (lokalizacja, VNet, P2S) może być skojarzone z tabelą routingu huba; priorytety tras i reguły propagacji określają ostateczne przekazywanie ruchu. Dobry projekt zaczyna się od domyślnej tabeli routingu huba, która przekazuje ruch kierowany do internetu do Azure Firewall lub urządzenia NVA, oraz od wyspecjalizowanych tabel routingu dla oddziałów wymagających wyjścia do internetu w lokalizacji on-premise (on-prem breakout). Protokół BGP z urządzeń VPN on-premise propaguje prefiksy do huba, a te można redystrybuować do sieci spoke lub filtrować za pomocą tabel routingu. Częstą pułapką są konflikty tras zdefiniowanych przez użytkownika (UDR) w sieciach VNet typu spoke, które próbują nadpisać propagację z huba; w vWAN tabele routingu huba mają pierwszeństwo dla połączeń wzajemnych, ale trasy UDR w sieciach spoke nadal wpływają na lokalny ruch wychodzący (egress). W przypadku tunelowania wymuszonego (forced tunneling), skojarz połączenia sieci spoke z tabelą routingu huba kierującą ruch 0.0.0.0/0 do wybranego urządzenia inspekcyjnego. Monitoruj i planuj limity tras: huby vWAN mają maksymalną liczbę nauczonych i anonsowanych prefiksów — projektuj sumaryzację prefiksów oraz używaj BGP communities lub filtrów, aby nie przekroczyć limitów. Zawsze testuj rozwiązywanie nazw DNS i konfigurację split-DNS dla prywatnych punktów końcowych oraz dokumentuj zachowanie w przypadku awarii (failover) dla projektów z wieloma hubami w trybie active/active, aby spełnić umowy SLA dotyczące odporności.

Problem praktyczny: Scenariusz użycia

Scenariusz: Firma Contoso Manufacturing zarządza globalną infrastrukturą w Azure z istniejącą architekturą VNet typu hub-and-spoke w dwóch regionach, wieloma lokalizacjami on-premise połączonymi przez SD-WAN oraz wymogiem centralizacji zabezpieczeń i zapewnienia prywatnej łączności z usługami PaaS między subskrypcjami.

Wyzwanie: Firma potrzebuje skalowalnego, zarządzanego globalnego tranzytu, który centralizuje inspekcję ruchu (inspekcja TLS, IDPS), obsługuje wiele połączeń z oddziałami przez SD-WAN i udostępnia prywatnie zasoby PaaS (usługi storage i bazy danych) dla sieci spoke i lokalizacji on-premise, bez publicznego ich eksponowania.

Zalecane podejście:

Wdróż usługę Azure Virtual WAN (vWAN) i utwórz zabezpieczone wirtualne huby w każdym regionie. W każdym hubie włącz Azure Firewall Premium (do inspekcji TLS i IDPS) i zintegruj go z Firewall Manager. Skojarz hub z partnerskimi połączeniami SD-WAN w ramach vWAN, aby zapewnić bezpośrednie dołączenie oddziałów (branch on-ramp).
Skonfiguruj tabele routingu huba, aby kierować ruch do internetu i między regionami do Azure Firewall Premium; utwórz wyspecjalizowane tabele routingu dla oddziałów, które muszą mieć wyjście do internetu w lokalizacji on-premise. Użyj protokołu BGP z SD-WAN do anonsowania prefiksów on-premise do vWAN i zastosuj filtry prefiksów, aby uniknąć nadmiernego rozrostu tabel routingu (route bloat).
Dla usług PaaS, udostępnij usługi Private Link w dedykowanej sieci VNet w każdym regionie za Standard Internal Load Balancer i udostępnij Private Endpoints w sieciach VNet typu spoke oraz w środowisku on-premise za pośrednictwem łączności vWAN. Użyj Azure DNS Private Zones i warunkowych serwerów przesyłania dalej (conditional forwarders), aby zapewnić rozwiązywanie nazw w środowisku on-premise.
Włącz usługę DDoS Protection Standard na publicznych punktach końcowych, wdróż NAT Gateway dla sieci spoke z dużymi potrzebami wychodzącego SNAT i monitoruj metryki SNAT/DNAT. Użyj zasad Firewall Manager do centralnej dystrybucji reguł i skonfiguruj logowanie do centralnego obszaru roboczego Log Analytics.

Uzasadnienie: Takie podejście wykorzystuje vWAN do skalowalnej łączności z oddziałami i globalnego tranzytu, używa Azure Firewall Premium do scentralizowanej, zaawansowanej inspekcji wymaganej przez politykę bezpieczeństwa oraz Private Link do bezpiecznego dostępu do PaaS bez publicznej ekspozycji — równoważąc łatwość zarządzania, bezpieczeństwo i skalę operacyjną.

← Monitorowanie sieci i rozwiązywanie problemów · Wszystkie domeny

Przećwicz te pytania → · Testy na czas na ExamRoll.io →