Skip to main content

MTU, VPN e Fragmentação — Análise Técnica Aplicada ao Caso MongoDB (HTB) | Redes

  • MTU, VPN e Fragmentação — Análise Técnica Aplicada ao Caso MongoDB (HTB) | Redes

Contexto do Problema​

Durante a exploração da máquina Mongod da Hack The Box, observou-se o seguinte comportamento:

  • nmap detectava a porta 27017 aberta
  • Script mongodb-databases funcionava
  • ping respondia normalmente
  • mongosh travava indefinidamente em Connecting to:

Após ajuste manual do MTU para 1350, a conexão passou a funcionar corretamente.

Este documento explica tecnicamente por que isso ocorreu.

O que é MTU​

MTU (Maximum Transmission Unit) define o tamanho máximo, em bytes, que um pacote pode ter antes de precisar ser fragmentado.

Valor padrão Ethernet:

1500 bytes

Se um pacote ultrapassa esse valor:

  • Ele é fragmentado
  • Ou descartado se o bit DF (Don't Fragment) estiver ativo

Encapsulamento de VPN e Overhead​

Quando utilizamos OpenVPN (como no HTB), o tráfego é encapsulado.

Representação simplificada:

Pacote TCP original
    ↓
Encapsulado dentro de pacote OpenVPN
    ↓
Encapsulado dentro de UDP/IP
    ↓
Transmitido na interface física

Cada camada adiciona overhead:

  • Header IP (~20 bytes)
  • Header TCP (~20 bytes)
  • Header UDP (~8 bytes)
  • Header OpenVPN (~40–60 bytes)
  • Overhead criptográfico

Isso reduz o MTU efetivo do caminho.

Se a interface está configurada para 1500 bytes, mas o caminho real suporta menos, ocorre fragmentação.

Por que o Ping Funcionava​

O comando:

ping 10.129.3.48

Envia pacotes ICMP pequenos (~64 bytes).

Isso não testa o limite real de MTU.

Portanto:

✔ ICMP funcionava ✖ Sessão TCP complexa falhava

Ping não valida conectividade de aplicação.

O Sintoma Clássico de MTU Incorreto​

O comportamento observado:

  • TCP SYN enviado
  • SYN/ACK recebido
  • Handshake inicial começa
  • Pacotes maiores são descartados
  • Conexão fica travada

O mongosh realiza handshake binário maior do que um simples SYN.

Quando os pacotes excedem o MTU real do caminho:

  • O roteador deveria enviar ICMP Fragmentation Needed
  • Se ICMP estiver bloqueado → cliente nunca ajusta
  • Ocorre blackhole MTU

Teste de Path MTU Discovery​

Para validar:

ping -M do -s 1472 10.129.3.48

Explicação:

  • 1472 bytes payload
    • 28 bytes header IP/ICMP
  • Total = 1500 bytes

Se retornar:

Frag needed and DF set

Significa que o caminho não suporta 1500 bytes reais.

Por que Reduzir para 1350 Resolveu​

Comando aplicado:

sudo ip link set dev eth0 mtu 1350
sudo ip link set dev tun0 mtu 1350

Agora:

1350 + overhead VPN < 1500 físico

Sem fragmentação.

Sem descarte silencioso.

Handshake TCP completo.

Conexão MongoDB estabelecida.

Relação com WSL2​

No ambiente analisado:

WSL2
↓
NAT Windows
↓
OpenVPN
↓
Interface física

Cada camada pode:

  • Alterar MTU
  • Bloquear ICMP Fragmentation Needed
  • Impedir ajuste automático via PMTUD

Isso cria cenário típico de blackhole MTU.

Esse problema é recorrente em:

  • WSL2
  • VPN corporativa
  • Ambientes cloud
  • CTFs como HTB

Diferença entre MTU e MSS​

MTU​

Tamanho máximo do pacote IP completo.

MSS (Maximum Segment Size)​

Tamanho máximo do payload TCP.

Relação:

MSS = MTU - 40 bytes (IP + TCP header)

Exemplo:

MTU 1500 → MSS 1460
MTU 1350 → MSS 1310

Se MSS estiver maior que o suportado pelo caminho, ocorre fragmentação.

Diagnóstico Mental para Pentest​

Se observar:

  • Ping OK
  • Nmap OK
  • Porta aberta
  • Aplicação trava em handshake

Suspeite imediatamente de:

MTU / Fragmentação / VPN encapsulation

Antes de investigar:

  • TLS
  • Autenticação
  • Versão de software

Configuração Permanente no OpenVPN​

Para evitar ajustes manuais:

mssfix 1300
tun-mtu 1400

Adicionar ao arquivo .ovpn.

Fluxo Visual do Problema​

[ mongosh ] 
     ↓
TCP handshake inicia
     ↓
Pacote > MTU real
     ↓
Descartado silenciosamente
     ↓
Conexão trava em "Connecting to:"

Após ajuste:

[ mongosh ]
     ↓
Pacote dentro do limite
     ↓
Handshake completo
     ↓
Shell conectado

Aplicação Direta ao Caso MongoDB​

No laboratório:

  • MongoDB 3.6 estava funcional
  • Porta 27017 acessível
  • Autenticação desabilitada
  • Problema era exclusivamente de rede

Após ajuste de MTU:

./mongosh mongodb://10.129.3.48:27017

Conexão estabelecida com sucesso.