Por que o tcpdump mostra texto simples do IPsec apenas numa direção
Esta assimetria é um artefacto do ponto de captura, não um caminho de resposta quebrado. Aqui está onde procurar o tráfego interno e externo num gateway IPsec Linux.
Executa o tcpdump na interface externa de um gateway IPsec Linux e vê duas coisas ao mesmo tempo: tramas ESP de entrada e, imediatamente depois, os pacotes internos decifrados. Na saída aparece apenas ESP. A conclusão natural é que as respostas não são enviadas ou que o IPsec cifra uma direção e esquece a outra. Nenhuma das duas é verdadeira.
O que está a ver é um ponto de captura. O kernel transforma os pacotes de saída antes de o caminho de transmissão do dispositivo os entregar ao socket de pacotes, pelo que o socket nunca vê a forma interna a sair. Na entrada, o pacote é capturado primeiro como ESP e a cópia desencapsulada torna-se visível quando volta a entrar na pilha. O mesmo tráfego, duas janelas de observação diferentes.
O ponto de captura decide o que vê
Numa interface normal, um socket AF_PACKET fica perto da camada do dispositivo. Os pacotes que saem do anfitrião passam primeiro pelo processamento de saída do IPsec, que transforma um segmento TCP interno num datagrama ESP ou UDP-4500, e só depois chegam a essa camada. Os pacotes que chegam são copiados para o socket à medida que saem do cabo, ainda cifrados, e o resultado decifrado torna-se visível mais tarde, quando a pilha o entrega localmente ou o reencaminha.
Essa ordem explica a assimetria por completo. Não é prova sobre direção, política ou comportamento da aplicação, e tratá-la como tal leva as pessoas a perseguir uma resposta que foi sempre enviada corretamente. É um dos poucos enigmas de rede em que o instrumento, e não a rede, cria a anomalia.
Faça corresponder o filtro à camada pretendida
Uma expressão como tcp port 443 seleciona uma ligação TCP interna. Na saída, essa ligação já se tornou ESP quando o socket é consultado, pelo que o filtro não corresponde a nada. Se quiser contar tráfego protegido, filtre pela forma externa: protocolo 50 para ESP em bruto ou porta UDP 4500 quando há travessia de NAT. Ambos os filtros produzem uma contagem de pacotes comparável entre os dois pares, que costuma ser o motivo para contar. Nenhum deles lhe diz se o pedido interno recebeu resposta.
Não trate uma contagem UDP 4500 como contagem de pacotes ESP. O IKE também usa essa porta para mensagens de manutenção NAT-T e para a troca encapsulada, pelo que o número inclui tráfego que não são os dados que queria medir. A troca IKE inicial na UDP 500 precisa do seu próprio filtro se for essa a pergunta. Um número que mistura tráfego de controlo com dados também torna qualquer estimativa de largura de banda errada numa margem desconhecida. Contagens separadas respondem a perguntas separadas.
Escreva o filtro ao lado da pergunta a que responde. «Quanto ESP saiu da caixa» e «o pedido web saiu da caixa» são medições diferentes com filtros diferentes, e uma única captura não resolve ambas. Sem essa nota, duas pessoas vão comparar números que nunca contavam a mesma coisa.
Observe antes da transformação, não depois
Se precisar de ver o texto simples de saída, mova o ponto de observação mais para trás, antes do processamento de saída do IPsec. O NFLOG dá-lhe um gancho Netfilter onde uma regra pode copiar pacotes selecionados para um socket em espaço de utilizador, que o tcpdump consegue ler. O guia de descarga de tráfego do strongSwan documenta esta abordagem exatamente por esse motivo.
A correspondência de política limita a regra ao tráfego que está prestes a entrar num túnel. -m policy --pol ipsec --dir out é o que torna a regra específica em vez de registar cada pacote que a caixa envia. Depois leia o grupo de registo com uma captura limitada: um pequeno número de instantâneos e um limite de tamanho impedem que o diagnóstico se torne um arquivo de tráfego. Uma captura limitada também é mais fácil de entregar a um revisor sem arrastar carga irrelevante. Decida o número antes de começar, não depois de ver quanto chegou.
iptables -I OUTPUT 1 -d 10.83.0.44/32 -p tcp --dport 8443 -m policy --pol ipsec --dir out -j NFLOG --nflog-group 5
tcpdump -ni nflog:5 -s 128 -c 20 'host 10.83.0.44 and tcp port 8443'Escolha o gancho adequado ao fluxo. OUTPUT cobre o tráfego que o próprio gateway gera; o trânsito de um cliente LAN passa pela cadeia FORWARD e uma regra em OUTPUT nunca o verá. O endereço e a porta acima são marcadores de posição para um destino de teste aprovado.
O que a observação prova
O NFLOG é um destino de registo, não uma decisão de aceitação. Um pacote que aparece ali mostra que chegou ao gancho e correspondia à regra. Não mostra que um filtro posterior o permitiu, que o dispositivo o transmitiu ou que o par recebeu algo.
Um registo vazio é igualmente ambíguo. Verifique o contador de pacotes da regra, confirme a direção, confirme que o fluxo correspondia mesmo a uma política IPsec e confirme o destino. Só um contador coincidente nos dois pares transforma uma observação em conclusão. Depois compare os contadores da associação de segurança nos dois pares para a mesma tentativa controlada, porque os contadores SA são o registo autoritativo do que foi protegido e enviado.
Mais uma armadilha: «texto simples» neste contexto significa fora da camada de cifra do IPsec. Uma sessão HTTPS interna continua a ter o seu próprio TLS. Capturar o pacote desencapsulado não decifra o TLS da aplicação, e ver HTTP legível ali significa que a aplicação nunca usava HTTPS.
Limpe e compare as duas pontas
Remova a regra exata que inseriu, pelo seu proprietário, assim que a observação terminar. Deixar uma regra de registo no lugar custa CPU em cada pacote correspondente e cria discretamente um problema de retenção de dados. Elimine repetindo a regra com -D em vez de esvaziar uma cadeia que não lhe pertence.
iptables -D OUTPUT -d 10.83.0.44/32 -p tcp --dport 8443 -m policy --pol ipsec --dir out -j NFLOG --nflog-group 5Se a implementação usar IPsec em espaço de utilizador, uma interface XFRM ou descarga por hardware, os pontos de observação deslocam-se e esta receita pode não se aplicar de todo. Com o libipsec, o local documentado para observar o tráfego interno é o dispositivo TUN. Identifique primeiro o caminho, depois escolha o ponto que responde à pergunta, e espere que as duas direções só pareçam diferentes quando olha para o lado errado da transformação.