Solucionar problemas de conectividade na VPC

Um servidor de aplicação em uma sub-rede privada não consegue abrir conexão com uma instância RDS na mesma VPC. O banco está no ar, as credenciais não mudaram e a conexão simplesmente estoura o tempo. Você tem 4 suspeitos e nenhuma evidência: um security group, uma network ACL, uma route table e a possibilidade de o banco nem estar escutando.

A maioria dos engenheiros começa clicando pelo console na ordem em que as abas aparecem. Isso funciona, com o tempo. Também queima os primeiros 20 minutos da queda em componentes que nunca estiveram envolvidos. A habilidade desta lição não é decorar mais serviços. É percorrer o caminho na ordem em que um pacote o percorre, para que a primeira coisa errada que você achar seja de fato a coisa que quebrou.

O caminho tem uma ordem, siga ela

Um pacote que sai de uma instância EC2 atravessa uma sequência fixa de portões. Cada um deles pode negar o pacote, e toda negativa parece idêntica do lado da aplicação: um timeout. Então trabalhe a sequência, não a intuição.

1. Security group de origem, saída. Existe uma regra de egress que permita o endereço e a porta de destino? Grupos padrão permitem toda a saída, então esse é suspeito apenas em ambiente fechado. Quando é a causa, foi porque alguém substituiu a regra de saída padrão e esqueceu uma porta.
2. Network ACL da sub-rede de origem, saída. Existe uma regra de saída que permita a requisição, e uma de entrada que permita a resposta nas portas efêmeras? Network ACLs são stateless, então as 2 direções são perguntas separadas.
3. Route table de origem. Existe uma rota cujo CIDR de destino contenha o endereço alvo, e o target dessa rota existe e funciona? Sem rota, o pacote morre antes de qualquer firewall ser consultado.
4. O intermediário. NAT gateway, internet gateway, VPC endpoint, conexão de peering ou transit gateway. Cada um tem os próprios modos de falha, e cada um apareceu nos tópicos anteriores deste domínio.
5. Network ACL da sub-rede de destino, entrada. O mesmo par stateless de perguntas, agora do outro lado.
6. Security group de destino, entrada. Existe uma regra de ingress que permita a origem, seja por CIDR seja referenciando o security group da origem?
7. A política do recurso. Uma endpoint policy, uma bucket policy do S3 ou uma política do lado do serviço pode recusar uma requisição cujos pacotes chegaram perfeitamente. Essa produz um erro em vez de um timeout, o que já é um sinal útil.

Depois percorra o caminho de volta. Parece formalidade até você encontrar a falha que isso pega: a requisição é aceita, o destino responde, e a resposta é negada por uma regra de saída de network ACL em que ninguém pensou, porque a aplicação só inicia conexão em uma direção.

Essa ordem paga porque cada portão esconde os que vêm depois dele. Se a route table não tem rota que case, o security group da ponta final pode estar escancarado ou fechado e você nunca saberia. Conferir na ordem do caminho significa que a primeira negativa encontrada é a que importa, e tudo depois dela é ruído.

Leia o sintoma antes de ler a configuração

Três das falhas acima produzem sintomas distinguíveis, se você olhar para a coisa certa.

A segunda linha merece uma frase própria, porque ela salva investigações inteiras. Um erro de "conexão recusada" significa que a rede funcionou. O SYN chegou ao host, o host não tinha nada escutando naquela porta e respondeu com honestidade. Nenhum security group produz esse erro, porque negativa de security group produz silêncio. Quando uma aplicação registra conexão recusada, pare de olhar a VPC e vá ver se o processo está rodando e escutando no endereço que você imagina.

O Reachability Analyzer lê o caminho inteiro por você

Percorrer 7 portões na mão, entre 2 contas, leva tempo real. O Reachability Analyzer faz isso em uma chamada.

O que mais importa entender sobre ele é onde ele olha. Ele monta um modelo da sua configuração de rede e raciocina sobre esse modelo. Ele não envia pacotes e não toca no data plane. Então ele consegue dizer que um security group descartaria esse tráfego, e consegue mostrar o caminho salto a salto que um pacote permitido tomaria, sem que exista tráfego nenhum. É por isso que ele funciona em um recurso completamente quebrado, e por isso funciona antes de você subir qualquer coisa de verdade.

Você define um path: uma origem, um destino e, se quiser, um protocolo, uma porta de destino e componentes intermediários a incluir ou excluir. Depois roda uma análise sobre esse path. As origens e destinos aceitos são instâncias EC2, internet gateways, network interfaces, transit gateways, attachments de transit gateway, virtual private gateways, VPC endpoint services, VPC endpoints e conexões de peering, além de um endereço IP puro como destino.

# 1. Defina o path uma vez
aws ec2 create-network-insights-path \
  --source i-0a1b2c3d4e5f67890 \
  --destination i-09876fedcba543210 \
  --destination-port 3306 \
  --protocol tcp

# 2. Rode uma analise contra ele quantas vezes quiser
aws ec2 start-network-insights-analysis \
  --network-insights-path-id nip-0abc123def456789a

# 3. Leia o veredito e as explicacoes
aws ec2 describe-network-insights-analyses \
  --network-insights-analysis-ids nia-0abc123def456789a \
  --query 'NetworkInsightsAnalyses[0].[NetworkPathFound,Explanations]'

Três fatos operacionais valem a pena carregar:

• A cobrança é por análise executada, não por path, então o objeto path é de graça para manter e reexecutar depois de cada mudança. É isso que o torna útil como teste de regressão e não só como ferramenta de incidente.
• Origem e destino precisam estar na mesma região, e na mesma VPC ou em VPCs ligadas por peering ou transit gateway. Podem estar em contas diferentes da mesma organização do AWS Organizations se você habilitar o acesso confiável.
• Análises são apagadas automaticamente 120 dias depois de criadas. Se um resultado é evidência para auditoria, exporte.

Os explanation codes nomeiam o componente culpado

Quando um caminho não é alcançável, a análise devolve um ou mais explanation codes. Você não precisa decorar a lista inteira, mas reconhecer as famílias transforma uma parede de saída em um diagnóstico de uma linha.

Dois desses codes ensinam algo além da própria mensagem. MORE_SPECIFIC_ROUTE é a lição de roteamento reescrita como diagnóstico: a sua rota está lá, correta, e mesmo assim inútil, porque algo mais longo casou primeiro. E TGW_ATTACH_MISSING_TGW_RTB_ASSOCIATION é a distinção entre association e propagation da lição de transit gateway aparecendo como falha concreta, já que um attachment que propaga rotas mas não está associado a nada não tem route table para consultar.

Onde o modelo termina e os pacotes começam

O Reachability Analyzer é um verificador de configuração, então ele é cego para tudo que não é configuração. Conhecer os pontos cegos é o que impede um resultado verde de te enganar.

• Ele não considera a saúde dos targets registrados. Um load balancer com todos os targets reprovando no health check ainda vai ser analisado como alcançável.
• Ele só cobre IPv4. Se um recurso tem as 2 famílias de endereço, apenas o lado IPv4 entra na análise. Uma falha exclusiva de IPv6 aparece como NO_PATH.
• Ele não enxerga DNS. Se a sua aplicação resolve um nome para o endereço errado, o caminho até o endereço certo continua perfeitamente alcançável.
• Ele para em attachments Connect de transit gateway, e caminhos que passam por um endpoint de Gateway Load Balancer excluem o Gateway Load Balancer e os targets dele, que precisam de análise própria.
• O suporte a Network Firewall é parcial. Ele lida com regras stateful e stateless de 5-tupla, mas não com listas de domínio, regras Suricata, rule options nem grupos de recursos por tag, e ele avisa isso nos detalhes do path quando encontra uma.
• Ele não diz nada sobre a aplicação. Um processo escutando, um handshake TLS, um banco que recusa as credenciais: tudo fora do modelo.

A regra honesta então é: o Reachability Analyzer prova que o caminho é permitido, não que a chamada vai dar certo. Quando ele diz não alcançável, você tem a resposta e pode parar. Quando ele diz alcançável e a aplicação continua falhando, você também aprendeu algo valioso, que é que o problema está acima da camada de rede, e os logs da próxima lição são o lugar para onde ir.

As falhas que não são falhas de rede

Quatro causas respondem por boa parte dos chamados que chegam rotulados como "conectividade da VPC" e nunca encostam em um security group.

DNS resolvendo para a coisa errada. Uma private hosted zone precisa de enableDnsSupport e enableDnsHostnames na VPC para ser usável, e um interface endpoint com private DNS desabilitado deixa o nome público do serviço resolvendo para um endereço público que uma sub-rede privada não alcança. A conexão falha na camada de rede, mas a correção é uma configuração de DNS.

Path MTU. Uma conexão que abre limpa e trava assim que uma carga grande começa quase nunca é problema de permissão. Handshakes são pequenos e cabem em qualquer lugar. Túneis reduzem o tamanho útil do pacote, e se um firewall descarta as mensagens ICMP de fragmentação necessária, o path MTU discovery não consegue avisar o remetente para mandar pacotes menores, e a transferência simplesmente trava. Verifique MTU antes de verificar regras sempre que o sintoma depender do tamanho.

Source/destination check. Qualquer instância que encaminha tráfego em nome de outros, como uma NAT instance ou um appliance, precisa disso desligado. Ligado, a interface descarta os pacotes encaminhados e todo o roteamento continua parecendo correto.

Portas efêmeras em uma network ACL stateless. Coberto por inteiro na lição de security groups, e reaparece aqui porque é o motivo mais comum de uma network ACL permitir a requisição e matar a resposta. Se o tráfego é de saída e as regras de entrada da network ACL não liberam 1024 a 65535 de volta, nada funciona e cada regra parece razoável.

Dicas de prova

• Percurso ordenado, sempre. Security group de origem, network ACL de origem, route table, intermediário, network ACL de destino, security group de destino, política do recurso, e depois o caminho de volta. Questões de cenário são montadas quebrando exatamente um desses.
• "Conexão recusada" não é problema de rede. Timeout significa descartado, recusado significa entregue. Uma questão que diz que o cliente recebeu recusa imediata está apontando para o serviço, não para a VPC.
• O Reachability Analyzer analisa configuração, não pacotes. Quando a questão pergunta como achar o componente que bloqueia sem gerar tráfego e sem mudar nada, a resposta é ele. Quando pergunta o que aconteceu de fato com tráfego real, são os flow logs.
• O Reachability Analyzer é só IPv4, mesma região, e ignora a saúde dos targets. Essas 3 restrições são o que a prova mais provavelmente cobra sobre ele.
• MORE_SPECIFIC_ROUTE e NO_ROUTE_TO_DESTINATION são roteamento; SUBNET_ACL_RESTRICTION é network ACL; ENI_SG_RULES_MISMATCH é security group. Conseguir mapear code para componente já basta.
• CIDRs sobrepostos não podem ficar em peering, porque a rota local sempre vence dentro do CIDR da própria VPC e não pode ser sobrescrita.
• Appliance encaminhando mais pacotes sumindo em silêncio é igual a source/destination check.
• Trava só em transferências grandes é igual a MTU, não a firewall.

O hábito para levar desta lição é menor que a lista de ferramentas: quando uma conexão falha, nomeie o primeiro portão do caminho que você ainda não verificou, e verifique esse. O Reachability Analyzer é como você faz esse percurso em uma chamada em vez de 7. O que ele não conta é o que aconteceu de fato com o tráfego real na terça passada às 03:00, e é para isso que servem os logs da próxima lição.