2026-06-02

Análise de buraco negro de MTU e fragmentação PCAP: encontrando falhas de PMTUD, problemas de MSS e TCP paralisado

Como diagnosticar buracos negros de MTU, falha de descoberta de caminho de MTU, incompatibilidade de TCP MSS, fragmentação, mensagens bloqueadas por ICMP, túneis VPN e conexões paralisadas em capturas de pacotes.

Os problemas de MTU criam algumas das falhas de rede mais confusas. Pequenos pedidos funcionam. Pings podem funcionar. DNS pode funcionar. TCP se conecta. O TLS pode começar. Em seguida, respostas grandes param, uploads são interrompidos, sites carregam parcialmente, o tráfego de VPN é interrompido ou fluxos RTSP/HTTP falham com taxas de bits mais altas. Os usuários procuram por "MTU black hole pcap", "path MTU Discovery Failure", "TCP MSS problem", "fragmentation packet capture" e "grandes pacotes paralisam VPN" porque a conexão não está simplesmente ativa ou inativa.

Uma captura de pacote pode mostrar se pacotes grandes são enviados, fragmentados, descartados, retransmitidos ou bloqueados pela falta de feedback ICMP. Mas o rastreamento deve ser interpretado com cuidado porque o ponto de captura, o descarregamento e a sobrecarga do túnel podem distorcer os tamanhos visíveis dos pacotes.

A cirurgia PCAP é útil aqui porque as investigações de MTU geralmente precisam de rastreamentos focados: uma conversa TCP, tempo original, mensagens ICMP, retransmissões, negociação MSS e pacotes suficientes antes e depois da parada.

O que significa MTU

MTU é a unidade máxima de transmissão em um link. A Ethernet normalmente usa 1.500 bytes. VPNs, PPPoE, túneis, sobreposições e redes em nuvem podem reduzir o caminho efetivo da MTU porque adicionam cabeçalhos.

Se um remetente transmite pacotes maiores do que um caminho pode transportar, uma de duas coisas deve acontecer:

Os pacotes são fragmentados quando permitido.
Os pacotes são descartados e o remetente deve aprender um MTU de caminho menor.

O Path MTU Discovery depende de mensagens ICMP para relatar que um pacote era muito grande. Se essas mensagens ICMP forem bloqueadas, o remetente poderá continuar enviando pacotes que desaparecem. Esse é o clássico buraco negro MTU.

Sintomas do buraco negro MTU

Os sintomas comuns incluem:

A conexão TCP é aberta, mas grandes transferências param.
O handshake HTTPS é interrompido após ClientHello ou ServerHello.
A página de login é carregada, mas o upload do arquivo falha.
A VPN conecta, mas alguns sites não carregam.
O SSH funciona até que uma saída grande apareça.
Chamadas de API com cargas pequenas funcionam, cargas grandes falham.
O controle RTSP funciona, mas a mídia ou grandes pacotes intercalados se comportam mal.
As retransmissões se repetem com tamanhos de pacotes semelhantes.

O padrão principal é a sensibilidade ao tamanho. Pequenos pacotes passam. Pacotes maiores falham.

Negociação MSS

O tamanho máximo do segmento TCP é negociado durante a troca SYN:

Client -> Server: SYN, MSS 1460
Server -> Client: SYN-ACK, MSS 1460

ICMP fragmentation needed

If the capture shows:

then Path MTU Discovery is working.

If the capture shows:

then an MTU black hole is plausible.

Fragmentation evidence

In a pcap, look for:

TLS handshake stalls and MTU

VPN and tunnel overhead

Capture point and offload

To avoid mistakes:

Checklist for MTU black hole PCAP analysis

Use this process:

Final diagnosis

Resposta por evidência de pacotes para “Análise de buraco negro de MTU e fragmentação PCAP: encontrando falhas de PMTUD, problemas de MSS e TCP paralisado”

A resposta direta é que label do analisador ou mensagem do aplicativo não determina causa. Comece por ponto de captura e direção, prove o último limite correto e o primeiro falho. Em “Análise de buraco negro de MTU e fragmentação PCAP: encontrando falhas de PMTUD, problemas de MSS e TCP paralisado”, outro revisor deve localizar packet, gap ou intervalo que sustenta cada frase e saber o que poderia refutá-la.

Colocar a captura no caminho

Registre client, server e proxy, load balancer, NAT ou firewall. Informe interface, local, clock, sistema e direções visíveis. Captura no client prova o que chegou ali, não que o server não enviou. Captura no server prova saída naquele ponto, não o caminho. Antes de comparar pontos, corrija clock offset e alinhe flow tuple, TCP sequence ou transaction ID.

Verifique snap length, dropped packets, offload, capture filter, ring buffer e início. Bad checksum no host pode ser offload artifact. Segmento grande pode ser GRO/TSO e não existir assim no fio. Packet ausente de arquivo limitado não vira network loss antes de provar que o ponto deveria vê-lo.

Ler limites em ordem

Limite	Prova de sucesso	Prova de falha útil
Link/IP	direction, addresses e rota coerentes	ARP/NDP ausente, ICMP, MTU, assimetria
TCP	SYN, SYN-ACK, ACK e sequence	retransmission, RST, zero window, timeout
TLS	ClientHello, ServerHello e progresso	alert ou limite SNI/ALPN/certificate
Aplicação	request completo e response associado	status, gap ou close precoce
Usuário	response time ou failure window	stall ligado a limite

Pare no primeiro limite sem sucesso. Se TCP não completa, não comece por HTTP. Se request chega ao proxy e não ao upstream, o limite está no proxy ou caminho. Se chega ao upstream sem response antes de timeout, ACK e avanço de bytes separam application delay de network loss.

Separar observação e hipótese

Observação pode ser apontada: “Client enviou até certa sequence, sender repetiu segmento três vezes e não apareceu ACK avançado neste ponto”. A hipótese é “o caminho perdeu o segmento”. Outra captura ou dropped records podem refutá-la. Para cada hipótese registre prova a favor e contrária.

Retransmission e duplicate ACK não definem culpado. Reordering, loss, capture artifact e receiver delay criam labels parecidos. Relacione direction, sequence, ACK, SACK, RTT, window e tempo da aplicação. Em DNS/DHCP alinhe transaction ID e tentativas; em HTTP request/response; em TLS direção do handshake.

Preservar original

Calcule checksum e não altere o original. Filtre, recorte e redija working copy. Registre input, transformação, hora, packet count antes/depois, checksum e razão. Após timestamp rewrite ou exclusão de packets, a cópia não suporta certas conclusões de timing ou sequence.

Troque addresses e identificadores por aliases constantes. Não remova port, direction ou length necessários. Separe o mapa secreto. Use limites de captura e export e visão geral PCAP Surgery.

QA antes de publicar

Título e resposta tratam do mesmo flow? Cada duração informa clock e pontos? Primeiro failure boundary está claro? Há alternativa? O teste muda uma variável? Original permanece? Limite a conclusão: “Este arquivo prova comportamento junto ao client no intervalo, não execução interna do server”.

O termo Semrush validado PCAP analyzer pertence somente ao produto. Este artigo não inventa volume ou KD.

Livro de flow e teste de exclusão

Para “Análise de buraco negro de MTU e fragmentação PCAP: encontrando falhas de PMTUD, problemas de MSS e TCP paralisado”, crie uma linha por direção: endpoints com alias, primeiro/último packet, bytes enviados e reconhecidos, resets, retransmissions, requests e responses. Não una conexões pelo hostname; source port, início e initial sequence separam sessions. Com NAT ou proxy, registre a relação sem esperar iguais sequence ou ports.

Calcular TCP, não contar labels

Siga next expected sequence do receiver. Payload avança sequence pelo comprimento; SYN e FIN consomem número. Duplicate ACK fixo após segmentos superiores apoia loss ou reordering. SACK blocks mostram ranges recebidos, não local de perda. Retransmission no sender e ausente no receiver exige teste do caminho; original ausente no sender capture exige capture loss ou offload.

Separe fast retransmit após duplicate ACKs de RTO após silêncio. Compare RTT anterior, advertised window, zero-window probes, burst e tamanho. Overlap, spurious retransmission e capture no meio do flow mudam o label; não use quantidade de labels como loss.

Medir tempo por limites

Use request first byte, request complete, response first byte e response complete. TTFB não é server time automaticamente. Retransmission antes da response pode acrescentar network delay; request reconhecido e silêncio longo apoia application wait. Informe valor, unidade, clock e ponto.

Em dois pontos alinhe packet distinto nas duas direções, estime offset e use intervals internos. Se clock for incerto, dê range. Compare janelas boas e falhas com duração e load semelhantes.

Perguntas de protocolo

DNS: ID, nome, tipo e retry resolver. DHCP: Discover, Offer, Request e ACK do mesmo client identifier. TLS: última handshake message por direção e alert. HTTP: autor de 4xx/5xx e upstream flow. TCP close: sender de FIN/RST e bytes sem ACK.

Teste decisivo e entrega

Escolha duas hipóteses e um teste separador. Captura no outro extremo separa network loss de measurement loss; desativar offload em teste verifica artifact; request igual em path fixo verifica intermittency; log upstream versus packet boundary verifica application delay. Escreva resultados esperados antes.

Aceite quando reviewer repete cálculo com metadata e encontra limite e restrição iguais. Entregue checksum original/derived, filter, packet ranges e passos trim/redaction. Feche com owner, ação e condição mensurável.

Revisão de reprodução

Abra nova connection e repita três vezes com entradas e filtros iguais. Ports e initial sequence podem mudar, mas limite, direção e padrão devem repetir. Informe sucessos e falhas. Uma correção muda uma variável e deve gerar a mudança prevista nos packets, não apenas esconder a mensagem.

Abra a cópia derivada em outro sistema. O reviewer encontra aliases, clock, capture point, último sucesso, primeira falha e alternativa. Procure hostname, query, header e payload sensível depois de redaction, mantendo lengths e directions necessários. Liste o não testado: direção oposta, IPv6, reconnect ou outra carga.

Feche como provado no escopo, ainda reproduzível ou aberto por captura específica. “Rede corrigida” é amplo demais após um flow.

Controle contrário e confiança

Antes de fechar “{{TITLE}}”, escreva previsão contrária. Se network path causa o problema, qual padrão aparece nos dois pontos ao mover a captura? Se é server delay, request bytes ficam reconhecidos sem response? Expectativas anteriores evitam reinterpretar depois.

Ligue confiança à evidência. “Alta” exige repetição e dois pontos ou prova independente; “média”, captura completa com alternativa aberta; “baixa”, apenas label ou timing aproximado. Confiança não torna hypothesis um fact, mas ordena a próxima ação.

Para falha lenta ou intermitente, meça além do intervalo típico. Compare taxas: retransmissions por megabyte, falhas por connection e percentis de latency sob carga parecida. Registre idle, reconnect, DNS cache e TLS session reuse, pois mudam a segunda execução.

Entregue tabela de flow, timeline de cinco eventos, primeira diferença, teste de exclusão, resultado da correção e escopo não testado. Packet numbers apontam à cópia derivada e um mapa temporal volta ao original. O receptor deve repetir o veredito sem secrets ou sessão do autor.