Sua Internet aparentemente está funcionando. O Windows mostra que existe conexão, o Wi-Fi permanece conectado, o roteador responde normalmente e alguns sites abrem sem qualquer dificuldade. Mesmo assim, determinado sistema não carrega, uma VPN conecta mas não consegue acessar determinados recursos, um site fica eternamente carregando ou um download começa e simplesmente para.

Esse tipo de problema costuma ser particularmente confuso porque não existe uma queda completa da Internet.

O usuário abre um mecanismo de busca e funciona.

Abre outro site e funciona.

Testa uma terceira página e ela não termina de carregar.

Reinicia o roteador, aparentemente melhora, mas o comportamento retorna.

Nesse cenário, DNS, firewall, IPv6, VPN, proxy e problemas de rota são algumas das possibilidades que precisam ser investigadas. Porém, existe outro componente frequentemente ignorado: MTU.

MTU significa Maximum Transmission Unit, ou Unidade Máxima de Transmissão.

De forma simplificada, ela determina o maior tamanho de pacote que determinada interface ou enlace consegue transportar sem exigir que o pacote seja tratado de outra maneira devido ao limite daquele trecho.

Mas o problema fica mais interessante quando percebemos que a comunicação não atravessa apenas nossa placa de rede.

Entre seu computador e um servidor na Internet podem existir diversos equipamentos e tecnologias:

Computador → Wi-Fi/Ethernet → roteador → operadora → outros roteadores → rede de destino → servidor

Cada trecho pode possuir características diferentes.

Por isso existe outro conceito fundamental:

Path MTU — PMTU

Ele representa o maior tamanho de pacote que consegue percorrer determinado caminho sem ultrapassar o menor limite de MTU encontrado nesse percurso.

Quando essa descoberta funciona corretamente, normalmente o usuário nem percebe sua existência.

Quando algo dá errado, porém, podemos encontrar um dos problemas de rede mais curiosos:

a Internet funciona, mas parece funcionar apenas pela metade.

Neste guia da VMIA, vamos entender o que é MTU, como funciona o Path MTU Discovery, por que VPNs e túneis podem reduzir o tamanho disponível para os pacotes e como diagnosticar situações em que alguns serviços funcionam enquanto outros falham.

---

O que é MTU?

Imagine que precisamos transportar uma grande quantidade de mercadorias por várias estradas.

Em vez de enviar tudo de uma única vez, dividimos a carga em veículos.

Existe, porém, um limite para o tamanho que cada trecho da rota consegue transportar.

Em redes de computadores ocorre algo conceitualmente semelhante.

Os dados são divididos e transportados através da rede respeitando limites definidos pelos protocolos e pelas tecnologias utilizadas.

A MTU estabelece o tamanho máximo de um pacote IP que pode ser transportado pela interface/enlace em questão sem exceder aquele limite.

Em uma rede Ethernet convencional, é muito comum encontrarmos:

MTU = 1500 bytes

Isso não significa que todas as redes da Internet obrigatoriamente utilizem 1500 bytes.

Significa apenas que esse é um valor extremamente comum em Ethernet.

E é justamente aqui que começam alguns problemas.

---

MTU 1500 significa que meus arquivos são enviados em blocos de 1500 bytes?

Não exatamente.

Quando você baixa um arquivo de 500 MB, o computador não cria simplesmente milhares de “arquivos menores” de exatamente 1500 bytes.

Existem diversas camadas envolvidas na comunicação.

Dentro de um pacote existem informações utilizadas pelos próprios protocolos.

Podemos pensar, de maneira simplificada:

Quadro Ethernet
└── Pacote IP
    └── Segmento TCP
        └── Dados da aplicação

Cada protocolo acrescenta seus próprios cabeçalhos.

Portanto:

MTU não é sinônimo de quantidade de dados úteis da aplicação.

Esse detalhe será muito importante quando começarmos a testar MTU utilizando ping.

---

Por que 1500 bytes aparecem tanto quando falamos de MTU?

Porque 1500 bytes são extremamente comuns como MTU IP em redes Ethernet tradicionais.

Se você verificar uma interface de rede de um computador, é bastante provável encontrar esse valor.

No Windows, podemos visualizar informações das interfaces por diferentes ferramentas.

Uma delas é o PowerShell.

Por exemplo:

Get-NetIPInterface

Dependendo da versão e configuração do Windows, você poderá encontrar informações relacionadas à MTU das interfaces IPv4 e IPv6.

Também existem comandos netsh capazes de exibir informações das subinterfaces.

Por exemplo:

netsh interface ipv4 show subinterfaces

O objetivo neste momento não é alterar nada.

Primeiro queremos descobrir:

Qual MTU minha interface está utilizando?

Essa diferença entre observar e alterar é fundamental em qualquer diagnóstico de rede.

---

MTU da placa não é necessariamente a MTU do caminho

Aqui está uma das partes mais importantes deste artigo.

Imagine que sua placa Ethernet esteja configurada com:

MTU 1500

Você poderia concluir:

“Então posso enviar pacotes de 1500 bytes para qualquer lugar da Internet.”

Não necessariamente.

O caminho pode ser:

Computador
MTU 1500
↓
Roteador
MTU 1500
↓
Enlace da operadora
MTU menor
↓
Túnel
MTU menor
↓
Servidor

O tamanho realmente utilizável ao longo de todo o percurso depende do trecho mais restritivo.

Esse conceito recebe o nome de:

Path MTU

ou:

PMTU

Podemos imaginar:

Trecho A → MTU 1500
Trecho B → MTU 1500
Trecho C → MTU 1492
Trecho D → MTU 1500

O caminho não pode simplesmente ignorar que existe um trecho com limite inferior.

É por isso que a MTU da interface local e a MTU efetiva do caminho não devem ser tratadas como se fossem sempre a mesma coisa.

---

Por que uma conexão pode ter MTU menor?

Existem vários motivos.

Um dos mais conhecidos envolve tecnologias que adicionam informações extras aos pacotes ou encapsulam tráfego.

Podemos encontrar diferenças relacionadas a:

• PPPoE;
• VPN;
• túneis;
• encapsulamento;
• determinadas redes corporativas;
• infraestrutura de provedores;
• virtualização;
• outros protocolos adicionados ao caminho.

Quando novos cabeçalhos precisam ser acrescentados, existe menos espaço disponível dentro de determinados limites físicos ou lógicos da comunicação.

É exatamente por isso que VPNs merecem atenção especial neste artigo.

---

A VPN pode alterar o MTU efetivamente disponível?

Sim.

Uma VPN normalmente precisa encapsular o tráfego original dentro de outro protocolo.

Simplificando bastante:

Sem VPN:

IP
└── TCP
    └── Dados

Com determinado tipo de túnel:

Novo cabeçalho
└── Pacote original
    └── TCP
        └── Dados

Essas informações adicionais ocupam espaço.

Dependendo da tecnologia, configuração e caminho, o tamanho máximo disponível para o pacote interno pode precisar ser reduzido.

É por isso que um problema de MTU pode aparecer somente quando a VPN está ativa.

O usuário observa:

Sem VPN: tudo funciona.

Com VPN: determinados sistemas param de abrir.

É tentador concluir imediatamente:

“A VPN está bloqueando o site.”

Mas o problema pode ser mais sutil.

A VPN pode estar funcionando, porém o tamanho de determinados pacotes pode não estar adequado ao caminho criado pelo túnel.

---

O que é fragmentação?

Imagine um pacote maior do que determinado trecho consegue transportar.

No IPv4, dependendo das condições e das informações existentes no cabeçalho, pode ocorrer fragmentação.

De maneira simplificada, o pacote é dividido em fragmentos menores para conseguir atravessar aquele trecho.

Isso parece uma solução perfeita:

Pacote grande → divide → atravessa → pronto.

Mas fragmentação possui custos e complicações.

Além disso, quando o bit Don’t Fragment (DF) está definido, os roteadores não podem simplesmente fragmentar aquele pacote IPv4.

É nesse contexto que o Path MTU Discovery se torna tão importante.

---

O que significa Don’t Fragment?

No IPv4 existe um sinalizador conhecido como:

DF — Don’t Fragment

Em português:

Não Fragmentar

Quando esse bit está definido, o pacote não deve ser fragmentado por um roteador no caminho.

Se o pacote for grande demais para o próximo enlace, precisamos de um mecanismo para informar ao remetente que aquele tamanho não consegue passar.

Essa informação permite que o computador ajuste o tamanho utilizado.

Esse processo está diretamente relacionado ao Path MTU Discovery.

---

O que é Path MTU Discovery?

O Path MTU Discovery, frequentemente abreviado como PMTUD, é um mecanismo utilizado para descobrir qual tamanho de pacote pode atravessar determinado caminho sem exigir fragmentação indevida.

Podemos representar o princípio assim:

Computador
↓
envia pacote
↓
Roteador A — suporta
↓
Roteador B — suporta
↓
Roteador C — limite menor
↓
pacote não consegue seguir naquele tamanho
↓
origem precisa ser informada
↓
tamanho é ajustado

Quando tudo funciona corretamente, o sistema consegue adaptar a comunicação ao caminho.

A documentação técnica do Windows descreve suporte à descoberta de MTU de caminho justamente para permitir que o TCP ajuste seus segmentos e evite fragmentação ao atravessar redes com MTUs diferentes.

---

Então qual é o problema?

O problema aparece quando o remetente precisa descobrir que determinado pacote é grande demais, mas a informação necessária para realizar esse ajuste não retorna corretamente.

É aqui que chegamos a um dos conceitos centrais deste artigo:

PMTUD Black Hole

ou:

Path MTU Discovery Black Hole

O nome “black hole”, ou buraco negro, descreve muito bem o comportamento.

Determinados pacotes entram no caminho e simplesmente não conseguem completar a comunicação como esperado.

O remetente não recebe adequadamente a informação necessária para corrigir o tamanho.

O resultado pode ser extremamente confuso.

---

Como nasce um MTU Black Hole?

Vamos imaginar um cenário simplificado.

Seu computador envia um pacote grande:

PC
↓
1500
↓
Roteador
↓
1500
↓
Trecho do caminho
↓
suporta apenas tamanho menor

O pacote não pode seguir naquele formato.

Se o mecanismo de sinalização necessário funcionar, a origem descobre o problema e reduz o tamanho.

Mas imagine que uma regra de firewall ou algum equipamento no caminho impeça a mensagem necessária de retornar.

Agora temos:

PC
↓
pacote grande
↓
trecho não suporta
↓
pacote descartado
↓
aviso necessário não chega
↓
PC continua sem descobrir corretamente o limite

Esse comportamento é uma das formas pelas quais surge o chamado PMTU Black Hole.

---

Por que pacotes pequenos continuam funcionando?

Essa pergunta explica por que o problema parece tão estranho.

Imagine que o caminho suporte até determinado tamanho inferior ao que a origem inicialmente tenta utilizar.

Um pacote pequeno:

500 bytes

passa normalmente.

Outro:

900 bytes

também.

Mas um pacote suficientemente grande pode encontrar o gargalo.

Isso cria um cenário em que:

• ping comum pode funcionar;
• pequenas consultas podem funcionar;
• determinadas páginas começam a carregar;
• conexões são estabelecidas;
• tráfego maior apresenta problemas.

É por isso que simplesmente executar:

ping google.com

e receber resposta não elimina a possibilidade de um problema relacionado a MTU.

---

O ping padrão utiliza pacotes relativamente pequenos

No Windows, o ping utiliza por padrão uma quantidade pequena de dados na solicitação ICMP.

Por isso:

ping destino

pode funcionar perfeitamente mesmo quando pacotes maiores apresentam dificuldades.

Isso nos leva a uma regra importante:

Ping funcionando não significa que todos os tamanhos de pacote atravessam corretamente o caminho.

Para investigar PMTU, precisamos controlar o tamanho do teste.

---

Como o Windows permite testar MTU com ping?

O comando ping do Windows possui dois parâmetros particularmente úteis:

-f

e:

-l

O parâmetro:

-f

define Don’t Fragment no IPv4.

Já:

-l

permite escolher o tamanho da área de dados enviada pelo ping.

Por exemplo:

ping exemplo.com -f -l 1472

Esse comando se torna uma ferramenta extremamente útil para investigar o tamanho máximo que consegue atravessar determinado caminho sem fragmentação.

Mas existe um detalhe importante:

1472 não significa MTU 1472.

Precisamos considerar os cabeçalhos.

---

Por que testar 1472 quando falamos em MTU 1500?

No IPv4 sem opções adicionais, podemos considerar para esse teste:

20 bytes do cabeçalho IPv4

8 bytes do ICMP

=

28 bytes

Portanto:

1472 + 28 = 1500

Assim, um teste:

ping destino -f -l 1472

é frequentemente utilizado para verificar se um pacote IPv4 correspondente a 1500 bytes consegue atravessar o caminho sem fragmentação.

Essa conta é extremamente importante.

Se simplesmente executarmos:

ping destino -f -l 1500

estaremos testando um pacote IP maior que 1500, porque ainda existem os cabeçalhos.

---

Primeiro teste prático

Suponha que queremos testar determinado servidor:

ping servidor.exemplo -f -l 1472

Se o caminho comportar esse tamanho e o destino responder ao ICMP, poderemos receber respostas normalmente.

Se o pacote precisar ser fragmentado, o Windows poderá indicar que a fragmentação seria necessária, dependendo do cenário e da resposta recebida.

Agora reduzimos:

ping servidor.exemplo -f -l 1464

Se funcionar, podemos continuar ajustando o tamanho.

O objetivo é descobrir aproximadamente:

qual é o maior payload ICMP que consegue atravessar sem fragmentação?

Depois adicionamos os 28 bytes correspondentes ao IPv4 + ICMP daquele teste.

---

Exemplo de cálculo

Imagine que:

ping destino -f -l 1472

falha.

Depois:

ping destino -f -l 1464

funciona.

Podemos testar valores intermediários até encontrar o maior tamanho funcional.

Suponha que o maior valor seja:

1464

Para esse teste IPv4/ICMP:

1464 + 28 = 1492

Temos então uma forte indicação de um Path MTU de aproximadamente 1492 bytes naquele caminho, considerando as condições específicas do teste.

Isso não significa que devemos imediatamente configurar todas as placas do computador para 1492.

Primeiro estamos diagnosticando.

Alterar configurações vem depois.

---

Por que 1492 aparece frequentemente?

Um dos cenários conhecidos envolve PPPoE.

A Ethernet tradicional frequentemente utiliza MTU 1500, mas o PPPoE adiciona overhead.

Por isso, 1492 é um valor bastante conhecido em redes que utilizam esse tipo de conexão.

Mas não devemos cair em outra armadilha:

nem toda conexão PPPoE necessariamente produzirá para o usuário exatamente o mesmo cenário de MTU em toda a rede, porque roteadores e equipamentos podem realizar ajustes e outras tecnologias podem estar envolvidas.

O importante é entender o princípio.

---

E se somente um site apresentar problema?

Esse é um cenário possível.

O Path MTU depende do caminho.

Dois destinos diferentes podem ser alcançados por rotas diferentes.

Por exemplo:

PC → operadora → rota A → servidor 1

e:

PC → operadora → rota B → servidor 2

O primeiro caminho pode funcionar normalmente.

O segundo pode atravessar um trecho com características diferentes.

Isso ajuda a explicar por que um problema de PMTU pode afetar determinados destinos e não necessariamente toda a Internet.

---

MTU errado pode fazer um site carregar apenas pela metade?

Pode contribuir para esse comportamento.

Uma página moderna não é um único arquivo.

Quando abrimos um site, o navegador pode buscar:

• HTML;
• CSS;
• JavaScript;
• imagens;
• fontes;
• APIs;
• conteúdo de CDNs;
• serviços externos.

Essas conexões podem utilizar destinos diferentes.

Assim, podemos encontrar situações em que:

estrutura básica aparece

mas:

parte do conteúdo não carrega.

Entretanto, é importante não diagnosticar MTU apenas pelo sintoma.

Esse mesmo comportamento também pode ser causado por:

• DNS;
• bloqueadores;
• firewall;
• CDN;
• proxy;
• certificado;
• navegador;
• IPv6;
• problemas do próprio servidor.

O diagnóstico precisa confirmar a hipótese.

---

VPN conecta, mas o sistema não abre

Esse é um dos cenários em que investigar MTU pode ser especialmente interessante.

O usuário consegue:

autenticar na VPN ✅

mas depois:

sistema interno não abre ❌

ou:

Remote Desktop fica instável

ou:

determinados compartilhamentos não respondem corretamente

ou:

aplicação corporativa trava durante transferências maiores.

O túnel existe.

A autenticação funcionou.

A rota pode até existir.

Mesmo assim, determinados pacotes podem encontrar um limite diferente dentro do caminho criado pela VPN.

Por isso, em diagnósticos avançados de VPN, MTU e MSS merecem atenção.

---

MTU e MSS são a mesma coisa?

Não.

Essa confusão é bastante comum.

MTU está relacionada ao tamanho máximo do pacote IP suportado naquele contexto.

MSS — Maximum Segment Size está relacionada à quantidade máxima de dados TCP em um segmento.

Em um cenário IPv4/TCP simples, sem opções adicionais:

MTU 1500
- 20 bytes IPv4
- 20 bytes TCP
= MSS 1460

Portanto, é comum encontrarmos:

MTU 1500
MSS 1460

Mas esses números não devem ser decorados como se fossem universais.

Cabeçalhos adicionais, IPv6, opções TCP e encapsulamentos podem alterar o cálculo.

O importante é entender:

MTU ≠ MSS

---

O que é MSS Clamping?

Em determinados roteadores, firewalls e VPNs existe um recurso conhecido como:

TCP MSS Clamping

A ideia é ajustar o MSS anunciado nas conexões TCP para evitar que segmentos grandes demais gerem pacotes incompatíveis com o caminho ou túnel.

Podemos pensar:

MTU do túnel é menor
↓
MSS precisa respeitar essa realidade
↓
equipamento ajusta MSS
↓
TCP passa a utilizar segmentos menores

Quando bem configurado, esse mecanismo pode evitar diversos problemas relacionados a túneis.

Quando está ausente ou configurado incorretamente, sintomas estranhos podem aparecer.

---

Não altere MTU apenas porque viu um tutorial

Este é provavelmente o alerta mais importante desta primeira parte.

Existem muitos tutoriais que recomendam:

“Internet lenta? Coloque MTU 1492.”

ou:

“VPN não funciona? Use MTU 1400.”

Isso não é diagnóstico.

É tentativa.

Um valor menor pode fazer determinado problema desaparecer e ainda assim não representar a configuração ideal.

Além disso, reduzir excessivamente a MTU aumenta overhead e pode prejudicar a eficiência da comunicação.

O procedimento correto é:

identificar o sintoma → medir → localizar o limite → entender a topologia → somente então decidir se alguma alteração é necessária.

---

MTU também não é a primeira explicação para Internet lenta

Outro cuidado importante.

Se sua Internet contratada é de 500 Mbps e o teste entrega 90 Mbps, não devemos começar imediatamente alterando MTU.

Existem causas muito mais comuns:

• Ethernet negociando a 100 Mbps;
• Wi-Fi fraco;
• interferência;
• cabo defeituoso;
• porta Fast Ethernet;
• driver;
• QoS;
• congestionamento;
• limitações do equipamento.

MTU entra principalmente quando o padrão da falha sugere problemas com determinados tamanhos de pacote, túneis ou caminhos.

---

Como reconhecer um possível problema de MTU

Alguns sintomas que justificam investigar MTU incluem:

• alguns sites funcionam e outros não;
• página começa a carregar e para;
• VPN conecta, mas aplicações internas falham;
• conexão remota funciona apenas parcialmente;
• pequenos pacotes passam, grandes falham;
• problema aparece somente através de determinado túnel;
• determinados uploads ou downloads travam;
• mudança de roteador/VPN/operadora coincidiu com o início do problema.

Nenhum desses sintomas sozinho comprova uma falha de MTU.

Eles apenas justificam incluir MTU no diagnóstico.

---

A lógica correta do diagnóstico

Antes de alterar qualquer configuração, devemos responder:

1. Existe conectividade IP?

↓

2. O gateway funciona?

↓

3. DNS funciona?

↓

4. O destino responde?

↓

5. Pacotes pequenos passam?

↓

6. Pacotes maiores passam sem fragmentação?

↓

7. O comportamento muda com ou sem VPN?

↓

8. Existe algum túnel ou encapsulamento no caminho?

Essa sequência transforma MTU de um “número mágico” em uma variável mensurável.

---

O que veremos na Parte 2

Agora já sabemos que a MTU configurada na placa não necessariamente representa o limite de todo o caminho e que o Path MTU Discovery existe justamente para lidar com diferenças entre os enlaces.

Também vimos por que um PMTUD Black Hole pode produzir um dos sintomas mais estranhos de redes: pequenas comunicações funcionam enquanto determinados pacotes desaparecem.

Na Parte 2, vamos colocar o diagnóstico em prática.

Veremos como utilizar corretamente:

ping -f -l

netsh

Get-NetIPInterface

Test-NetConnection

e outros recursos do Windows para descobrir a MTU, comparar resultados com e sem VPN, diferenciar problemas de MTU de DNS e testar valores progressivamente sem simplesmente alterar a configuração da placa.

Também veremos por que 1472 + 28 = 1500, quando 1492 pode aparecer, como interpretar mensagens de fragmentação e como descobrir se o verdadeiro problema está no computador, roteador, VPN ou caminho até o destino.

MTU errado pode deixar a Internet funcionando pela metade? Diagnóstico prático no Windows

Entendemos que MTU não é apenas um número configurado na placa de rede. O que realmente importa em muitas situações é o tamanho que consegue atravessar todo o caminho entre o computador e determinado destino.

Também vimos por que uma conexão pode parecer saudável mesmo quando existe um problema relacionado à MTU:

pacotes pequenos passam → pacotes maiores encontram um limite → PMTUD não consegue ajustar corretamente → determinados serviços falham.

Agora vamos sair da teoria e partir para o diagnóstico no Windows.

O objetivo desta etapa não é encontrar um número qualquer na Internet e configurá-lo na placa. Vamos medir o comportamento da conexão, comparar diferentes destinos e descobrir se existem evidências reais de um problema relacionado à MTU.

---

Antes de testar MTU, confirme que a rede realmente funciona

Um erro comum é começar pelo MTU quando o computador possui um problema completamente diferente.

Antes dos testes avançados, confirme o básico.

Abra o Prompt de Comando e execute:

ipconfig /all

Observe principalmente:

• endereço IPv4;
• máscara;
• gateway padrão;
• servidores DNS;
• adaptador utilizado.

Depois teste o gateway.

Por exemplo:

ping 192.168.1.1

Utilize o endereço real do seu roteador.

Se nem o gateway responde e existe um problema de conectividade local, investigar Path MTU para um servidor na Internet ainda não é nossa prioridade.

Primeiro precisamos resolver a comunicação básica.

---

Teste a Internet por endereço IP

Depois de confirmar a rede local, podemos testar um destino externo conhecido que aceite ICMP.

Por exemplo:

ping 1.1.1.1

Se houver resposta, sabemos que pelo menos aquele tipo de comunicação IP está funcionando.

Agora teste resolução de nomes:

nslookup vmia.com.br

Esses testes ajudam a separar problemas.

Se endereço IP funciona, mas nomes não são resolvidos corretamente, DNS merece investigação antes de MTU.

Não devemos transformar MTU na explicação universal para qualquer falha de Internet.

---

Ping funcionando não elimina problema de MTU

Agora chegamos ao ponto interessante.

Execute:

ping 1.1.1.1

O teste pode responder perfeitamente.

Mesmo assim, ainda podemos ter problemas com pacotes maiores.

Isso acontece porque o ping padrão utiliza uma quantidade relativamente pequena de dados.

Precisamos aumentar deliberadamente o tamanho.

No Windows, utilizamos:

-l

para determinar o tamanho dos dados ICMP.

E, no IPv4:

-f

para definir o bit Don’t Fragment.

---

Primeiro teste: 1472 bytes

Em uma rede em que esperamos um Path MTU IPv4 de 1500, podemos começar com:

ping 1.1.1.1 -f -l 1472

Por que 1472?

Porque, nesse teste IPv4/ICMP convencional:

1472 dados
+ 20 cabeçalho IPv4
+ 8 cabeçalho ICMP
-------------------
1500 bytes

Se o pacote consegue atravessar o caminho sem fragmentação e o destino responde, temos um bom sinal de que um pacote IPv4 desse tamanho consegue realizar aquele percurso nas condições testadas.

---

Quando aparece “O pacote precisa ser fragmentado”

Dependendo do caminho e da resposta recebida, o Windows pode informar algo equivalente a:

O pacote precisa ser fragmentado, mas a desfragmentação está ativa.

A tradução e a mensagem podem variar conforme a versão do sistema.

O significado importante é:

o pacote testado é grande demais para algum ponto daquele caminho sem fragmentação.

Isso não significa automaticamente que existe um defeito.

Pode simplesmente significar que o Path MTU é menor que 1500.

Agora precisamos descobrir aproximadamente qual é o limite.

---

Reduza o tamanho progressivamente

Suponha que:

ping 1.1.1.1 -f -l 1472

não passe.

Podemos reduzir:

ping 1.1.1.1 -f -l 1464

Se ainda falhar:

ping 1.1.1.1 -f -l 1452

Depois:

ping 1.1.1.1 -f -l 1440

O objetivo não é testar aleatoriamente dezenas de números.

Estamos procurando a fronteira entre:

funciona

e:

precisa fragmentar/não consegue atravessar nas condições testadas.

---

Encontrando o maior valor funcional

Imagine os seguintes resultados:

1472 → falha
1464 → falha
1452 → funciona

Agora sabemos que o limite está em algum ponto entre 1452 e 1464.

Podemos testar:

ping 1.1.1.1 -f -l 1458

Depois:

ping 1.1.1.1 -f -l 1460

E assim sucessivamente até encontrar o maior valor que passa.

Essa estratégia é muito mais eficiente do que testar todos os números individualmente.

---

Encontrou o maior payload? Some 28

Suponha que o maior valor funcional seja:

1464

Para nosso teste IPv4/ICMP:

1464
+ 20 IPv4
+ 8 ICMP
= 1492

Isso sugere um PMTU de aproximadamente:

1492 bytes

naquele caminho e naquele momento.

A palavra caminho é fundamental.

Não estamos necessariamente descobrindo um valor universal para toda a Internet.

---

Teste vários destinos

Não utilize apenas um servidor.

O fato de:

ping destinoA -f -l 1472

funcionar não significa que o mesmo ocorrerá com todos os destinos.

Rotas podem ser diferentes.

Faça testes com destinos relevantes para o problema.

Se o usuário relata:

“O sistema da empresa não funciona.”

o caminho até aquele ambiente é muito mais relevante do que testar somente um servidor público aleatório.

Da mesma maneira, se o problema acontece apenas dentro da VPN, o teste precisa considerar a VPN.

---

Cuidado: alguns servidores bloqueiam ICMP

Esse detalhe é extremamente importante.

Um ping sem resposta não significa automaticamente:

MTU errado.

O destino pode simplesmente não responder a ICMP Echo Request.

Firewalls e servidores podem bloquear ou limitar ping.

Por isso, antes de utilizar um destino para testes de tamanho, confirme que:

ping destino

funciona normalmente com o tamanho padrão.

Se nem o ping pequeno recebe resposta, aquele destino pode não ser adequado para esse tipo de teste.

---

Diferencie “sem resposta” de “precisa fragmentar”

Esses resultados não são equivalentes.

Resultado A

Resposta normal

O pacote chegou ao destino e houve resposta.

Resultado B

Fragmentação necessária

Existe evidência relacionada ao tamanho do pacote e ao caminho.

Resultado C

Tempo limite esgotado

Pode significar muitas coisas:

• ICMP bloqueado;
• perda de pacote;
• destino indisponível;
• firewall;
• rota;
• problema de conectividade;
• possível black hole.

Portanto, timeout sozinho não comprova MTU inadequado.

---

Como identificar a MTU configurada no Windows

Agora podemos comparar o Path MTU observado com a configuração local.

Abra o Prompt de Comando como administrador e execute:

netsh interface ipv4 show subinterfaces

O Windows exibirá as interfaces e informações relacionadas.

Podemos encontrar algo semelhante a:

MTU       Estado        Interface
1500      conectado     Ethernet
1500      conectado     Wi-Fi

Os nomes e detalhes apresentados podem variar.

O ponto importante é identificar qual interface está realmente transportando o tráfego.

---

PowerShell: outra forma de verificar MTU

Também podemos utilizar:

Get-NetIPInterface

Para restringir ao IPv4:

Get-NetIPInterface -AddressFamily IPv4

Observe a interface ativa e o valor relacionado a NlMtu.

Em computadores com:

• Ethernet;
• Wi-Fi;
• VPN;
• Hyper-V;
• VMware;
• VirtualBox;
• adaptadores virtuais;

podem existir várias interfaces.

Não analise o primeiro valor da lista e conclua que encontrou a interface correta.

---

Descubra qual interface realmente está sendo utilizada

Execute:

Get-NetIPConfiguration

Analise:

• InterfaceAlias;
• IPv4Address;
• IPv4DefaultGateway;
• DNSServer.

A interface com o gateway utilizado para aquela comunicação merece atenção especial.

Também podemos observar a tabela de rotas:

route print

Essa ferramenta ajuda a entender por qual interface determinados destinos serão alcançados.

Isso se torna especialmente importante quando existe VPN.

---

VPN ativa: repita todos os testes

Imagine:

Sem VPN

1472 passa
PMTU aparente ≈ 1500

Agora conectamos a VPN.

Repetimos:

ping destino -f -l 1472

e falha.

Reduzimos.

Suponha que apenas:

ping destino -f -l 1372

funcione.

Temos uma diferença importante.

O caminho criado pela VPN provavelmente possui características diferentes do caminho direto.

Isso não prova sozinho que a VPN esteja configurada incorretamente, mas fornece uma evidência concreta para continuar o diagnóstico.

---

Por que VPN reduz espaço disponível?

Considere um pacote original.

A VPN precisa encapsulá-lo.

Dependendo do protocolo, podemos adicionar:

• novo cabeçalho IP;
• UDP;
• informações do túnel;
• autenticação;
• criptografia;
• outros campos.

Podemos representar:

Pacote original
↓
Encapsulamento VPN
↓
Pacote externo maior
↓
Rede física

Se a rede física aceita um tamanho máximo limitado, o pacote interno precisa deixar espaço para esse overhead.

É por isso que MTUs como:

• 1400;
• 1420;
• 1380;

podem aparecer em determinados túneis.

Mas esses valores não devem ser aplicados universalmente.

Cada tecnologia e topologia precisa ser analisada.

---

WireGuard, IPsec, OpenVPN e outras VPNs têm o mesmo overhead?

Não.

Protocolos diferentes encapsulam dados de formas diferentes.

Além disso, fatores como:

• IPv4 ou IPv6 externo;
• TCP ou UDP;
• criptografia;
• NAT;
• outros túneis;

podem alterar o overhead.

Por isso, frases como:

“VPN sempre usa MTU 1400”

são simplificações perigosas.

O correto é verificar a documentação da solução utilizada e medir o ambiente real.

---

PPPoE: por que 1492 aparece tanto?

Em Ethernet tradicional, 1500 bytes são comuns.

Quando PPPoE clássico é utilizado sem mecanismos que permitam transportar payload maior no enlace inferior, existe overhead adicional.

Um valor frequentemente encontrado é:

MTU 1492

Por isso, em determinadas conexões PPPoE, um teste:

ping destino -f -l 1472

pode não passar.

Mas:

ping destino -f -l 1464

pode funcionar.

E novamente:

1464 + 28 = 1492

Isso explica matematicamente o resultado.

---

Não confunda MTU da WAN com MTU do computador

Seu computador pode continuar configurado com:

1500

na Ethernet.

Enquanto o roteador utiliza outro tamanho em sua conexão WAN.

Isso pode funcionar perfeitamente quando o roteador e os mecanismos de descoberta/ajuste lidam corretamente com a diferença.

Portanto, descobrir que a WAN utiliza 1492 não significa automaticamente que todos os computadores da LAN devem ser alterados para 1492.

Essa distinção evita muitas configurações desnecessárias.

---

Como testar um site que não abre

Suponha que:

Site A funciona

e:

Site B não abre.

Primeiro verifique DNS:

nslookup siteB.com

Se o domínio resolve corretamente, avance.

Podemos utilizar:

Test-NetConnection siteB.com -Port 443

Esse comando verifica, entre outras informações, a possibilidade de estabelecer uma conexão TCP com a porta HTTPS.

Se retornar sucesso na conexão TCP, temos uma pista diferente de um cenário em que a porta 443 nem sequer é alcançável.

---

Test-NetConnection ajuda a provar MTU?

Não diretamente.

Ele ajuda a construir o diagnóstico.

Por exemplo:

DNS resolve ✅

TCP 443 conecta ✅

site começa a carregar e trava ❌

Agora faz sentido investigar etapas posteriores, incluindo:

• TLS;
• proxy;
• navegador;
• MTU;
• PMTUD;
• conteúdo externo;
• firewall.

A ferramenta elimina possibilidades.

Diagnóstico de rede funciona melhor quando cada teste responde uma pergunta específica.

---

Teste também sem a VPN

Se o problema ocorre em uma aplicação corporativa, faça uma comparação.

Cenário A — VPN desligada

• sites normais funcionam;
• ping grande funciona;
• navegação normal.

Cenário B — VPN ligada

• autenticação funciona;
• aplicação começa a abrir;
• transferência trava;
• pacotes maiores falham.

Essa diferença aumenta bastante a relevância da hipótese de MTU/túnel.

---

O navegador pode mascarar o problema

Navegadores modernos utilizam tecnologias complexas.

Uma única página pode envolver:

• IPv4;
• IPv6;
• TCP;
• QUIC/HTTP/3;
• HTTPS;
• múltiplas CDNs;
• DNS seguro;
• cache;
• conexões paralelas.

Por isso, utilizar apenas:

“Chrome abre / Chrome não abre”

é insuficiente para determinar a causa.

Ferramentas de linha de comando ajudam a reduzir essas variáveis.

---

curl pode ajudar

Versões modernas do Windows incluem curl em muitos ambientes.

Podemos testar:

curl -I https://exemplo.com

Isso solicita os cabeçalhos HTTP/HTTPS.

Também podemos utilizar modo detalhado:

curl -v https://exemplo.com

O resultado pode ajudar a identificar em qual etapa a comunicação está falhando.

Por exemplo:

• resolução DNS;
• conexão TCP;
• negociação TLS;
• resposta HTTP.

Novamente, curl não é um “detector de MTU”.

Ele ajuda a localizar a camada em que o problema aparece.

---

Tracert pode mostrar onde está a MTU menor?

Não diretamente.

Execute:

tracert destino

O tracert ajuda a visualizar parte do caminho IP até o destino.

Mas ele não informa automaticamente:

“O roteador número 7 possui MTU 1420.”

Além disso, equipamentos podem não responder às sondagens do traceroute.

Ainda assim, comparar rotas pode ser útil quando:

• um destino funciona;
• outro não;
• VPN muda a rota;
• caminhos diferentes apresentam comportamentos diferentes.

---

Pathping também pode complementar o diagnóstico

O Windows oferece:

pathping destino

A ferramenta combina características de descoberta de rota e análise de perda ao longo do caminho.

Ela pode ajudar em problemas de:

• perda;
• latência;
• instabilidade.

Mas, novamente, não devemos interpretar qualquer perda exibida como prova de MTU incorreto.

Cada ferramenta responde a uma pergunta diferente.

---

O grande teste: pequeno funciona, grande não

Um padrão particularmente interessante seria:

ping destino -f -l 500   → funciona
ping destino -f -l 1000  → funciona
ping destino -f -l 1300  → funciona
ping destino -f -l 1472  → falha

Agora temos evidência clara de que o tamanho influencia o comportamento.

Precisamos encontrar o limite e descobrir se ele é esperado para aquela rede.

Isso é muito diferente de simplesmente:

ping destino → timeout

No segundo caso, não sabemos se o tamanho tem qualquer relação com a falha.

---

E quando pacotes grandes simplesmente somem?

Aqui podemos suspeitar de um possível PMTUD Black Hole, especialmente quando:

• pacotes menores passam;
• maiores desaparecem;
• não recebemos adequadamente a sinalização necessária;
• aplicações apresentam travamentos estranhos.

Nesse cenário, uma captura de pacotes pode ser extremamente útil.

Ferramentas como o Wireshark permitem observar:

• tamanho dos pacotes;
• retransmissões TCP;
• ICMP;
• MSS;
• SYN/SYN-ACK;
• comportamento antes da falha.

Isso será aprofundado na próxima parte.

---

IPv6 muda a história

Até agora, nossos exemplos com:

ping -f

e a conta:

1472 + 28 = 1500

foram voltados ao IPv4.

IPv6 possui diferenças importantes.

No IPv6, roteadores no caminho não fragmentam pacotes da mesma maneira que no IPv4.

O host de origem precisa lidar com o tamanho apropriado e com o Path MTU Discovery.

Isso torna mensagens ICMPv6 relacionadas a pacotes grandes demais especialmente importantes.

Portanto, não devemos simplesmente aplicar a lógica do teste IPv4 sem considerar as diferenças do IPv6.

---

ICMP não deve ser bloqueado indiscriminadamente

Existe uma ideia antiga de que:

“ICMP é ping, então posso bloquear tudo.”

Isso é tecnicamente problemático.

ICMP possui funções importantes no funcionamento e diagnóstico das redes.

No contexto de PMTUD, determinadas mensagens ICMP ajudam a informar que um pacote não consegue atravessar determinado enlace no tamanho atual.

Bloquear indiscriminadamente essas mensagens pode contribuir para comportamentos de black hole.

Segurança de rede deve utilizar políticas específicas, não simplesmente eliminar protocolos necessários sem compreender sua função.

---

Alterar a MTU no Windows

Depois de medir e confirmar que uma alteração realmente é necessária, o Windows permite configurar a MTU de uma interface.

Antes de qualquer alteração, veja as interfaces:

netsh interface ipv4 show subinterfaces

Suponha que a interface seja:

Ethernet

Um exemplo de configuração seria:

netsh interface ipv4 set subinterface "Ethernet" mtu=1492 store=persistent

Não execute esse comando simplesmente porque 1492 aparece neste artigo.

O valor é apenas um exemplo.

Utilize o valor adequado ao ambiente somente quando houver motivo técnico para isso.

---

Como voltar para MTU 1500

Se você realizou um teste controlado e deseja retornar a interface ao valor anterior, supondo que o original fosse 1500:

netsh interface ipv4 set subinterface "Ethernet" mtu=1500 store=persistent

Depois confirme:

netsh interface ipv4 show subinterfaces

Sempre registre o valor original antes de alterar configurações.

---

Evite alterar várias coisas simultaneamente

Imagine que você:

1. muda MTU;
2. troca DNS;
3. reseta Winsock;
4. desativa IPv6;
5. reinstala driver;
6. reinicia roteador.

Depois o problema desaparece.

O que resolveu?

Você não sabe.

Um bom diagnóstico altera uma variável por vez.

Teste.

Registre.

Compare.

Só então avance.

---

Quando NÃO alterar a MTU do computador

Evite alterar a MTU local apenas porque:

• teste de velocidade está baixo;
• ping está alto;
• Wi-Fi está fraco;
• um site ficou fora do ar;
• alguém recomendou 1492;
• você utiliza fibra;
• sua conexão é PPPoE;
• instalou uma VPN.

Primeiro confirme que existe uma relação real entre tamanho do pacote e falha observada.

---

Um roteiro prático de diagnóstico

Podemos organizar tudo que vimos até agora:

1. Verifique configuração IP

ipconfig /all

2. Teste o gateway

ping IP_DO_GATEWAY

3. Teste conectividade externa

ping 1.1.1.1

4. Teste DNS

nslookup dominio

5. Teste TCP

Test-NetConnection dominio -Port 443

6. Teste pacotes maiores

ping destino -f -l 1472

7. Reduza progressivamente

Encontre o maior payload que funciona.

8. Some 28 no teste IPv4/ICMP

payload + 28 = PMTU aproximada

9. Compare com e sem VPN

Observe se o limite muda.

10. Só depois considere alterar configurações

Essa sequência é muito mais segura do que procurar “melhor MTU para Internet” em uma tabela.

---

Agora conseguimos transformar o conceito de MTU em um diagnóstico reproduzível.

A principal ideia é:

não precisamos adivinhar o MTU. Podemos medir o comportamento do caminho.

Também aprendemos que:

• ping pequeno não elimina problemas de MTU;
• -f impede fragmentação no teste IPv4;
• -l controla o tamanho dos dados ICMP;
• 1472 + 28 corresponde a 1500 no cenário IPv4/ICMP utilizado;
• o limite pode mudar conforme o destino;
• VPN pode criar um caminho com MTU menor;
• PPPoE ajuda a explicar por que 1492 é um valor conhecido;
• MTU da WAN não precisa ser igual à MTU da LAN;
• timeout sozinho não prova MTU incorreto;
• alterar MTU deve ser consequência do diagnóstico, não o começo dele.

Abaixo vamos entrar no nível avançado: Wireshark, TCP MSS, retransmissões, ICMP Fragmentation Needed, PMTUD Black Hole, IPv6 Packet Too Big, MSS Clamping, VPN, firewall e roteadores.

Wireshark, MSS, PMTUD Black Hole e diagnóstico avançado

Nas duas primeiras partes deste guia, construímos a base necessária para entender o problema. Vimos que a MTU define um limite de tamanho para os pacotes em determinado contexto, que o Path MTU depende do menor limite existente ao longo do caminho e que o Path MTU Discovery tenta ajustar a comunicação quando existe uma diferença entre esses limites.

Também vimos como utilizar o Windows para testar o comportamento da rede com:

ping -f -l

netsh

Get-NetIPInterface

Test-NetConnection

e outros recursos.

Agora chegamos à parte mais avançada do diagnóstico.

Aqui, o objetivo é entender o que acontece quando os pacotes realmente começam a falhar, como identificar retransmissões no TCP, como o MSS se relaciona com a MTU, por que o ICMP é tão importante para o PMTUD e como VPNs, firewalls e roteadores podem criar situações em que a Internet parece funcionar apenas parcialmente.

---

Quando reduzir a MTU resolve, mas não corrige a causa

Imagine que um computador está com problemas para acessar determinado sistema.

Você reduz a MTU de:

1500

para:

1400

e tudo começa a funcionar.

É tentador concluir:

Problema resolvido.

Mas, tecnicamente, precisamos fazer uma pergunta adicional:

Por que a comunicação só funciona quando reduzimos a MTU?

O valor menor pode ter evitado que os pacotes atinjam o tamanho que dispara a falha, mas a causa original ainda pode estar em:

• PMTUD quebrado;
• ICMP bloqueado;
• VPN mal configurada;
• MSS inadequado;
• túnel;
• firewall;
• roteador;
• equipamento da operadora.

Por isso, reduzir MTU pode funcionar como diagnóstico e até como solução prática em alguns ambientes, mas nem sempre identifica a causa raiz.

---

MTU e MSS: a relação que realmente importa no TCP

Na Parte 1, vimos que MTU e MSS não são a mesma coisa.

A MTU trata do tamanho máximo do pacote IP.

O MSS, ou Maximum Segment Size, representa a quantidade máxima de dados TCP que um host deseja receber em cada segmento.

Em um cenário IPv4/TCP simples:

MTU 1500
- 20 bytes IPv4
- 20 bytes TCP
----------------
MSS 1460

Por isso, em muitas conexões Ethernet tradicionais, encontramos:

MTU 1500 → MSS 1460

Mas existem várias situações que alteram essa conta:

• opções TCP;
• IPv6;
• VPN;
• encapsulamento;
• IPsec;
• túneis;
• outros cabeçalhos adicionais.

O princípio importante é:

o TCP precisa escolher segmentos que, depois de encapsulados, caibam no caminho.

---

Onde aparece o MSS?

O MSS é negociado durante o estabelecimento de uma conexão TCP.

Quando ocorre o famoso handshake:

SYN
↓
SYN-ACK
↓
ACK

os hosts podem anunciar o valor de MSS que desejam utilizar.

Isso ajuda cada lado a evitar o envio de segmentos de dados maiores do que o outro consegue receber adequadamente.

Em uma captura de rede, essa informação pode ser observada nos pacotes SYN.

---

Como o Wireshark mostra o MSS

Abra o Wireshark e inicie uma captura na interface correta.

Depois estabeleça uma nova conexão TCP.

Podemos utilizar um filtro como:

tcp.flags.syn == 1

Selecione um pacote SYN.

Dentro das opções TCP, procure por:

Maximum Segment Size

Você poderá encontrar algo como:

MSS: 1460

ou outro valor.

Esse número ajuda a entender como aquela conexão está sendo negociada.

---

MSS menor não significa problema

É importante não interpretar todo MSS menor que 1460 como defeito.

Se a conexão utiliza uma VPN ou outro tipo de encapsulamento, um MSS menor pode ser completamente intencional.

Por exemplo, se o túnel possui um MTU efetivo menor, anunciar um MSS também menor ajuda a evitar que os segmentos TCP produzam pacotes grandes demais.

Portanto:

MSS reduzido pode ser justamente a solução correta.

O problema aparece quando o MSS anunciado não respeita a realidade do caminho.

---

O que é TCP MSS Clamping?

O MSS Clamping é uma técnica utilizada por roteadores e firewalls para ajustar o MSS anunciado em conexões TCP.

Imagine:

Cliente
MSS 1460
↓
Roteador/VPN
↓
Túnel possui MTU menor

Se o cliente continuar utilizando segmentos compatíveis com MTU 1500, o túnel pode precisar lidar com pacotes maiores do que suporta adequadamente.

O equipamento intermediário pode então modificar o MSS anunciado.

Por exemplo:

MSS original: 1460
↓
Firewall ajusta
↓
MSS anunciado: 1360

Agora o TCP utiliza segmentos menores e os pacotes finais podem caber no túnel.

---

Por que MSS Clamping pode resolver problemas de VPN?

Porque ele atua antes de os grandes segmentos começarem a circular.

Sem MSS Clamping adequado:

TCP cria segmento grande
↓
pacote é encapsulado
↓
tamanho final fica grande demais
↓
depende de PMTUD
↓
PMTUD falha
↓
tráfego trava

Com MSS ajustado:

TCP já cria segmento menor
↓
encapsulamento
↓
pacote final cabe no caminho
↓
comunicação continua

Essa técnica é particularmente comum em:

• VPNs;
• PPPoE;
• firewalls;
• túneis;
• roteadores.

---

MSS Clamping não corrige UDP

Existe uma limitação importante.

O MSS pertence ao TCP.

Protocolos baseados em UDP não utilizam MSS TCP.

Isso significa que uma configuração de MSS Clamping pode resolver um problema em:

• HTTPS sobre TCP;
• RDP;
• SMB;
• aplicações TCP;

mas não necessariamente corrige aplicações que utilizam UDP.

Esse detalhe se tornou ainda mais relevante com protocolos modernos.

---

HTTP/3 e QUIC podem complicar o diagnóstico

Navegadores modernos podem utilizar HTTP/3, que funciona sobre QUIC e UDP.

Assim, um site pode apresentar um comportamento diferente dependendo do protocolo negociado.

Isso significa que:

site funcionando via TCP não garante comportamento idêntico via QUIC

e vice-versa.

Por isso, em um diagnóstico muito avançado, é importante lembrar que a navegação moderna não depende exclusivamente de TCP/443.

Esse também é um motivo para evitar conclusões baseadas apenas em um único teste.

---

Wireshark: procurando retransmissões

Quando o TCP envia dados e não recebe confirmação adequada, pode retransmitir os segmentos.

No Wireshark, filtros úteis incluem:

tcp.analysis.retransmission

e:

tcp.analysis.fast_retransmission

Se uma aplicação trava durante transferências e aparecem várias retransmissões, sabemos que existe perda ou ausência de confirmações.

Isso ainda não prova que a causa seja MTU.

Mas podemos correlacionar:

• tamanho dos pacotes;
• momento da falha;
• presença de ICMP;
• retransmissões;
• comportamento com MTU menor.

A correlação é o que transforma os dados em diagnóstico.

---

Um padrão típico de PMTUD Black Hole

Imagine a seguinte sequência:

1. conexão TCP é criada;
2. pequenos pacotes passam;
3. aplicação começa a transmitir dados maiores;
4. determinados pacotes desaparecem;
5. nenhuma mensagem adequada de erro retorna;
6. TCP retransmite;
7. retransmite novamente;
8. aplicação parece congelar.

Para o usuário:

“O site começa a abrir e trava.”

Para o técnico:

há um fluxo que funcionou até determinado ponto e depois entrou em retransmissões.

Esse é um cenário em que MTU e PMTUD merecem investigação.

---

Como procurar ICMP no Wireshark

Para IPv4, podemos utilizar:

icmp

Em cenários relacionados a MTU, uma das mensagens importantes historicamente envolve a necessidade de fragmentação.

Dependendo do equipamento e do caminho, podemos observar informações indicando que o pacote não pode seguir no tamanho atual.

Se essas mensagens aparecem corretamente, o PMTUD possui informações para se ajustar.

Se deveriam existir, mas são bloqueadas, pode surgir um black hole.

---

ICMP não é apenas ping

Esse ponto é tão importante que merece ser repetido.

Muitas pessoas associam:

ICMP = ping

e concluem:

“Não uso ping, então posso bloquear ICMP inteiro.”

Isso pode quebrar mecanismos importantes da rede.

ICMP carrega várias mensagens de controle e erro.

Entre elas estão informações úteis para:

• destino inalcançável;
• problemas de rota;
• limite de tamanho;
• tempo excedido.

Bloquear ICMP indiscriminadamente pode prejudicar o funcionamento normal da rede.

---

O papel do ICMP no PMTUD IPv4

No PMTUD tradicional IPv4, quando um roteador encontra um pacote grande demais e não pode fragmentá-lo devido ao DF, ele pode informar o remetente sobre o problema.

Essa informação permite que a origem reduza o tamanho dos pacotes.

Podemos representar:

PC envia pacote
↓
DF ativo
↓
roteador encontra MTU menor
↓
não pode fragmentar
↓
envia ICMP para origem
↓
origem reduz tamanho

Se a mensagem ICMP for bloqueada:

PC envia pacote
↓
roteador descarta
↓
ICMP é bloqueado
↓
PC não sabe por quê
↓
retransmissões

É assim que podemos chegar a um black hole de PMTU.

---

Firewall pode ser o responsável

Imagine uma empresa com uma política de firewall:

Bloquear todo ICMP

A intenção talvez tenha sido “aumentar a segurança”.

Mas essa regra pode prejudicar o funcionamento de mecanismos legítimos.

Uma política mais madura diferencia:

• tipos de ICMP;
• direção;
• origem;
• destino;
• função da mensagem.

Segurança não significa bloquear tudo.

Significa permitir o necessário e restringir o que realmente representa risco.

---

E no IPv6?

No IPv6, o tratamento da fragmentação é diferente.

Roteadores no caminho não fragmentam pacotes IPv6 da mesma maneira que ocorre em determinados cenários IPv4.

Quando um pacote é grande demais, uma mensagem ICMPv6 Packet Too Big é fundamental para que a origem ajuste o tamanho.

Isso torna o bloqueio indiscriminado de ICMPv6 ainda mais problemático.

Podemos representar:

Host IPv6
↓
pacote grande
↓
roteador com MTU menor
↓
ICMPv6 Packet Too Big
↓
host reduz o tamanho

Se essa mensagem não chega, o caminho pode apresentar falhas difíceis de diagnosticar.

---

PMTUD e IPv6 são ainda mais importantes

Como os roteadores não simplesmente fragmentam os pacotes IPv6 durante o percurso, a origem precisa conhecer o tamanho adequado.

Por isso, mecanismos de descoberta de MTU e mensagens ICMPv6 fazem parte do funcionamento normal do IPv6.

Desativar IPv6 apenas porque determinado site não abre pode fazer o sintoma desaparecer em alguns casos, mas não necessariamente corrige a causa.

Esse tipo de mudança deve ser tratado como teste, não como solução universal.

---

Por que desativar IPv6 às vezes “resolve”?

Imagine:

IPv4: caminho funciona.

IPv6: existe problema de PMTU ou roteamento.

O navegador prefere IPv6 quando disponível.

Resultado:

site falha.

Você desativa IPv6.

O sistema passa a utilizar IPv4.

Resultado:

site funciona.

O usuário conclui:

“IPv6 é ruim.”

Mas isso não é necessariamente verdade.

O que você demonstrou foi:

o caminho IPv6 possui algum problema que o IPv4 não possui.

A próxima etapa deveria ser descobrir qual.

---

Como comparar IPv4 e IPv6

No Windows:

ping -4 dominio

e:

ping -6 dominio

Também podemos utilizar:

tracert -4 dominio

e:

tracert -6 dominio

Esses testes ajudam a comparar os dois caminhos.

As rotas podem ser completamente diferentes.

Isso é especialmente importante quando um problema aparece somente em IPv6.

---

VPN sobre IPv6 pode ter outro overhead

O encapsulamento também muda conforme o protocolo externo utilizado.

Um túnel sobre IPv6 possui cabeçalhos diferentes de um túnel sobre IPv4.

Por isso, cálculos de overhead devem considerar a tecnologia real.

Não existe uma única fórmula universal como:

MTU da VPN = 1400

O valor correto depende do protocolo e do ambiente.

---

Captura com e sem VPN

Uma técnica muito útil é realizar duas capturas.

Captura A — VPN desligada

Observe:

• MSS;
• tamanho dos pacotes;
• retransmissões;
• ICMP;
• comportamento do site.

Captura B — VPN ligada

Observe os mesmos elementos.

Agora compare.

Se a falha surge apenas depois da ativação do túnel e o padrão de tamanho/retransmissão muda, temos uma pista importante.

---

A VPN pode ter sua própria interface MTU

Muitos clientes VPN criam interfaces virtuais.

No Windows, execute:

Get-NetIPInterface

Você pode encontrar:

Ethernet
Wi-Fi
VPN

com MTUs diferentes.

Isso é perfeitamente possível e pode ser intencional.

A interface virtual pode precisar utilizar um valor menor para acomodar o encapsulamento realizado depois.

---

Roteador pode fazer o ajuste sem o computador perceber

Em muitas redes, o computador continua com:

MTU 1500

e tudo funciona.

Isso acontece porque:

• o roteador lida corretamente com PMTUD;
• MSS Clamping está adequado;
• o túnel ajusta os pacotes;
• mensagens ICMP chegam normalmente.

Portanto, não existe necessidade de alterar manualmente todos os computadores apenas porque existe um enlace com MTU menor em algum ponto.

Uma boa infraestrutura deve esconder essa complexidade do usuário sempre que possível.

---

Quando alterar MTU no roteador é melhor que alterar em todos os PCs?

Se a causa está na saída da rede ou em um túnel centralizado, pode fazer mais sentido corrigir o equipamento responsável.

Imagine 30 computadores.

Todos apresentam o mesmo problema.

Alterar cada máquina individualmente:

30 PCs × alteração manual

provavelmente não é a melhor arquitetura.

Se todos passam pelo mesmo roteador com configuração inadequada, corrigir o ponto central pode ser mais consistente.

Novamente, depende do ambiente e do equipamento.

---

Quando o problema está na operadora

Nem sempre a rede local é culpada.

Pode existir:

• falha de roteamento;
• túnel da operadora;
• configuração incorreta;
• problema de PMTUD em algum trecho;
• equipamento intermediário;
• filtragem indevida.

Uma evidência interessante é quando:

• sua LAN está normal;
• outro provedor acessa o destino normalmente;
• sua conexão apresenta falha repetível;
• VPN por outro caminho faz o site funcionar.

Isso não prova automaticamente que a operadora é culpada, mas ajuda a construir um caso técnico.

---

VPN pode ser usada como diagnóstico

Existe um teste interessante.

Imagine que determinado site não funciona normalmente.

Você ativa uma VPN.

O site passa a funcionar.

Isso demonstra que alguma coisa mudou.

A VPN pode alterar:

• rota;
• DNS;
• endereço de origem;
• MTU;
• MSS;
• protocolo;
• caminho até o destino.

Portanto, dizer:

“funcionou com VPN”

não identifica sozinho a causa.

Mas é uma evidência extremamente útil.

---

Trocar DNS pode produzir a mesma confusão

Se você troca o DNS e o site passa a funcionar, pode parecer que o problema era necessariamente DNS.

Mas o novo resolvedor pode entregar um endereço de CDN diferente.

Agora o navegador acessa outro servidor por outra rota.

Portanto, até uma alteração aparentemente simples pode mudar o caminho.

Esse é um bom exemplo de por que testes precisam ser interpretados com cuidado.

---

CDN pode fazer o mesmo site usar caminhos diferentes

Grandes serviços utilizam redes de distribuição de conteúdo.

O mesmo domínio pode resolver para servidores diferentes dependendo de:

• localização;
• provedor;
• DNS;
• disponibilidade;
• balanceamento;
• Anycast.

Assim, dois computadores podem acessar o “mesmo site” por caminhos distintos.

Isso ajuda a explicar por que determinados problemas aparecem apenas em uma operadora ou região.

---

MTU e HTTPS

HTTPS envolve TLS sobre o transporte utilizado.

A conexão pode:

1. resolver DNS;
2. estabelecer transporte;
3. iniciar TLS;
4. trocar certificados e parâmetros;
5. começar a transferir conteúdo.

Se a falha começa apenas quando determinados pacotes maiores entram na comunicação, o site pode parecer travar durante o TLS ou logo depois.

Isso não significa que o certificado esteja necessariamente com problema.

Precisamos observar em qual etapa o fluxo interrompe.

---

curl -v pode ajudar a localizar a etapa

Execute:

curl -v https://dominio

O modo detalhado pode mostrar informações sobre:

• resolução;
• conexão;
• TLS;
• resposta HTTP.

Se o processo para em uma etapa consistente, temos uma pista.

Combine isso com:

• Wireshark;
• ping com DF;
• Test-NetConnection;
• comparação com VPN.

Nenhuma ferramenta isolada precisa dar toda a resposta.

---

Um exemplo prático de diagnóstico completo

Imagine o seguinte chamado:

“A Internet funciona, mas o sistema da empresa não abre quando estou trabalhando de casa.”

Começamos:

1. Rede local

ping gateway

Funciona.

2. Internet

ping 1.1.1.1

Funciona.

3. DNS

nslookup sistema.empresa.com

Funciona.

4. Porta

Test-NetConnection sistema.empresa.com -Port 443

Funciona.

5. Navegador

Página começa a carregar e congela.

6. Sem VPN

Internet normal.

7. Com VPN corporativa

Problema aparece.

8. Ping pequeno pelo túnel

Funciona.

9. Ping maior com DF

Falha acima de determinado tamanho.

Agora temos uma hipótese muito mais forte de:

MTU/MSS/túnel/PMTUD

do que tínhamos no começo.

---

Wireshark confirma retransmissões

Capturamos o tráfego.

Observamos:

• handshake TCP normal;
• MSS anunciado;
• primeiros segmentos funcionando;
• segmentos maiores sendo retransmitidos;
• ausência da sinalização esperada.

Agora o diagnóstico possui várias evidências convergentes.

Isso é muito diferente de simplesmente alterar a MTU para 1400 “porque alguém recomendou”.

---

Como interpretar retransmissões com cautela

Retransmissões também podem ocorrer por:

• Wi-Fi ruim;
• congestionamento;
• perda na operadora;
• servidor sobrecarregado;
• buffer;
• falha física.

Portanto, retransmissão não significa automaticamente MTU.

Procure a combinação:

falha dependente de tamanho + retransmissões + caminho específico + mudança com MTU/VPN + ausência/presença de ICMP

Quanto mais evidências apontam na mesma direção, mais forte fica o diagnóstico.

---

O MTU pode afetar velocidade sem derrubar a conexão?

Sim, em alguns cenários.

Se existe fragmentação excessiva ou utilização de pacotes menores do que o necessário, pode haver aumento de overhead.

Porém, uma MTU menor não significa automaticamente uma Internet “muito mais lenta”.

O impacto depende:

• volume de dados;
• protocolo;
• CPU;
• encapsulamento;
• latência;
• taxa de pacotes.

Para problemas comuns de velocidade, ainda vale investigar primeiro:

• link Ethernet;
• Wi-Fi;
• sinal;
• interferência;
• congestionamento;
• equipamento.

---

Jumbo Frames: aumentar MTU melhora a Internet?

Normalmente, não.

Em redes locais específicas, podemos utilizar Jumbo Frames, com MTUs maiores que 1500.

Isso pode ser útil em determinados ambientes, especialmente redes controladas de alto desempenho.

Mas configurar Jumbo Frames em um computador não faz a Internet ficar automaticamente mais rápida.

Todos os equipamentos do caminho local relevante precisam suportar a configuração adequada.

Misturar MTUs sem planejamento pode causar problemas em vez de melhorar desempenho.

---

Não configure MTU 9000 para acessar a Internet

Esse é um bom exemplo de otimização fora de contexto.

Uma rede de armazenamento local pode ser projetada para Jumbo Frames.

A Internet pública, porém, possui caminhos diversos.

O fato de sua placa suportar MTU 9000 não significa que o caminho externo suporte o mesmo tamanho.

Por isso, Jumbo Frames devem ser utilizados dentro de ambientes controlados onde existe motivo técnico.

---

MTU automático é geralmente a melhor escolha

Na maioria das redes domésticas, o usuário não precisa mexer manualmente na MTU.

Roteadores, sistemas operacionais e protocolos modernos foram projetados para lidar com essas diferenças.

Se tudo funciona normalmente:

não altere a MTU apenas para “otimizar”.

MTU é principalmente algo a investigar quando existe um sintoma compatível.

---

Quando vale alterar manualmente?

Uma mudança manual pode fazer sentido quando:

• documentação do provedor ou VPN exige;
• testes confirmam determinado limite;
• equipamento não ajusta corretamente;
• solução corporativa possui configuração recomendada;
• workaround é necessário enquanto a causa central é corrigida;
• ambiente é controlado e administrado.

Mesmo assim, registre:

• valor original;
• valor novo;
• motivo;
• resultado.

---

Como saber se a alteração realmente resolveu?

Depois da mudança, repita os mesmos testes.

Se antes:

1472 → falhava
1400 → funcionava

e agora a aplicação funciona, documente.

Mas também compare:

• com VPN;
• sem VPN;
• diferentes destinos;
• TCP;
• UDP quando relevante;
• IPv4;
• IPv6.

A solução deve ser consistente, não apenas “pareceu melhor”.

---

Erros comuns em diagnósticos de MTU

1. Usar um único ping

Ping pequeno funcionando não elimina problemas de tamanho.

2. Testar um destino que bloqueia ICMP

Sem resposta não significa MTU incorreta.

3. Esquecer os 28 bytes no IPv4/ICMP

-l 1472 não significa MTU 1472.

4. Configurar 1492 em qualquer conexão

1492 é conhecido em determinados cenários, não é valor universal.

5. Alterar MTU antes de confirmar DNS e gateway

Pode estar tentando resolver o problema errado.

6. Desativar IPv6 permanentemente sem diagnosticar

Pode apenas mascarar uma falha no caminho IPv6.

7. Ignorar VPN e túneis

Eles podem mudar completamente o tamanho efetivo disponível.

8. Bloquear ICMP inteiro

Isso pode prejudicar PMTUD e outros mecanismos legítimos.

---

Checklist avançado de MTU

Quando o sintoma justificar investigação, siga esta sequência:

1. Confirme IP, gateway e DNS.
2. Teste conectividade básica.
3. Verifique se o destino responde a ICMP.
4. Teste pacotes pequenos.
5. Teste pacotes maiores com DF no IPv4.
6. Encontre o maior payload funcional.
7. Calcule o PMTU aproximado.
8. Compare diferentes destinos.
9. Compare com e sem VPN.
10. Verifique MTU das interfaces.
11. Observe rotas.
12. Analise MSS nos SYNs.
13. Procure retransmissões.
14. Verifique mensagens ICMP/ICMPv6.
15. Investigue MSS Clamping.
16. Confira firewall e túnel.
17. Só depois altere configurações.

---

Perguntas frequentes sobre MTU

O que é MTU?

MTU é a Unidade Máxima de Transmissão e representa o maior tamanho de pacote IP que pode ser transportado em determinado contexto sem ultrapassar o limite daquele enlace ou interface.

Qual é a melhor MTU para Internet?

Não existe um único valor ideal para todas as conexões. 1500 é comum em Ethernet, mas PPPoE, VPNs e túneis podem exigir valores diferentes.

MTU 1492 é melhor que 1500?

Não necessariamente. 1492 aparece frequentemente em contextos relacionados a PPPoE, mas reduzir a MTU sem motivo pode apenas diminuir a eficiência da conexão.

Como testar MTU no Windows?

No IPv4, pode-se utilizar ping com as opções -f e -l, aumentando ou reduzindo o tamanho até encontrar o maior payload que atravesse o caminho sem fragmentação.

Por que somar 28 ao resultado do ping?

Em um teste IPv4/ICMP comum, consideramos 20 bytes do cabeçalho IPv4 e 8 bytes do ICMP. Assim, payload de 1472 bytes corresponde a um pacote IP de 1500 bytes.

VPN pode causar problema de MTU?

Sim. VPNs adicionam encapsulamento, reduzindo o espaço disponível para o pacote interno em determinados caminhos.

O que é PMTUD Black Hole?

É uma situação em que pacotes grandes demais são descartados, mas a informação necessária para que a origem reduza o tamanho não chega adequadamente. O resultado pode ser uma conexão que funciona apenas parcialmente.

Bloquear ICMP pode causar problemas?

Sim. ICMP não serve apenas para ping. Algumas mensagens são importantes para diagnóstico e para mecanismos como Path MTU Discovery.

Alterar MTU pode melhorar a velocidade?

Somente em situações específicas. Para problemas comuns de velocidade, causas como Wi-Fi, cabo, negociação Ethernet e congestionamento normalmente devem ser investigadas primeiro.

MTU e MSS são a mesma coisa?

Não. MTU refere-se ao tamanho máximo do pacote IP, enquanto MSS define a quantidade máxima de dados TCP anunciada durante a conexão.

---

Conclusão

Problemas relacionados à MTU são um excelente exemplo de como uma rede pode estar funcionando e falhando ao mesmo tempo.

O computador possui endereço IP.

O gateway responde.

O DNS funciona.

O site começa a carregar.

A VPN conecta.

Ainda assim, determinados dados não conseguem atravessar o caminho corretamente.

É por isso que o diagnóstico precisa ir além da pergunta:

“Tem Internet?”

A pergunta correta passa a ser:

“Qual parte da comunicação funciona, qual tamanho de pacote atravessa e o que muda quando o caminho muda?”

Entender MTU, Path MTU, PMTUD, MSS e encapsulamento permite identificar situações que muitas vezes são confundidas com:

• DNS;
• navegador;
• antivírus;
• servidor fora do ar;
• problema da operadora;
• VPN defeituosa.

A principal regra continua sendo a mesma utilizada em outros diagnósticos técnicos da VMIA:

não altere configurações antes de medir e compreender o comportamento da rede.

Um valor de MTU encontrado em um fórum pode fazer o sintoma desaparecer, mas um diagnóstico correto explica por que aquele valor funcionou.

---

Precisa descobrir por que sua Internet funciona apenas parcialmente?

A VMIA – Manutenção e Configuração realiza diagnóstico de problemas de rede em computadores Windows, notebooks, roteadores, Wi-Fi, VPNs e redes Mesh.

Situações como:

• alguns sites abrem e outros não;
• VPN conecta, mas o sistema não funciona;
• Internet trava somente em determinadas aplicações;
• downloads ou uploads interrompem;
• problemas de DNS, IPv4, IPv6, MTU e roteamento;

podem exigir uma análise mais detalhada do que simplesmente reiniciar o roteador.

A VMIA trabalha com diagnóstico técnico para identificar se a falha está no Windows, no adaptador, no Wi-Fi, no roteador, na VPN, no DNS ou no caminho até o serviço utilizado.

Atendimento com agendamento, incluindo suporte remoto quando o problema pode ser analisado à distância e atendimento presencial quando é necessário verificar a infraestrutura local.