Segurança : Cisco Compatible IntraGuard Firewall Series

Notas Técnica dos compatíveis com o sistema: Fragmentação de IP e descoberta de caminho MTU com VPN

16 Janeiro 2016 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (6 Novembro 2015) | Feedback


Índice


Introdução

Este documento descreve o framentation IP e a descoberta de caminho MTU com VPN.

Pré-requisitos

Requisitos

Não existem requisitos específicos para este documento.

Componentes Utilizados

Este documento não se restringe a versões de software e hardware específicas.

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a sua rede estiver ativa, certifique-se de que entende o impacto potencial de qualquer comando.

Convenções

Consulte as Convenções de Dicas Técnicas da Cisco para obter mais informações sobre convenções de documentos.

Edições da fragmentação de IP

A família do protocolo IP foi criada para usar uma ampla variedade de enlaces de transmissão. A extensão máxima do pacote de IP é de 65000+ bytes. A maioria de enlaces de transmissão reforçam um limite menor do comprimento máximo do pacote, chamado unidade de transmissão máxima, ou MTU, que varia com o tipo do enlace de transmissão. O design do IP acomoda limites de comprimento de pacote de enlace ao permitir que os roteadores intermediários fragmentem os pacotes de IP, conforme for necessário para seus enlaces de saída. O destino final de um pacote IP é responsável pela remontagem de seus fragmentos conforme necessário.

Por exemplo, o MTU para a maioria de encapsulamento comum do IP sobre um enlace de transmissão dos Ethernet (RFC 894leavingcisco.com ) é 1500 bytes. Por convenção o MTU inclui o IP datagram inteiro, incluindo todos os cabeçalhos IP, mas exclui cabeçalhos de encapsulamento do link. Os cabeçalhos extras de nível de link para o encapsulamento RFC 894 abrange 18 bytes, para um tamanho máximo de estrutura de Ethernet de 1518 bytes.

Na teoria a fragmentação deve ser no pior dos casos um problema de desempenho razoavelmente menor, mas na prática pode conduzir a uma incapacidade completa comunicar-se usando pacotes longos. A descoberta de MTU de caminho, uma técnica comum para evitar fragmentação e que é discutida abaixo, pode falhar de modo catastrófico.

Uma conexão de TCP tem duas extremidades, e a fragmentação poderia ocorrer em um ou outro sentido. Dois fatores limitam o comprimento máximo de pacote de TCP em cada direção: o MTU da interface enviada do computador de fonte, como visto por sua pilha de IP, e o Maximum Segment Size (MSS), eventualmente, que foi anunciada pelo computador de destino durante a instalação TCP. (Os números MSS normalmente são 40 bytes menores que os números MTU, já que o MSS exclui os cabeçalhos IP e TCP, ambos de 20 bytes.)

O IPsec pode fazer problemas de fragmentação mais ruins, porque alonga cada pacote IP por um, ou possivelmente dois, cabeçalhos IP. Estes encabeçamentos adicionados variam de comprimento pela escolha dos protocolos IPSec (e se a “transparência de NAT” de Intraport é igualmente dentro uso), mas empiricamente não excedem 80 bytes por pacote. Para a maioria de encapsulamento comum do IP sobre Ethernet, o padrão MTU é 1500 bytes. Mas se um aplicativo se emitiu um pacote 1500-byte que precisasse de viajar embora um túnel de IPsec, os cabeçalhos IPSec adicionados exigiriam a fragmentação de cada pacote. Uma boa técnica (a melhor técnica, realmente) de evitar a fragmentação com IPsec está reduzindo a interface MTU que os aplicativos e a pilha de protocolos IP consideram no ambas as extremidades da conexão de TCP. Se os aplicativos e a pilha de protocolos IP pensam que a interface MTU é 1420 bytes ou menos, não se emitirão os pacotes que precisam de ser fragmentados após o encapsulamento de IPSec para o transporte através do Roteadores e dos links Ethernet-tamanho-capazes.

Descoberta da MTU do caminho

A Descoberta de MTU de Caminho (PMTUD) é uma otimização pela qual uma conexão de TCP tenta enviar os pacotes mais longos que não serão fragmentados no caminho da origem ao destino. Faz este usando uma bandeira, não-fragmentar, no pacote IP. Esta bandeira é suposta para alterar o comportamento de um roteador intermediário que não possa enviar o pacote através de um link porque é demasiado longo. Normalmente a bandeira está e o roteador deve fragmentar o pacote e enviar os fragmentos. Mas se a bandeira do não-fragmentar está ligada, o roteador deve rejeitar o pacote e retornar um pacote de erro que explica a dificuldade à fonte do pacote original. PMTUD é uma boa idéia, em princípio, mas frágil na prática. Com implementações de TCP mal configuradas ou deficientes e roteadores mal implementados ou firewalls mal configurados, pode ocorrer um estado persistente no qual cada extremidade de uma conexão TCP ficará aguardando a outra extremidade transmitir algo. (O roteador/Firewall A onde este problema ocorre é chamado amusingly um buraco negro do Path MTU Discovery.)

Uma fonte que faz o PMTUD começa com um comprimento máximo do pacote que seja o mínimo do MTU de partida da relação e do MSS anunciado durante o TCP setup (eventualmente) + 40, e trabalhos para baixo desse comprimento encontrar um comprimento do pacote que chegue no receptor mesmo se a bandeira do não-fragmentar do pacote é ajustada. Se você escolheu seu MTU de partida com cuidado (e seu ISP com cuidado), os pacotes do comprimento máximo do pacote inicial sobreviverão à viagem sem fragmentação. Assim se o PMTUD está causando um problema, você pode apenas desligá-lo sem a penalidade de desempenho de todo.

O Path MTU Discovery do apoio da linha de produtos de Intraport. Isto pode ser girado sobre configurando os seguintes pares de Keyword=value na seção geral: PreTunnelFragmentation=true, e MTUDiscoveryTimeout=10.

Mais informação em relação ao PMTUD pode ser encontrada no RFC 1191leavingcisco.com , no site IETFleavingcisco.com .

Diagnóstico

Suponha que seu computador remoto seja chamado de Alpha, você está tentando acessar um servidor chamado Bravo, por meio do IntraPort Client, e ele não esteja funcionando. Os pacotes de ping do padrão são muito curtos. Se o bravo não responde “para sibilar” (mas o bravo responde a um “sibilo” de um computador no LAN local), a fragmentação não é o problema. Verifique a conectividade básica. Verifique se traceroute (ou tracert no Windows) para o endereço IP IntraPort o leva pelos roteadores corretos ou se fica preso em um "loop de roteador" (isto é, passa rapetidamente pela mesma dupla de servidores).

Se o bravo responde a um sibilo do padrão, e se a alfa é um computador Windows, você pode agora tentar (de um prompt do DOS) o “sibilo - endereço IP de Um ou Mais Servidores Cisco ICM NT l 2000 bravo”. Se você obtém muito um alto percentual das boas respostas (>95%), você sabe que a fragmentação e a remontagem devem trabalhar corretamente, desde que os pacotes IP de 2000-byte não podem possivelmente viajar não-fragmentado em um Ethernet. Se você não obtém nenhuma resposta, ou o porcentagem de muitas tentativas perdidas excede a porcentagem de respostas perdidas para pacotes de ping do padrão-comprimento, é plausível que seu problema está sendo causado pela fragmentação.

Ao jogar com sibilo de Windows, esteja ciente que quando você especifica “- l <n>”, os pacotes IP que você gera é realmente <n> + 28 bytes por muito tempo, pela mesma convenção usada em calcular o MTU: todos os cabeçalhos de IP, nenhum cabeçalho no nível de link. Igualmente esteja ciente que você pode ajustar a bandeira do não-fragmentar em seus pacotes de ping: é “- o parâmetro f”. Se você envia um pacote longo com o grupo do flag " - f " e você não ouve nenhuma desculpa e nenhuma resposta, você pôde ver um buraco negro PMTUD. É possível até mesmo localizá-lo usando o "tracert" (traceroute do Windows) para analisar a cadeia de roteadores entre você e o destino, e "ping" para investigar cada roteador.

Parâmetros de configuração Fragmentação-relacionados para vários sistemas operacionais do computador de cliente

Windows 9x

Um parâmetro de registro opcional MaxMTU pode ser associado com os emperramentos do adaptador. Influencia aparentemente o MTU de partida como visto pela pilha de protocolos IP, e o MSS anunciado durante a instalação TCP. Se o MaxMTU falta de um emperramento, o MTU padrão para o adaptador (1500 para Ethernet) está suposto. Se você está vendo problemas da fragmentação, ajuste o MaxMTU em sua interface de rede ativa TCP a 1420. Se você fez que (recarregado) e você ainda está tendo o problema, eu sugiro que você ajustado o parâmetro de registro PMTUDiscovery explicitamente a 0.

Para detalhes em onde encontrar os parâmetros, leia o artigo da base de conhecimento do Microsoft Q158474leavingcisco.com . O parâmetro MTU máximo é complicado: não é fácil figurar que para fora que ligar (posicionada por quatro dígitos decimais) é essa você quer (sugestão: procure o endereço IP de Um ou Mais Servidores Cisco ICM NT), e as alterações mínimas consideráveis em sua configuração de rede de comunicação podem fazer o parâmetro desaparecer. É possível experimentar o utilitário trialware TweakDUN ou o utilitário optionware MTUSpeed se preferir não arriscar a instalação do sistema operacional com hacking de registro manual.

Windows NT 4.0

Para obter informações gerais sobre dos parâmetros de registro IP de NT, leia o artigo da base de conhecimento do Microsoft Q120642leavingcisco.com . O artigo Q183229leavingcisco.com entra no detalhe específico sobre as interações do MTU com Remote Access Services, que o cliente intraporta até a versão 3.3.x usa. O artigo parece sugerir que tem que ficar com um MTU de 1500 para RAS a menos que instale pelo menos SP4 e faça as alterações de registro indicadas. Você pode tentar o utilitário de trialware TweakDUN se você preferiria não arriscar sua instalação de OS com registro-corte manual.

MacOS

Parece não haver um meio de ajustar o MTU manualmente em um Macintosh. Felizmente, há o afinador avançado OT do utilitário de trialwareleavingcisco.com , que carrega a similaridade notável ao ndd dos solaris abaixo.

Unix

Os sabores diferentes de Unix fazem-no diferentemente. O utilitário ifconfig pode ser usado (como raiz) para alterar a MTU de uma interface. Com Unix mais velho mudar outros parâmetros exige geralmente recompiling o núcleo. Com o Unix mais recente, os valores de parâmetro são geralmente variáveis durante o tempo de execução, usando os utilitários administrativos. Por exemplo o Solaris 2.2 e posterior possui um utilitário administrativo ndd, enquanto o 4.4BSD e posterior usa o utilitário sysctl. Verifique suas páginas man, e/ou leia o “TCP/IP ilustrado, o volume 1", por W. Richard Stevens, um livro excelente que cubra o assunto.

Discussões relacionadas da comunidade de suporte da Cisco

A Comunidade de Suporte da Cisco é um fórum onde você pode perguntar e responder, oferecer sugestões e colaborar com colegas.


Informações Relacionadas


Document ID: 17639