Microsoft AZ-700: Monitorowanie sieci i rozwiązywanie problemów — 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.

Narzędzia i źródła danych obserwacyjnych

Obserwowalność (observability) w sieciach Azure koncentruje się wokół usług Network Watcher, Azure Monitor (Log Analytics) oraz ustawień diagnostycznych (diagnostic settings), które przesyłają dane telemetryczne z zasobów do centralnego obszaru roboczego lub konta magazynu. Network Watcher zapewnia funkcje takie jak packet capture, IP flow verify, next hop, connection troubleshoot i Connection Monitor. Connection Monitor v2 obsługuje testy z wieloma punktami końcowymi i protokołami, a wyniki przechowuje w obszarze roboczym Log Analytics, co umożliwia przeszukiwanie telemetrii za pomocą zapytań. Logi przepływów NSG (NSG flow logs) są włączane za pośrednictwem Network Watcher i zapisują rekordy w formacie JSON na koncie magazynu. Włączenie Traffic Analytics (które wymaga logów przepływów i obszaru roboczego Log Analytics) wzbogaca te logi o wgląd w aplikacje/dane geograficzne i wizualizacje. Ustawienia diagnostyczne w usługach Azure Firewall, Application Gateway/WAF, Front Door i load balancerach powinny być kierowane do tego samego obszaru roboczego Log Analytics w celu korelacji sygnałów. Częste pułapki to m.in. reguły zapory na koncie magazynu blokujące zapis logów przepływów, zapominanie o włączeniu Network Watcher dla każdego regionu w starszych tenantach oraz niespójne zasady przechowywania danych na kontach magazynu w porównaniu z Log Analytics. Kompromisy między kosztem a możliwościami są jasne: zapisywanie surowych logów na koncie magazynu w celu niskokosztowej archiwizacji w porównaniu z pozyskiwaniem ich do Log Analytics w celu tworzenia zapytań i alertów (wyższy koszt, ale znacznie większa wartość diagnostyczna). Kontrola dostępu oparta na rolach (Role-Based Access Control) – rola Monitor Reader oraz, w razie potrzeby, Storage Blob Data Reader – musi być skonfigurowana tak, aby potoki diagnostyczne mogły zapisywać, a analitycy odczytywać logi.

Packet capture, Connection Monitor i zaawansowana diagnostyka

Do rozwiązywania problemów na poziomie pakietów służy funkcja packet capture w Network Watcher (dostępna przez portal/CLI/PowerShell), która tworzy pliki PCAP na koncie magazynu lub w lokalnym pliku na maszynie wirtualnej. Skonfiguruj filtry przechwytywania pakietów (protokół, źródłowy/docelowy adres IP, porty) oraz limity rozmiaru/czasu, aby uniknąć nadmiernego zużycia magazynu i wpływu na wydajność. W przypadku maszyn wirtualnych o dużej przepustowości z akceleracją sieciową (accelerated networking) widoczność pakietów po stronie hosta może być ograniczona; użyj VNet TAP, aby kopiować ruch do maszyny wirtualnej kolektora lub urządzenia NVA, aby uniknąć utraty pakietów odciążonych (offloaded). Connection Monitor powinien być używany do aktywnych testów syntetycznych: zdefiniuj źródłowe i docelowe punkty końcowe (IP, FQDN, port), wybierz częstotliwość testów i włącz pomiar opóźnienia per-hop oraz przechwytywanie ścieżki dla diagnozy wielosegmentowej. Użyj IP Flow Verify, aby sprawdzić, czy określona 5-krotka (5-tuple) jest dozwolona czy odrzucona przez NSG/UDR, oraz Next-hop, aby potwierdzić efektywny routing. Uważaj na pułapki: przechwytywanie pakietów na maszynach wirtualnych z systemem Windows może wymagać podwyższonych uprawnień i wpływ na nie mogą mieć mechanizmy odciążania w systemie operacyjnym; przechwytywanie pakietów może intensywnie obciążać procesor/dysk, dlatego preferuj ukierunkowane filtry i ograniczenia czasowe. Do ciągłej inspekcji pakietów na dużą skalę połącz VNet TAP z urządzeniem do analizy pakietów lub chmurowym systemem SIEM, który potrafi przetwarzać strumienie PCAP.

Logi przepływów NSG, Traffic Analytics i diagnostyka bezpieczeństwa

Logi przepływów NSG (wersja 2) dostarczają rekordy przepływów z sygnaturami czasowymi, 5-krotką (5-tuple), liczbą bajtów/pakietów i decyzją (dozwolony/odrzucony). Nie zawierają one ładunku (payload), szczegółów sesji warstwy aplikacji ani odszyfrowanego ruchu TLS. Traffic Analytics wzbogaca logi przepływów o informacje o najaktywniejszych komunikujących się (top talkers), numerach ASN i mapowaniu geograficznym, co wymaga obszaru roboczego Log Analytics. Usługi Azure Firewall, Application Gateway/WAF i Azure Front Door emitują własne logi diagnostyczne; muszą one być kierowane do Log Analytics w celu umożliwienia ujednoliconych zapytań. Ważne pułapki projektowe: reguły NSG zastosowane na poziomie karty sieciowej (NIC) mają pierwszeństwo przed regułami na poziomie podsieci; istnieją reguły domyślne (np. AzureLoadBalancer, reguły internetowe), których nie można usunąć, a jedynie nadpisać regułami o wyższym priorytecie. Logi przepływów są użyteczne tylko na tyle, na ile pozwala na to strategia przechowywania i pozyskiwania danych — długie przechowywanie w Log Analytics jest kosztowne, podczas gdy krótkie grozi utratą dowodów kryminalistycznych (forensic evidence). Połącz logi przepływów NSG z logami diagnostycznymi usługi Firewall oraz regułami alertów opartymi na zapytaniach Kusto, aby wykrywać ruch boczny (lateral movement) lub eksfiltrację danych. Podczas planowania działań naprawczych rozważ dodanie dedykowanych publicznych adresów IP do Azure Firewall, aby ograniczyć wyczerpanie portów SNAT, oraz wykorzystaj DiagnosticSettings do kierowania logów do Event Hubs w celu integracji z SIEM, jeśli koszty Log Analytics są zaporowe.

Wzorce rozwiązywania problemów, pułapki routingowe i kompromisy projektowe

Podczas rozwiązywania problemów z łącznością, postępuj zgodnie z podejściem warstwowym: zweryfikuj NSG/UDR na poziomie zasobu, sprawdź obowiązujące trasy (effective routes) i następny skok (next hop), użyj IP Flow Verify i Connection Troubleshoot, a w razie potrzeby eskaluj do przechwytywania pakietów (packet capture) lub VNet TAP. Pułapki routingowe często ujawniają się przy wymuszonym tunelowaniu (forced tunneling), nakładających się zakresach CIDR lub błędnie skonfigurowanych UDR, które wysyłają ruch do AzureFirewallSubnet bez odpowiednich tras powrotnych. W celu równoważenia obciążenia i skalowania, wybieraj między Azure Standard Load Balancer, Application Gateway WAF i Front Door w zależności od potrzeb na warstwie L4 vs L7 oraz globalnego vs regionalnego zarządzania ruchem. Rozważ następujące kompromisy dotyczące jednostek SKU:

Azure Firewall Standard vs Premium: Wersja Premium dodaje inspekcję TLS, IDPS i filtrowanie URL za wyższą cenę; wybierz Premium, gdy wymagana jest głęboka inspekcja ruchu i kontrola zgodności z regulacjami.
Azure Front Door Standard vs Premium: Wersja Premium obsługuje zaawansowane funkcje WAF i integracje z private link; wersja Standard jest tańsza dla typowych zastosowań globalnego CDN i routingu.
VNet TAP vs packet capture: TAP jest droższy, ale wymagany do bezstratnego przechwytywania na dużą skalę oraz gdy accelerated networking odciąża przetwarzanie pakietów. Kompromisy koncentrują się na wydajności, koszcie i odporności: urządzenia NVA mogą być tańsze lub bogatsze w funkcje niż Firewall Premium, ale dodają narzut zarządczy i ryzyko pojedynczego punktu awarii (single-point-of-failure), chyba że są zaprojektowane z myślą o wysokiej dostępności (HA). Planuj pojemność SNAT, rezerwuj zapasowe publiczne adresy IP i przygotuj potoki diagnostyczne, aby zrównoważyć potrzeby obserwacyjne z kosztami pozyskiwania danych (ingestion).

Praktyczny problem: Scenariusz użycia

Scenariusz: Firma Contoso Electronics działa w dwóch regionach Azure (EastUS, WestEurope) z sieciami VNet w topologii hub-and-spoke, Azure Firewall Standard w hubie, wieloma Application Gateway WAF w sieciach spoke oraz centralnym obszarem roboczym Log Analytics do monitorowania. Ostatnio wdrożyli zestaw produkcyjnych maszyn wirtualnych w jednej z sieci spoke, które zgłaszają sporadyczne problemy z dotarciem do lokalnego klastra SQL przez obwód ExpressRoute.

Wyzwanie: Sporadyczna łączność i wysokie opóźnienia do zasobów lokalnych bez jednoznacznych dowodów na poziomie pakietów; istniejące logi przepływu NSG (NSG flow logs) są włączone, ale pokazują dozwolone przepływy bez metryk opóźnień.

Zalecane podejście:

Wdróż Connection Monitor v2 z reprezentatywnych maszyn wirtualnych do FQDN i adresu IP lokalnego klastra SQL, używając portu TCP 1433, ustaw testy co 30 sekund i wysyłaj wyniki do centralnego obszaru roboczego Log Analytics, aby przechwytywać opóźnienia na każdym skoku (per-hop latency) i osiągalność.
Włącz przechwytywanie pakietów (packet capture) Network Watcher na maszynie wirtualnej, której dotyczy problem, z filtrami na źródłowy/docelowy adres IP klastra SQL i port 1433, przechowuj pliki PCAP na koncie magazynu z polityką cyklu życia; jednocześnie włącz VNet TAP w podsieci spoke, aby kopiować ruch (mirror) do dedykowanej maszyny zbierającej (collector VM), jeśli włączone jest accelerated networking.
Skonfiguruj ustawienia diagnostyczne dla Azure Firewall (Standard), aby wysyłać logi aplikacji i sieci do tego samego obszaru roboczego Log Analytics, a następnie uruchom zapytania korelacyjne łączące wyniki Connection Monitor, logi zapory sieciowej i logi przepływu NSG w celu wykrycia wyczerpania portów SNAT zapory lub odrzuceń przez polityki.
Użyj IP Flow Verify i Next Hop dla niedziałającej 5-krotki (5-tuple) podczas incydentu; jeśli podejrzewany jest SNAT lub routing asymetryczny, dodaj dodatkowy publiczny adres IP do Azure Firewall lub wdróż NAT Gateway w sieci spoke w celu uzyskania przewidywalnego ruchu wychodzącego (egress) i zaktualizuj UDR, aby kierowały ruch przez hub.

Uzasadnienie: Connection Monitor dostarcza syntetyczne dane o osiągalności i opóźnieniach na każdym skoku (per-hop latency) z sygnaturami czasowymi; przechwytywanie pakietów i VNet TAP zapewniają bezstratne dane do analizy śledczej (forensic data), gdy odciążanie w systemie operacyjnym ukrywa ruch. Korelowanie logów zapory sieciowej i NSG w Log Analytics identyfikuje problemy z politykami, SNAT lub routingiem asymetrycznym; dodanie publicznych adresów IP lub NAT Gateway łagodzi problem wyczerpania portów i stabilizuje zachowanie ruchu wychodzącego.

← Równoważenie obciążenia i zarządzanie ruchem · Wszystkie domeny · Azure Virtual WAN i Hub-Spoke →

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