Google PCNE: Trasowanie, Network Connectivity Center i segmentacja — Przewodnik do nauki

By Laurynas Brazys · 22 August 2026 · #google #PCNE #certification #exam-prep #study-guide

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

Przegląd

Ta sekcja wyjaśnia routing, Network Connectivity Center (NCC) oraz wzorce segmentacji w Google Cloud. Skupia się na tym, jak trasy są tworzone i wybierane, jak łączyć sieci VPC i organizacje z zachowaniem izolacji, jak budować skalowalne projekty tranzytowe i wstawiania usług (service insertion) oraz jak walidować i ograniczać awarie.

Podstawy i kontrola routingu

• Typy tras

  • Trasy podsieci generowane przez system: Jedna dla każdego głównego i dodatkowego zakresu podsieci; zawsze mają najwyższy priorytet dla swoich dokładnych prefiksów.
  • Domyślna trasa do bramy internetowej: Automatycznie tworzona w nowych sieciach VPC; może być usunięta lub nadpisana.
  • Trasy statyczne: Niestandardowe prefiksy z następnymi skokami (next hop), takimi jak domyślna brama internetowa, konkretna instancja, wewnętrzny load balancer TCP/UDP (ILB) jako następny skok lub tunel Cloud VPN. Trasy oparte na politykach dodają warunki dopasowania (tagi, konta usług, protokół/port) i kierują ruch do instancji lub ILB jako następnego skoku w celu zaawansowanego wstawiania usług (service insertion).
  • Trasy dynamiczne: Uczone przez Cloud Router za pomocą BGP z Cloud VPN lub Cloud Interconnect. Ich zasięg jest kontrolowany przez tryb routingu dynamicznego sieci VPC (regionalny lub globalny).

• Wybór trasy

  • Najpierw dopasowanie najdłuższego prefiksu.
  • Jeśli wiele tras ma tę samą długość prefiksu, wygrywa najniższy numerycznie priorytet trasy (domyślnie 1000 dla tras niestandardowych). Unikaj nakładania się tych samych prefiksów na ścieżkach statycznych/dynamicznych; projektuj tak, aby jednoznacznie preferować jedną z nich.
  • Remisy poza priorytetem są rozstrzygane przez wewnętrzne mechanizmy platformy; nie należy na nich polegać.

• Wybór następnego skoku i wstawianie usług

  • Aby scentralizować ruch wychodzący (egress) lub wstawić usługi L3/L7, skieruj trasę statyczną 0.0.0.0/0 lub trasy oparte na politykach na następny skok typu ILB, którego backendami są sieciowe urządzenia wirtualne (NVA).
  • Gdy urządzenia muszą być omijane dla interfejsów API Google przez instancje bez zewnętrznych adresów IP, włącz Private Google Access na podsieciach i dodaj niestandardowe trasy statyczne dla opublikowanych zakresów VIP interfejsów API Google do domyślnej bramy internetowej. Zachowuje to prywatny dostęp do usług Google, podczas gdy inny ruch wychodzący podąża ścieżką przez NGFW.

• Tryb routingu dynamicznego i zachowanie w wielu regionach

  • Regionalny: Trasy nauczone przez Cloud Router są instalowane tylko dla podsieci w tym samym regionie.
  • Globalny: Trasy nauczone w dowolnym miejscu są instalowane dla wszystkich regionów w sieci VPC, co umożliwia prostą łączność wieloregionalną i zmniejsza narzut operacyjny w projektach typu hub-and-spoke. Dla użytkowników i obciążeń w pobliżu us-east1 i europe-west1, pojedyncza sieć VPC z regionalnymi podsieciami i globalnym routingiem dynamicznym pozwala im na prywatną komunikację przez RFC1918 z optymalną wydajnością.

• Kontrola anonsowania tras

  • Cloud Router może anonsować do środowiska on-premises wszystkie podsieci lub niestandardowy zestaw prefiksów (w tym trasę domyślną). Kontroluj wybór ścieżki przychodzącej z on-premises za pomocą standardowych narzędzi BGP (MED, AS-path prepending, local preference on-prem). W przypadku konfiguracji active/standby w kierunku on-prem, ustaw niższy MED na ścieżce głównej i wyższy na zapasowej.
  • Unikaj anonsowania tego samego prefiksu od różnych peerów on-premises z różnymi numerami ASN do tego samego Cloud Router; w celu uzyskania dual-homed ECMP lub czystego przełączania awaryjnego (failover), używaj tego samego numeru ASN peera na redundantnych routerach on-premises.

Łączność między sieciami VPC i segmentacja

• VPC Network Peering

  • Umożliwia prywatną łączność RFC1918 między sieciami VPC z niskim opóźnieniem i bez urządzeń w płaszczyźnie danych. Domyślnie wymienia trasy podsieci i opcjonalnie może importować/eksportować trasy niestandardowe (statyczne i dynamiczne), aby rozszerzyć osiągalność zasobów za Cloud VPN/Interconnect. Nie ma routingu tranzytowego: trasy nauczone od jednego peera nie są reeksportowane do innego.
  • Tryby awarii i ograniczenia: Brak nakładających się zakresów CIDR; reguły zapory sieciowej pozostają niezależne dla każdej sieci VPC; przepustowość jest wysoka, ale nie zastępuje load balancerów; routing asymetryczny w topologii siatki (mesh) peeringu nie jest obsługiwany. Aby połączyć trzy sieci VPC w trójkąt, skonfiguruj pełną siatkę par peeringu; połączenia Sprzedaż↔Finanse i Marketing↔Finanse nie umożliwiają komunikacji Sprzedaż↔Marketing, chyba że ta para również jest połączona peeringiem.
  • Planowanie adresacji: Podczas peeringu z siecią VPC w trybie auto (która rezerwuje 10.128.0.0/9), utwórz sieć peer w trybie niestandardowym z nienakładającym się zakresem CIDR, takim jak 10.0.0.0/9.

• Shared VPC i łączność między wieloma projektami

  • Projekt hosta jest właścicielem sieci VPC; projekty usługowe dołączają się do wybranych podsieci. Centralizuje to sieć i łączność hybrydową (Cloud Routers, Cloud NAT, Interconnect), jednocześnie umożliwiając delegowanie własności aplikacji na poziomie projektu. Umieść załączniki VLAN i Cloud Routers dla Dedicated Interconnect w projekcie hosta, aby zapewnić efektywną kosztowo, scentralizowaną łączność on-prem dla wszystkich projektów usługowych.
  • Zasada najmniejszych uprawnień: Administratorzy sieci (Network Admins) zarządzają routingiem i podsieciami; Administratorzy bezpieczeństwa (Security Admins) zarządzają regułami i politykami zapory sieciowej. Jeśli nie możesz zaktualizować zapór sieciowych jako Administrator sieci, poproś o uprawnienia Administratora bezpieczeństwa w zakresie Shared VPC.
  • Segmentacja: Udostępniaj tylko te konkretne podsieci, które są wymagane przez projekt usługowy. Jest to zgodne z najlepszymi praktykami Google, aby ściśle kontrolować ekspozycję tras między środowiskami produkcyjnym (Production) i testowym (Staging).

• Mechanizmy izolacji sieci

  • Granice VPC: Brak routingu między sieciami VPC bez jawnego peeringu, VPN lub Private Service Connect. Używaj oddzielnych sieci VPC dla działów lub najemców, którzy muszą być w pełni odizolowani; łącz peeringiem tylko te, które potrzebują łączności, aby zminimalizować narzut operacyjny.
  • Polityki zapory sieciowej: Używaj hierarchicznych polityk zapory sieciowej na poziomie organizacji/folderu, aby zapewnić spójne zabezpieczenia (guardrails), oraz reguł per-VPC dla lokalnych wyjątków. Domyślne ustawienie blokady ruchu przychodzącego (ingress deny) i zezwolenia na ruch wychodzący (egress allow) można zaostrzyć.
  • Perymetry: Używaj VPC Service Controls, aby ograniczyć dostęp do interfejsów API Google i zminimalizować ryzyko eksfiltracji danych między projektami i sieciami.
  • Ekspozycja IPv6: Aby uzyskać publiczny dostęp IPv6, przypisz adres IPv6 do globalnego zewnętrznego load balancera HTTP(S) obsługującego Twoją usługę. Backendy pozostają prywatne.

Network Connectivity Center i architektury tranzytowe

• Architektura hub-and-spoke z NCC

  • Hub zapewnia płaszczyznę sterowania dla routingu między szprychami. Szprychy obejmują załączniki VLAN (Interconnect), tunele HA VPN, szprychy typu router appliance oraz obsługiwane szprychy VPC do transferu danych site-to-site. Tablice routingu NCC kontrolują, które prefiksy są importowane/eksportowane i które szprychy je otrzymują, umożliwiając precyzyjną segmentację.
  • Transfer danych site-to-site pozwala lokalizacjom on-premise komunikować się ze sobą przez sieć szkieletową Google, używając huba jako tranzytu, co zmniejsza potrzebę korzystania z tranzytu od firm trzecich i upraszcza operacje.

• Szprychy typu router appliance i urządzenia NVA firm trzecich

  • Szprychy typu router appliance umożliwiają wdrażanie wirtualnych routerów/firewalli hostowanych na Compute Engine jako usługi tranzytowe lub inline. Użyj ILB jako następnego przeskoku (next hop), aby osiągnąć skalowalność i przełączanie awaryjne (failover) z kontrolą stanu (health check) między wieloma urządzeniami.
  • Projektowanie wysokiej dostępności (HA): Wdróż co najmniej dwa urządzenia w różnych strefach; umieść je za ILB z MIG, jeśli to możliwe; włącz przekazywanie IP (IP forwarding) na instancjach; użyj symetrycznego kierowania ruchem z ILB jako następnym skokiem; rozkładaj obciążenie za pomocą tras opartych na politykach (policy-based routes) bazujących na tagach lub kontach usług.
  • Kompromisy między przepustowością a awaryjnością: Urządzenia NVA są ograniczone przez typ instancji i przepustowość karty sieciowej (NIC); zaplanuj skalowanie horyzontalne. Awaria urządzenia lub niepowodzenie kontroli stanu wyzwala usunięcie go z ILB i szybkie przełączenie awaryjne, ale upewnij się, że liczniki czasu konwergencji tras i progi kontroli stanu są dostrojone, aby unikać niestabilności (flapping).

• Kompromisy w topologiach tranzytowych

  • Hub-and-spoke z NCC: Scentralizowane polityki, wysoka skalowalność, wyraźna kontrola zasięgu awarii (blast radius); wymaga zaprojektowania tablic routingu i zdefiniowania intencji importu/eksportu.
  • Peering w pełnej siatce (full mesh): Prosty dla małej liczby sieci VPC, brak centralnego tranzytu, ale słabo się skaluje i nie zapewnia tranzytywności ani wstawiania usług (service insertion).
  • Scentralizowany ruch wychodzący (egress): Proste egzekwowanie bezpieczeństwa przez jeden NGFW lub NAT; może dodawać opóźnienia i stać się wąskim gardłem; można to złagodzić za pomocą regionalnych punktów wyjścia i autoskalowania.
  • Siatka VPN (Mesh VPN) z Cloud Routers: Elastyczna i szybka do wdrożenia; narzut operacyjny rośnie wraz z liczbą peerów; rozważ użycie NCC w celu konsolidacji.

• Kwestie do rozważenia przy Cloud VPN

  • Jeśli urządzenie on-premise nie obsługuje BGP, użyj Cloud VPN opartego na politykach (policy-based) z trasami statycznymi i starannie zdefiniowanymi selektorami ruchu (traffic selectors); zaplanuj docelową migrację do HA VPN z BGP, aby zminimalizować długoterminowy narzut operacyjny.
  • Dla tuneli active/standby w kierunku on-premise, manipuluj atrybutami MED lub AS-path po stronie on-premise. W przypadku podwójnych routerów on-premise łączących się z jednym Cloud Router, preferuj identyczne numery ASN peerów, aby umożliwić instalację obu ścieżek i ECMP; użycie różnych numerów ASN peerów zazwyczaj skutkuje wybraniem tylko jednej ścieżki.

Operacje: weryfikacja, analiza i ograniczanie skutków awarii

• Weryfikacja łączności i analiza tras

  • Użyj Connectivity Tests w Network Intelligence Center, aby śledzić ścieżkę danych przez maszyny wirtualne, load balancery, VPC peering, Cloud VPN i Interconnect, weryfikując reguły zapory sieciowej i trasy.
  • Analizuj efektywne trasy dla każdej maszyny wirtualnej/podsieci, aby potwierdzić następne skoki (next-hops) i dynamiczne prefiksy; sprawdź, czy zakres trybu routingu dynamicznego jest zgodny z zamierzeniami.
  • W przypadku problemów z wydajnością lub doświadczeniem użytkownika, preferuj globalny load balancing HTTP(S), aby zmniejszyć opóźnienia dla użytkowników na całym świecie dzięki wejściu anycast i terminacji na brzegu sieci; sieciowe load balancery są regionalne i nie poprawiają globalnych opóźnień.

• Ograniczanie skutków awarii i redukcja zasięgu rażenia (blast radius)

  • Segmentuj za pomocą sieci VPC, tabel routingu NCC i podsieci Shared VPC per projekt, aby zapobiec niezamierzonej propagacji awarii lub błędnych konfiguracji.
  • Unikaj zależności przechodnich (transitive) przez peering; tam, gdzie wymagany jest tranzyt, użyj NCC i kontrolowanego importu/eksportu tras, aby ograniczyć osiągalność.
  • Używaj scentralizowanych polityk zapory sieciowej na poziomie organizacji dla bazowych reguł typu deny/allow oraz lokalnych polityk dla wyjątków aplikacyjnych; testuj zmiany za pomocą Connectivity Tests.
  • Tam, gdzie wymagane są zabezpieczenia inline, wdróż ILB jako następny skok (next-hop) z kontrolą stanu (health checks) i routingiem opartym na politykach (policy-based routing) dla płynnego przełączania awaryjnego (graceful failover). Upewnij się, że krytyczne API Google są osiągalne przez Private Google Access lub Cloud NAT bez polegania na zewnętrznych adresach IP.
  • Monitoruj sesje BGP i zmiany tras; standaryzuj metryki (MED, local preference) i plany adresacji, aby unikać oscylacji tras i asymetrycznych przepływów.

• Krótkie przykłady konfiguracji

  • Utwórz trasę statyczną, aby skierować ruch przez urządzenie inline za ILB:

undefined

• Preferuj jedną z dwóch ścieżek BGP przychodzących do środowiska on-premise za pomocą MED (na routerze on-premise):

undefined

-

undefined

-

undefined

-

undefined

Praktyczny scenariusz problemowy

Firma Acme Retail działa w organizacji Google Cloud z wieloma projektami, z dwiema populacjami użytkowników w pobliżu regionów us-east1 i europe-west1. Potrzebują prywatnej, taniej komunikacji między obciążeniami roboczymi (workloads) w różnych regionach, scentralizowanej łączności on-premise oraz filtrowania URL inline dla ruchu wychodzącego do internetu, jednocześnie utrzymując izolację działu Finansów od działu Inżynierii.

1. Zbuduj pojedynczą sieć Shared VPC w projekcie hosta z regionalnymi podsieciami w us-east1 i europe-west1, a następnie ustaw tryb routingu dynamicznego na globalny.

• Uzasadnienie: Jedna sieć VPC umożliwia bezpośrednią komunikację w ramach RFC1918 między regionami bez narzutu związanego z peeringiem. Globalny routing dynamiczny instaluje nauczone trasy hybrydowe we wszystkich regionach, co upraszcza operacje i zapewnia wydajne przepływy wewnątrz VPC.

2. Udostępnij tylko wymagane podsieci każdemu projektowi usługowemu; umieść działy Finansów i Inżynierii w oddzielnych projektach usługowych.

• Uzasadnienie: Udostępnianie na poziomie podsieci zapewnia segmentację organizacyjną i minimalizuje niezamierzoną ekspozycję tras. Dział Finansów pozostaje odizolowany dzięki prostemu nieudostępnianiu podsieci działu Inżynierii oraz dzięki oddzielnym zakresom polityk zapory sieciowej.

3. Zakończ połączenie Dedicated Interconnect w projekcie hosta i dołącz Cloud Routers; rozgłaszaj tylko niezbędne prefiksy, używając niestandardowych rozgłoszeń (custom advertisements).

• Uzasadnienie: Scentralizowana łączność hybrydowa redukuje koszty i złożoność, jednocześnie zachowując kontrolę nad tym, co dociera do środowiska on-premise. Niestandardowe rozgłoszenia zapobiegają nadmiernej ekspozycji i ograniczają zasięg rażenia (blast radius).

4. Wstaw urządzenie inline do filtrowania URL w warstwie 7 za regionalnym wewnętrznym load balancerem TCP/UDP; kieruj ruch wychodzący za pomocą trasy statycznej 0.0.0.0/0 do ILB jako następnego skoku w każdym regionie.

• Uzasadnienie: ILB jako następny skok (next hop) wraz z kontrolą stanu (health checks) zapewnia wysokodostępne wstawianie usług (service insertion) z symetrycznymi przepływami. Trasy statyczne o wyższym priorytecie niż domyślna brama internetowa zapewniają, że cały ruch wychodzący jest filtrowany.

5. Upewnij się, że instancje bez zewnętrznych adresów IP mogą bezpośrednio docierać do API Google: włącz Private Google Access na wszystkich podsieciach i dodaj trasy statyczne dla zakresów VIP API Google do domyślnej bramy internetowej, aby ominąć urządzenie filtrujące.

• Uzasadnienie: Private Google Access zachowuje prywatny dostęp do BigQuery i Pub/Sub; niestandardowe trasy zapobiegają niepotrzebnemu zjawisku hairpinning przez filtr, co redukuje koszty i opóźnienia.

6. Utrzymaj izolację działu Finansów: zabroń ruchu międzyprojektowego w hierarchicznych politykach zapory sieciowej i nie konfiguruj peeringu między działami Finansów i Inżynierii. Gdzie wymagana jest współpraca między działami Inżynierii i Analityki, utwórz dedykowaną parę połączonych peeringiem sieci VPC z niepokrywającymi się zakresami CIDR.

• Uzasadnienie: Granice VPC, brak peeringu i polityki zapory na poziomie organizacji wymuszają izolację. Ukierunkowany peering oferuje niski narzut operacyjny dla specyficznej łączności między działami bez przechodniości (transitivity).

7. Weryfikuj i monitoruj: użyj Connectivity Tests, aby zweryfikować osiągalność między regionami i wstawienie urządzenia; monitoruj stan BGP i tabele routingu w Cloud Router; zaimplementuj MED na routerach on-premise dla przełączania awaryjnego w trybie active/standby, jeśli istnieje wiele tuneli.

• Uzasadnienie: Proaktywna weryfikacja wcześnie wykrywa błędne konfiguracje. Mechanizmy kontrolne BGP utrzymują deterministyczne ścieżki on-premise podczas prac konserwacyjnych lub awarii, a telemetria z NCC/Cloud Router przyspiesza rozwiązywanie problemów.

Ten projekt spełnia wymagania Acme Retail przy minimalnych kosztach i wysokiej wydajności: zapewnia prywatny routing wieloregionalny w jednej sieci VPC, scentralizowaną łączność hybrydową, kontrolowane wstawianie usług i silną segmentację organizacyjną.

← Prywatna łączność do Google i usług zarządzanych · Wszystkie domeny · GKE →

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

Przeglądaj Google →