MTR, Path MTU e Detecção de Bloqueios por SNI no iOS sem Entitlements

Em abril, lancei o NetDiag+ na App Store, um conjunto de ferramentas de rede para iOS que inclui ping, traceroute, DNS, whois, e scanner de portas e LAN. O principal diferencial é que todas essas funcionalidades operam sem a necessidade de entitlements privados, utilizando sockets BSD puros através de C-interop. Em maio, compartilhei essa experiência no Habr, onde o artigo obteve boa repercussão e impulsionou as instalações do aplicativo.

Nos meses seguintes, adicionei nove novas ferramentas. Inicialmente, a expectativa era de que fosse um processo simples, apenas encapsulando alguns sockets em SwiftUI. No entanto, cada nova ferramenta apresentou desafios técnicos únicos. Em alguns casos, foi necessário analisar pacotes ICMP brutos; em outros, abordagens aparentemente óbvias falharam em redes reais; e em certas situações, testes TCP indicavam disponibilidade quando, na verdade, o serviço estava inacessível.

Vamos detalhar as implementações mais interessantes:

1. MTR – Traceroute Contínuo sem Lentidão

MTR (My TraceRoute) é uma evolução do traceroute. Em vez de realizar um único trajeto e parar, ele envia sondas continuamente, coletando estatísticas para cada hop: perda de pacotes, RTT mínimo, médio e máximo, e jitter. Profissionais de rede o utilizam para diagnosticar problemas onde a conexão parece lenta, mas o ping indica que está tudo bem – um cenário comum quando há perda de pacotes em hops intermediários, visível apenas em análises dinâmicas.

A primeira versão implementou sondas sequenciais: uma sonda para TTL=1, aguardando a resposta ou timeout, depois TTL=2, e assim por diante. Com 12 hops e alguns roteadores limitando a taxa de pacotes ICMP, um ciclo completo levava de 5 a 7 segundos. Se o usuário definisse um intervalo de 1 segundo, o ciclo de contagem só era atualizado a cada cinco segundos, o que era inaceitável. A solução foi enviar todas as sondas de um ciclo simultaneamente e coletar as respostas em uma única janela. A complexidade reside em associar cada resposta ICMP ao TTL correspondente. Para isso, cada sonda recebe uma porta UDP de destino única (base + ttl + cycle_offset). Quando um roteador retorna um ICMP Time Exceeded, ele anexa os primeiros bytes do pacote original, incluindo o cabeçalho UDP com essa porta. A desmultiplexação é feita com base nesse valor:

swift
/// Extrai a porta de destino interna do cabeçalho UDP embutido em um erro ICMP Time-Exceeded para saber a qual sonda pendente esta resposta se refere.
static func extractInnerDestPort(from data: Data) -> UInt16? {
    let bytes = Array(data)
    let icmpHeader = 8
    guard bytes.count > icmpHeader else { return nil }
    let ihlBytes = Int(bytes[icmpHeader] & 0x0F) * 4   // Comprimento do cabeçalho IP interno
    guard ihlBytes >= 20 else { return nil }
    let innerUDP = icmpHeader + ihlBytes
    guard bytes.count >= innerUDP + 4 else { return nil }
    return (UInt16(bytes[innerUDP + 2]) << 8) | UInt16(bytes[innerUDP + 3])
}

Com essa abordagem, o tempo de ciclo se aproxima do probeTimeout, em vez de ser a soma dos tempos de espera de todos os hops. Outro ponto crucial é a estatística. Calcular o desvio padrão de forma direta (armazenando todos os RTTs e recalculando) para uma ferramenta em execução contínua é inviável devido ao consumo de memória. Para resolver isso, utilizamos o algoritmo online de Welford, que atualiza a média e a variância com complexidade O(1) por amostra e é numericamente estável:

swift
mutating func recordReply(rttMs: Double) {
    recv += 1
    lastMs = rttMs
    bestMs = bestMs.map { min($0, rttMs) } ?? rttMs
    worstMs = worstMs.map { max($0, rttMs) } ?? rttMs
    // Welford: média móvel + M2
    let delta = rttMs - mean
    mean += delta / Double(recv)
    m2 += delta * (rttMs - mean)
}

var stdDevMs: Double? {
    guard recv >= 2 else { return nil }
    return (m2 / Double(recv - 1)).squareRoot()
}

Um desafio adicional foi a interface do usuário. No primeiro ciclo, o comprimento do caminho ainda é desconhecido, então enviamos sondas para todos os 30 TTLs. No entanto, o destino responde com Port Unreachable para cada TTL maior ou igual ao real (o pacote consegue chegar), o que inflava a tabela com 30 linhas de IPs idênticos. A solução foi, após a primeira resposta "final", registrar o TTL mínimo até o destino e truncar o restante.

2. Path MTU Discovery – Por que a Abordagem "Óbvia" Falhou

Path MTU é o tamanho máximo de pacote que pode transitar até o destino sem fragmentação. É um conceito clássico para depurar VPNs e túneis. Se, por exemplo, seu WireGuard limita o MTU para 1420 e uma aplicação envia pacotes de 1500 com o flag DF (Don't Fragment) ativado, esses pacotes são silenciosamente descartados, resultando em uma conexão que "funciona, mas metade dos sites não carrega".

O algoritmo é intuitivo: uma busca binária. Enviamos um pacote com o flag Don't Fragment e um payload crescente, e esperamos por um ICMP "Fragmentation Needed" para identificar o ponto de falha. A primeira versão enviava pacotes UDP para uma porta aleatória alta, esperando um Port Unreachable como sinal de que o pacote havia chegado.

Ao testar contra o servidor 1.1.1.1, obtive um Path MTU de 688 bytes, o que é anômalo para qualquer rede moderna. A razão é que o Cloudflare (e a maioria dos hosts públicos confiáveis) filtra silenciosamente pacotes UDP para portas aleatórias, impedindo que o Port Unreachable seja retornado. O algoritmo interpretava cada timeout como um pacote "muito grande" e convergia para um valor incorreto.

Reescrevi a implementação para usar ICMP Echo com DF. Hosts públicos respondem a pings de forma confiável, tornando o sinal de "chegou" preciso:

swift
let payload = Data(repeating: 0x40, count: size - 28)  // 20 IP + 8 ICMP
let packet = ICMPHeader.echoRequest(identifier: 0, sequence: seq, payload: payload)
icmpSock.setDontFragment(true)
try icmpSock.send(data: packet, to: address)

Quando um roteador retorna Frag-Needed, ele inclui, de acordo com a RFC 1191, o MTU do próximo salto no pacote. Isso permite saltar diretamente para o valor correto, sem precisar de uma busca binária completa:

swift
/// O MTU do próximo salto reside nos bytes [6..7] de um pacote ICMP Frag-Needed (RFC 1191).
static func extractNextHopMTU(from data: Data) -> Int? {
    let bytes = Array(data)
    guard bytes.count >= 8 else { return nil }
    let mtu = (UInt16(bytes[6]) << 8) | UInt16(bytes[7])
    return mtu > 0 ? Int(mtu) : nil
}

Um bônus: com base no valor encontrado, é possível inferir o tipo de conexão. Valores como 1492 indicam PPPoE, 1480 sugere GRE, 1420-1440 são típicos de WireGuard, e 1400 pode ser OpenVPN/IPSec. No aplicativo, isso é exibido como uma dica ("provavelmente PPPoE"), o que ajuda usuários não técnicos a entenderem a origem do valor.

3. Site Reach e Detecção de Bloqueios por SNI

Esta ferramenta verifica a acessibilidade de uma lista de sites populares. A versão inicial era simples: um TCP-connect para a porta 443. Se a conexão fosse bem-sucedida, o site era considerado "acessível". No entanto, essa abordagem não detecta o principal tipo de bloqueio moderno.

Inspeção Profunda de Pacotes (DPI) em níveis nacional ou corporativo frequentemente funciona da seguinte maneira: o handshake TCP é concluído com sucesso. Somente após identificar um hostname proibido no SNI dentro do TLS Client Hello, o DPI injeta um pacote RST. Do ponto de vista do dispositivo, a conexão TCP foi estabelecida, o que significa que uma sonda TCP-only reportaria "acessível", mesmo que o HTTPS não esteja funcionando.

Para capturar isso, é necessário levar o processo até o handshake TLS. Implementei dois tipos de sondas e comparo os resultados:

A sonda TLS utiliza NWConnection com NWProtocolTLS. Essa configuração define automaticamente o SNI com o hostname da conexão, o que, por sua vez, aciona o DPI sensível a SNI. Na interface do usuário, sites com esse tipo de bloqueio recebem um distintivo "SNI" para diferenciá-los da indisponibilidade geral.

As outras seis ferramentas em resumo:

• TLS Inspector: Testa o servidor com todas as versões TLS (1.0 a 1.3) em paralelo (usando TaskGroup, uma NWConnection por versão com pin de protocolo mínimo/máximo). Exibe o cipher negociado e marca versões obsoletas (1.0/1.1) e cifras fracas (RC4, 3DES).
• Encrypted DNS: Resolve um domínio usando DoH e DoT em provedores como Cloudflare, Google, Quad9 e NextDNS. Compara as respostas e a latência. Inclui um codec DNS wire mínimo.
• STUN / NAT: Realiza um Binding Request real (RFC 5389) para vários servidores, analisa o XOR-Mapped-Address e classifica o tipo de NAT (Open, Cone, Symmetric) com base na correspondência dos endereços IP e portas externas. Útil para diagnosticar problemas em chamadas P2P.
• Bonjour browser: Utiliza NWBrowser para descobrir cerca de 20 tipos de serviços mDNS (AirPlay, Chromecast, HomeKit, impressoras), com análise das gravações TXT.
• HTTP/3 (QUIC): Realiza um handshake QUIC real através de NWConnection + NWProtocolQUIC com ALPN "h3" em UDP/443. O URLSession não faz upgrade para QUIC sem cache Alt-Svc, tornando esta a única forma confiável de verificar se a rede permite QUIC.
• IPv6 Check: Exibe endereços IPv6 locais, reconhece túneis (utun → iCloud Private Relay / NAT66), detecta NAT64/DNS64 (RFC 7050) e compara a latência entre IPv4 e IPv6.

O que aprendi:

• Sondas "óbvias" frequentemente enganam. Testes como UDP para porta aleatória (Path MTU) ou TCP-only para disponibilidade (Site Reach) fornecem resultados falsos em redes reais. Apenas trocas de protocolo autênticas, como ICMP Echo com DF ou um handshake TLS completo, oferecem respostas confiáveis.
• Pacotes ICMP/UDP brutos no iOS são mais acessíveis do que parecem. Através de sockets ICMP SOCK_DGRAM sem entitlements, é possível implementar ping, traceroute, MTR e Path MTU. No entanto, acesso a pacotes RAW SYN, ARP ou captura de pacotes ainda é restrito.
• Teste em pelo menos duas redes. Metade dos bugs foram detectados ao rodar os testes em uma rede europeia limpa versus uma rede móvel russa com CGNAT/symmetric NAT. O comportamento era drasticamente diferente, e falsos "bloqueios" surgiram nesses cenários.
• Network.framework é a ferramenta correta para TLS/QUIC. Enquanto para ICMP utilizamos sockets BSD, para TLS Inspector e HTTP/3, NWConnection é mais conveniente. Ele lida com pin de versão TLS, ALPN e handshake QUIC real em UDP/443 nativamente, sem a necessidade de bibliotecas de terceiros.

Todas as ferramentas continuam operando sem entitlements privados e não coletam dados; os resultados permanecem no dispositivo.

NetDiag+ na App Store: https://apps.apple.com/app/id6761954529 (agora com 12 idiomas e 25 ferramentas).

Perguntas e comentários sobre a implementação são bem-vindos nos comentários. Responderei a todos.