Professional Cloud Network Engineer — Questions d'entraînement et examen blanc

D'après la documentation officielle (cloud.google.com/firewall/docs/firewall-policies-rule-eval-order), l'ordre d'application AFTER_CLASSIC_FIREWALL évalue : (1) les stratégies de pare-feu hiérarchiques, (2) les stratégies de pare-feu système régionales, (3) les règles de pare-feu VPC, (4) les stratégies de pare-feu réseau globales, (5) les stratégies de pare-feu réseau régionales, (6) les règles de pare-feu implicites. Les stratégies hiérarchiques sont toujours évaluées en premier, quel que soit l'ordre d'application. AFTER_CLASSIC_FIREWALL (valeur par défaut) préserve la rétrocompatibilité en évaluant les anciennes règles VPC avant les stratégies de pare-feu réseau plus récentes. Chaque niveau peut autoriser, refuser ou utiliser goto_next pour poursuivre l'évaluation. L'option « Règles VPC, puis stratégies hiérarchiques… » inverse l'ordre entre les stratégies hiérarchiques et les règles VPC. Les options « Stratégies hiérarchiques, puis stratégies réseau… » et « Stratégies réseau, puis stratégies hiérarchiques… » placent à tort les stratégies réseau avant les règles VPC sous le paramètre AFTER_CLASSIC. Ref: cloud.google.com/firewall/docs/firewall-policies-rule-eval-order.

Quand un tunnel VPN est établi (IKE a réussi) et que les sessions BGP apparaissent comme établies mais qu'aucun trafic ne circule, la cause est l'absence de routes annoncées. D'après la documentation (cloud.google.com/network-connectivity/docs/router/concepts/advertised-routes), Cloud Router dispose de deux modes d'annonce : le mode par défaut (annonce automatiquement les plages des sous-réseaux) et le mode personnalisé (nécessite une configuration explicite des préfixes). Si Cloud Router est en mode personnalisé sans préfixes configurés, ou si le routeur on-premises n'a aucune annonce BGP, aucun des deux côtés n'apprend de routes pour joindre les réseaux de l'autre. Une clé pré-partagée IKE qui ne correspond pas (l'option « La clé pré-partagée IKE est incorrecte ») empêcherait totalement l'établissement du tunnel. Cloud NAT (l'option « Cloud NAT perturbe le trafic VPN ») fonctionne indépendamment du trafic du plan de données VPN. Les problèmes de MTU (l'option « La MTU du tunnel VPN est réglée trop bas ») provoquent des pertes de paquets ou de la fragmentation, pas des routes manquantes. Correctif : vérifie le mode d'annonce de Cloud Router et les exports BGP on-premises. Ref: cloud.google.com/network-connectivity/docs/router/concepts/advertised-routes.

L'IP masquerade (SNAT) dans GKE remplace l'IP source du Pod par l'IP du nœud pour le trafic sortant. D'après la documentation (cloud.google.com/kubernetes-engine/docs/concepts/ip-masquerade-agent), c'est nécessaire quand des destinations hors du VPC n'ont pas de routes vers la plage CIDR des Pods — par exemple des réseaux on-premises connectés via VPN/Interconnect. Sans SNAT, le trafic retour ne peut pas être routé vers les IP des Pods. GKE contrôle le masquerading via le DaemonSet ip-masq-agent et la liste nonMasqueradeCIDRs de sa ConfigMap. Le flag --disable-default-snat conserve les IP des Pods pour toutes les destinations lorsqu'aucun ip-masq-agent n'est présent. Le trafic entre Pods dans les clusters VPC-native n'a pas besoin de SNAT (le VPC dispose de routes vers les CIDR des Pods). Le trafic des Pods vers le control plane (l'option « Quand les Pods doivent communiquer avec le control plane GKE ») et celui de Private Google Access (l'option « Quand les Pods doivent accéder aux API Google Cloud via Private… ») circulent au sein du réseau de Google et ne nécessitent pas de masquerading. Ref: cloud.google.com/kubernetes-engine/docs/concepts/ip-masquerade-agent.

D'après la doc (cloud.google.com/load-balancing/docs/passthrough-network-load-balancer), les NLB passthrough transmettent les paquets avec les IP source et destination inchangées : 'les paquets sont reçus par les VM de backend avec les adresses IP source et destination, le protocole et les ports du paquet inchangés.' Le NLB passthrough externe régional (basé sur Maglev) prend en charge TCP, UDP, ESP, GRE, ICMP et ICMPv6. Il conserve nativement l'IP source du client grâce au Direct Server Return (DSR). L'option « Global external Application Load Balancer » (Application LB externe global) ne gère que le HTTP(S), pas un TCP quelconque. L'option « Internal passthrough Network Load Balancer » (NLB passthrough interne) sert du trafic interne, pas des clients externes. L'option « Regional external proxy Network Load Balancer » (NLB proxy externe régional) termine les connexions et en ouvre de nouvelles vers les backends, ce qui fait perdre l'IP source d'origine, sauf si tu utilises le protocole PROXY (des en-têtes réservés au HTTP ne fonctionnent pas pour du trafic non HTTP). Ref : cloud.google.com/load-balancing/docs/passthrough-network-load-balancer.