Segurança : Dispositivos de segurança adaptáveis Cisco ASA 5500 Series

O Firewall ASA tiver a alta utilização da CPU devido a um laço do tráfego quando disconexão dos clientes VPN

14 Agosto 2013 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (9 Agosto 2013) | Feedback

Introdução

Este documento descreve um problema comum que ocorra quando a disconexão dos clientes VPN de uma ferramenta de segurança adaptável de Cisco (ASA) essa é executado como um final do cabeçalho do acesso remoto VPN. Este documento igualmente descreve a situação onde um laço do tráfego ocorre quando disconexão dos usuários VPN de um Firewall ASA. Este documento não cobre como configurar ou estabelecer o Acesso remoto ao VPN, simplesmente a situação específica que elevara de determinadas configurações de roteamento comuns.

Contribuído por Magnus Mortensen, engenheiro de TAC da Cisco.

Pré-requisitos

Requisitos

A Cisco recomenda que você tenha conhecimento destes tópicos:

  • Configuração do acesso remoto VPN na ferramenta de segurança adaptável
  • Conceitos de distribuição da camada básica 3

Componentes Utilizados

A informação neste documento é baseada em um modelo adaptável 5520 da ferramenta de segurança que execute a versão de código ASA 9.1(1).

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.

Produtos Relacionados

Este documento pode ser usado com estes versão de hardware e software:

  • Algum modelo adaptável da ferramenta de segurança
  • Alguma versão de código ASA

Informações de Apoio

Quando um usuário conecta ao ASA como um concentrador do acesso remoto VPN, o ASA instala uma rota host-baseada na tabela de roteamento do ASA que distribui o tráfego a esse cliente VPN para fora a interface externa (para o Internet). Quando as disconexões desse usuário, a rota são removidas da tabela, e os pacotes na rede interna (destinada àquela o usuário desligado VPN) pôde ser dado laços entre o ASA e um dispositivo de roteamento interno.

Um outro problema é que os pacotes de transmissão dirigidos (da rede) (gerados pela remoção dos clientes VPN) puderam ser enviados pelo ASA como um frame de unicast para a rede interna. Isto pôde enviá-lo de volta ao ASA, que faz com que o pacote esteja dado laços até que o Time to Live (TTL) expire.

Este documento explica estas edições e mostra que técnicas de configuração podem ser usadas para impedir o problema.

Problema: Pacotes destinados para um laço desligado do cliente VPN dentro da rede interna

Quando as disconexões de um usuário do acesso remoto VPN de um Firewall ASA, os pacotes ainda atuais na rede interna (destinada para aqueles usuários desligado) e o endereço do IP atribuído VPN puderam se tornar dados laços dentro da rede interna. Estes loop de pacote puderam fazer com que o CPU no ASA aumente até as paradas de laço ou devido ao valor IP TTL no encabeçamento de pacote IP que decresce a 0, ou o usuário reconecta e o IP é atribuído novamente a um cliente VPN.

A fim compreender melhor esta encenação, considere esta topologia:

Neste exemplo, o cliente de acesso remoto foi atribuído o endereço IP de Um ou Mais Servidores Cisco ICM NT de 10.255.0.100. O ASA neste exemplo é conectado ao mesmo segmento da rede interna junto com um roteador. O roteador tem duas camadas adicionais três segmentos de rede conectados a ela. A interface relevante (roteamento) e as configurações de VPN do ASA e do roteador são:

Os destaques da configuração ASA são mostrados neste exemplo:

interface GigabitEthernet0/0
nameif outside
security-level 0
ip address 198.51.100.100 255.255.255.0
!
interface GigabitEthernet0/1
nameif inside
security-level 100
ip address 10.1.0.1 255.255.255.0
!
same-security-traffic permit intra-interface
!
ip local pool VPNpool 10.255.0.1-10.255.0.255
!
route outside 0.0.0.0 0.0.0.0 198.51.100.1
route inside 10.0.0.0 255.0.0.0 10.1.0.2

Os destaques da configuração de roteador são mostrados neste exemplo:

interface FastEthernet0
description connected to the inside interface of the ASA G0/1
ip address 10.1.0.2 255.255.255.0
!
interface FastEthernet1
 description connected to network segment
 ip address 10.2.0.1 255.255.255.0
!
interface FastEthernet2
 description connected to other network segment
 ip address 10.3.0.1 255.255.255.0
!
ip route 0.0.0.0 0.0.0.0 10.1.0.1

A tabela de roteamento do roteador conectado ao interior do ASA tem simplesmente uma rota padrão apontada à interface interna do ASA de 10.1.0.1.

Quando o usuário for conectado através do VPN ao ASA a tabela de roteamento ASA mostra como segue:

ASA# show route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route
Gateway of last resort is 198.51.100.1 to network 0.0.0.0
S 10.255.0.100 255.255.255.255 [1/0] via 198.51.100.1, outside
S 10.0.0.0 255.0.0.0 [1/0] via 10.1.0.2, inside
C 198.51.100.0 255.255.255.0 is directly connected, outside
C 10.1.0.0 255.255.255.0 is directly connected, inside
S* 0.0.0.0 0.0.0.0 [1/0] via 198.51.100.1, outside

O problema ocorrer quando as disconexões do usuário do acesso remoto VPN do VPN. A rota host-baseada é removida neste momento da tabela de roteamento ASA. Se um host dentro da rede tenta enviar o tráfego ao cliente VPN, esse tráfego está distribuído à interface interna do ASA pelo roteador. Esta série de etapas ocorre:

  1. O pacote destinado a 10.255.0.100 chega na interface interna do ASA.
  2. As verificações padrão ACL são executadas.
  3. A tabela de roteamento ASA é verificada a fim determinar a interface de saída para este tráfego.
  4. O destino do pacote combina a rota 10.0.0.0/8 larga esses pontos para trás para fora a interface interna para o roteador.
  5. O ASA verifica para ver se o tráfego do hair pinning é permitido - procura a intra-relação da licença da mesmo-Segurança e encontra que está permitido.
  6. Uma conexão é construída a e da interface interna e o pacote é enviado para trás ao roteador como um salto seguinte.
  7. O roteador recebe um pacote destinado a 10.255.0.100 na relação que enfrenta o ASA. O roteador verifica sua tabela de roteamento para ver se há um salto seguinte apropriado. O roteador encontra que o salto seguinte seria a interface interna ASA e o pacote está enviado ao ASA.
  8. Retornar à etapa 1.

Um exemplo é mostrado aqui:

Este laço ocorre até o TTL de decréscimos deste pacote a 0. Note que o Firewall ASA não decresce o valor TTL à revelia quando processar um pacote. O roteador decresce o TTL enquanto distribui o pacote. Isto impede a ocorrência deste laço indefinidamente, mas este laço aumenta a carga de tráfego no ASA e faz com que o CPU crave.

Problema: Os pacotes de transmissão dirigidos (da rede) gerados por clientes VPN são dados laços em uma rede interna

Esta edição é similar ao primeiro problema. Se um cliente VPN gera um pacote da transmissão direcionada a sua sub-rede do IP atribuído (10.255.0.255 no exemplo anterior) então esse pacote pôde ser enviado como um frame de unicast pelo ASA ao roteador interno. O roteador interno pôde então enviá-lo de volta ao ASA, que faz com que o pacote dê laços até que o TTL expire.

Esta série de eventos ocorre:

  1. A máquina de cliente VPN gera um pacote destinado ao endereço 10.255.0.255 do broadcast de rede e o pacote chega no ASA.
  2. O ASA trata-a este pacote como um frame de unicast (devido à tabela de roteamento) e para a frente ao roteador interno.
  3. O roteador interno, que igualmente trata o pacote como um frame de unicast, decresce o TTL do pacote e para a frente do ele de volta ao ASA.
  4. As repetições do processo até o TTL do pacote são reduzidas a 0.

Soluções ao problema

Há diversas soluções potencial a esta edição. Segundo a topologia de rede e a situação específica, uma solução pôde ser mais fácil de executar do que outra.

Solução 1 - Use um IP pool diferente para clientes VPN 

Esta solução é atribuir aos usuários remotos VPN um endereço IP de Um ou Mais Servidores Cisco ICM NT que não sobrepor com nenhuma sub-rede da rede interna. Isto impediria o ASA dos pacotes da transmissão destinados a essa sub-rede VPN de volta ao roteador interno se o usuário VPN não foi conectado.

Solução 2 - Faça a tabela de roteamento ASA mais específica para rotas internas

Esta solução é assegurar-se de que a tabela de roteamento do ASA não tenha nenhuma rotas muito larga que sobrepor com o IP pool VPN. Para este exemplo de rede específico, remova a rota 10.0.0.0/8 do ASA e configurar umas rotas estáticas mais específicas para as sub-redes que residem fora da interface interna. O dependente em cima do número de sub-redes e da topologia de rede, isto pôde ser um grande número rotas estáticas e não pôde ser possível. 

Solução 3 - Adicionar uma rota mais específica para a sub-rede VPN para trás para fora a interface externa

Esta solução é um pouco mais complicada do que a outro alistada aqui e não é recomendada acima da outro devido à situação descrita na nota na parte inferior desta seção. Esta solução é impedir o ASA dos pacotes IP da transmissão originado da sub-rede IP VPN de volta ao roteador interno adicionando uma rota mais específica para a sub-rede VPN para fora a interface externa. Desde que esta sub-rede IP é reservada para usuários exteriores VPN, os pacotes com um endereço IP de origem desta sub-rede IP VPN devem nunca chegar de entrada na interface interna do ASA. A maneira a mais fácil de conseguir isto é adicionar para fora uma rota para o IP pool do acesso remoto VPN a interface externa com um endereço IP de Um ou Mais Servidores Cisco ICM NT do salto seguinte do roteador ISP ascendente.

Neste exemplo da topologia de rede, essa rota olharia como:

route outside 10.255.0.0 255.255.255.0 198.51.100.1

Além do que esta rota, adicionar o IP verificam o caminho reverso dentro do comando para fazer com que o ASA deixe cair todos os pacotes recebeu de entrada na interface interna originado da sub-rede IP VPN, devido a mais rota preferida que existe na interface externa:

ip verify reverse-path inside

Depois que estes comandos implemeted, a tabela de roteamento do ASA olha similar ao seguinte quando o usuário é conectado:

ASA# show route

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route

Gateway of last resort is 198.51.100.1 to network 0.0.0.0

S 10.255.0.100 255.255.255.255 [1/0] via 198.51.100.1, outside
S 10.0.0.0 255.0.0.0 [1/0] via 10.1.0.2, inside
S 10.255.0.0 255.255.255.0 [1/0] via 198.51.100.1, outside
C 198.51.100.0 255.255.255.0 is directly connected, outside
C 10.1.0.0 255.255.255.0 is directly connected, inside
S* 0.0.0.0 0.0.0.0 [1/0] via 198.51.100.1, outside

Quando o cliente VPN é conectado, a rota host-baseada a esse endereço IP de Um ou Mais Servidores Cisco ICM NT VPN esta presente na tabela e está preferida. Quando as disconexões do cliente VPN, traficam originado desse endereço IP cliente que chega na interface interna é verificado contra a tabela de roteamento, e deixados cair devido ao IP verificam o caminho reverso dentro do comando.

Se o cliente VPN gera um broadcast de rede dirigido à sub-rede IP VPN, esse pacote está enviado ao roteador interno, e enviado pelo roteador de volta ao ASA, onde será deixado cair devido ao IP verifique o caminho reverso dentro do comando.

Nota: Depois que esta solução está executada, se o comando intra-interface da licença da mesmo-Segurança esta presente na configuração e as políticas de acesso a permitem, trafique originado de um usuário VPN destinado a um endereço IP de Um ou Mais Servidores Cisco ICM NT no IP pool VPN para um usuário que não seja conectado possa ser distribuído para trás para fora a interface externa na minuta. Esta é uma situação rara e pode ser abrandada com o uso dos VPN-filtros dentro da política de VPN. Esta situação ocorre somente se o comando intra-interface da licença da mesmo-Segurança esta presente na configuração do ASA.
Igualmente, se os host internos geram o tráfego destinados a um endereço IP de Um ou Mais Servidores Cisco ICM NT no pool VPN, e esse endereço IP de Um ou Mais Servidores Cisco ICM NT não é atribuído a um usuário remoto VPN, que o tráfego pôde saída a parte externa do ASA na minuta.


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.


Document ID: 116170