Minha jornada até o CCIE RS — DMVPN 2

Published in

TechRebels

8 min readJan 28, 2019

E aí pessoal, tudo bem?

Continuo nossa série de artigos, compartilhando anotações acumuladas durante 15 anos de trabalho e estudos. Para o CCIE RS foram quase 400 páginas com informações e observações que considero importantes ao trabalhar com Routing and Switching.

Estas informações podem ajudar não só para certificações, mas principalmente no dia-a-dia de outros network engineers como eu a lidar com infraestrutura de redes.

Para quem não leu os artigos anteriores da série, seguem os links sobre “Switching”, “PPP”, “IP Routing”, “RIP”, “EIGRP”, “OSPF”, “BGP” e “Redistribuição”, “MPLS” e “DMVPN - Parte 1”.

Como já dissemos, DMVPNs podem ser implantadas de 1001 formas. Portanto, para chegarmos ao ponto em como DMVPNs são utilizadas hoje, precisamos explicar pontos básicos. Recomendo muito que leiam o artigo anterior (DMVPN — Parte 1) onde exploramos os pontos-chave sobre IPsec VPN.

Hoje exploraremos GRE + IPsec e IPsec VTI, como testar e ao final uma lista de comandos “show” + filtros que considero eficiente.

Fique a vontade para comentar e entrar em contato comigo no LinkedIn. Se gostou do que leu, incentivo a compartilhar com colegas do ramo. Não se esqueça de seguir a mim e ao TechRebels clicando follow lá em cima :)

GRE over IPsec

Por que usar GRE e IPsec juntos?

Dificuldades:

Crypto map não possui interface associada na tabela de roteamento.
Por esse motivo, roteamento IGP não é suportado.
Permite somente roteamento estático, que não é escalável.
Uma solução seria usar BGP, mas torna a solução ainda mais complicada.

Solução simples:

Utilizar uma interface túnel (GRE +IPsec).
Dessa forma o roteamento ocorre dentro do túnel GRE e o túnel é encriptado dentro do IPsec.
Essa solução pode ser implementada com Crypto Map ou Crypto Profile.

Crypto map não é a solução preferida — é confuso entender se devemos aplicar na interface física ou interface túnel.

GRE over IPsec (recomendado)

Crypto map na interface física .
IPsec é o transporte.
Encapsulamento GRE primeiro e criptografia depois.
Proxy ACL simples com única entrada <permit gre A B>.

IPsec over GRE (design ruim)

Crypto map aplicado no túnel.
GRE é o transporte.
Criptografia primeiro e encapsulamento GRE depois.
Proxy ACLs com entradas fim-a-fim.

Transport vs Tunnel Mode

Afeta diretamente o payload.
Tunnel mode adiciona cabeçalho GRE IP que é redundante quando usado dentro do IPsec, porque ESP usa o mesmo cabeçalho.
MTU no tunnel mode deve ser ajustada porque o DF não é copiado entre os cabeçalhos. Neste caso o PMTUD não funciona porque o router primeiro encripta e depois fragmenta.
— MTU L3 é 1500 bytes por default.
— MTU L2 é 1518 bytes por default, incluindo cabeçalho L2 (14 bytes) e Vlan tag (4 bytes) (dot1Q).

OBS: Para usar transform-set mode transport, o Proxy-ACL deve obrigatoriamente ser especificado de gateway para gateway <permit gre host A.A.A.A host B.B.B.B>.

“tunnel protocol/transport”
“transport MTU” — payload máximo

<sh crypto ipsec sa> mostra todas as MTU

plaintext MTU
ip MTU

Formato de pacote, geralmente:

IP header — 20 bytes
TCP/UDP header — 20 bytes
Data — 1460 máximo

Problemas de Fragmentação de GRE sobre IPsec

Overhead GRE não é um problema porque 20 bytes significam pouco da MTU de 1500.

A Cisco informa que devemos ajustar manualmente o MTU do túnel levando em conta o cabeçalho IPsec, mas não explica o porquê. Isto é solicitado porque o principal problema está relacionado ao DF bit.

O DF bit do pacote IP dentro do GRE (interno) não é copiado para o cabeçalho IP do IPsec (externo). Portanto, PMTUD não funciona.

Neste caso o router pode precisar encriptar e depois fragmentar. Este processo acaba com o throughput, principalmente porque o processador tem que processar tudo (throughput pode baixar para 1% depois de habilitar a criptografia).

OBS: Este problema é uma das principais diferenças entre GRE sobre IPsec e VTI tunnel.
Payload máximo de GRE = 1476 (IP 20 + GRE 4)

OBS: Mesmo que a criptografia seja realizada em hardware, toda fragmentação é processada em software. Portanto fragmentação é um processo de uso intensivo de CPU e NÃO DEVE ser realizado pelo roteador. Controle de MSS deve ser realizado pelos end hosts através de PMTUD (e retorno de unreachable).

IP MTU e Ajuste MSS do TCP

Precisamos então diminuir o MTU do IP do GRE considerando o overhead ESP sobre a MTU do link. O overhead real varia baseado no algoritmo de criptografia.

OBS: É muito complexo calcular o valor exato porque depende do tamanho do bloco utilizado pelo algoritmo de criptografia e o padding varia conforme quantidade de blocos do pacote.

DOC: https://packetpushers.net/ipsec-bandwidth-overhead-using-aes/

Bom artigo da Packet Pushers mostrando sobre fragmentação dos pacotes IPsec, padding, etc.

Uma boa regra é diminuir o MTU normal para 1400 bytes, assim como o MTU jumbo para 9000 bytes.

Para os casos que o host não implementa PMTUD, precisa ajustar o MSS para +- 1360 bytes [1400 bytes — 20 (IP header) — 20 (TCP header)]. Nesse caso o router altera o MSS do TCP SYN e SYN ACK, repassando a fragmentação para os end hosts.

Resumo:

Transferir fragmentação para o host.
— O cabeçalho ESP não é exato pois varia com o algoritmo.
— Diminuir o IP MTU do túnel GRE levando em conta o encapsulamento ESP.
— Regra geral é utilizar IP MTU de 1400 bytes.
MSS
— Também é necessário diminuir a MSS porque o host pode não utilizar PMTUD.
— Ajuste do TCP MSS = [IP MTU — 20 bytes IP — 20 bytes TCP]
— — Ex: IP MTU 1400 bytes -> TCP MSS 1360 bytes
— — <ip tcp adjust-mss>

IPsec Virtual Tunnel Interface (VTI)

Interface túnel com encapsulamento IPsec direto. O conceito é similar ao GRE, mas sem overhead GRE.
Static VTI (SVTI) — Usado para VPNs site-of-site.
Dynamic VTI (DVTI) — substituto do legado crypto-map dinâmico.
— Utilizado para VPNs de acesso remoto para clientes ezvpn.

GRE sobre IPsec x IPsec VTI

GRE sobre IPsec

Mais overhead (geralmente irrelevante).
* Encapsulamento multi-protocolo.
— IPv4, IPv6, IS-IS, etc
VPN on-demand.
— Geralmente acionada por IGP.
Line protocol baseado na rota para destino (default para GRE) (não é fim-a-fim)

IPsec VTI

Menos overhead (pouca coisa).
Encapsulamento de único protocolo:
— IPv4 sobre IPv4 IPsec
— IPv6 sobre IPv6 IPsec
* VPN sempre UP.
— Não há necessidade de especificar tráfego interessante.
* Line protocol baseado no sucesso da PHASE 2 (fim-a-fim).
— Se o túnel está está UP é porque está funcionando.

OBS: VTI possui interface na RIB e, portanto, pode suportar IGP dinâmico.

Crypto IPsec Profile

Basicamente uma versão simplificada do crypto map contendo somente parâmetros de negociação IPsec PHASE 2 (transform set).

Não contém endereço do peer ou proxy ACL porque já são implícitos do túnel.

Peer é o próprio destino do túnel.
Proxy ACL é implicitamente <permit IP/GRE any any>.

IPsec Profile pode ser aplicado para ambos GRE e IPsec VTI. Ao mesmo tempo a implementação é muito mais simples que crypto map.

Utilizando GRE suporta multi-protocolo mas tem redundância GRE.
Utilizando IPsec VTI (ipsec ipv4) suporta apenas IPv4 mas não precisa de 2 encapsulamentos. Principal desvantagem é suportar somente IPv4 ou IPv6 somente, mas não ambos.
<sh int tunnel> mostra “tunnel protocol/transport” GRE/IP ou IPsec/IP. O MTU já aponta o MTU do payload.

A pergunta então é “Multi-protocolo ou apenas IPv4?”

OBS: Por default, ACLs outbound não afetam tráfego local outbound. Criptografia é uma exceção e as ACLs envolvidas fazem match no tráfego local outbound.

OBS: Ao usar tunnel sempre tome cuidado com erros de recursividade de roteamento. Solução mais simples é rodar um protocolo de roteamento fora do túnel e outro diferente dentro.

DOC: “Resolve IP Fragmentation, MTU, MSS and PMTUD issues with GRE and IPsec”

Pre-shared keys aceitam wildcards como peer address. Portanto é possível utilizar 0.0.0.0 e definir uma única key para todos, mesmo porque não é escalável utilizar uma pre-shared por host. Porém essa prática não é recomendada porque uma chave comprometida, compromete todos os sites. Com N sites, o correto é utilizar certificados.

Obviamente, Ipsec Crypto Map e Crypto Profiles não são compatíveis.

IPsec VTI — Configuração

PHASE 1

Passos são idênticos ao crypto map. Ou seja, ISKAMP não muda.

PHASE 2

Who? — Túnel define o destino <tunnel destination>
What? — Túnel define o tráfego (qualquer coisa no túnel).
— Portanto, não há necessidade de crypto map para estes parâmetros.
How? — Crypto profile determina a tratativa do tráfego.

Túnel default é GRE over IP (GRE/IP), enquanto VTI é IPsec over IPv4 (IPsec/IP).

<int tu X>
— <tunnel mode ipsec ipv4>
— <tunnel prot ipsec profile PROFILE>
<sh crypto ipsec sa>
— O túnel ainda aparece com crypto-map, porém o crypto-map é criado dinâmicamente com Proxy ACL “0…0/0…0/0/0”(qualquer coisa).
— Como Proxy ACL não é especificado, VTI só opera como tunnel mode.

Verificação de IPsec

Esta etapa é similar a explicada no artigo anterior. Você pode conferir como verificar se a conectividade sobre IPsec está OK nas sessões “Verificação de IPsec” e “Problemas” no artigo anterior (DMVPN — Parte 1).

Comandos Show para IPsec VPN

ISAKMP e IPsec

sh cry isa key — pre-shared keys para autenticação
sh cry isa po — PHASE 1 Policies
sh cry isa sa — Status PHASE 1
sh cry isa sa det
sh cry isa peer
sh cry map [int] — config final do crypto map
— OBS: informa se a config está incompleta.
sh cry ip pro
sh cry ip trans — PHASE 2 Policies
sh cry ip sa — Status PHASE 2 — Mostra SA in e SA out.
sh cry ip sa | in ident|caps
sh cry ip sa | in ident|esp|spi
sh cry debug condition — filtros de debug (geralmente usado por peer)
debug cry isa
debug cry ipsec
debug crypto condition peer ipv4 X.X.X.X
<debug dmvpn all> basicamente a combinação de <debug nhrp> e <debug crypto>

Mostram o resultado das negociações:

sh cry isa sa
sh cry ip sa

Mostram exatamente o que houve de errado e precisa saber interpretar:

debug cry isa
debug cry ipsec

O que achou deste artigo sobre IPsec VPN?

Esse artigo te ajudará no dia-a-dia?

Fala pra gente nos comentários?

Se gostou do conteúdo, peço para compartilhar com outros do ramo. Não se esqueça de seguir a mim e ao TechRebels clicando follow aí embaixo :)

Sobre o autor:

Giuliano Barros é Network Engineer & Founder da Control Plane — Network Services.

Graduado em Ciência da Computação, certificado CCIE RS e Cisco Champion 2019 pela Cisco Systems, trabalha há 15 anos como Network Engineerem projetos para grandes e médias empresas. linkedin.com/in/giulianobarros