Professional Cloud Network Engineer — Übungsfragen und Probeprüfung

Laut offizieller Doku (cloud.google.com/firewall/docs/firewall-policies-rule-eval-order) wertet die Durchsetzungsreihenfolge AFTER_CLASSIC_FIREWALL so aus: (1) hierarchische Firewall-Richtlinien, (2) regionale System-Firewall-Richtlinien, (3) VPC-Firewallregeln, (4) globale Netzwerk-Firewall-Richtlinien, (5) regionale Netzwerk-Firewall-Richtlinien, (6) implizite Firewallregeln. Hierarchische Richtlinien werden unabhängig von der Durchsetzungsreihenfolge immer zuerst ausgewertet. AFTER_CLASSIC_FIREWALL (Standard) wahrt die Abwärtskompatibilität, indem klassische VPC-Regeln vor den neueren Netzwerk-Firewall-Richtlinien ausgewertet werden. Jede Ebene kann zulassen, ablehnen oder mit goto_next die Auswertung fortsetzen. Die Option „VPC-Regeln, dann hierarchische Richtlinien …“ dreht die Reihenfolge von hierarchischen Richtlinien und VPC-Regeln um. Die Optionen „Hierarchische Richtlinien, dann Netzwerkrichtlinien …“ und „Netzwerkrichtlinien, dann hierarchische Richtlinien …“ ordnen die Netzwerkrichtlinien unter der AFTER_CLASSIC-Einstellung fälschlich vor den VPC-Regeln ein. Ref: cloud.google.com/firewall/docs/firewall-policies-rule-eval-order.

Wenn ein VPN-Tunnel steht (IKE war erfolgreich) und die BGP-Sessions als established angezeigt werden, aber kein Traffic fließt, liegt die Ursache darin, dass keine Routen angekündigt werden. Laut Doku (cloud.google.com/network-connectivity/docs/router/concepts/advertised-routes) hat Cloud Router zwei Ankündigungsmodi: den Standardmodus (kündigt Subnetzbereiche automatisch an) und den benutzerdefinierten Modus (erfordert eine explizite Konfiguration der Präfixe). Steht Cloud Router im benutzerdefinierten Modus ohne konfigurierte Präfixe, oder hat der lokale Router keine BGP-Ankündigungen, lernt keine der beiden Seiten Routen zu den Netzwerken der anderen. Ein nicht übereinstimmender IKE-Pre-Shared-Key (die Option „Der IKE-Pre-Shared-Key ist falsch“) würde den Tunnelaufbau komplett verhindern. Cloud NAT (die Option „Cloud NAT stört den VPN-Traffic“) arbeitet unabhängig vom Data-Plane-Traffic der VPN. MTU-Probleme (die Option „Die MTU des VPN-Tunnels ist zu niedrig eingestellt“) führen zu Paketverlusten oder Fragmentierung, nicht zu fehlenden Routen. Lösung: den Ankündigungsmodus von Cloud Router und die BGP-Exporte on-premises prüfen. Ref: cloud.google.com/network-connectivity/docs/router/concepts/advertised-routes.

IP Masquerade (SNAT) in GKE ersetzt bei ausgehendem Traffic die Quell-IP des Pods durch die IP des Nodes. Laut Doku (cloud.google.com/kubernetes-engine/docs/concepts/ip-masquerade-agent) ist das nötig, wenn Ziele außerhalb der VPC keine Routen zum Pod-CIDR-Bereich haben — etwa lokale Netzwerke, die über VPN/Interconnect angebunden sind. Ohne SNAT kann der Rückweg-Traffic nicht zu den Pod-IPs zurückgeroutet werden. GKE steuert das Masquerading über das DaemonSet ip-masq-agent und die Liste nonMasqueradeCIDRs in dessen ConfigMap. Das Flag --disable-default-snat erhält die Pod-IPs für alle Ziele, wenn kein ip-masq-agent vorhanden ist. Pod-zu-Pod-Traffic in VPC-native Clustern braucht kein SNAT (die VPC hat Routen für die Pod-CIDRs). Traffic von Pods zur Control Plane (die Option „Wenn Pods mit der GKE-Control-Plane kommunizieren müssen“) und Private Google Access (die Option „Wenn Pods über Private Google Access auf Google Cloud APIs zugreifen …“) laufen innerhalb des Google-Netzwerks und benötigen kein Masquerading. Ref: cloud.google.com/kubernetes-engine/docs/concepts/ip-masquerade-agent.

Laut Doku (cloud.google.com/load-balancing/docs/passthrough-network-load-balancer) stellen Passthrough-NLBs Pakete mit unveränderten Quell- und Ziel-IPs zu – 'Pakete kommen bei den Backend-VMs mit unveränderten Quell- und Ziel-IP-Adressen, unverändertem Protokoll und unveränderten Ports an.' Der regionale externe Passthrough-NLB (basiert auf Maglev) unterstützt TCP, UDP, ESP, GRE, ICMP und ICMPv6. Er erhält die Quell-IP des Clients nativ über Direct Server Return (DSR). Die Option „Global external Application Load Balancer“ (globaler externer Application LB) verarbeitet nur HTTP(S), nicht beliebigen TCP-Traffic. Die Option „Internal passthrough Network Load Balancer“ (interner Passthrough-NLB) bedient internen Traffic, keine externen Clients. Die Option „Regional external proxy Network Load Balancer“ (regionaler externer Proxy-NLB) terminiert Verbindungen und baut neue zu den Backends auf, wodurch die ursprüngliche Quell-IP verloren geht – es sei denn, du nutzt das PROXY-Protokoll (reine HTTP-Header funktionieren bei Nicht-HTTP-Traffic nicht). Ref: cloud.google.com/load-balancing/docs/passthrough-network-load-balancer.