Detecção de MTU usando API do ISP.Tools e testes locais em Bash

December 10, 2025

Detectar MTU de ponta a ponta é uma das tarefas mais chatas quando há Path MTU Discovery quebrado. Em muitos cenários o problema só aparece em um dos sentidos e descobrir isso manualmente costuma ser um tormento. Neste artigo você vai montar uma ferramenta em Bash que:

Obtém o IP público local usando ip.isp.tools.
Faz teste de MTU interno usando ping local com DF ativado.
Faz teste de MTU externo usando a API do ISP Tools apontando para seu IP.
Compara os dois resultados para identificar gargalos no caminho de ida e no caminho de volta.

Tudo isso sem precisar instalar nada além de curl e ping.

1. Obtendo o IP público local

O ISP.Tools fornece uma forma simples de descobrir o IP público atual.

Se você usar esse IP como alvo da API, a probe do ISP Tools testa exatamente o caminho de fora para dentro até seu host.

2. Descobrindo MTU local via ping com DF

Montamos uma função de busca binária para encontrar o maior pacote possível sem fragmentação. Isso garante precisão e evita gastar tempo demais testando tamanho por tamanho.

      detect_local_mtu() {
    TARGET="$1"
    LOW=576
    HIGH=2000

    while [ $LOW -lt $HIGH ]; do
        MID=$(( (LOW + HIGH + 1) / 2 ))
        if ping -c1 -W1 -M do -s $((MID - 28)) "$TARGET" >/dev/null 2>&1; then
            LOW=$MID
        else
            HIGH=$((MID - 1))
        fi
    done

    echo "$LOW"
}

Essa função retorna o MTU máximo (tamanho total do pacote IP). O ping precisa do tamanho payload, que é MTU – 28.

3. Usando a API de MTU do ISP Tools para medir o caminho inverso

O endpoint da API segue o padrão:

O retorno real tem esse formato:

Ou seja, o campo de interesse é:

Para extrair:

Se quiser ver rapidamente todos os testes feitos:

Isso ajuda a entender exatamente onde ocorre a quebra.

4. Script completo de detecção MTU ida e volta

Aqui está a ferramenta final revisada e funcional.

      #!/bin/bash

API_KEY="SUA_CHAVE"
PROBE="291"

detect_local_mtu() {
    TARGET="$1"
    LOW=576
    HIGH=2000

    while [ $LOW -lt $HIGH ]; do
        MID=$(( (LOW + HIGH + 1) / 2 ))
        if ping -c1 -W1 -M do -s $((MID - 28)) "$TARGET" >/dev/null 2>&1; then
            LOW=$MID
        else
            HIGH=$((MID - 1))
        fi
    done

    echo "$LOW"
}

echo "Consultando IP público atual"
LOCAL_IP=$(curl -s https://ip.isp.tools)
echo "IP detectado $LOCAL_IP"

echo "Testando MTU local na saída"
LOCAL_MTU=$(detect_local_mtu 8.8.8.8)
echo "MTU local de saída $LOCAL_MTU"

echo "Testando MTU externo na volta"
RES=$(curl -s \
  --request GET \
  --url "https://isp-tools.p.rapidapi.com/mtu/${PROBE}/${LOCAL_IP}" \
  --header "x-rapidapi-host: isp-tools.p.rapidapi.com" \
  --header "x-rapidapi-key: ${API_KEY}")

REMOTE_MTU=$(echo "$RES" | jq '.data.discoveredMTU')
echo "MTU externo de retorno $REMOTE_MTU"

if [ "$LOCAL_MTU" -ne "$REMOTE_MTU" ]; then
    echo "Diferença entre MTU de ida e volta"
    echo "Provável problema de Path MTU Discovery em algum trecho da rota"
else
    echo "MTU consistente nos dois sentidos"
fi

5. Como interpretar os dados de testes retornados pela API

O campo tests vem assim:

Use isso para analisar onde exatamente o caminho externo falha. O tamanho máximo onde success é true corresponde ao MTU efetivo no sentido externo.

Para visualizar rapidamente:

Isso cria uma tabela bem útil para ver onde ocorre a quebra.

6. Casos típicos de falha

MTU menor na saída
Firewall local filtrando ICMP, PPPoE, tunelamento interno, VLANs antigas com overhead.

MTU menor na entrada
Rota de retorno passando por algum backbone com FIB quebrada ou ICMP bloqueado. Muito comum quando o upstream não respeita PMTU Discovery.

MTU baixo nos dois sentidos
Fortes indícios de encapsulamento como GRE, VXLAN, L2TP, CGNAT de um dos lados ou múltiplos túneis empilhados.