Fragmentação IP: quando a mudança exige cuidado

Índice:

• O que é fragmentação IP?
• Por que a MTU provoca essa divisão?
• Como IPv4 e IPv6 tratam fragmentos?
• Como o PMTUD evita pacotes partidos?
• Qual impacto surge na latência?
• Quando a perda afeta a aplicação?
• Quais sinais aparecem nos equipamentos?
• Como ajustar MSS em conexões TCP?
• Como testar a MTU sem interromper serviços?
• Por que túneis exigem cuidado extra?
• Quais riscos afetam a segurança?
• Quando jumbo frames fazem sentido?
• Como proteger o storage contra esse problema?
• Qual método evita ajustes arriscados?
• Como reduzir falhas após a mudança?
• Como transformar diagnóstico em ganho?

Fragmentação IP divide pacotes grandes em partes menores para atravessar uma rede com MTU limitada. Esse processo aumenta atrasos, consumo e riscos, especialmente em VPNs e túneis.

Uma alteração simples em firewall, roteador ou provedor costuma reduzir o tamanho útil dos pacotes. Assim, algumas aplicações ficam lentas, certas conexões falham e poucos logs explicam a causa.

Por isso, administradores precisam relacionar MTU, MSS, PMTUD e mensagens ICMP antes de alterar parâmetros. Ainda, cada ajuste exige testes em vários caminhos, como veremos.

O que é fragmentação IP?

A fragmentação IP ocorre quando um pacote supera a MTU disponível no caminho. Em IPv4, um roteador pode dividir esse pacote em dois ou mais fragmentos para concluir a entrega.

Cada fragmento recebe campos próprios no cabeçalho IPv4. O destino usa identificação, deslocamento e uma marca final para recompor a unidade original. Se uma parte desaparecer, o sistema descarta o conjunto inteiro.

Em uma rede doméstica, essa divisão talvez passe despercebida. Já em uma filial com VPN, firewall e dois links, poucos bytes acima do limite podem elevar a latência e interromper aplicações sensíveis.

Por que a MTU provoca essa divisão?

A MTU define o maior pacote aceito por uma interface. Uma Ethernet comum usa 1500 bytes, enquanto alguns túneis reduzem esse valor por causa dos cabeçalhos adicionais.

Uma VPN IPsec, por exemplo, acrescenta campos para autenticação e criptografia. Com isso, um pacote interno que caberia em 1500 bytes ultrapassa o limite externo. O roteador então fragmenta o tráfego ou descarta a unidade.

Além disso, redes com PPPoE, GRE, VXLAN e MPLS adotam limites próprios. Muitas vezes, o problema aparece apenas entre duas localidades, pois a LAN local ainda aceita quadros maiores.

Como IPv4 e IPv6 tratam fragmentos?

IPv4 atribui essa tarefa ao emissor e aos roteadores intermediários. O campo DF impede a divisão, enquanto o campo MF informa que outros fragmentos ainda virão.

IPv6 retirou a fragmentação feita por roteadores. Apenas a origem pode inserir um cabeçalho Fragment. Assim, o caminho precisa informar seu limite por ICMPv6 Packet Too Big.

Essa diferença melhora o controle do tráfego, mas cria dependência sobre ICMP. Se um firewall bloquear essa mensagem, algumas conexões IPv6 falham sem apresentar um erro claro ao usuário.

Como o PMTUD evita pacotes partidos?

O Path MTU Discovery testa o maior tamanho aceito por todo o caminho. Em IPv4, o emissor usa DF e aguarda uma mensagem ICMP Fragmentation Needed quando encontra um limite menor.

O sistema reduz o tamanho dos pacotes após receber essa resposta. Em IPv6, o ICMPv6 Packet Too Big cumpre papel semelhante. Portanto, filtros excessivos contra ICMP prejudicam o mecanismo.

Alguns firewalls bloqueiam essas mensagens por receio de ataques. Ainda assim, a regra precisa aceitar ICMP relacionado ao tráfego permitido. Sem esse cuidado, o PMTUD quebra e cria o chamado black hole.

Qual impacto surge na latência?

Cada fragmento exige cabeçalho próprio, cópia em memória e controle adicional. Dois fragmentos para um pacote geram mais trabalho que uma unidade única, embora o aumento varie conforme a carga.

O destino também reserva memória para a remontagem. Se vários fluxos enviarem partes incompletas, o equipamento acumula estruturas até expirar o temporizador.

Por isso, um servidor ocupado ou um firewall pequeno pode elevar a latência. Raramente o usuário vê a palavra fragmentação, mas ele percebe páginas lentas, chamadas instáveis e transferências irregulares.

Quando a perda afeta a aplicação?

TCP retransmite dados quando identifica perda, mas esse reparo acrescenta espera. Uma conexão web talvez apenas carregue mais devagar, enquanto um banco de dados sofre com consultas que excedem seus tempos limite.

UDP não retransmite fragmentos por conta própria. Voz sobre IP, vídeo e DNS recebem impacto imediato quando uma parte some. Assim, a aplicação precisa corrigir a perda ou aceitar a interrupção.

Um túnel IPsec entre duas unidades ilustra o risco. Se o caminho suportar 1400 bytes e o servidor insistir em 1500, vários pacotes serão descartados ou divididos. O usuário então associa a falha ao sistema errado.

Quais sinais aparecem nos equipamentos?

Roteadores costumam registrar contadores para fragmentos criados, recebidos e descartados. Switches gerenciáveis também exibem erros relacionados a MTU, embora cada fabricante use nomes distintos.

O administrador pode consultar ping com o bit DF e tamanhos progressivos. No Linux, o comando ping aceita parâmetros para esse teste. No Windows, o ping usa a opção que impede fragmentação.

Além disso, uma captura no Wireshark mostra flags, offsets e mensagens ICMP. Duas ou três medições em cada segmento revelam o menor limite e simplificam a correção.

Como ajustar MSS em conexões TCP?

O MSS informa ao TCP quanto payload cabe em cada segmento. Um firewall pode reduzir esse valor quando o caminho inclui VPN, PPPoE ou outro encapsulamento.

Um enlace com MTU 1400 costuma exigir MSS próximo a 1360 em IPv4. O cálculo desconta 20 bytes para IP e 20 bytes para TCP, mas opções TCP podem alterar o resultado.

Esse ajuste não corrige UDP nem tráfego IP bruto. Ainda assim, ele resolve muitos acessos web e sessões administrativas. Antes da mudança, dois testes com captura evitam uma correção maior que a necessária.

Como testar a MTU sem interromper serviços?

O teste começa com uma lista curta dos caminhos críticos. Inclua acesso externo, VPN, replicação, storage remoto e sistemas publicados, pois cada rota pode apresentar limite distinto.

Depois, envie pacotes com DF em tamanhos crescentes. Reduza o valor após a primeira falha e confirme o resultado em horários com pouca carga. Nunca altere todas as interfaces após uma única medição.

Em Linux, tracepath identifica limites por rota e exibe respostas ICMP. No Windows, PowerShell e ping ajudam na validação. Também vale comparar IPv4 e IPv6, pois os dois caminhos raramente coincidem.

Por que túneis exigem cuidado extra?

Todo encapsulamento acrescenta bytes ao pacote original. IPsec, WireGuard, GRE, VXLAN e PPPoE reduzem a carga útil antes que o tráfego alcance o próximo roteador.

Uma rede overlay pode atravessar três ou quatro camadas virtuais. Cada camada altera o cálculo, por isso um valor fixo copiado da LAN local costuma falhar.

Se a equipe usar jumbo frames sem validar o caminho inteiro, um único enlace menor descarta os quadros. Nesse cenário, a economia esperada desaparece e a investigação fica mais difícil.

Quais riscos afetam a segurança?

Fragmentos dificultam inspeção em firewalls, IDS e proxies. Alguns dispositivos reconstroem o fluxo antes da análise, mas outros aplicam regras em cada parte.

Um atacante pode explorar diferenças entre a remontagem no firewall e no servidor. Fragmentos sobrepostos, offsets inválidos e cabeçalhos incomuns já apareceram em técnicas para escapar de filtros.

As plataformas atuais descartam vários padrões malformados. Mesmo assim, firmware antigo e regras incompletas ainda expõem riscos. Logs, atualização e normalização no perímetro reduzem esse espaço de ataque.

Quando jumbo frames fazem sentido?

Jumbo frames usam quadros Ethernet acima dos 1500 bytes tradicionais. Em redes de storage, links 10GbE e clusters, quadros de 9000 bytes podem reduzir cabeçalhos e interrupções.

O ganho aparece quando todos os switches, NICs, interfaces e hosts aceitam o mesmo valor. Um único trecho menor quebra a comunicação ou força ajustes específicos.

Por isso, esse recurso raramente ajuda usuários comuns. Em uma SAN IP ou em um NAS QNAP com tráfego intenso, a equipe deve validar latência, CPU e taxa real antes da adoção.

Como proteger o storage contra esse problema?

Um NAS QNAP precisa seguir a MTU usada por servidores, switches e roteadores. A equipe deve validar SMB, NFS, iSCSI e replicação separadamente, pois cada serviço reage de forma distinta.

Em iSCSI, perda e atraso afetam blocos, filas e máquinas virtuais. Em SMB, o usuário percebe abertura lenta. Em replicação, o atraso acumula alterações e amplia a janela necessária para cópias.

Também configure alertas para erros nas interfaces e acompanhe retransmissões. Uma política com MTU comum, firmware atualizado e backup testado reduz o impacto operacional.

Qual método evita ajustes arriscados?

Comece pelo caminho mais curto e avance até o enlace externo. Registre MTU, MSS, encapsulamento e resposta ICMP em uma tabela simples.

Depois, altere um parâmetro por vez e repita quatro testes. Compare latência, perda, taxa TCP e estabilidade UDP antes de aprovar a mudança.

Se a rede usar dois provedores, teste os dois caminhos. Uma rota pode aceitar 1500 bytes, enquanto outra suporta apenas 1492 ou 1400. Assim, o ajuste correto precisa atender ao menor limite necessário.

Como reduzir falhas após a mudança?

Documente cada valor aplicado em roteadores, firewalls, hosts e storages. Essa prática evita que uma troca futura restaure 1500 bytes sem avaliar túneis e enlaces externos.

Agende uma nova medição após mudanças no provedor, na VPN ou no switch. Pequenas alterações físicas mudam o caminho lógico e podem criar outra restrição.

Além disso, preserve uma rota administrativa fora do serviço alterado. Se a configuração falhar, essa segunda via encurta a recuperação e reduz a indisponibilidade.

Como transformar diagnóstico em ganho?

A fragmentação IP raramente exige trocar todo o hardware. Primeiro, corrija PMTUD, libere ICMP adequado e ajuste MSS nos pontos certos.

Depois, valide cada aplicação com tráfego real. Um teste isolado com ping não comprova o comportamento em backup, banco, vídeo ou máquina virtual.

Se sua equipe encontrar perdas persistentes, nossa consultoria em Itapevi atende projetos para redes, servidores, NAS QNAP e datacenters. Fale pelo WhatsApp ou telefone no número (11) 91789-1293.

Uma rede bem medida reduz atrasos, evita correções improvisadas e protege seus serviços. Por isso, controlar o tamanho dos pacotes antes da mudança é a resposta para atravessar redes complexas com previsibilidade.