Microsoft AZ-104: Sieci wirtualne Azure — Przewodnik do nauki

By Laurynas Brazys · 6 August 2026 · #microsoft #az-104 #certification #exam-prep #study-guide

Część Microsoft Azure Administrator Associate AZ-104 — Przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów Microsoft, albo rozwiąż testy na czas na ExamRoll.io.

Przegląd

Usługa Azure Virtual Networking tworzy programowo zdefiniowaną strukturę centrum danych dla obciążeń IaaS i PaaS. Projektujesz plan adresacji za pomocą CIDR, wydzielasz podsieci dopasowane do granic zaufania, zabezpieczasz przepływy wschód-zachód i północ-południe za pomocą Network Security Groups (NSG) i Azure Firewall, łączysz środowiska przy użyciu VNet peering, VPN Gateway lub ExpressRoute, kształtujesz ruch za pomocą tras zdefiniowanych przez użytkownika i zapewniasz niezawodne rozpoznawanie nazw za pomocą Azure DNS. Prawidłowe skonfigurowanie tych elementów umożliwia tworzenie skalowalnych architektur typu hub-and-spoke, bezpieczny dostęp do PaaS przez Private Endpoints oraz przewidywalny routing, który spełnia wymagania dotyczące zgodności i wydajności.

Adresacja, segmentacja i polityka (VNet, podsieci, NSG, ASG, UDR)

Sieć wirtualna (VNet) definiuje jedną lub więcej niepokrywających się przestrzeni adresowych RFC1918 przy użyciu notacji CIDR (na przykład 10.0.0.0/16). Możesz później dodać dodatkowe prefiksy adresowe, jeśli nie ma konfliktów z połączonymi sieciami (peers). Podsieci segmentują VNet na rutowalne bloki (na przykład 10.0.1.0/24 dla warstwy web, 10.0.2.0/24 dla warstwy app). Zarezerwuj dedykowaną podsieć GatewaySubnet dla bram VPN/ExpressRoute; przydziel adresację z zapasem (co najmniej /27), aby uniknąć przyszłych ograniczeń skalowania. Alokacja IP jest domyślnie dynamiczna; w razie potrzeby można ustawić statyczne prywatne adresy IP na kartach sieciowych (NIC).

Domyślne trasy systemowe zezwalają na ruch wewnątrz VNet i wysyłają 0.0.0.0/0 do internetu (pod warunkiem istnienia publicznego adresu IP). Trasy zdefiniowane przez użytkownika (UDR) nadpisują te domyślne ustawienia na poziomie podsieci. Utwórz tabelę routingu i powiąż ją z podsiecią; wpisy obejmują:

Następny skok (Next hop): Urządzenie wirtualne (adres IP NVA w tej samej sieci VNet), Brama sieci wirtualnej (aby skierować ruch do środowiska on-premise przez VPN/ExpressRoute), Internet (aby wymusić wyjście do internetu) lub Brak (None) (czarna dziura/blackhole).
Wymuszone tunelowanie (Forced tunneling): Wyślij 0.0.0.0/0 do bramy sieci wirtualnej, aby wymusić skierowanie całego ruchu wychodzącego do środowiska on-premise, lub do NVA/Azure Firewall w celu scentralizowanej kontroli ruchu wychodzącego. Jeśli używasz BGP z bramą, która anonsuje trasę domyślną, rozważ wyłączenie propagacji tras bramy na określonych podsieciach, aby zapobiec niezamierzonemu wyborowi ścieżki.

Grupy NSG egzekwują stanową politykę L3–L4 na kartach sieciowych (NIC) lub podsieciach; oba zakresy mogą być używane jednocześnie, a ruch musi być dozwolony przez wszystkie obowiązujące grupy NSG. Reguły są oceniane według priorytetu (100–4096; niższe numery mają pierwszeństwo) i kierunku (przychodzący/wychodzący). Domyślne reguły obejmują:

Przychodzące (Inbound): AllowVnetInBound (65000), AllowLoadBalancerInBound (65001), DenyAllInBound (65500)
Wychodzące (Outbound): AllowVnetOutBound (65000), AllowInternetOutBound (65001), DenyAllOutBound (65500) Nadpisz domyślne ustawienia za pomocą niestandardowych reguł o wyższym priorytecie. Używaj tagów usług (service tags) (na przykład Internet, AzureLoadBalancer, Storage), aby uprościć utrzymanie, oraz grup IP (IP Groups) dla list adresów wielokrotnego użytku.

Grupy Application Security Groups (ASG) oddzielają adresację IP od polityki. Przypisz karty sieciowe (NIC) do grup ASG, które reprezentują role (na przykład Web, App, DB) i odwołuj się do tych grup ASG w regułach NSG. Pozwala to na zmiany w polityce bez modyfikowania adresów IP lub podsieci i ułatwia spójną segmentację opartą na rolach w obrębie sieci VNet.

Opcje łączności: Peering, VPN Gateway i ExpressRoute

Peering sieci VNet łączy sieci VNet za pośrednictwem sieci szkieletowej Microsoft, zapewniając niskie opóźnienia i dużą przepustowość. Peering lokalny odbywa się w obrębie jednego regionu; peering globalny obejmuje wiele regionów. Peering jest nietranzytywny i wymaga niepokrywających się przestrzeni adresowych. Kluczowe flagi:

Zezwalaj na dostęp do sieci wirtualnej (Allow virtual network access) włącza łączność routowaną między połączonymi sieciami.
Zezwalaj na ruch przekazywany (Allow forwarded traffic) pozwala na przechodzenie przez peering ruchu przekazywanego przez wirtualne urządzenia sieciowe (NVA).
Użyj bram zdalnych (Use remote gateways) pozwala sieci VNet korzystać z bramy VPN/ER w połączonej sieci typu „hub”. Sieć hub musi mieć włączoną opcję Zezwalaj na tranzyt przez bramę (Allow gateway transit). Sieć VNet może używać bram zdalnych tylko z jednej połączonej sieci. Sieci VNet połączone peeringiem nie otrzymują automatycznie tras klienta P2S; użytkownicy końcowi muszą zainstalować zaktualizowane konfiguracje klienta VPN, które zawierają trasy do nowych sieci typu „spoke”.

Azure VPN Gateway dostarcza tunele IPSec/IKE:

Site-to-site (S2S) łączy lokalne urządzenia VPN z Azure; w większości scenariuszy używaj VPN opartego na trasach (IKEv2), zwłaszcza przy BGP i wielu tunelach.
Point-to-site (P2S) umożliwia pojedynczym klientom (Windows, macOS, Linux) łączenie się za pomocą OpenVPN, IKEv2 lub SSTP. Konfiguracja klienta zawiera statyczne trasy do prefiksów Azure; należy ją pobrać ponownie, gdy zmienią się przestrzenie adresowe lub gdy dodasz osiągalne sieci „spoke” za koncentratorem (hub).
VNet-to-VNet używa S2S w obrębie regionów/dzierżaw Azure, wymagając niepokrywających się adresów. Przydatne, gdy peering nie jest możliwy (np. między dzierżawami z granicami administracyjnymi).
Jednostki SKU: Preferuj VpnGw1–VpnGw5 (oraz warianty AZ dla redundancji strefowej). SKU Basic jest przestarzała i pozbawiona funkcji (brak IKEv2/BGP). Opcja oparta na trasach (route-based) obsługuje P2S, BGP i konfigurację aktywny-aktywny. Opcja oparta na zasadach (policy-based) jest ograniczona (tylko S2S, brak BGP).
BGP dynamicznie rozgłasza prefiksy, wspiera tranzyt przez wiele tuneli i upraszcza przełączanie awaryjne tras. Reguły NAT bramy VPN mogą tłumaczyć pokrywające się prefiksy lokalne/Azure, gdy jest to nieuniknione.

ExpressRoute dostarcza prywatną łączność z gwarancją SLA za pośrednictwem obwodu partnera do brzegu sieci Microsoft:

Obwód jest aprowizowany przez dostawcę (przepustowość, model rozliczeń, jednostka SKU) i łączony z Twoją subskrypcją za pomocą klucza usługi. Redundancja jest wbudowana: każdy obwód udostępnia podwójne połączenia podstawowe/pomocnicze; Twój router powinien ustanowić podwójne sesje BGP w celu zapewnienia wysokiej dostępności (HA).
Typy komunikacji równorzędnej (peeringu):
- Prywatna komunikacja równorzędna (Private peering) przenosi prywatny ruch RFC1918 do sieci VNet przez bramę sieci wirtualnej ExpressRoute (ErGw1AZ–ErGw3AZ). Obsługuje BGP, szybkie przełączanie awaryjne i opcjonalnie FastPath do akceleracji płaszczyzny danych.
- Komunikacja równorzędna firmy Microsoft (Microsoft peering) udostępnia publiczne usługi Microsoft (np. Storage, SQL, Microsoft 365) przez publiczne adresy IP z filtrami tras. Używaj dla punktów końcowych dostępnych z internetu, pozostając poza publicznym internetem. Usługa Microsoft 365 wymaga dodatkowej weryfikacji.
Użyj ExpressRoute Global Reach, aby połączyć lokalizacje on-premises za pośrednictwem sieci szkieletowej Microsoft. W celu tunelowania wymuszonego rozgłaszaj trasę domyślną przez prywatną komunikację równorzędną lub połącz z UDR/Azure Firewall w celu selektywnego ruchu wychodzącego.

Współistnienie: Sieć VNet może mieć zarówno bramę VPN, jak i ExpressRoute, używając tej samej podsieci GatewaySubnet; użyj tranzytu przez bramę i tras zdefiniowanych przez użytkownika (UDR), aby kontrolować przepływy. ExpressRoute jest preferowany dla stałego ruchu korporacyjnego; VPN służy jako kopia zapasowa lub do łączności z oddziałami/małymi biurami.

Rozpoznawanie nazw i bezpieczny dostęp do PaaS (Azure DNS, punkty końcowe)

Azure DNS hostuje strefy publiczne, dzięki czemu Twoje rekordy dostępne z internetu rezydują na globalnej platformie DNS Azure o wysokiej dostępności. Do rozpoznawania nazw wewnątrz sieci VNet, Prywatne strefy Azure DNS (Azure DNS Private Zones) zapewniają usługę nazw typu split-horizon. Połącz sieci VNet ze strefą prywatną, aby włączyć rozpoznawanie nazw; opcjonalnie włącz automatyczną rejestrację, aby rekordy A maszyn wirtualnych rejestrowały się i aktualizowały automatycznie po zmianie adresu IP karty sieciowej. W celu hybrydowego rozpoznawania nazw i warunkowego przekazywania zapytań między Azure a środowiskiem lokalnym, wdróż Azure DNS Private Resolver z punktami końcowymi przychodzącymi/wychodzącymi i zestawami reguł, które przekazują wybrane domeny (np. corp.contoso.com do lokalnego serwera DNS lub privatelink.* z powrotem do Azure).

Punkty końcowe usługi (Service Endpoints) rozszerzają tożsamość Twojej sieci VNet na wybrane usługi Azure (np. Storage, SQL) przez sieć szkieletową Microsoft, zachowując publiczny adres IP usługi. Na zaporze PaaS ogranicz dostęp do określonej sieci VNet/podsieci. Są łatwe do włączenia dla każdej podsieci i usługi, nie wymagają zmian w DNS i dobrze sprawdzają się w prostych scenariuszach wyłącznie w Azure. Jednak zasób nadal ma publiczny adres IP i nie jest adresowalny prywatnie z lokalizacji on-premises bez przechodzenia przez publiczny punkt końcowy.

Prywatne punkty końcowe (Private Endpoints) umieszczają kartę sieciową (NIC) z prywatnym adresem IP z Twojej podsieci w zasobie PaaS za pośrednictwem usługi Private Link. Ruch pozostaje w sieci prywatnej, umożliwiając szczegółową kontrolę eksfiltracji danych i dostęp z lokalizacji on-premises przez VPN/ExpressRoute. Kluczowe jest prawidłowe działanie DNS: należy nadpisać publiczną nazwę FQDN zasobu, aby była rozpoznawana jako jego nazwa FQDN privatelink, która wskazuje na Twój prywatny adres IP. Użyj Prywatnych stref Azure DNS (np. privatelink.blob.core.windows.net) połączonych z sieciami VNet. Wybierz Private Endpoints, gdy potrzebujesz prawdziwego adresowania prywatnego, dostępu międzylokalizacyjnego i ścisłej kontroli ruchu wychodzącego.

Azure Firewall i scentralizowane zarządzanie ruchem wychodzącym/przychodzącym

Azure Firewall to stanowa, natywna dla chmury zapora sieciowa, która skaluje się elastycznie i zapewnia centralne zasady dla architektur hub-and-spoke. Wdraża się ją w dedykowanej podsieci AzureFirewallSubnet. W scenariuszach wymuszonego tunelowania (forced tunneling) należy dodać podsieć AzureFirewallManagementSubnet, aby ruch zarządczy korzystał z internetu, podczas gdy ruch danych podążał za trasą domyślną.

Typy kolekcji reguł są stosowane w tej kolejności i według priorytetu kolekcji reguł:

Reguły DNAT tłumaczą przychodzące publiczne adresy IP/porty na zaporze na adresy prywatne (na przykład mapują publiczny adres IP zapory:443 na maszynę wirtualną z serwerem WWW). Należy je połączyć z grupami NSG w podsieci docelowej, aby wymusić zasadę najmniejszych uprawnień.
Reguły sieciowe filtrują ruch L3–L4 (źródłowe/docelowe adresy IP, protokoły, porty). Używane dla protokołów innych niż HTTP(S) oraz do kontrolowania przepływów wychodzących i wewnątrz sieci szprychowych (intra-spoke).
Reguły aplikacji kontrolują wychodzący ruch HTTP/S według FQDN lub tagów FQDN (na przykład WindowsUpdate). Wersja SKU Premium dodaje inspekcję TLS i IDPS do głębokiego filtrowania HTTP(S). Analiza zagrożeń (Threat intelligence) może być ustawiona na Alert (Alertuj) lub Deny (Odmów), aby reagować na znane złośliwe adresy IP/domeny. Połącz Azure Firewall z trasami UDR (0.0.0.0/0 do zapory jako urządzenie wirtualne), aby scentralizować ruch wychodzący; zezwól na ruch przekazywany (forwarded traffic) w peeringu dla sieci szprychowych (spokes). Loguj zdarzenia do Log Analytics w celu audytu i analityki, a do standaryzacji na dużą skalę użyj hierarchii zasad/Azure Firewall Manager.

Praktyczny scenariusz problemowy

Firma Adobe musi zmodernizować sieć hybrydową: bezpieczny hub w Azure musi zapewniać scentralizowany ruch wychodzący do internetu, łączność on-premise z wysoką dostępnością, prywatny dostęp do usług Storage i SQL oraz przewidywalne rozwiązywanie nazw w środowiskach Azure i centrach danych. Zdalni deweloperzy potrzebują również dostępu P2S do wszystkich sieci szprychowych.

Zaprojektuj przestrzeń adresową i segmentację

Utwórz sieć VNet Hub 10.0.0.0/16 z podsieciami: AzureFirewallSubnet 10.0.0.0/26, GatewaySubnet 10.0.0.64/27, SharedServices 10.0.1.0/24. Utwórz sieci VNet Spoke dla aplikacji (Apps) 10.1.0.0/16 i danych (Data) 10.2.0.0/16.
Uzasadnienie: Niepokrywające się zakresy CIDR umożliwiają peering i przyszły rozwój; dedykowane podsieci spełniają wymagania platformy i upraszczają zakres stosowania UDR/NSG.

Ustanów łączność hub-and-spoke

Skonfiguruj peering Hub↔Apps i Hub↔Data z opcjami Allow virtual network access i Allow forwarded traffic. W hubie ustaw Allow gateway transit; w sieciach spoke ustaw Use remote gateways.
Uzasadnienie: Centralizuje to przepływy północ-południe przez bramę/zaporę huba, jednocześnie pozwalając na ruch wschód-zachód przez hub, co pozwala uniknąć złożoności architektury siatkowej (mesh).

Zapewnij prywatną, redundantną łączność on-premise

Zamów obwód ExpressRoute (Private Peering) u dostawcy; skonfiguruj podwójne sesje BGP. Wdróż bramę sieci wirtualnej ExpressRoute (ErGw2AZ) w podsieci GatewaySubnet huba i połącz ją z obwodem.
Uzasadnienie: Prywatna łączność z gwarancją SLA, wbudowaną redundancją i bramą strefowo-redundantną spełnia korporacyjne wymagania dotyczące wysokiej dostępności (HA) i wydajności.

Scentralizuj ruch wychodzący i chroń obciążenia robocze

Wdróż Azure Firewall Standard w podsieci AzureFirewallSubnet. Utwórz UDR w każdej podsieci spoke: 0.0.0.0/0, następny przeskok (next hop) Urządzenie wirtualne → prywatny adres IP zapory. Dodaj grupy NSG do sieci spoke, zezwalając tylko na wymagane porty do zapory i wewnątrz VNet.
Uzasadnienie: Azure Firewall + UDR wymuszają spójne zasady ruchu wychodzącego, logowanie i analizę zagrożeń; grupy NSG zapewniają mikrosegmentację na poziomie podsieci/karty sieciowej.

Zabezpiecz PaaS za pomocą prawdziwie prywatnego dostępu

Utwórz Private Endpoints dla usług Storage i SQL w sieci spoke Data. Połącz strefy Azure Private DNS (privatelink.blob.core.windows.net, privatelink.database.windows.net) z hubem i sieciami spoke. Wyłącz publiczny dostęp sieciowy do zasobów PaaS.
Uzasadnienie: Private Endpoints eliminują publiczną ekspozycję i umożliwiają dostęp z lokalizacji on-premise przez ExpressRoute; Azure Private DNS zapewnia prawidłowe rozwiązywanie nazw.

Zaimplementuj hybrydowe rozwiązywanie nazw i przekierowywanie warunkowe

Wdróż Azure DNS Private Resolver w hubie z punktami końcowymi dla ruchu przychodzącego i wychodzącego. Utwórz reguły przekierowujące zapytania o corp.adobe.com do serwerów DNS on-premise i rozwiązujące nazwy stref privatelink wewnątrz Azure.
Uzasadnienie: Zapewnia to deterministyczny DNS typu split-horizon w środowiskach Azure i on-premise bez potrzeby używania niestandardowych maszyn wirtualnych z serwerem DNS.

Umożliw zdalny dostęp deweloperom do wszystkich sieci spoke

Skonfiguruj P2S VPN na bramie VPN Gateway w hubie obok ExpressRoute (współistnienie). Rozpowszechnij profil klienta VPN. Po dodaniu sieci spoke, pobierz ponownie pakiet klienta, aby zawierał trasy do 10.1.0.0/16 i 10.2.0.0/16.
Uzasadnienie: P2S oparty na hubie upraszcza operacje i, dzięki zaktualizowanym trasom klienta oraz tranzytowi przez bramę w peeringu, zapewnia użytkownikom dostępność do wszystkich sieci spoke.

Wzmocnij zabezpieczenia za pomocą ASG i NSG

Przypisz karty sieciowe (NIC) do grup ASG (Web, App, DB) i zaimplementuj reguły NSG zezwalające na ruch Web→App (TCP 443), App→DB (TCP 1433) według ASG, odmawiając reszcie. Zachowaj domyślne reguły tam, gdzie jest to stosowne.
Uzasadnienie: Zasady oparte na rolach skalują się bez zarządzania adresami IP i wymuszają zasadę najmniejszych uprawnień.

Ta architektura spełnia wymagania firmy Adobe dzięki redundancji ExpressRoute, scentralizowanemu zarządzaniu przez Azure Firewall, prywatnemu dostępowi do PaaS i spójnemu systemowi DNS, jednocześnie zapewniając, że zdalni użytkownicy i systemy on-premise mogą bezpiecznie dotrzeć do każdego obciążenia roboczego przez hub.

← Maszyny wirtualne Azure i usługi obliczeniowe · Wszystkie domeny · Równoważenie obciążenia Azure i zarządzanie ruchem →

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