NetCatTest

Anonimato & OPSEC

GRE e VXLAN no Wireshark: protocolo dentro de protocolo

Leia HTTP dentro de GRE e DNS IPv6 dentro de VXLAN. Compare camadas internas e externas, VNIs e campos repetidos em um laboratório reproduzível.

Por Daniel Felipe 8 min leitura

Um protocolo dentro de outro muda o que cada coluna do Wireshark parece representar. Em GRE e VXLAN, o pacote pode transportar outra rede inteira. O IP exibido no resumo pode pertencer ao túnel, enquanto o serviço investigado usa um endereço interno. O mesmo campo pode existir mais de uma vez dentro do frame.

O laboratório NetCatTest contém 43 pacotes: uma conversa HTTP sobre GRE e 32 mensagens DNS sobre VXLAN. A segunda usa IPv4 no transporte externo e IPv6 na rede interna. Os arquivos foram criados offline, com endereços de documentação, e lidos no Wireshark 4.6.9 real. Não houve captura ou alteração da rede pessoal.

O mapa das duas pilhas

Ethernet → IPv4 externo → GRE → IPv4 interno → TCP → HTTP
Ethernet → IPv4 externo → UDP → VXLAN → Ethernet interno → IPv6 → UDP → DNS

Abra 21-gre-vxlan.pcap. Na primeira parte, os endpoints externos são 198.51.100.1 e 198.51.100.2. Os endpoints HTTP internos são 192.0.2.10 e 192.0.2.20. Na parte VXLAN, os endpoints externos são 203.0.113.1 e 203.0.113.2, enquanto o DNS interno usa 2001:db8:42::10 e 2001:db8:42::53.

CamadaGREVXLAN
Transporte externoIPv4, protocolo 47IPv4 e UDP/4789
Identificação no exercícioPar externo e conversa internaVNI 4200 ou 4201
Conteúdo internoIPv4/TCP/HTTPEthernet/IPv6/UDP/DNS
Primeiro frame de aplicação412

GRE: o túnel não é a sessão HTTP

O frame 4 contém GET /inventario. Expanda primeiro o IPv4 externo, depois GRE e o segundo IPv4. Confirme os endereços em cada camada antes de procurar o TCP. A árvore expõe duas identidades de origem e destino: uma para o caminho do túnel, outra para o serviço.

gre
gre && http
gre && tcp.port == 80
http.request.uri == "/inventario"

O filtro que combina GRE e HTTP retorna dois frames: a request e a response. O servidor interno devolve JSON fictício de inventário. A resposta informa um ambiente de laboratório e três equipamentos, não um inventário real do computador.

Wireshark real mostrando IPv4 externo, GRE, IPv4 interno, TCP e HTTP no mesmo frame de laboratório

O frame 4 transporta HTTP dentro de GRE. Endereços externos e internos pertencem a papéis diferentes na investigação.

A RFC 2784 descreve o encapsulamento GRE. Neste exercício, GRE não fornece criptografia ou autenticação do conteúdo. Observar um túnel não permite concluir que a comunicação é privada; isso depende de proteções adicionais e da arquitetura.

VXLAN: separar VTEP, VNI e host interno

Os VTEPs externos transportam quadros Ethernet de duas redes virtuais. O VNI 4200 e o VNI 4201 têm 16 pacotes cada: oito consultas DNS e oito respostas. O conjunto reutiliza os mesmos endereços internos nos dois segmentos para demonstrar por que o VNI precisa entrar na chave de agrupamento.

Se uma ferramenta agrupar apenas pelo endereço IPv6 interno, misturará as duas redes virtuais. Se agrupar apenas pelos VTEPs, perderá a distinção entre segmentos. Uma identidade mais útil para essa captura inclui VNI, endereço interno, protocolo e porta interna.

vxlan
vxlan.vni == 4200
vxlan.vni == 4201
vxlan && dns
vxlan && ipv6.addr == 2001:db8:42::53

Wireshark real detalhando VXLAN VNI 4200 com quadro Ethernet, IPv6 e consulta DNS internos

No frame 12, o cabeçalho VXLAN identifica o segmento 4200. A consulta DNS pertence à rede interna IPv6.

A RFC 7348 contextualiza VXLAN e o VNI. A porta externa 4789 ajuda a localizar o tráfego deste laboratório, mas o reconhecimento do protocolo deve ser confirmado pela estrutura. Uma porta, isoladamente, não comprova que o payload é válido.

Campos repetidos: um filtro pode encontrar a camada errada

No GRE há dois cabeçalhos IPv4. No VXLAN há dois cabeçalhos UDP, com funções diferentes. Um teste genérico de porta pode corresponder ao transporte externo ou ao serviço interno. Antes de transformar um filtro em regra de detecção, verifique a árvore do frame que passou.

Para extrair a multiplicidade, use TShark com todas as ocorrências. A saída mantém os valores em vez de escolher silenciosamente apenas o primeiro. Em ferramentas que importam CSV ou JSON, confira se listas foram preservadas.

tshark -n -r 21-gre-vxlan.pcap -Y gre -T fields -E occurrence=a -E aggregator=, -e frame.number -e ip.src -e ip.dst -e tcp.port
tshark -n -r 21-gre-vxlan.pcap -Y vxlan -T fields -E occurrence=a -E aggregator=, -e frame.number -e vxlan.vni -e ip.src -e ipv6.src -e udp.srcport -e udp.dstport

Essas extrações ajudam a construir uma tabela com camada externa e interna explícitas. A documentação do TShark explica as opções de campos. A escolha de nomes claros para cada coluna deve acompanhar a exportação.

MTU: calcular a sobrecarga do caminho observado

O VXLAN deste exercício acrescenta IPv4 externo, UDP, VXLAN e Ethernet interno. Esses cabeçalhos consomem espaço além do pacote IP interno. A conta exata depende das camadas realmente presentes, de opções e de tags como VLAN. Não copie um valor de sobrecarga sem conferir o frame.

Nos nossos pacotes, não há VLAN adicional e as mensagens são pequenas. Portanto, o arquivo demonstra a composição, mas não mede um problema real de MTU. Para investigar um incidente operacional, compare tamanhos próximos ao limite, ICMP de erro, retransmissões e a configuração de MTU dos endpoints do túnel.

Uma falha seletiva em mensagens maiores pode ter relação com encapsulamento, mas também pode resultar de perda, policer ou servidor. O primeiro passo é identificar em qual camada o tamanho foi medido e se a fragmentação ocorreu antes ou depois do encapsulamento.

O que um sensor enxerga depende de onde está

Um sensor fora do túnel pode ver VTEPs e volumes. Um sensor depois da decapsulação pode ver hosts internos e serviços. Se o sensor externo decodificar o túnel, as duas perspectivas aparecem no mesmo arquivo, como neste laboratório.

Essa diferença afeta atribuição e cobertura. Dizer que o IP externo fez uma consulta DNS pode ser um atalho impreciso: ele transportou o quadro de um cliente interno. Registre ambos quando o caso exige rastrear o caminho de uma ação. Em ambientes compartilhados, inclua também o contexto do segmento virtual.

Encapsulamento legítimo e canal indevido

GRE e VXLAN são mecanismos comuns de infraestrutura. Sua presença não indica, por si só, evasão ou exfiltração. Uma hipótese de uso indevido depende da autorização do túnel, das rotas, dos endpoints e do conteúdo transportado.

O nosso exercício usa túneis declarados e hosts fictícios. Não implementa um canal clandestino nem demonstra bypass de controles. A análise defensável descreve encapsulamento, identidade das camadas e limites da observação. Se surgir um endpoint externo desconhecido em produção, a próxima ação é confrontá-lo com o inventário e a política de rede.

Reassembly e análise do conteúdo interno

Depois de selecionar o HTTP interno, acompanhe a conversa TCP e confira a request e a response completas. O JSON devolvido pertence ao serviço interno, não ao VTEP. A leitura do conteúdo continua dependendo de reassembly correto e de visibilidade dos dois sentidos.

Na parte DNS, selecione os frames 12 e 13 para comparar pergunta e resposta no VNI 4200. Depois filtre 4201 e observe nomes com o segundo identificador de segmento. A diferença deliberada entre nomes permite confirmar que o agrupamento por VNI funcionou.

Validar uma tabela de ativos sem fundir redes

Monte primeiro um inventário agrupado apenas pelo IPv6 interno. Em seguida, refaça a mesma tabela incluindo VNI. A segunda versão deve manter separados os nomes de segmento 4200 e 4201, apesar dos endereços internos reutilizados. O exercício permite enxergar um erro comum de integração: campos tecnicamente corretos, mas uma identidade de ativo incompleta.

Repita o teste com o GRE. Se a tabela de serviços atribuir HTTP exclusivamente a 198.51.100.1, confira se ela leu apenas o IP externo. O serviço demonstrado pertence ao endereço interno. Em casos reais, a atribuição precisa preservar também o vínculo com o túnel para que outra pessoa consiga localizar o caminho observado.

A saída esperada não é uma lista universal de ativos, mas um modelo de proveniência: frame, encapsulamento, segmento e endpoint interno. Esse modelo pode alimentar um mapa de relações sem apagar a hierarquia. Quando a captura não tiver o conteúdo interno, mantenha o campo desconhecido em vez de inventar o serviço a partir do transporte externo.

Um relatório que mantém a hierarquia

  1. Liste as camadas externas e internas na ordem encontrada.
  2. Registre endereços e portas com o papel de cada camada.
  3. Inclua VNI ou outro identificador de segmentação quando houver.
  4. Documente múltiplas ocorrências dos campos exportados.
  5. Descreva onde o sensor estaria posicionado em uma rede real.
  6. Separe transporte do túnel, ação da aplicação e hipótese de segurança.

O pacote de laboratórios inclui o arquivo e o manifesto de validação. Este método também ajuda em outros encapsulamentos: começar pela pilha completa evita atribuir ao equipamento de transporte uma ação executada por um serviço que viaja dentro dele.

Escrito por

Daniel Felipe é criador do NetCatTest e produz conteúdos sobre cibersegurança, privacidade digital, OSINT, laboratórios autorizados e ferramentas para estudo técnico responsável.

Compartilhar

Enviar este artigo