Professional Cloud Network Engineer — Questões de prática e simulado

Conforme a documentação oficial (cloud.google.com/firewall/docs/firewall-policies-rule-eval-order), a ordem de aplicação AFTER_CLASSIC_FIREWALL avalia: (1) políticas de firewall hierárquicas, (2) políticas de firewall do sistema regionais, (3) regras de firewall de VPC, (4) políticas de firewall de rede globais, (5) políticas de firewall de rede regionais, (6) regras de firewall implícitas. As políticas hierárquicas são sempre avaliadas primeiro, independentemente da ordem de aplicação. A AFTER_CLASSIC_FIREWALL (padrão) preserva a compatibilidade retroativa ao avaliar as regras de VPC legadas antes das políticas de firewall de rede mais novas. Cada nível pode permitir, negar ou usar goto_next para continuar a avaliação. A opção “Regras de VPC, depois políticas hierárquicas…” inverte a ordem entre as políticas hierárquicas e as regras de VPC. As opções “Políticas hierárquicas, depois políticas de rede…” e “Políticas de rede, depois políticas hierárquicas…” colocam incorretamente as políticas de rede antes das regras de VPC sob a configuração AFTER_CLASSIC. Ref: cloud.google.com/firewall/docs/firewall-policies-rule-eval-order.

Quando um túnel VPN está estabelecido (o IKE funcionou) e as sessões BGP aparecem como estabelecidas, mas nenhum tráfego flui, a causa é a ausência de rotas sendo anunciadas. Conforme a documentação (cloud.google.com/network-connectivity/docs/router/concepts/advertised-routes), o Cloud Router tem dois modos de anúncio: o padrão (anuncia automaticamente as faixas das sub-redes) e o personalizado (exige a configuração explícita dos prefixos). Se o Cloud Router estiver no modo personalizado sem prefixos configurados, ou se o roteador on-premises não tiver anúncios BGP, nenhum dos lados aprende rotas para alcançar as redes do outro. Uma chave pré-compartilhada do IKE divergente (a opção “A chave pré-compartilhada do IKE está incorreta”) impediria completamente o estabelecimento do túnel. O Cloud NAT (a opção “O Cloud NAT está interferindo no tráfego da VPN”) opera de forma independente do tráfego do plano de dados da VPN. Problemas de MTU (a opção “A MTU do túnel VPN está configurada baixa demais”) causam descarte ou fragmentação de pacotes, não rotas ausentes. Correção: verifique o modo de anúncio do Cloud Router e as exportações BGP on-premises. Ref: cloud.google.com/network-connectivity/docs/router/concepts/advertised-routes.

O IP masquerade (SNAT) no GKE substitui o IP de origem do Pod pelo IP do nó no tráfego de saída. Conforme a documentação (cloud.google.com/kubernetes-engine/docs/concepts/ip-masquerade-agent), isso é necessário quando destinos fora da VPC não têm rotas para a faixa CIDR dos Pods — por exemplo, redes on-premises conectadas via VPN/Interconnect. Sem SNAT, o tráfego de retorno não consegue ser roteado de volta para os IPs dos Pods. O GKE controla o masquerading pelo DaemonSet ip-masq-agent e pela lista nonMasqueradeCIDRs do seu ConfigMap. A flag --disable-default-snat preserva os IPs dos Pods para todos os destinos quando não há um ip-masq-agent presente. O tráfego entre Pods em clusters VPC-native não precisa de SNAT (a VPC tem rotas para os CIDRs dos Pods). O tráfego de Pod para o control plane (a opção “Quando os Pods precisam se comunicar com o control plane do GKE”) e o do Private Google Access (a opção “Quando os Pods precisam acessar as APIs do Google Cloud via Private…”) trafega dentro da rede do Google e não exige masquerading. Ref: cloud.google.com/kubernetes-engine/docs/concepts/ip-masquerade-agent.

Segundo a documentação (cloud.google.com/load-balancing/docs/passthrough-network-load-balancer), os NLBs passthrough entregam os pacotes com os IPs de origem e destino inalterados: 'os pacotes são recebidos pelas VMs de backend com os endereços IP de origem e destino, o protocolo e as portas do pacote inalterados.' O NLB passthrough externo regional (construído sobre o Maglev) oferece suporte a TCP, UDP, ESP, GRE, ICMP e ICMPv6. Ele preserva o IP de origem do cliente de forma nativa via Direct Server Return (DSR). A opção “Global external Application Load Balancer” (Application LB externo global) lida apenas com HTTP(S), não com TCP arbitrário. A opção “Internal passthrough Network Load Balancer” (NLB passthrough interno) atende tráfego interno, não clientes externos. A opção “Regional external proxy Network Load Balancer” (NLB proxy externo regional) encerra as conexões e cria novas até os backends, perdendo o IP de origem original a menos que você use o protocolo PROXY (cabeçalhos exclusivos de HTTP não funcionam para tráfego não HTTP). Ref: cloud.google.com/load-balancing/docs/passthrough-network-load-balancer.