Configuração de NAT MTU duplo para a rede interna


0

Eu tenho uma rede doméstica com dois roteadores, um atrás do outro. A porta WAN do roteador externo é uma conexão PPPoE VDSL2 com um endereço IP ativo e o tamanho MTU de 1492. A porta WAN do roteador interno é atribuída via DHCP como apenas outro cliente na rede LAN do roteador externo. O padrão MTU para ele era 1500 por padrão. Eu mudei para 1492 para combinar com o roteador externo.

Agora me pergunto se faz algum sentido reduzir ainda mais o tamanho da MTU para a rede interna. Isso tornaria a rede interna mais robusta nesse cenário duplo de NAT?


Você tem um motivo para duplicar o NAT? Geralmente é muito mais fácil conectar a rede e estendê-la.
Tim_Stewart

@Tim_Stewart, a razão é principalmente manter meus PCs / VMs / dispositivos relacionados ao trabalho atrás de um firewall separado dos demais usuários / dispositivos da minha rede doméstica, mas ainda assim poder ver e acessá-los.
noseratio

Respostas:


3

O NAT apenas altera endereços IP / portas nos pacotes, não inclui nenhuma informação extra (cabeçalhos, etc.) no pacote. Portanto, ele não reduz o MTU de nenhuma maneira, e ter o mesmo MTU é bom.


Devo ainda estar configurando a WAN MTU no roteador interno para 1492? Ou deixá-lo em 1500?
noseratio

1
A descoberta de MTU pode ser complicada e eu não sou especialista em todos os casos que podem dar errado, ou que funcionará mesmo com MTUs diferentes. Se você tiver um desempenho ruim em pacotes de saída, a primeira coisa a tentar é definitivamente configurar o MTU no roteador interno para 1492, para evitar a fragmentação dos pacotes de saída. E não faz mal fazer isso desde o começo. Em dúvida, meça com o tcpdump, etc., para ver se algo está fragmentado.
Dirkt

1

Embora o NAT não aumente o tamanho dos pacotes (ou, talvez de forma mais precisa, diminua o tamanho máximo de carga útil por pacote), o PPOE e outros protocolos de encapsulamento geralmente fazem isso.

No entanto, os sistemas operacionais mais modernos implementaram o Path MTU Discovery , descrito na RFC1191 , que, de maneira ideal, adaptará pacotes de saída àquele do menor MTU de qualquer um dos links entre o host de envio e o destino, automaticamente. Ele faz isso configurando o DF bit(Não Fragmentar) em pacotes de saída grandes e procura por um erro de ICMP Fragmentation Needed.

No MacOS e em outros sistemas operacionais semelhantes ao Unix, o pingutilitário possui vários comutadores que podem definir DF bit, definir o tamanho da carga útil e até varrer um intervalo de tamanhos, determinando efetivamente uma MTU entre o host de origem e o destino. Há 8 bytes de sobrecarga nos ICMP Echo Request pingenvios e 20 bytes de sobrecarga no pacote IP, fazendo com que a carga máxima de 1472 para um pacote de ping com o DF bitconjunto em uma interface de MTU de 1500 bytes.

Você pode configurar seu MTU mais baixo para otimizar, de uma maneira muito pequena, esse caminho específico, em troca de um tamanho de pacote muito menos otimizado para todos os outros fluxos de pacotes dos quais o host participa.

Portanto, a menos que você tenha problemas com a transferência de arquivos, talvez seja melhor deixar o sistema operacional lidar com o MTU automaticamente.

[nevin-mac-mini: ~] nevin% ping -c 1 -D -s 1472 192.168.2.1
PING 192.168.2.1 (192.168.2.1): 1472 bytes de dados
1480 bytes de 192.168.2.1: icmp_seq = 0 ttl = 64 tempo = 0,667 ms

--- estatísticas de ping 192.168.2.1 ---
1 pacote transmitido, 1 pacote recebido, 0.0% de perda de pacote
viagem de ida e volta min / avg / max / stddev = 0,667 / 0,667 / 0,667 / 0,000 ms
[nevin-mac-mini: ~] nevin% ping-c 1 -D -s 1473 192.168.2.1
PING 192.168.2.1 (192.168.2.1): 1473 bytes de dados
ping: sendto: Mensagem muito longa

--- estatísticas de ping 192.168.2.1 ---
1 pacotes transmitidos, 0 pacotes recebidos, 100,0% de perda de pacotes

Obrigado pela resposta, estou ciente do PMTUD e até mesmo implementei o MSS Clamping no meu roteador ( eis um acompanhamento sobre isso), mas ainda tenho problemas ocasionais com sites HTTPS no Chrome / Win10. Eu vou configurar manualmente o MTU manualmente via netsh e ver se ele muda alguma coisa.
noseratio

1
Eu não tenho acesso a nenhuma caixa de janelas para ver a implementação mais recente ping, mas a versão MacOS / BSD permite varrer o tamanho com os sinalizadores -g / -G, portanto ping -D -g 1450 -G 1500 host.name, ajudaria. Seus problemas envolvem o envio de dados (como o upload de imagens) ou o recebimento? Se este último, então o possível problema de MTU está no lado remoto, e quase fora de seu controle: Assegure-se de que seus dispositivos possam enviar mensagens de erro ICMP quando grandes pacotes forem recebidos.
Nevin Williams
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.