1-Introdução
vamos continuar nossa discussão sobre túneis GRE. Se você não leu o artigo relacionado ao GRE, eu recomendaria que você dê uma olhada no artigo “passo a passo : Entendendo os túneis GRE”.
nesta seção, melhoraremos a topologia que construímos no post anterior, adicionando uma camada de segurança com IPSec.
como lembrete, já configuramos a seguinte infraestrutura:
- um túnel GRE simples entre o ramo-1 e o ramo-2 com sua respectiva interface Serial como endpoints.
por que usar GRE sobre IPsec em vez de túneis IPsec puros?
existem vários benefícios de usar túneis GRE ao lado do IPSec, principalmente porque o IPSec não suporta tráfego diferente do unicast. Isso pode levar a problemas se você planeja usar serviços que exigem esse tipo de tráfego, como protocolos de roteamento como OSPF ou EIGRP.
graças ao processo de encapsulamento GRE, o tráfego de transmissão e multicast é encapsulado em um pacote unicast que pode ser tratado pelo IPSec, tornando possível o roteamento dinâmico entre pares separados por uma área de rede insegura.
você pode simplesmente estar disposto a implementar o IPSec se desejar se beneficiar dos pontos fortes do GRE e se preocupar com a privacidade (lembre-se de que o GRE não criptografa o tráfego). Além disso, os túneis GRE fornecem um nível mais alto de resiliência do que os keepalives Ike realmente.
Desvantagens
claro, existem várias desvantagens da utilização deste tipo de solução, considere o seguinte antes de obter as mãos sobre coisas técnicas:
- Usando GRE consome largura de banda e impactos performances. Adicionar criptografia pode alterar ainda mais os recursos de processamento e aumentar a latência da rede. Certifique-se de que sua infraestrutura o suporte.
- as entradas ACL precisam ser mantidas manualmente, o que pode se tornar tedioso para empresas de médio e grande porte.
- usar túneis GRE-Over-IPSec ponto a ponto não escala bem. Se você planeja adicionar vários sites remotos, considere implementar outras soluções, como DMVPN, que constrói túneis dinamicamente entre pares remotos, reduzindo as tarefas de gerenciamento administrativo.
2- Implementação
Nota: para se beneficiar dos recursos de criptografia IPSec, certifique-se de que sua versão do IOS OS suporte. Você pode usar a ferramenta Cisco Feature Navigator para obter uma lista completa dos recursos suportados em http://www.cisco.com/go/fn
Ike Phase 1
as opções IPSec usadas por comunicações eficazes são definidas em um conjunto de transformação. Neste exemplo de configuração, podemos usar tanto o AH e o ESP com AES para criptografia, e SHA respectivas verificações de integridade:
| Filial-1 | Ramo-2 |
|
crypto ipsec transform-set FORTE ah-sha-hmac esp-aes 256 esp-sha-hmac mapa de criptografia IPSEC_MAP 10 ipsec-isakmp ip access-list extended IPSEC_ACL Interface Serial0/0 |
crypto ipsec transform-set FORTE ah-sha-hmac esp-aes 256 esp-sha-hmac mapa de criptografia IPSEC_MAP 10 ipsec-isakmp ip access-list extended IPSEC_ACL Interface Serial0/1 |
O interessante tráfego que precisa ser criptografado através de um túnel é o tráfego que corresponde a IPSEC_ACL. Agora podemos simplesmente agrupar todas as opções do túnel em um crypto-map, definindo o endereço de par remoto e cujo tráfego deve ser criptografado por qual conjunto de transformação específico. A Política ISAKMP não é especificada no crypto-map, pois está relacionada à Fase 1 do ISAKMP e negociada dependendo da configuração de cada endpoint.
o IPSEC_ACL deve ser espelhado entre os 2 Pontos finais. Em palavras de ordem, o tráfego que você precisa criptografar deve ser aceito do outro lado. Como resultado, basta alternar as seções de origem e destino para cada entrada em ambos os roteadores. Você notará que correspondemos ao tráfego que sai da interface física: especificamos GRE como o tipo de tráfego e os endereços de origem / destino do túnel
finalmente, o crypto-map é aplicado na interface física. Observe que a aplicação do mapa na interface do túnel pode não funcionar conforme o esperado.
A seguinte mensagem de log devem ser levantadas:
%CRYPTO-6-ISAKMP_ON_OFF: ISAKMP é EM
Verificação
Você pode verificar e solucionar problemas de fase 1 e 2 SA através da elaboração de “show de criptografia isakmp sa’ e ‘show crypto ipsec sa’, respectivamente.
Branch-1 (ISAKMP)
Filial-1#mostrar criptografia isakmp sa
IPv4 Criptografia ISAKMP SA
src dst estado conn-identificação do slot de status
203.0.0.6 203.0.0.2 QM_IDLE 1001 0 ATIVO
IPv6 Criptografia ISAKMP SA
O segundo comando pode ajudar a monitorar quantos pacotes foram viajar através do túnel:
Filial-1 (IPSec, trecho)
Filial-1#mostrar crypto ipsec sa
interface: interface Serial0/0
mapa de Criptografia marca: IPSEC_MAP, local addr 203.0.0.2
protegido vrf: (nenhum)
local de identificação (endereço/máscara de/prot/porta): (203.0.0.2/255.255.255.255/47/0)
remoto de identificação (endereço/máscara de/prot/porto): (203.0.0.6/255.255.255.255/47/0)
current_peer 203.0.0.6 porta 500
PERMITIR, sinalizadores={origin_is_acl,}
#pkts encaps: 4, #pkts encriptar: 4, #pkts digest: 4
#pkts decaps: 4, #pkts descriptografar: 4, #pkts verificar: 4
#pkts comprimido: 0, #pkts descompactado: 0
#pkts não compactado: 0, #pkts compr. falha: 0
#pkts não descompactado: 0, #pkts descompactar falhou: 0
#enviar erros 1, #recv erros 0
Se dermos uma olhada em como pacotes parecer:
observe que o ping de 10.0.1.1 a 10.0.2.1 viaja para seu destino como um pacote encapsulado autenticado (AH) e criptografado (ESP) de acordo com as configurações configuradas acima.
Nota: algum tráfego interessante precisa ser gerado antes que o túnel esteja totalmente operacional. Se você estiver trabalhando em um ambiente de laboratório, poderá detectar o tráfego ISAKMP e observar como o processo de troca funciona.
este artigo destina-se a compartilhar conhecimento. Se você encontrar algo faltando, ou que deve ser melhorado, eu ficaria feliz em adicionar essas informações.