quarta-feira, 6 de março de 2013

Pergunta de VPN - CCNA Security

VPN significa Virutal Private Network, é o túnel seguro formado entre pelo menos 2 pontos afim de criptografar toda a informação trocada a um nível extremamente seguro. Hoje em dia ela é usada para conectar redes distantes de maneira segura, por exemplo:

  • Quando um usuário doméstico trabalha de casa ele precisará, de algum jeito, acessar as informações da empresa. Normalmente isso é feito usando uma conexão vpn entre o computador e a empresa (algum servidor de VPN, podendo ser um roteador, um firewall ou um servidor windows ou linux)

  • Para proteger as informações que serão trocadas dentro de 2 pontos diferentes da mesma rede (dados bancários ou de finanças)


Há alguns dias recebi um e-mail de um ex-aluno de CCNA, agora instrutor de CCNA, me perguntando sobre por que sua topologia de VPN não estava funcionando, assunto de CCNA Security. Depois de enrolar um pouco consegui tempo para ver o problema e gostaria de compartilhar a resolução aqui:

Cenário


O software utilizado foi o Cisco Packet Tracer Version: 5.2.2.0019, veja a topologia abaixo:

[caption id="attachment_124" align="alignleft" width="300"]Topologia Topologia[/caption]

  •  A conexão de VPN está sendo feita entre R1 e R2

  • Não precisamos nos preocupar com a internet, pois a VPN passa transparente por ela

  • Temos que fazer que a rede 192.168.1.0/24 converse com a rede 192.168.2.0/24 pelo Túnel


Configurações dos dispositivos


A seguir as configurações dos dispositivos

R1:
Interface conectada com a rede interna  -> FastEthernet 0/0 192.168.1.1 /24
Interface conectada com a rede externa -> Serial 0/0 172.30.1.2/24
Configurações de VPN de R1:
crypto isakmp policy 10
encr 3des
hash md5
authentication pre-share
!
crypto isakmp key cisco123 address 172.30.2.2
!
crypto ipsec transform-set TS01 esp-3des esp-md5-hmac
!
crypto map MYMAP 10 ipsec-isakmp
set peer 172.30.2.2
set pfs group1
set security-association lifetime seconds 86400
set transform-set TS01
match address 110
!
access-list 102 permit ahp host 172.30.2.2 host 172.30.1.2
access-list 102 permit esp host 172.30.2.2 host 172.30.1.2
access-list 102 permit udp host 172.30.2.2 host 172.30.1.2 eq isakmp
access-list 102 permit ospf any any
!
access-list 110 permit tcp 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255
access-list 110 permit icmp 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255
!
interface Serial0/0/0
 ip address 172.30.1.2 255.255.255.0
 clock rate 2000000
ip access-group 102 in
 crypto map MYMAP

Tabela de roteamento de R1
     172.30.0.0/24 is subnetted, 2 subnets
C 172.30.1.0 is directly connected, Serial0/0/0
O 172.30.2.0 [110/128] via 172.30.1.1, 00:35:48, Serial0/0/0
C 192.168.1.0/24 is directly connected, FastEthernet0/0
O 192.168.2.0/24 [110/129] via 172.30.1.1, 00:35:38, Serial0/0/0

R2:
Interface conectada com a rede interna -> FastEthernet 0/0 192.168.2.1 /24
Interface conectada com a rede externa -> Serial 0/0 172.30.2.2 /24
Configurações de VPN de R2:
crypto isakmp policy 10
encr 3des
hash md5
authentication pre-share
!
crypto isakmp key cisco123 address 172.30.1.2
!
!
crypto ipsec transform-set TS01 esp-3des esp-md5-hmac
!
crypto map MYMAP 10 ipsec-isakmp
set peer 172.30.1.2
set pfs group1
set security-association lifetime seconds 86400
set transform-set TS01
match address 110
!
access-list 102 permit ahp host 172.30.2.2 host 172.30.1.2
access-list 102 permit esp host 172.30.2.2 host 172.30.1.2
access-list 102 permit udp host 172.30.2.2 host 172.30.1.2 eq isakmp
access-list 102 permit ospf any any
!
access-list 110 permit tcp 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255
access-list 110 permit icmp 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255
!
interface Serial0/0/0
ip address 172.30.2.2 255.255.255.0
ip access-group 102 in
crypto map MYMAP

Tabela de roteamento de R2:
     172.30.0.0/24 is subnetted, 2 subnets
O 172.30.1.0 [110/128] via 172.30.2.1, 00:34:27, Serial0/0/0
C 172.30.2.0 is directly connected, Serial0/0/0
O 192.168.1.0/24 [110/129] via 172.30.2.1, 00:34:27, Serial0/0/0
C 192.168.2.0/24 is directly connected, FastEthernet0/0

Sobre o cenário e VPN


Como podemos ver a comunicação está sendo feito por dentro de uma intranet, não há túnel para esconder as rotas, há apenas a necessidade de criptografar o tráfego entre a rede 192.168.1.0/24 e 192.168.2.0/24

Com essas configurações setadas, veja o que acontece quando uma configuração é iniciada (o teste foi, tentar pingar da rede 192.168.1.0 um host na 192.168.2.0):

Fase 1:
R1#show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst src state conn-id slot status
172.30.2.2 172.30.1.2 QM_IDLE 1003 0 ACTIVE
!
R2#show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst src state conn-id slot status
172.30.1.2 172.30.2.2 QM_IDLE 1032 0 ACTIVE

Como podemos ver, tudo está certinho na fase 1, agora vamos ver a fase 2

Fase 2:
R1#show crypto ipsec sa

interface: Serial0/0/0
Crypto map tag: MYMAP, local addr 172.30.1.2

protected vrf: (none)
local ident (addr/mask/prot/port): (192.168.1.0/255.255.255.0/6/0)
remote ident (addr/mask/prot/port): (192.168.2.0/255.255.255.0/6/0)
current_peer 172.30.2.2 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 3, #pkts encrypt: 3, #pkts digest: 0
#pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 1, #recv errors 0

local crypto endpt.: 172.30.1.2, remote crypto endpt.:172.30.2.2
path mtu 1500, ip mtu 1500, ip mtu idb Serial0/0/0
current outbound spi: 0x615C2599(1633428889)

Aqui encontramos um problema, conseguimos ver pacotes sendo encapsulados e criptografados porém não conseguimos ver nenhum pacote descriptografado:
   #pkts encaps: 3, #pkts encrypt: 3, #pkts digest: 0
#pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0

Isso pode acontecer devido a muitos problemas, primeiro vamos ver se as ACL's estão sendo correspondidas:
R1#sh access-lists 
Extended IP access list 102
    permit ahp host 172.30.2.2 host 172.30.1.2
    permit esp host 172.30.2.2 host 172.30.1.2
    permit udp host 172.30.2.2 host 172.30.1.2 eq isakmp
!

R1#sh access-lists
Extended IP access list 102
    permit ahp host 172.30.2.2 host 172.30.1.2
    permit esp host 172.30.2.2 host 172.30.1.2
    permit udp host 172.30.2.2 host 172.30.1.2 eq isakmp

Problema localizado, como o tráfego está sendo criptografado mas não mostra que nenhuma acl foi usada?

Esse é um bug do packet tracer! O mesmo cenário foi testado no GNS3 e funcionou normalmente, para burlar esse problema no packet tracer adicione a seguinte acl:
!R1
access-list 102 permit ip host 172.30.2.2 host 172.30.1.2
access-list 102 permit ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255

!R2
access-list 102 permit ip host 172.30.1.2 host 172.30.2.2
access-list 102 permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255

Problema resolvido!

Arquivos Usados


Arquivo com problema
Arquivo Corrigido

Um comentário:

  1. [...] site2site está ok, o bug mencionado por esse blog no link: http://blog.ragazzid.com.br/2013/03/06/pergunta-vpn-ccna-security/ foi [...]

    ResponderExcluir