Questão Uma conexão PPPoE residencial pode acessar todos os sites, independentemente das configurações de MTU da infraestrutura do site?


Eu só estou tentando dar a volta na cabeça MTU, MRU e MSS.

Meu interesse inicialmente veio da resposta neste post: Risco de segurança do PING?:

Alguns tipos de pacotes ICMP NÃO DEVEM ser bloqueados, em particular a mensagem ICMP "destination unreachable", porque bloqueia aquele que quebra a descoberta MTU path, sintomas sendo que usuários DSL (atrás de uma camada PPPoE que restringe MTU a 1492 bytes) não podem acessar sites que bloquear esses pacotes (a menos que eles usem o proxy da Web fornecido pelo seu ISP).

Eu já encontrei Este artigo que apoia isso:

Algumas pessoas que executam servidores da Web (principalmente alguns bancos) configuram sua rede para bloquear a mensagem de erro que é enviada quando um pacote é muito grande. Isso não seria muito ruim se eles também não tentassem enviar pacotes de 1.500 bytes com o conjunto de bits DF. O resultado é que o pacote é descartado quando atinge um link de 1.500 MTU e precisa tentar novamente. Eventualmente, pode tentar um tamanho de pacote menor, mas isso pode ser 20 segundos depois. Esta é uma configuração de rede estúpida por parte da pessoa que está executando o servidor da web.

Minha pergunta é: isso é realmente um problema real? Tanto quanto eu sei, eu nunca vi isso acontecer na minha conexão BT Infinity que usa PPPoE. Presumivelmente, isso tem as mesmas restrições mencionadas acima (o MTU do meu roteador está configurado para 1492).

Poderia ser meu roteador empregando silenciosamente Fixação MSS?


1


origem


Quantos anos são esses artigos? Esta foi uma questão muito quente no final dos anos 90, início dos anos 00; não tanto hoje. - Nevin Williams
@NevinWilliams: O post do Sec.SE é de 2011 e o que menciona o exemplo do banco é 2009. Estaria interessado em saber por que isso não é um problema hoje em dia? - SilverlightFox
Não assim uma questão muito hoje. Políticas corporativas, práticas comuns e até mesmo pilhas de PI acabam se adaptando, embora muitas vezes a uma velocidade glacial, para corrigir esses tipos de problemas. Os remédios para um problema particularmente generalizado podem vir de um ou vários níveis: padrões do kernel, padrões de pacotes de software, modelos de configuração, intervenção do ISP, recursos de software do roteador, protocolos alternativos, dependência reduzida de serviços depreciativos. - Nevin Williams


Respostas:


MTU significa unidade máxima de transmissão, ou seja. o limite de tamanho do datagrama IP (em bytes). A MTU padrão e máxima permitida pela Ethernet é 1500.

Vamos imaginar que temos uma rede como a abaixo. C é um cliente; S é um servidor; X e Y são roteadores.

 ___          ___          ___          ___
| C |        | X |        | Y |        | S |
|___|========|___|--------|___|========|___|

Existem quatro redes entre C e S. Três delas têm um MTU máximo de 1500 e um MTU inferior de 1200 (apenas um exemplo). A rede baixa de MTU é marcada com traços.

C tenta Path MTU Discovery no caminho para S. Ele envia um datagrama IP com 20 B header e 1480 B payload, 1500 B no total. o Não fragmentar O sinalizador (DF) é definido no cabeçalho IP.

O datagrama alcança X. X tenta passá-lo ainda mais para Y, mas Y responde com Fragmentação necessária Mensagem ICMP porque sua MTU é muito baixa e o sinalizador DF está definido. C recebe essa mensagem e descobre que a MTU do caminho é menor que 1500. Ela então tenta novamente com carga útil menor, cada vez que recebe Fragmentação necessária, até que o tamanho da carga útil atinja 1180 B. 1180 + 20 = 1200, de modo que o datagrama finalmente atinja S com êxito e a MTU do caminho seja descoberta.

PMTUD funciona apenas se Y responder com Fragmentação necessária Mensagens ICMP. Caso contrário, C não saberá que o datagrama foi descartado.

Seu roteador envia mensagens ICMP adequadas, tudo funciona conforme o esperado, não há motivo para a Internet ser quebrada por causa de um MTU mais baixo.


O que acontece se o PMTUD não funcionar? (por exemplo, por causa do ICMP bloqueado em qualquer direção)

Nenhuma das extremidades da conexão realmente precisa conhecer o caminho MTU. O protocolo IP pode lidar com isso. Pode ser sub-ótimo, mas funcionará.

O IP é capaz de transmitir uma carga útil de qualquer tamanho, não importando qual seja o caminho da MTU. Esta propriedade é reforçada pelo Modelo OSI: IP funciona na camada 3. A camada 4 não deve se preocupar com o protocolo subjacente, portanto, nenhum limite de tamanho pode ser colocado na carga útil.

Cabeçalho IP básico é 20 bytes de comprimento. Incluído neste cabeçalho são duas bandeiras interessantes: Não fragmentar (DF) e Mais fragmentos (MF), e também o Deslocamento de fragmento campo (FO). Eu já mencionei 20 tamanho de cabeçalho B e a bandeira DF antes. (Estou falando sobre Cabeçalho IPv4O IPv6 é diferente)

O IP é capaz de dividir uma grande carga útil em fragmentos e remontá-lo ao destino.

Digamos que queremos transmitir uma carga útil de 5000 B de C para D, ambas na mesma rede (ou seja, conectadas por meio de um switch ou hub). O MTU das NICs de C e D é 1500. Cada cabeçalho de fragmento tem 20 B de comprimento, portanto, o tamanho máximo de dados para um único datagrama é 1480 B (1500 - 20). A carga será enviada em 4 datagramas: (MF - Mais fragmentos, FO - Deslocamento de fragmento)

  1. Bytes 1-1480, MF: 1, FO: 0
  2. Bytes 1481-2560, MF: 1, FO: 1480
  3. Bytes 2561-4440, MF: 1, FO: 2560
  4. Bytes 4441-5000, MF: 0, FO: 4440

A bandeira do DF não importa neste caso. MF é 0 para o último fragmento, 1 caso contrário. FO é o deslocamento do primeiro byte em um fragmento (os deslocamentos são indexados começando com 0). Esses datagramas serão automaticamente remontados na NIC de destino.

Agora, C quer enviar uma carga útil de 5000 B para S. Suponhamos que ela magicamente conhece o caminho MTU (ou a NIC de C está configurada com MTU = 1200, portanto, C envia datagramas de 1200 B). Ele fragmentará a carga assim:

  1. Bytes 1-1180, MF: 1, FO: 0
  2. Bytes 1181-2360, MF: 1, FO: 1180
  3. Bytes 2361-3540, MF: 1, FO: 2360
  4. Bytes 3541-4720, MF: 1, FO: 3540
  5. Bytes 4721-5000, MF: 0, FO: 4720

Essa é a fragmentação mais ideal da carga útil.

Se C não souber e não puder determinar o caminho MTU, ele deve confiar nos nós intermediários para fragmentar a carga corretamente. C tem MTU = 1500, então envia 4 datagramas como mostrado no exemplo C → D acima. No entanto, esses datagramas terão que ser fragmentados novamente para serem transmitidos através da conexão X-Y. Cada um dos datagramas recebidos por Y tem que ter, no máximo, 1200B de comprimento, então datagramas de 1500B de comprimento serão divididos em dois: 1200B e 320B (20B extra para o segundo cabeçalho). Esta fragmentação resulta em 7 datagramas (e, portanto, 7 cabeçalhos) sendo transmitidos de X para S em vez do ótimo 5:

  1. Bytes 1-1180, MF: 1, FO: 0
  2. Bytes 1181-1480, MF: 1, FO: 1180
  3. Bytes 1481-2260, MF: 1, FO: 1480
  4. Bytes 2261-2560, MF: 1, FO: 2260
  5. Bytes 2561-4140, MF: 1, FO: 2560
  6. Bytes 4141-4440, MF: 1, FO: 4140
  7. Bytes 4441-5000, MF: 0, FO: 4440

Note que desta vez os fragmentos não são iguais. Os datagramas não são recombinados e fragmentados novamente de forma otimizada em nós intermediários, apenas a fragmentação é executada.

Na prática, os roteadores intermediários podem ser configurados para negar a própria fragmentação e exigir que os terminais de transmissão usem MTUs ideais, portanto, a fragmentação de nós intermediários não deve ser confiável. O PMTUD é o preferido.


5



Obrigado. No seu exemplo, o S precisa testar o PMTUD para a resposta ao C? E se o firewall (no exemplo do banco) estiver configurado para não permitir nenhum tipo de pacote ICMP de qualquer forma (digamos que isso seja entre X e Y)? Eu acho que seria quebrar as coisas, no entanto eu não tendem a ouvir esse tipo de problema com muita freqüência. - SilverlightFox
@SilverlightFox Se o PMTUD falhar em qualquer direção, o remetente ainda poderá tentar confiar nos roteadores intermediários para executar a fragmentação. Por favor, veja minha edição para detalhes. - gronostaj
que parece muito impressionante, você pode fornecer alguma fonte para aprender essas coisas? - barlop
@barlop eu posso recomendar O guia TCP / IP, está disponível online gratuitamente e abrange muitas coisas relacionadas a redes. - gronostaj
@gronostaj: Felicidades - minha pergunta parece ter sido encerrada. Eu agora editei. Alguma chance de votar para reabri-lo, se você acha que agora está no tópico? - SilverlightFox