Professional Cloud Network Engineer — Preguntas de práctica y simulacro de examen

Según la documentación oficial (cloud.google.com/firewall/docs/firewall-policies-rule-eval-order), el orden de aplicación AFTER_CLASSIC_FIREWALL evalúa: (1) políticas de firewall jerárquicas, (2) políticas de firewall del sistema regionales, (3) reglas de firewall de VPC, (4) políticas de firewall de red globales, (5) políticas de firewall de red regionales, (6) reglas de firewall implícitas. Las políticas jerárquicas siempre se evalúan primero, sin importar el orden de aplicación. AFTER_CLASSIC_FIREWALL (el predeterminado) preserva la compatibilidad hacia atrás al evaluar las reglas de VPC heredadas antes que las políticas de firewall de red más nuevas. Cada nivel puede permitir, denegar o usar goto_next para continuar la evaluación. La opción “Reglas de VPC, luego políticas jerárquicas…” invierte el orden entre las políticas jerárquicas y las reglas de VPC. Las opciones “Políticas jerárquicas, luego políticas de red…” y “Políticas de red, luego políticas jerárquicas…” colocan incorrectamente las políticas de red antes de las reglas de VPC bajo la configuración AFTER_CLASSIC. Ref: cloud.google.com/firewall/docs/firewall-policies-rule-eval-order.

Cuando un túnel VPN está establecido (IKE tuvo éxito) y las sesiones BGP aparecen como establecidas pero no fluye tráfico, la causa es que no se están anunciando rutas. Según la documentación (cloud.google.com/network-connectivity/docs/router/concepts/advertised-routes), Cloud Router tiene dos modos de anuncio: el predeterminado (anuncia automáticamente los rangos de las subredes) y el personalizado (requiere configurar los prefijos de forma explícita). Si Cloud Router está en modo personalizado sin prefijos configurados, o el router on-premises no tiene anuncios BGP, ninguno de los dos lados aprende rutas para llegar a las redes del otro. Una clave precompartida de IKE que no coincide (la opción “La clave precompartida de IKE es incorrecta”) impediría por completo que el túnel se estableciera. Cloud NAT (la opción “Cloud NAT está interfiriendo con el tráfico de la VPN”) funciona de forma independiente del tráfico del plano de datos de la VPN. Los problemas de MTU (la opción “La MTU del túnel VPN está configurada demasiado baja”) provocan descarte o fragmentación de paquetes, no rutas faltantes. Solución: verifica el modo de anuncio de Cloud Router y las exportaciones BGP on-premises. Ref: cloud.google.com/network-connectivity/docs/router/concepts/advertised-routes.

El IP masquerade (SNAT) en GKE reemplaza la IP de origen del Pod por la IP del nodo en el tráfico saliente. Según la documentación (cloud.google.com/kubernetes-engine/docs/concepts/ip-masquerade-agent), esto se necesita cuando los destinos fuera de la VPC no tienen rutas hacia el rango CIDR de los Pods; por ejemplo, redes on-premises conectadas por VPN/Interconnect. Sin SNAT, el tráfico de retorno no puede enrutarse de vuelta a las IP de los Pods. GKE controla el masquerading mediante el DaemonSet ip-masq-agent y la lista nonMasqueradeCIDRs de su ConfigMap. La marca --disable-default-snat conserva las IP de los Pods para todos los destinos cuando no hay un ip-masq-agent presente. El tráfico entre Pods dentro de clústeres VPC-native no necesita SNAT (la VPC tiene rutas para los CIDR de los Pods). El tráfico de Pod al control plane (la opción “Cuando los Pods necesitan comunicarse con el control plane de GKE”) y el de Private Google Access (la opción “Cuando los Pods necesitan acceder a las APIs de Google Cloud mediante Private…”) se enruta dentro de la red de Google y no requiere masquerading. Ref: cloud.google.com/kubernetes-engine/docs/concepts/ip-masquerade-agent.

Según la documentación (cloud.google.com/load-balancing/docs/passthrough-network-load-balancer), los NLB de tipo passthrough entregan los paquetes con las IP de origen y destino sin modificar: 'los paquetes llegan a las VMs de backend con las direcciones IP de origen y destino, el protocolo y los puertos del paquete sin cambios.' El NLB passthrough externo regional (construido sobre Maglev) admite TCP, UDP, ESP, GRE, ICMP e ICMPv6. Conserva la IP de origen del cliente de forma nativa mediante Direct Server Return (DSR). La opción “Global external Application Load Balancer” (Application LB externo global) solo maneja HTTP(S), no TCP arbitrario. La opción “Internal passthrough Network Load Balancer” (NLB passthrough interno) atiende tráfico interno, no clientes externos. La opción “Regional external proxy Network Load Balancer” (NLB proxy externo regional) termina las conexiones y abre otras nuevas hacia los backends, con lo que se pierde la IP de origen original salvo que uses el protocolo PROXY (los encabezados solo de HTTP no sirven para tráfico que no es HTTP). Ref: cloud.google.com/load-balancing/docs/passthrough-network-load-balancer.