Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Tunelamento L2TP baseado em filtro de firewall em visão geral da IPv4 Networks

O protocolo de tunelamento de camada 2 (L2TP) é um protocolo de servidor do cliente que permite que o protocolo ponto a ponto (PPP) seja tunelado em uma rede. O L2TP encapsula pacotes de Camada 2, como PPP, para transmissão em uma rede. Um concentrador de acesso L2TP (LAC), configurado em um dispositivo de acesso, recebe pacotes de um cliente remoto e os encaminha para um servidor de rede L2TP (LNS) em uma rede remota. O L2TPv3 define o protocolo de controle de base e o encapsulamento para tunelamento de várias conexões de Camada 2 entre dois nós IPv6. As diferenças significativas entre L2TPv2 e L2TPv3 incluem:

  • Separação de todos os AVPs e referências relacionados ao PPP, o que permite a inclusão de uma parte do cabeçalho de dados L2TP específica para as necessidades do PPP.

  • Transição de um ID de sessão de 16 bits e ID de túnel para um ID de session ID de 32 bits e ID de conexão de controle, respectivamente.

  • Extensão do mecanismo de autenticação do túnel para cobrir toda a mensagem de controle, em vez de apenas uma parte de determinadas mensagens.

  • O L2TPv3 é compatível apenas com IPv6.

  • Para filtros de firewall, é suportado apenas o encapsulamento/descapsulação L2TPv3 do plano de dados.

O L2TP é composto por dois tipos de mensagens, mensagens de controle e mensagens de dados (às vezes referidos como pacotes de controle e pacotes de dados, respectivamente). As mensagens de controle são usadas no estabelecimento, manutenção e limpeza de conexões e sessões de controle. Essas mensagens utilizam um canal de controle confiável dentro do L2TP para garantir a entrega. As mensagens de dados são usadas para encapsular o tráfego L2 que está sendo transportado durante a sessão L2TP.

Você pode configurar uma rede IPv4 para transportar tráfego de trânsito IPv4, IPv6 ou MPLS usando mecanismos de protocolo de tunelamento GRE iniciados por duas ações padrão de filtro de firewall. Esse recurso também é suportado em sistemas lógicos. Ao configurar o tunelamento L2TP com filtros de firewall, você não precisa criar interfaces de túnel em placas de interface física (PICs) dos Serviços de Túnel ou em Concentradores de Portas Modulares MPC3E (MPCs). Em vez disso, os Mecanismos de encaminhamento de pacotes fornecem serviços de túnel para interfaces lógicas Ethernet ou interfaces Ethernet agregadas hospedadas em placas de interface modular (MICs) ou MPCs em plataformas de roteamento universal 5G da Série MX.

Dois roteadores da Série MX instalados como roteadores de borda de provedor (PE) fornecem conectividade aos roteadores de borda do cliente (CE) em duas redes desarticuladas. As interfaces MIC ou MPC nos roteadores PE executam encapsulamento L2TP IPv4 e des encapsulamento de cargas. Após a descapsulação, os pacotes são enviados para a interface local de uma tabela de roteamento especificada na ação ou para a tabela de roteamento padrão, com base no campo de protocolo do cabeçalho L2TP. No entanto, um pacote L2TP pode ser enviado opcionalmente por toda a malha com um símbolo igual a um índice de interface de saída para realizar a conexão cruzada de Camada 2. Você pode especificar o especificador de interface de saída a ser usado para o pacote L2TP a ser enviado, incluindo a decapsulate l2tp output-interface interface-name cookie l2tpv3-cookie declaração no nível de [edit firewall family family-name filter filter-name term term-name then] hierarquia.

Durante a descapsulação, o cabeçalho interno deve ser Ethernet para túneis L2TP. A classe de encaminhamento por padrão é aplicada antes do firewall e ela não é preservada para o pacote descapsulado (usando a forwarding-class class-name declaração no nível de [edit firewall family family-name] hierarquia, que é uma ação de filtro não sufocante). No entanto, você pode especificar a classe de encaminhamento contra a qual o pacote deve ser classificado, incluindo a ação do filtro para um pacote descapsulado usando a decapsulate l2tp forwarding-class class-name declaração no nível de [edit firewall family family-name filter filter-name term term-name then] hierarquia.

As definições de campo a seguir são definidas para uso em todos os encapsulamentos de Cabeçalho de Sessão L2TP.

  • O campo de ID de sessão é um campo de 32 bits que contém um identificador não zero para uma sessão. As sessões L2TP são nomeadas por identificadores que têm apenas significado local. A mesma sessão lógica receberá IDs de sessão diferentes em cada extremidade da conexão de controle para a vida da sessão. Quando a conexão de controle L2TP é usada para o estabelecimento de sessão, os IDs de sessão são selecionados e trocados como AVPs de ID de sessão local durante a criação de uma sessão. O Session ID por si só fornece o contexto necessário para todo o processamento adicional de pacotes, incluindo a presença, tamanho e valor do Cookie, o tipo de subcamada específica de L2 e o tipo de carga sendo tunelada.

  • O campo cookie opcional contém um valor de comprimento variável (máximo de 64 bits) usado para verificar a associação de uma mensagem de dados recebida com a sessão identificada pela ID da sessão. O campo cookie deve ser definido para o valor aleatório configurado ou sinalizado para esta sessão. O Cookie fornece um nível adicional de garantia de que uma mensagem de dados foi direcionada para a sessão adequada pela ID da sessão. Um Cookie bem escolhido pode evitar o desvio inadvertido de pacotes aleatórios com IDs de sessão recentemente reutilizados ou para IDs de sessão sujeitos à corrupção de pacotes. O Cookie também pode fornecer proteção contra alguns ataques de inserção de pacotes maliciosos específicos. Quando a conexão de controle L2TP é usada para o estabelecimento de sessão, os valores aleatórios de cookie são selecionados e trocados como AVPs de cookies atribuídos durante a criação da sessão.

Uma sessão é uma conexão lógica criada entre o LAC e o LNS quando uma conexão PPP de ponta a ponta é estabelecida entre um sistema remoto e o LNS. Há uma relação de um a um entre sessões L2TP estabelecidas e suas conexões PPP associadas. Um túnel é uma agregação de uma ou mais sessões L2TP.

A partir do Junos OS Release 15.1, a descapsulação de pacotes IP que são enviados por um túnel L2TP com condições e ações de correspondência de filtro de firewall padrão especificadas é realizada usando uma pesquisa de Camada 3. No junos OS versão 14.2 e anterior, a descapsulação do tráfego em um túnel L2TP com ações de filtro de firewall configuradas é realizada usando propriedades de interface de Camada 2.

Tunelamento unidirecional

Os túneis L2TP baseados em filtro em redes IPv4 são unidirecionais. Eles transportam apenas pacotes de trânsito, e não exigem interfaces de túnel. Embora você possa aplicar filtros de firewall em endereços de loopback, as ações de filtro de firewall encapsuladas e encapsuladas por GRE não são suportadas em interfaces de loopback do roteador. Operações de encapsulamento e descapsulação iniciadas por filtro de pacotes L2TP são executadas em mecanismos de encaminhamento de pacotes para interfaces lógicas Ethernet e interfaces Ethernet agregadas. Esse design permite o uso mais eficiente da largura de banda do Packet Forwarding Engine em comparação com o tunelamento GRE usando interfaces de túnel. As sessões de protocolo de roteamento não podem ser configuradas em cima dos túneis baseados em firewall.

Segurança de túneis

O tunelamento baseado em filtros em redes IPv4 não é criptografado. Se você precisar de tunelamento seguro, você deve usar a criptografia de segurança IP (IPsec), que não é suportada em interfaces MIC ou MPC. No entanto, as interfaces de DPC multisserviços (MS-DPC) nos roteadores MX240, MX480 e MX960 oferecem suporte a ferramentas IPsec para configurar associações de segurança manuais ou dinâmicas (SAs) para criptografia do tráfego de dados, bem como tráfego destinado ou originado no Mecanismo de Roteamento.

Desempenho de encaminhamento

O tunelamento baseado em filtros em redes IPv4 permite o uso mais eficiente da largura de banda do Packet Forwarding Engine em comparação com o tunelamento L2TP usando interfaces de túnel. Encapsulamento, des encapsulamento e pesquisa de rota são atividades de processamento de cabeçalho de pacotes que, para tunelamento baseado em filtro de firewall, são realizadas no Mecanismo de encaminhamento de pacotes baseado em chipset Junos Trio. Consequentemente, o encapsulador nunca precisa enviar pacotes de carga para uma interface de túnel separada (que pode residir em um PIC em um slot diferente da interface que recebe pacotes de carga).

Escalabilidade de encaminhamento

O encaminhamento do tráfego L2TP com interfaces de túnel exige que o tráfego seja enviado a um slot que hospeda as interfaces do túnel. Quando você usa interfaces de túnel para encaminhar o tráfego GRE, esse requisito limita a quantidade de tráfego que pode ser encaminhado por endereço de destino de túnel GRE. Como exemplo, suponha que você queira enviar 100 Gbps de tráfego L2TP do Roteador A para o Roteador B e tenha apenas 10 Gbps de interfaces. Para garantir que sua configuração não encapsula todo o tráfego na mesma placa que vai para a mesma interface de 10 Gbps, você deve distribuir o tráfego em vários pontos de encapsulamento.

Tabela de histórico de alterações

A compatibillidadde com o recurso dependerá da platadorma e versão utilizada. Use o Feature Explorer para saber se o recurso é compatível com sua plataforma.

Versão
Descrição
15.1
A partir do Junos OS Release 15.1, a descapsulação de pacotes IP que são enviados por um túnel L2TP com condições e ações de correspondência de filtro de firewall padrão especificadas é realizada usando uma pesquisa de Camada 3.
14.2
No junos OS versão 14.2 e anterior, a descapsulação do tráfego em um túnel L2TP com ações de filtro de firewall configuradas é realizada usando propriedades de interface de Camada 2.