Microsoft AZ-700: Projektowanie Azure Virtual Network — 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.

Planowanie przestrzeni adresowej i podsieci

Zdyscyplinowany plan adresacji IP zapobiega przyszłym przeróbkom i pozwala uniknąć kolizji z sieciami lokalnymi (on-premises) lub innymi sieciami VNet. Używaj hierarchicznych bloków CIDR (na przykład /16 na główną jednostkę biznesową, /24 na sieć VNet, /26–/22 na podsieć w zależności od roli) i rezerwuj ciągłe zakresy na potrzeby rozbudowy, peeringu i mapowań lokacji VPN/S2S. Azure wymusza wymagania dotyczące nazw i podsieci dla kilku usług platformy: GatewaySubnet musi istnieć (i być zwymiarowana tak, aby uwzględnić bramę VPN i jej jednostki skalowania), AzureFirewallSubnet musi być dedykowana i nazwana AzureFirewallSubnet, a AzureBastionSubnet musi być dedykowaną podsiecią /27 lub większą. Application Gateway i wiele sieciowych urządzeń wirtualnych również wymagają dedykowanych podsieci (bez innych zasobów). Zaplanuj brak nakładania się adresów między sieciami VNet połączonymi peeringiem a zakresami lokalnymi; nakładające się przestrzenie adresowe uniemożliwiają peering, VPN i routing. Rozważ delegowanie podsieci podczas wdrażania usług platformy (AKS, instancje zarządzane Azure Database) i unikaj umieszczania grup NSG lub tras UDR, które są w konflikcie z wymaganymi trasami platformy dla tych usług. Częstą pułapką jest niedoszacowanie rozmiaru GatewaySubnet lub AzureFirewallSubnet; usługi te mogą się skalować i z czasem wymagać dodatkowych adresów IP. Kompromisy: mniejsze bloki CIDR oszczędzają przestrzeń adresową, ale zwiększają ryzyko przyszłej rekonfiguracji; większe bloki CIDR nic nie kosztują, ale zwiększają powierzchnię zarządzania. Dokumentuj wszystkie przydziały i rezerwuj bloki dla prywatnych punktów końcowych PaaS, serwerów pośredniczących (jump host), agentów monitorujących i pojemności NAT dla ruchu wychodzącego.

Peering VNet, tranzyt przez bramę i pierwszeństwo tras

Peering sieci VNet zapewnia łączność o niskim opóźnieniu i dużej przepustowości, ale nie jest przechodni: ruch z połączonej sieci typu spoke nie jest automatycznie kierowany przez drugą sieć VNet połączoną peeringiem, aby dotrzeć do środowiska lokalnego. Aby scentralizować łączność lokalną, należy wdrożyć sieć VNet typu hub z bramą VPN Gateway lub ExpressRoute. Skonfiguruj peering w hubie z włączoną opcją allowGatewayTransit i skonfiguruj peering w spoke z włączoną opcją useRemoteGateways; brama VPN Gateway musi istnieć tylko w hubie. Pamiętaj, że peering wymaga nienakładających się przestrzeni adresowych i obsługuje zarówno peering regionalny, jak i globalny (peering globalny wiąże się z kosztami transferu danych i nieco wyższym opóźnieniem). Kolejność pierwszeństwa tras ma znaczenie: trasy zdefiniowane przez użytkownika (UDR) mają pierwszeństwo przed trasami nauczonymi przez BGP i trasami systemowymi; trasy BGP mają pierwszeństwo przed trasami systemowymi. Jeśli potrzebujesz wymuszonego tunelowania (forced-tunneling) do inspekcji ruchu wychodzącego, utwórz trasy UDR wskazujące na urządzenie wirtualne (NVA) lub Azure Firewall, a następnie, w razie potrzeby, rozgłoś odpowiednie trasy z powrotem do środowiska lokalnego przez BGP. Częste pułapki to zapomnienie o ustawieniu allowGatewayTransit w hubie lub useRemoteGateways w sieciach spoke, brak ponownego pobrania konfiguracji klienta P2S po dodaniu sieci spoke (klienci P2S potrzebują zaktualizowanych tras) oraz zakładanie, że peering jest przechodni. Wybieraj jednostki SKU bramy VPN Gateway na podstawie przepustowości i funkcji P2S: rozważ VpnGw1/2/3 dla produkcyjnych wdrożeń P2S i BGP; wersja Basic nie ma wielu funkcji.

• Jednostki SKU bramy VPN Gateway: VpnGw1 — umiarkowana przepustowość, obsługa OpenVPN/IKEv2/P2S; VpnGw2 — wyższa przepustowość i skalowanie TLS; VpnGw3 — najwyższa przepustowość i największa skala. Basic — ograniczone funkcje i niezalecana do scenariuszy typu hub.

Punkty końcowe usługi a prywatne punkty końcowe i implikacje DNS

Punkty końcowe usługi (Service endpoints) rozszerzają tożsamość sieci VNet na usługi PaaS platformy Azure (Storage, SQL, Cosmos DB), dzięki czemu ruch korzysta z sieci szkieletowej Microsoftu, a publiczny punkt końcowy usługi jest zabezpieczony dla wybranych podsieci. Prywatne punkty końcowe (Private Endpoints) umieszczają interfejs sieciowy w Twojej podsieci, który mapuje się na prywatny adres IP zasobu PaaS, zapewniając prawdziwie prywatną łączność. Wybierz punkty końcowe usługi, gdy chcesz prostej kontroli dostępu na poziomie podsieci bez zmian w DNS; wybierz prywatne punkty końcowe, gdy wymagasz dostępu na poziomie pojedynczego zasobu, izolacji na poziomie VNet lub całkowitego wyłączenia dostępu z sieci publicznej. Prywatne punkty końcowe tworzą interfejs sieciowy (ENI) i muszą być powiązane z prywatną strefą DNS (privatelink.<service>.azure.com) lub wymagają ręcznych rekordów A w DNS — częstą pułapką jest zaniedbanie DNS, co powoduje, że klienci rozwiązują publiczny adres IP zamiast prywatnego punktu końcowego. Należy również pamiętać, że prywatne punkty końcowe zużywają adres IP z docelowej podsieci; zaplanuj pojemność adresów IP. Punkty końcowe usługi nie eliminują publicznego punktu końcowego — aby w pełni zablokować konto magazynu, musisz wyłączyć dostęp z sieci publicznej po włączeniu prywatnego punktu końcowego. Kompromisy kosztowe i operacyjne: prywatne punkty końcowe zwiększają zarządzanie (DNS i zatwierdzenia dla każdego zasobu) i nieznacznie komplikują operacje, ale oferują silniejszą izolację; punkty końcowe usługi są prostsze i tańsze, ale mniej granularne.

Bramka NAT, Azure Firewall i kompromisy w projektowaniu routingu

Aby uzyskać przewidywalny wychodzący SNAT i uproszczone zarządzanie ruchem egress, wdróż Azure Virtual Network NAT (Standard NAT Gateway) w podsieciach lub na kartach sieciowych (NIC) i dołącz publiczne adresy IP lub prefiksy w wersji Standard (tylko jednostka SKU Standard). NAT Gateway odciąża zarządzanie portami efemerycznymi; jeśli przewidujesz dużą liczbę połączeń wychodzących, dołącz wiele prefiksów publicznych adresów IP, aby zwiększyć liczbę dostępnych portów SNAT i uniknąć ich wyczerpania — co jest częste w przypadku wielu maszyn wirtualnych lub hostów kontenerów. Azure Firewall zapewnia scentralizowaną, w pełni zarządzaną inspekcję stanową, analizę zagrożeń (threat intelligence) oraz filtrowanie na poziomie aplikacji/FQDN; wybierz Azure Firewall Standard do podstawowego filtrowania, a jednostkę SKU Premium do inspekcji TLS, IDPS i zaawansowanych funkcji ochrony przed zagrożeniami. Sieciowe urządzenia wirtualne (NVA firm trzecich) oferują bogactwo funkcji lub alternatywy kosztowe, ale wymagają zarządzania, konfiguracji wysokiej dostępności (HA) i planowania skalowalności. Trasy zdefiniowane przez użytkownika (UDR) wskazujące na VirtualAppliance lub Internet/NAT muszą być oceniane w kontekście tras systemowych Azure, ponieważ nieprawidłowe UDR-y mogą zakłócić ruch usług platformy (na przykład blokując ruch do punktów końcowych usług lub sondy kondycji zarządzane przez platformę). Aby zapewnić wysoką dostępność i wydajność, rozważ jednostki SKU nadmiarowe strefowo (Application Gateway v2, Firewall w Strefach Dostępności) oraz możliwości autoskalowania w porównaniu z urządzeniami o stałym koszcie. Częste pułapki: dołączanie NAT zarówno do podsieci, jak i karty sieciowej prowadzi do nieoczekiwanego pierwszeństwa; zapominanie, że NAT wymaga publicznych adresów IP w wersji Standard; nieprawidłowe nazewnictwo i wymiarowanie podsieci AzureFirewallSubnet; oraz zakładanie, że UDR-y zostaną zignorowane — one nadpisują trasy systemowe.

Problem praktyczny: Scenariusz użycia

Scenariusz: Firma Contoso Enterprises zarządza siecią Azure w topologii hub-and-spoke. Hub w regionie West US zawiera bramę ExpressRoute i VpnGw2 (w podsieci GatewaySubnet). Kilka sieci spoke zawiera podsieci aplikacyjne i prywatne punkty końcowe (private endpoints) dla usług PaaS. Zdalni pracownicy łączą się z hubem za pomocą VPN typu Point-to-Site (P2S).

Wyzwanie: Zdalni użytkownicy mogą uzyskać dostęp do zasobów w hubie, ale nie mogą dotrzeć do zasobów VNet w sieciach spoke po niedawnym dodaniu nowych sieci spoke, a niektórzy klienci P2S wykazują nieaktualne zestawy tras.

Zalecane podejście:

1. W sieci VNet huba upewnij się, że brama VPN to VpnGw2 wdrożona w odpowiednio zwymiarowanej podsieci GatewaySubnet (co najmniej /27); zweryfikuj, że jest to jedyna brama w topologii połączonej peeringiem i że ExpressRoute współistnieje dzięki wymianie tras.
2. W połączeniu peeringowym z huba do spoke ustaw allowGatewayTransit = true po stronie huba. W każdym połączeniu peeringowym sieci spoke ustaw useRemoteGateways = true i upewnij się, że przestrzenie adresowe się nie pokrywają.
3. Wygeneruj ponownie i rozprowadź zaktualizowaną konfigurację klienta P2S VPN z bramy VPN w hubie (uwzględniając IKEv2/OpenVPN) i wymagaj od zdalnych użytkowników ponownej instalacji klienta, aby ich tabele routingu zawierały nowe prefiksy sieci spoke.
4. Jeśli sieci spoke muszą kierować ruch wychodzący przez hub w celu inspekcji, dodaj UDR-y w tabelach routingu sieci spoke, kierując ruch 0.0.0.0/0 do wirtualnego urządzenia w hubie lub do Azure Firewall (wdrożonego w AzureFirewallSubnet) i rozgłaszaj niezbędne trasy z powrotem przez BGP na ExpressRoute/VPN.

Uzasadnienie: Włączenie tranzytu przez bramę (gateway transit) za pomocą useRemoteGateways centralizuje routing on-premise i P2S przez bramę w hubie bez tworzenia dodatkowych bram, podczas gdy ponowne wydanie konfiguracji klienta P2S aktualizuje tabele routingu klienta, dzięki czemu nowe prefiksy sieci spoke stają się osiągalne; UDR-y i BGP zapewniają kontrolowany ruch wychodzący i widoczność na potrzeby inspekcji.

← ExpressRoute i Łączność WAN · Wszystkie domeny · Sieci hybrydowe →

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

Przeglądaj Microsoft →