Google ACE: Sieci VPC, łączność i zarządzanie ruchem — Przewodnik do nauki

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

Część Google Associate Cloud Engineer — Przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów Google, albo rozwiąż testy na czas na ExamRoll.io.

Przegląd

Sieci Virtual Private Cloud (VPC) w Google Cloud dostarczają zdefiniowane programowo, globalne prymitywy sieciowe z granularną kontrolą adresacji, routingu, bezpieczeństwa i zarządzania ruchem. Ta sekcja skupia się na praktycznych aspektach projektowania i operacji, które wykorzystasz do budowy odpornych, bezpiecznych i obserwowalnych sieci łączących usługi Google Cloud, środowiska on-premises oraz publiczny internet.

Podstawowa architektura VPC i planowanie IP

Sieci VPC i podsieci
- Sieć VPC jest zasobem globalnym; jej podsieci są regionalne i mogą obejmować wiele stref. Instancje w dowolnej strefie danego regionu mogą korzystać z tej samej podsieci.
- Używaj sieci VPC w trybie niestandardowym (custom mode) dla środowisk produkcyjnych. Tryb automatyczny (auto mode) tworzy domyślnie jedną podsieć w każdym regionie, używając predefiniowanego zestawu zakresów CIDR, co może prowadzić do konfliktów nakładających się adresów IP, marnowania przestrzeni adresowej i bolesnej refaktoryzacji podczas rozbudowy.
- Dodatkowe zakresy IP (secondary IP ranges) w podsieciach umożliwiają przypisywanie adresów IP dla podów/serwisów GKE oraz aliasów IP dla maszyn wirtualnych. Zaplanuj z góry podstawowe i dodatkowe zakresy CIDR, aby uniknąć konieczności rekonfiguracji adresacji.
Planowanie adresacji IP
- Wybierz nienakładające się pule adresów z przestrzeni RFC1918 dla wszystkich obecnych i przyszłych sieci VPC oraz sieci on-prem, z którymi możesz się łączyć. Zarezerwuj bloki adresów na potrzeby przyszłych regionów i usług.
- Dobieraj odpowiednio rozmiar podsieci (np. od /24 do /20), uwzględniając przyszły wzrost, i unikaj zbyt dużych zakresów, które komplikują listy ACL i diagnostykę.
- Dokumentuj wykorzystanie adresacji IP: podstawowe zakresy dla obciążeń roboczych, dodatkowe zakresy dla GKE oraz zarezerwowane bloki dla pul NAT lub punktów końcowych usług.
Przykład
- gcloud compute networks create prod-net –subnet-mode=custom
- gcloud compute networks subnets create app-us-central1 –network=prod-net –region=us-central1 –range=10.10.0.0/20 –secondary-range=gke-pods=10.20.0.0/16,gke-svcs=10.21.0.0/20

Routing, zapory sieciowe i hierarchia polityk

Trasy i tryby routingu dynamicznego
- Każda sieć VPC posiada tablicę routingu składającą się z tras generowanych przez system dla podsieci, tras domyślnych oraz niestandardowych tras statycznych lub dynamicznych.
- Tryb routingu dynamicznego:
  - Regionalny: trasy dynamiczne (BGP) nauczone przez Cloud Router są dostępne tylko dla zasobów w tym samym regionie.
  - Globalny: trasy dynamiczne są dostępne dla zasobów we wszystkich regionach sieci VPC. Preferuj tryb globalny dla sieci hybrydowych, które muszą mieć dostęp do środowiska on-prem z wielu regionów.
- Następne skoki (next hops): domyślna bramka internetowa (0.0.0.0/0), tunel VPN, Cloud Router (BGP), instancja (urządzenie routingowe) lub wewnętrzny load balancer jako następny skok dla urządzeń wirtualnych.
- Priorytet trasy: preferowane są niższe wartości. Błędnie skonfigurowane priorytety mogą powodować utratę ruchu (blackhole) lub jego wyciek do niezamierzonego następnego skoku. Stosuj jasne konwencje (np. 1000 dla domyślnego ruchu wychodzącego, 900 dla bardziej szczegółowych tras).
Hierarchia zapór sieciowych
- Reguły zapory sieciowej VPC są stanowe i przetwarzane przed przekazaniem pakietu. Istnieją na poziomie VPC i mają zastosowanie do wszystkich podsieci.
- Hierarchiczne polityki zapory sieciowej (przypisane do organizacji, folderu lub projektu) egzekwują reguły zezwalające/blokujące przed regułami VPC. Używaj ich do wdrażania centralnych barier ochronnych (np. blokowania publicznie dostępnych portów administracyjnych).
- Reguły domyślne (implied rules): istnieją domyślna reguła zezwalająca na ruch wychodzący (allow egress) i domyślna reguła blokująca ruch przychodzący (deny ingress) o najniższym priorytecie; nie można ich usunąć. Każda łączność wymaga jawnych reguł zezwalających na ruch przychodzący.
Reguły zapory, tagi, konta serwisowe, bezpieczne tagi
- Celowanie (targeting): używaj tagów sieciowych lub kont serwisowych, aby stosować reguły do określonych maszyn wirtualnych; celowanie za pomocą kont serwisowych oferuje ściślejszą kontrolę opartą na tożsamości.
- Bezpieczne tagi (secure tags) dostarczają centralnie zarządzane, chronione przez IAM etykiety do celowania polityk; uniemożliwiają one samodzielne przypisywanie tagów przez obciążenia robocze i wspierają segmentację w modelu zero-trust.
- Logowanie: włączaj logowanie reguł zapory selektywnie dla najważniejszych reguł, aby zrównoważyć widoczność z kosztami; próbkuj pakiety, a nie całe ich zawartości (payloads).
- Częste przyczyny awarii: brakujące zakresy źródłowe dla health checków, routing asymetryczny powodujący odrzucanie odpowiedzi, zbyt szerokie zakresy źródłowe tworzące niezamierzoną ekspozycję na zagrożenia.
Przykład
- gcloud compute firewall-rules create allow-ilb-hc –network=prod-net –direction=INGRESS –action=ALLOW –priority=1000 –rules=tcp:80 –source-ranges=load-balancer-health-checks –target-service-accounts=web-sa@proj.iam.gserviceaccount.com

Równoważenie obciążenia, adresy IP, DNS i zarządzanie ruchem

Typy i działanie Cloud Load Balancing
- Globalne oparte na proxy: External HTTP(S), External TCP Proxy, External SSL Proxy. Terminują połączenia klientów na brzegu sieci Google, obsługują globalne adresy VIP anycast i wstawiają nagłówki (np. X-Forwarded-For). Oryginalny adres IP klienta jest dostępny przez nagłówki lub protokół PROXY (dla TCP), a nie zachowywany jako źródło L3.
- Regionalne typu passthrough: External Network Load Balancer i Internal TCP/UDP Load Balancer przekierowują ruch na warstwie L4 i zachowują adres IP klienta. Używaj, gdy wymagasz widoczności źródłowego adresu IP w backendach bez użycia protokołu PROXY.
- Wewnętrzny HTTP(S) Load Balancer: regionalne proxy L7 dla usług wewnętrznych z zaawansowanymi opcjami routingu i mTLS.
Usługi backendowe, kontrole stanu i polityki ruchu
- Usługi backendowe definiują backendy (grupy instancji, NEG/VM/Endpoint, usługi GKE), tryb równoważenia (UTILIZATION lub RATE), limity pojemności, koligację sesji (session affinity) i opróżnianie połączeń (connection draining).
- Kontrole stanu (health checks) muszą mieć zezwolenie w zaporach sieciowych (firewall) dla systemów kontroli stanu Google. Backendy w złym stanie są automatycznie usuwane; błędnie skonfigurowane kontrole stanu mogą spowodować całkowitą awarię.
- Polityki ruchu obejmują lokalizację (region/strefa), backendy przepełnienia (overflow) i awaryjne (failover) oraz ważone dzielenie ruchu dla stopniowych wdrożeń (gradual rollouts) w niektórych typach LB.
Zewnętrzne i wewnętrzne adresy IP, reguły przekierowania
- Zewnętrzne i wewnętrzne adresy mogą być efemeryczne lub zarezerwowane jako statyczne. Globalne statyczne adresy zewnętrzne są używane przez globalne LB; większość pozostałych jest regionalna.
- Reguły przekierowania (forwarding rules) mapują parę IP:port na cel (np. targetHttpProxy lub usługę backendową). Wybierz reguły globalne lub regionalne, aby pasowały do typu LB; niedopasowanie uniemożliwia utworzenie.
Cloud DNS
- Strefy (Zones): strefy publiczne są rozwiązywane w publicznym internecie; strefy prywatne są rozwiązywane tylko z autoryzowanych sieci VPC. Używaj zarządzanych rekordów (A/AAAA, CNAME, TXT, MX, SRV itp.).
- Split-horizon: utwórz zarówno publiczne, jak i prywatne strefy dla tej samej domeny, aby wewnętrzne resolwery otrzymywały odpowiedzi prywatne (np. IP wewnętrznego LB), podczas gdy publiczni użytkownicy otrzymują adresy IP dostępne z internetu.
- Prywatne przekierowywanie DNS: użyj polityk Cloud DNS dla przekierowywania przychodzącego i wychodzącego w celu integracji z lokalnymi resolwerami (on-prem); użyj DNS peering między sieciami VPC, aby udostępniać strefy prywatne bez pełnej łączności peeringowej.
Przykład

undefined

Łączność hybrydowa i prywatna

Cloud Router, Cloud NAT i Private Google Access
- Cloud Router wymienia trasy z infrastrukturą lokalną (on-prem) przez BGP, rozgłasza podsieci VPC i importuje prefiksy on-prem. Używaj globalnego routingu dynamicznego, gdy wiele regionów potrzebuje osiągalności do infrastruktury on-prem.
- Cloud NAT zapewnia wyjście do internetu (egress) dla prywatnych maszyn wirtualnych i węzłów GKE bez zewnętrznych adresów IP. Dobierz rozmiar puli adresów IP NAT, aby uniknąć wyczerpania portów; monitoruj logi pod kątem odrzuconych połączeń i odpowiednio skaluj liczbę adresów.
- Private Google Access (PGA) pozwala prywatnym maszynom wirtualnym docierać do API Google bez zewnętrznych adresów IP, korzystając z domyślnej ścieżki routingu. Private Service Connect (PSC) dla API Google udostępnia prywatne punkty końcowe (endpoints) IP w Twojej sieci VPC z kontrolą polityk i całkowicie eliminuje publiczny ruch wychodzący (egress); preferuj punkty końcowe PSC dla ściślejszej kontroli ruchu wychodzącego i spójnego DNS.
Private Service Connect (usługi producenta i konsumenta)
- Udostępniaj usługi wewnętrzne za pomocą service attachment w projekcie producenta i konsumuj je za pomocą prywatnych punktów końcowych w projektach konsumentów. Mapowanie DNS i jawne polityki zezwalające kontrolują dostęp. Poprawia to izolację w porównaniu z VPC Peering i centralizuje publikowanie usług.
VPC Network Peering, Shared VPC i segmentacja
- VPC Peering oferuje prywatną łączność między sieciami VPC z niskim opóźnieniem. Jest nietranzytywny i nie pozwala na nakładające się adresy IP. Opcjonalny import/eksport tras niestandardowych rozszerza osiągalność, ale nadal nie tworzy routingu tranzytywnego; świadomie planuj architekturę hub-and-spoke.
- Shared VPC centralizuje podsieci w projekcie hosta (host project) do użytku przez projekty usługowe (service projects). Umożliwia to scentralizowany routing, zapory sieciowe, NAT i LB, jednocześnie delegując uprawnienia IAM dla poszczególnych aplikacji. Połącz z hierarchicznymi zaporami sieciowymi i bezpiecznymi tagami (secure tags) w celu segmentacji.
- Network Connectivity Center (NCC) zapewnia centralny punkt (hub) do orkiestracji połączeń typu spoke (VPN, Interconnect, urządzenie routera, VPC spokes) i spójnego zarządzania topologiami korporacyjnej sieci WAN.
Cloud VPN, Cloud Interconnect i BGP
- Cloud VPN: używaj HA VPN z routingiem dynamicznym (BGP) dla zapewnienia dostępności i automatycznego przełączania awaryjnego tras (failover). Jeśli to możliwe, buduj dwa tunele do każdego peera przez niezależne interfejsy Cloud VPN i oddzielne urządzenia/łącza on-prem.
- Cloud Interconnect: Dedicated Interconnect zapewnia prywatne łącza 10–100 Gb/s; Partner Interconnect korzysta z dostawcy usług. Dla zapewnienia odporności, wdrażaj redundantne połączenia Interconnect w różnych domenach dostępności brzegowej (edge availability domains) i używaj BFD z BGP tam, gdzie jest to wspierane.
- Domeny awarii (Failure domains): izoluj według regionu, strefy, urządzenia i dostawcy. Regularnie testuj przełączanie awaryjne; asymetryczne ścieżki mogą zakłócić działanie stanowych zapór sieciowych (stateful firewalls) w środowisku on-prem.
Przykłady

undefined

Obserwowalność i rozwiązywanie problemów

Connectivity Tests
- Symuluj i weryfikuj osiągalność między źródłami a miejscami docelowymi w różnych sieciach VPC, środowiskach on-premise (przez łącza hybrydowe) i systemach równoważenia obciążenia. Narzędzie ocenia trasy, reguły zapory sieciowej i konfigurację, aby zlokalizować utracone pakiety lub błędnie kierowany ruch przed wprowadzeniem zmian w środowisku produkcyjnym.
- Przykład:

undefined

VPC Flow Logs
- Włączane na poziomie podsieci, aby uzyskać wgląd w czasie rzeczywistym w przepływy 5-krotkowe (5-tuple), liczbę bajtów, utracone pakiety i opóźnienia. Eksportuj do Cloud Logging, Pub/Sub lub BigQuery w celu analizy. Dostosuj poziomy próbkowania i metadanych, aby kontrolować koszty.
- Przypadki użycia: walidacja skuteczności zapory sieciowej, wykrywanie eksfiltracji danych, planowanie pojemności i monitorowanie SLO.
Packet Mirroring
- Kopiuj ruch z maszyn wirtualnych lub GKE do punktów końcowych kolektora w celu głębokiej inspekcji pakietów (DPI) lub użycia w systemach IDS. Określ zakres kopiowania według podsieci, tagu lub instancji. Zrozum narzut wydajnościowy i upewnij się, że kolektory są w stanie obsłużyć wolumen kopiowanego ruchu. Unikaj kopiowania ruchu po translacji NAT, jeśli potrzebujesz oryginalnych nagłówków.
Typowe wzorce diagnostyczne
- Blackhole: trasa istnieje, ale ścieżka odpowiedzi jest zablokowana przez zaporę sieciową lub routing asymetryczny; zweryfikuj za pomocą Connectivity Tests i logów przepływu (flow logs) po obu stronach.
- Błędy kontroli stanu (health check): potwierdź, że zapora sieciowa zezwala na ruch od systemów kontroli stanu, a backendy nasłuchują na właściwych portach; przetestuj lokalnie z maszyny wirtualnej w tej samej podsieci.
- Wyczerpanie zasobów NAT: szukaj odrzuconych przepływów z powodem „no available NAT ports”; dodaj więcej adresów IP dla NAT lub zmniejsz limity portów na maszynę wirtualną.

Praktyczny scenariusz problemowy

Firma Acme Retail prowadzi wieloregionalną platformę e-commerce z prywatnymi backendami, publicznym punktem wejścia do aplikacji webowej i systemem ERP w środowisku on-premise. Muszą oni segmentować obciążenia robocze, zapewnić prywatny ruch wychodzący do interfejsów API Google, umożliwić hybrydową osiągalność ze wszystkich regionów oraz wzmocnić bezpieczeństwo, zachowując jednocześnie obserwowalność.

Utwórz Shared VPC w trybie niestandardowym (custom-mode) w celu centralnego zarządzania

undefined

Uzasadnienie: Tryb niestandardowy (custom mode) pozwala uniknąć automatycznie przypisywanych zakresów CIDR i umożliwia świadome planowanie adresacji IP. Shared VPC centralizuje routing, zapory sieciowe i NAT w projekcie hosta, jednocześnie pozwalając na bezpieczne wdrażanie zasobów w projektach usługowych.

Zaplanuj i utwórz podsieci z dodatkowymi zakresami (secondary ranges) dla GKE

undefined

Uzasadnienie: Nienakładające się na siebie zakresy podstawowe i dodatkowe zapobiegają przyszłym konfliktom podczas peeringu i umożliwiają użycie aliasów IP dla GKE bez ryzyka wyczerpania adresów IP.

Ustaw routing dynamiczny VPC na globalny i wdróż Cloud Router

undefined

Uzasadnienie: Tryb globalny sprawia, że trasy on-premise nauczone przez BGP są użyteczne we wszystkich regionach, co upraszcza hybrydową osiągalność i przełączanie awaryjne (failover).

Ustanów połączenie HA VPN ze środowiskiem on-premise i rozgłaszaj podsieci

Utwórz dwa tunele HA VPN do różnych urządzeń on-premise. Użyj BGP do wymiany prefiksów i zapewnienia płynnego przełączania awaryjnego.
Uzasadnienie: Podwójne tunele eliminują pojedyncze punkty awarii; BGP zapewnia szybką konwergencję tras podczas prac konserwacyjnych lub awarii.

Wdróż Cloud NAT dla prywatnego ruchu wychodzącego i PSC dla interfejsów API Google

undefined

Utwórz punkty końcowe Private Service Connect dla interfejsów API Google i zaktualizuj prywatny DNS, aby mapować punkty końcowe API na PSC.
Uzasadnienie: NAT umożliwia ruch wychodzący do internetu bez konieczności posiadania zewnętrznych adresów IP przez maszyny wirtualne; PSC utrzymuje ruch do API na prywatnych adresach IP i pod ścisłą kontrolą polityk, eliminując publiczne ścieżki wyjścia.

Frontend za globalnym External HTTP(S) Load Balancer; usługi wewnętrzne przez Internal HTTP(S)

Utwórz globalny zewnętrzny HTTP(S) LB z zarządzanym certyfikatem i usługą backendową wskazującą na backendy typu NEG.
Utwórz regionalne Internal HTTP(S) LB dla ruchu między usługami (service-to-service) z mTLS pomiędzy mikrousługami.
Uzasadnienie: Globalny LB typu proxy zapewnia anycast, automatyczne skalowanie i CDN; wewnętrzny LB warstwy 7 oferuje zaawansowany routing i bezpieczeństwo dla ruchu wschód-zachód (east-west).

Zaimplementuj hierarchiczne polityki zapory sieciowej i targetowanie oparte na tożsamości obciążeń

Dołącz politykę na poziomie organizacji, która blokuje dostęp do portów administracyjnych z internetu; zezwalaj na ruch tylko ze źródeł kontroli stanu (health-check) systemu równoważenia obciążenia.
Utwórz reguły VPC targetujące konta usługowe (service accounts) w celu zapewnienia dostępu o najniższych uprawnieniach (least-privilege) między warstwami; użyj bezpiecznych tagów (secure tags) do dynamicznej segmentacji.
Uzasadnienie: Hierarchia umożliwia centralne egzekwowanie zabezpieczeń (guardrails); targetowanie oparte na tożsamości jest odporne na podszywanie się pod tagi (tag spoofing) i upraszcza automatyzację.

Skonfiguruj Cloud DNS z podziałem horyzontu (split-horizon) i przekierowywaniem (forwarding)

Utwórz publiczną strefę acme.com dla adresu VIP aplikacji webowej oraz prywatną strefę acme.com dla nazw usług wewnętrznych mapowanych na wewnętrzne systemy równoważenia obciążenia (ILB).
Skonfiguruj przekierowywanie zapytań wychodzących (outbound forwarding) do serwerów DNS on-premise oraz przychodzących (inbound), aby umożliwić środowisku on-premise rozwiązywanie nazw ze stref prywatnych.
Uzasadnienie: Podział horyzontu (split-horizon) zapobiega wyciekom danych i zapewnia poprawne rozwiązywanie nazw w zależności od sieci źródłowej; przekierowywanie (forwarding) integruje starsze przestrzenie nazw.

Użyj Connectivity Tests, logów przepływu i packet mirroring dla zapewnienia widoczności

Utwórz testy dla krytycznych ścieżek (użytkownik do webowego LB, ruch z web do usług wewnętrznych, ruch z usług do systemu ERP on-premise).
Włącz logi przepływu (flow logs) na podsieciach; eksportuj je do BigQuery w celu analizy trendów. Włączaj tymczasowo packet mirroring podczas reagowania na incydenty.
Uzasadnienie: Proaktywna walidacja i telemetria skracają średni czas do naprawy (MTTR), ujawniają błędy w konfiguracji i dostarczają informacji na temat pojemności.

Udokumentuj i przetestuj scenariusze awaryjne

Symuluj utratę tunelu VPN, awarię regionu oraz awarię backendowej grupy MIG. Zweryfikuj przełączanie awaryjne BGP, usuwanie backendu przez system kontroli stanu LB oraz poprawność działania DNS.
Uzasadnienie: Regularne ćwiczenia (game days) potwierdzają założenia dotyczące redundancji i ujawniają zmiany w konfiguracji (configuration drift), zanim spowodują one awarie.

← Kontenery · Wszystkie domeny · Pamięć masowa →

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