TCC VPN

(1)

COMPUTADORES

ANÁLISE COMPARATIVA ENTRE VPNs:

GET VPN E DMVPN

Bruno César de Sena Serrano

Jorge Alexandre Pereira de Andrade

Marivaldo Alex Gomes Gonçalves

Natália Ingrid Pereira do Nascimento

Victor Yuri Santana de Queiroz

(2)

Natália Ingrid Pereira do Nascimento

Victor Yuri Santana de Queiroz

ANÁLISE COMPARATIVA ENTRE VPNs:

GET VPN E DMVPN

Trabalho de conclusão do curso de Tecnologia em Redes de Computadores da UNIBRATEC. Orientado pelos professores Dailson de Oliveira Fernandes e Marcos Antônio Alves Gondim.

(3)

Natália Ingrid Pereira do Nascimento

Victor Yuri Santana de Queiroz

ANÁLISE COMPARATIVA ENTRE VPNs:

GET VPN E DMVPN

Este trabalho de conclusão de curso foi julgado adequado como parte dos requisitos para obtenção do título acadêmico em Redes de Computadores,

FACULDADE DE TECNOLOGIA IBRATEC

Recife, 30 de Junho de 2014.

______________________________________________________ Prof.º DAILSON DE OLIVEIRA FERNANDES

UNIBRATEC – FACULDADE DE TECNOLOGIA IBRATEC

______________________________________________________ Prof.º MARCOS ANTONIO ALVES GONDIM

(4)

Bruno César de Sena Serrano

Primeiramente, agradeço а Deus que permitiu que tudo isso acontecesse ao longo da minha vida, não somente estes anos como universitário, mas em todos os momentos pois Deus é o maior mestre que alguém pode conhecer.

Agradeço а minha mãe Maria Cristina Guerra de Sena, heroína que me deu apoio, incentivo nas horas difíceis de desânimo е cansaço.

Meus agradecimentos aos amigos Jorge Alexandre, Marivaldo Gonçalves, Natália Nascimento e Victor Queiroz, companheiros de trabalhos е irmãos na amizade que fizeram parte da minha formação е que vão continuar presentes em minha vida.

Agradeço aos professores Marcos Gondim e Dailson Fernandes, pela orientação, apoio е confiança. A instituição Unibratec, seu corpo docente, direção е administração que oportunizaram а realização deste curso.

Jorge Alexandre Pereira de Andrade

Agradeço ao empenho de toda a equipe por buscarem o sucesso desse trabalho, que proporcionará a todos nós, trilhar novos caminhos em busca do sucesso profissional. Agradeço a minha família e a Deus, por estarem sempre na minha vida me dando apoio e comemorando cada conquista na minha vida.

(5)

Primeiramente agradeço a Deus por ter me capacitado a cada dia e proporcionado uma condição de vida boa financeiramente, intelectualmente e saudável.

Agradeço a minha família, incluindo minha noiva Iris Cristina de Moura Silva, por ter me ajudado e dado força para suportar e encarar todas as barreiras enfrentadas ao longo dos anos.

Por fim agradeço a todos os professores que compartilhar dos seus conhecimentos e experiências profissionais, aos meus colegas e amigos principalmente os do grupo, que é formado por Natália Nascimento, Bruno César, Victor Queiroz e Jorge Alexandre, com quem passei momentos de alegrias e tristezas, onde no decorrer do projeto juntos aprendemos, comemos e sorrimos.

Que toda honra, toda glória e toda majestade seja dada ao Senhor Jesus Cristo pelos séculos dos séculos, amém.

(6)

Agradeço primeiramente a Deus, por ter dado sabedoria e discernimento para chegar até aqui, pelas promessas feitas que vem se cumprindo a cada dia, sendo essa a primeira de muitas. Glória a ele eternamente, porque Dele, e por Ele, e para Ele, são todas as coisas.

Decido o desenvolvimento deste trabalho a todos meus familiares, especialmente a minha mãe, Maria das Mercês Pereira da Silva, que sempre me apoiou nas minhas decisões, pelas suas palavras de conforto e orações. Dedico também ao meu tio, Bernardino Pereira da Silva Junior, que me proporcionou e incentivou a seguir um objetivo,e me inspirou com suas experiências de vida. Também não poderia esquecer da minha tia Marilene Pereira da Silva, que me acobertou com suas orações, me acolhendo como filha me ajudou e motivou nessa conquista.

Agradeço aos professores Jadiel França, Kelmo Siqueira e Fred Lucena pelos seus ensinamentos que ajudaram na construção da minha vida pessoal e profissional. Aos Professores, Marcos Gondim e Dailson Fernandes pela paciência e dedicação durante o desenvolvimento deste projeto.

Por fim, dedico aos meus companheiros, Marivaldo Alex, Bruno César, Jorge Alexandre e Victor Queiroz, pela confiança depositada e por ter proporcionado momentos maravilhosos durante a execução deste projeto. Dedico as amizades feita nesse tempo, Tatiane Kassia C. Santos, Ádesson Ricart C. de Barros, Naftali Jose Sabino, entre outros. Dedico também a todas as pessoas que diretamente ou indiretamente contribuíram para a realização deste projeto.

Meus sinceros agradecimentos a todos.

Victor Yuri Santana de Queiroz

Agradeço a todos que fizeram e fazem parte de minha vida ao longo desses anos, contribuindo de várias formas para meu sucesso e aprendizado ao longo da vida. Aos companheiros de equipe, no qual se dedicaram com todo amor, paciência e fé na elaboração

(7)

de Computadores dessa instituição e aos meus pais por sempre estarem juntos apoiando e ajudando em minhas decisões nessa vida.

(8)

planejar, mas também acreditar."

(Anatole France)

RESUMO

Este trabalho de conclusão de curso tem como finalidade compreender os conceitos teóricos das tecnologias para aplicação em ambiente de teste que simula um ambiente coorporativo, explicando o funcionamento de criptografia por meio de túneis fixos e dinâmicos, e como prover segurança em uma rede MPLS, visando entender suas vantagens e desvantagens. Fazendo uma análise comparativa entre duas tecnologias de VPN (Redes Virtuais Privadas), sendo: GET VPN (Group Encrypted Transport Virtual Private Network)

(9)

(10)

AH Autentication Header

COOK KS Co-operative Key Server

DMVPN Dynamic Multipoint VPN

EGP Extensive Gateway Protocol

ESP Encapsulated Security Payload

FEC Forwarding Equivalent Class

GDOI Group Domain of Interpretation

GET VPN Grupo Encrypted Transport Virtual Private Network

GM Group Member

GRE Generic Routing Encapsulation

ICMP Internet Control Message Protocol

IKE Internet Key Exchange

IKEv1 Internet Key Exchange Version 1

IKEv2 Internet Key Exchange Version 2

IOS Internetwork Operating System

IP Internet Protocol

IPSec Internet Protocol Security

IPv4 Internet Protocol Version 4

IPv6 Internet Protocol Version 6

ISAKMP Internet Security Association and Key Management Protocol

KEK Key Encryption Key

KS Key Server

LDP Label Distribution Protocol

LRS Label Switch Router

LSP Label Switch Path

MD5-HMAC Message-Digest Algorithm 5 - Hash-based Message Authentication Code

mGRE Multipoint Generic Routing Encapsulation

MPLS Multiprotocol Label Switching

NBMA Non-Broadcast Multiple Access

NHC Next Hop Client

NHRP Next Hop Resolution Protocol

OSI Open System Interconnection

RFC Request for Comments

SA Security Association

SHA-HMAC-96 Secure Hash Algorithm - Hash-based Message Authentication Code

SOX Sarbanes-Oxley

TEK Traffic Encryption Key

(11)

(12)

QUADRO 4: CONFIGURAÇÃODAFASE 2º DO IPSEC...39

QUADRO 5: CONFIGURAÇÃODAS ACL...39

QUADRO 6: CRIAÇÃODOSERVIDOR GDOI...39

QUADRO 7: CONFIGURAÇÃODO REKEY ...40

QUADRO 8: CONFIGURAÇÃODOCRYPTOMAP...40

QUADRO 9: CONFIGURAÇÃODASINTERFACESDO GM...41

QUADRO 10: CONFIGURAÇÃODO IPSEC...41

QUADRO 11: CONFIGURAÇÃOPARAOBTERASCHAVES...42

QUADRO 12: CONFIGURAÇÃODOCRYPTOMAP...42

QUADRO 13: CONFIGURAÇÃODASINTERFACESDOROTEADOR CE12...43

QUADRO 14: CONFIGURAÇÃOPARAOBTERASCHAVESDOROTEADOR CE12...43

QUADRO 15: O COMANDOTRACEROUTEANTESDEAPLICARO GET VPN...44

QUADRO 16: O COMANDOTRACEROUTEDEPOISDEAPLICARO GET VPN...44

QUADRO 17: PACOTES ICMP ANTESDO GET VPN...45

QUADRO 18: PACOTESCRIPTOGRAFADOS ESP...45

QUADRO 19: CONFIGURAÇÃODO GDOI...46

QUADRO 20: CONFIGURAÇÃODO GDOI...47

QUADRO 21: CAPTURADEPACOTES GDOI...48

QUADRO 22: SHOW CRYPTO GDOI NO GM...49

QUADRO 23: CONFIGURANDOINTERFACESDOHUB...51

QUADRO 24: CONFIGURAÇÃODA 1º FASEDO IKE...51

QUADRO 25: CONFIGURANDODASEGUNDAFASEDO IKE...52

QUADRO 26: CONFIGURAÇÃODAINTERFACETUNNEL0...52

QUADRO 27: CONFIGURANDOINTERFACESDO SPOKE1...53

QUADRO 28:CONFIGURANDOINTERFACESDO SPOKE2...53

QUADRO 29: 1º FASEDOPROTOCOLO ISAKMP NO SPOKE1...54

QUADRO 30: 1º FASEDOPROTOCOLO ISAKMP NO SPOKE2...54

QUADRO 31: 2º FASEDOPROTOCOLO IKE NO SPOKE1...54

QUADRO 32: 2º FASEDOPROTOCOLO IKE NO SPOKE2...55

QUADRO 33: CONFIGURAÇÃODAINTERFACETÚNELEOSPROTOCOLOSUTILIZADOSNO SPOKE1...55

QUADRO 34: CONFIGURAÇÃODAINTERFACETÚNELEOSPROTOCOLOSUTILIZADOSNO SPOKE2...56

QUADRO 35: COMANDODEVERIFICAÇÃODETÚNEIS...56

QUADRO 36: PACOTES ISAKMP...57

QUADRO 37: PACOTES ICMP...57

QUADRO 38: PACOTES ESP...58

QUADRO 39: VERIFICAÇÃODETÚNEISANTESDETRÁFEGOGERADOENTRE SPOKES...58

QUADRO 40: VERIFICAÇÃODOCAMINHODOPACOTEANTESDOTÚNELDINÂMICOFECHAR...59

QUADRO 41: VERIFICAÇÃODETÚNEISFECHADOAPÓSTRÁFEGOGERADOENTRE SPOKES...59

QUADRO 42: VERIFICAÇÃODOCAMINHODOPACOTEAPÓSDOTÚNELDINÂMICOFECHAR...59

(13)

FIGURA 2: EXEMPLODOMODELOCLIENT-TO-SITE...20

FIGURA 3: EXEMPLODOMODELOSITE-TO-SITE...20

FIGURA 4: PRIMEIRAFASEDO IKEV1...22

FIGURA 5: SEGUNDAFASEDO IKEV1...22

FIGURA 6: CRIPTOGRAFIAPORMEIODECHAVESSIMÉTRICAS...23

FIGURA 7: ALGORITMODEHASH...24

FIGURA 8: EXEMPLODOMODOTRANSPORTE IPSEC...25

FIGURA 9: EXEMPLODOMODOTÚNEL IPSEC...25

FIGURA 10: EXEMPLODE MPLS...26

FIGURA 11: PRESERVAÇÃODOCABEÇALHO IP ...27

FIGURA 12: DISTRIBUIÇÃODECHAVES...28

FIGURA 13: PLANODECONTROLE KEY SERVER...29

FIGURA 14: CO-OPERATIVE KEY SERVER...30

FIGURA 15: TOPOLOGIADE DMVPN...31

FIGURA 16: ESTABELECIMENTODETÚNEIS...32

FIGURA 17: ESTABELECIMENTODETÚNELFIXOENTREOHUBESPOKE...32

FIGURA 18: CRIAÇÃODETÚNELDINÂMICOENTESSPOKES...33

FIGURA 19: BACKBONE MPLS...34

FIGURA 20: BACKBONE MPLS DO GET VPN...36 Y

(14)

(15)

SUMÁRIO

1. INTRODUÇÃO...17

1.1 OBJETIVO GERAL...18

1.1.1 OBJETIVOS ESPECÍFICOS...18

2. FUNDAMENTAÇÃO TEÓRICA...19

2.1 VPN (Virtual Private Network)...19

2.1.1 Modelo de VPN (Virtual Private Network)...20

2.2 IPSec (Internet Protocol Security)...21

2.2.1 IKE (Internet Key Exchange)...21

2.2.2 Algoritmos de criptografia e autenticação...23

2.2.3 Protocolos de segurança...24

2.3 GET VPN (Group Encrypted Transport Virtual Private Network)...25

2.3.1 MPLS (Multiprotocol Label Switching)...26

2.3.2 Tecnologia GET VPN (Group Encrypted Transport VPN)...27

2.3.2.1GDOI (Group Domain of Interpretation)...28

2.3.2.2GM (Group Member)...28

2.3.2.3KS (Key Server)...29

2.4 DMVPN (Dynamic Multipoint Virtual Private Network)...30

3. MÉTODO CIENTÍFICO...34

3.1 Descrição do cenário...34

3.2 Elementos de configuração do GET VPN (Group Encrypt Transport VPN)...35

3.2.1 Configuração do KS (Key Server)...35

3.2.2 Configuração do GM (Group Member) CE22...39

3.2.3 Configuração do GM (Group Member) CE12...41

3.2.4 Estabelecimento da VPN (Virtual Private Network)...42

3.2.4.1Análise de pacotes da VPN (Virtual Private Network)...43

3.2.5 Verificação das configurações do KS (Key Server)...45

3.2.6 Verificação das configurações dos GMs (Group Members)...45

3.2.7 Análise de pacotes GDOI (Group Domain of Interpretation)...47

3.3 Elementos de configuração do DMVPN (Dynamic Multipoint VPN)...49

3.3.2 Configuração do Spoke1 e Spoke2...52

3.3.3 Captura de pacote da SA (Security Association) do ISAKMP e IPSec...55

3.3.4 Verificando o funcionamento do DMVPN (Dynamic Multipoint VPN)...57

4. ANÁLISE COMPARATIVA...59

4.1 Comparação das principais características das tecnologias GET VPN e DMVPN...59

4.2Comparação do funcionamento dos protocolos utilizados nas tecnologias GET VPN e DMVPN...61

4.3 Compatibilidade das versões do sistema operacional IOS...61

5. CONCLUSÃO...62

6. REFERÊNCIAS...64

(16)

(17)

1. INTRODUÇÃO

A crescente necessidade de cada vez mais estar conectado para compartilhamento de recursos e arquivos de forma segura, faz com que as empresas busquem cada vez mais utilizar soluções que mantenham e melhorem a sua comunicação, conservando a segurança, afim de evitar qualquer tipo de espionagem por meio de interceptação durante a transmissão. As redes virtuais privadas são soluções de grande importância no mundo corporativo, pois interconectam de forma segura e confiável sites geograficamente separados, por meio de protocolos de segurança e túneis.

“Uma VPN (Virtual Private Network) é uma conexão estabelecida por uma infraestrutura “pública” ou compartilhada existente, usando tecnologias de criptografia para proteger seu tráfego de dados. Isso cria um segmento “Virtual” entre duas entidades qualquer que tem acesso.” (NORTHCUTT, 2005)

O GET VPN (Group Encrypted Transport Virtual Private Network) foi desenvolvido para prover segurança em redes MPLS (Multiprotocol Label Switching), por meio da criptografia fornecida pelo IPSec, onde é preservado o endereçamento IP original do pacote. A tecnologia é baseada na RFC1_{6407 que define criptografia por meio de grupos pelo protocolo GDOI} (Group Domain of Interpretation), os elementos envolvidos são: o KS (Key Server) responsável por enviar as chaves criptográficas, registrar e autorizar os membros do grupo e os GM (Group Member) são os roteadores que irão se comunicar pela rede MPLS criptografando os dados com os outros membros do grupo.

Em relação à tecnologia, o DMVPN (Dynamic Multipoint Virtual Private Network) trabalha fazendo associações de segurança com mecanismos do IPSec. Baseado nas tecnologias NHRP (Next Hop Resolution Protocol) a qual está descrita na RFC 2332 e no mGRE (Multipoint Generic Routing Encapsulation), onde ambos trabalham em conjunto construindo túneis dinâmicos de acordo com a necessidade de transmissão de dados.

Este trabalho consiste em uma análise comparativa das tecnologias de VPN, simulando o backbone de uma operadora para a transferência de tráfego entre sites distintos, mantendo a privacidade dos dados.

No final desse trabalho será demonstrada a aplicação das duas tecnologias relatando suas dificuldades, facilidades e descrevendo o nível de complexidade dos elementos, sugerindo qual a melhor tecnologia de acordo com o cenário.

1.1 OBJETIVO GERAL

1 RFC (Request for Comments) trata-se de uma regulamentação formalizada que deve ser seguida por quem trabalha com a Internet. Forouzan, 2008

(18)

Elaborar uma análise comparativa das tecnologias Group Encrypted Transport Virtual

Private Network (GET VPN) e Dynamic Multipoint Virtual Private Network (DMVPN).

1.1.1 OBJETIVOS ESPECÍFICOS

 Comparar as principais características das tecnologias GET VPN e DMVPN;  Comparar o funcionamento dos protocolos utilizados nas tecnologias GET

(19)

2. FUNDAMENTAÇÃO TEÓRICA

Este capítulo tem o propósito de explanar sobre redes virtuais privadas, as principais características das tecnologias GET VPN e DMVPN, tais como os protocolos que permitem a utilização destas tecnologias.

2.1 VPN (Virtual Private Network)

Segundo Ferguson (1998a), as redes locais caracterizam-se por um conjunto de dispositivos sejam computadores, impressoras, roteadores, dentre outros, com a finalidade de trocar informações entre si. Com o propósito de estabelecer uma conexão segura por meio de túneis e/ou criptografia2_{entre duas redes locais dentro de uma rede pública} (Internet) surgiu o conceito de rede privada virtual, ou Virtual Private Network. Como exemplificado na Figura 1.

Figura 1: Exemplo de rede privada virtual

Fonte: Próprios autores, (2014).

2 Criptografia é a ciência que utiliza algoritmos matemáticos para criptografar/encriptar (cripto = esconder) dados (texto claro) numa forma aparentemente não legível (texto cifrado) e recuperá-los (descriptografá-los). Moraes, 2010

(20)

2.1.1 Modelo de VPN (Virtual Private Network)

De acordo com Nakamura e Geus (2007), existem vários modelos para implementar uma VPN, cada um com seu próprio conjunto específico de requisitos de tecnologias. Serão citadas o client-to-site e o site-to-site.

No modelo client-to-site como mostra a Figura 2, a conexão VPN é iniciada no equipamento do usuário, por meio de um programa que é instalado na máquina do cliente VPN. Para estabelecer a conexão é necessário importar arquivos que contenham informações como usuário e senha.

Figura 2: Exemplo do modelo client-to-site

No modelo site-to-site sua conexão começa e termina nos gateways3_{das organizações,}

possibilitando assim a extensão das redes locais como ilustra a Figura 3.

Figura 3: Exemplo do modelo site-to-site

2.2 IPSec (Internet Protocol Security)

3 Gateways servem como hardware intermediário para transferir dados de uma rede à outra, segundo Cerf e Kahn que tiveram a ideia desse dispositivo. Forouzan, 2008

(21)

Segundo Frankel (1998), IPSec (Internet Protocol Security) é um conjunto de protocolos que oferecem segurança para comunicação via Internet na camada de rede do modelo OSI4_{. O uso mais frequente do IPSec é prover segurança para as VPNs; tanto o GET} VPN quanto o DMVPN utilizam o IPSec.

O IPSec trabalha em conjunto com o IKE (Internet Key Exchange) que é um protocolo de gerenciamento de chaves de criptografia, que cria a SA (Security Association), onde são definidos o algoritmo de criptografia e algoritmo de autenticação.

A proteção do IPSec é fornecida mediante dois protocolos de segurança que atribuem cabeçalhos ao pacote IP5_{. O AH (Autentication Header) que é um cabeçalho de autenticação} e ESP (Encapsulated Security Payload) que é encapsulamento de segurança de carga útil.

2.2.1 IKE (Internet Key Exchange)

O IKE na sua primeira versão está definido nas RFC 2407, 2408 e 2409. Já em sua segunda versão está definida na RFC 4306. Segundo HARKINS (1998), o IKEv1 descreve as técnicas de troca de chaves, garante a proteção da identidade e negocia a forma de autenticação. A comunicação IKE é realizada em duas fases.

Na primeira fase de comunicação ocorre a troca de seis mensagens. No primeiro par são definidas as suas políticas (algoritmo de criptografia e método de autenticação), o segundo par calcula a chave de sessão e no terceiro par as mensagens são utilizadas para autenticação dos pares, como exemplificado na Figura 4.

4 OSI (Open System Interconnection) modelo de sete camadas para comunicação de dados, definido pela ISO. Forouzan, 2008

5 IP (Internet Protocol) é um dos principais protocolos da camada de rede do conjunto de protocolos TCP/IP. Albuquerque, 2001

(22)

Figura 4: Primeira fase do IKEv1

Fonte: Adaptado de Lewis, (2006).

A segunda fase é definida pela troca de três pares de mensagens. O primeiro par das mensagens define qual algoritmo de criptografia, o algoritmo de hash6_{e o tempo de vida do}

IPSec. No segundo par é dado o aceite na negociação e o terceiro par serve apenas como reconhecimento, como ilustra a Figura 5.

Figura 5: Segunda fase do IKEv1

6 Hash é o algoritmo que cria uma compilação de tamanho fixo com base em uma mensagem de comprimento variável. Forouzan, 2008

(23)

O IKEv2 preserva as fases de negociação, passando a dar suporte para a plataforma móvel e fazendo a detecção se o túnel ainda está em utilização, sendo capaz de restabelecer a conexão caso seja quebrada. Tudo isso consumindo uma menor largura de banda.

2.2.2 Algoritmos de criptografia e autenticação

Segundo Lewis (2006), o algoritmo de criptografia é responsável por codificar o conteúdo que é transportado dentro dos pacotes. Na codificação das mensagens, utilizam a mesma chave para codificar e decodificar o conteúdo transportado, esse processo é denominado criptografia por meio de chaves simétricas, como exemplificado na Figura 6. Eles podem trabalhar com dois métodos, cifrando as mensagens com um tamanho pré-determinado (cifra de bloco) ou cifrar as mensagens de acordo com o fluxo (cifra de fluxo).

Figura 6: Criptografia por meio de chaves simétricas

Fonte: Adaptado de Forouzan, (2008).

O autor ainda ressalta que existem vários algoritmos de autenticação, que também são conhecidos como algoritmo de hash, garantindo assim a integridade de uma conexão. Dois algoritmos bastante utilizados são o MD5-HMAC-128 e o SHA-HMAC-128, que criam uma mensagem compactada de 128 bits. A Figura 7 exemplifica o funcionamento de um algoritmo de hash.

(24)

Fonte: Adaptado de Nakamura, (2007).

2.2.3 Protocolos de segurança

Segundo Kent (1998a), AH (Autentication Header) fornece integridade, autenticação da origem dos dados e controle de acesso. Por meio de um algoritmo, utiliza os dados contidos no pacote e uma chave secreta definida durante a SA (Security Association) criando o hash. Na recepção do pacote esse hash é recalculado, e caso o pacote não tenha sido alterado, o valor do hash será o mesmo.

De acordo com Kent (1998b), ESP (Encapsulated Security Payload) fornece confidencialidade por meio da criptografia apenas do Payload7_{do pacote IP. Essa criptografia}

é feita por algoritmos utilizando uma chave secreta definida na SA (Security Association), trazendo assim integridade, graças à proteção destas informações.

O IPSec trabalha com dois modos de atuação, o modo transporte e o modo túnel. No modo transporte, o pacote IP é criptografado adicionando o AH, ESP ou os dois, porém mantém o cabeçalho IP original como descrito na Figura 8.

(25)

Figura 8: Exemplo do modo transporte IPSec

No modo túnel, conforme mostra a Figura 9, todo o pacote é criptografado e um novo cabeçalho IP é colocado no pacote. O endereço de destino e origem desse novo cabeçalho é o endereço IP dos gateways. Ao chegar ao destino, a autenticidade é verificada e o pacote é descriptografado, reconstruindo assim o pacote IP original.

Figura 9: Exemplo do modo túnel IPSec

2.3 GET VPN (Group Encrypted Transport Virtual Private Network)

Nesse tópico será abordada a tecnologia GET VPN, que foi desenvolvida para resolver problemas de confidencialidade e integridade em redes MPLS. Para um melhor entendimento da tecnologia GET VPN, será feita uma breve abordagem sobre o protocolo MPLS. A seguir será feita uma maior explanação sobre a tecnologia e os elementos de configurações.

(26)

Segundo Moraes (2012), O protocolo MPLS (Multiprotocol Label Switching) é uma solução consolidada no mercado que vem sendo muito utilizada, e, apesar de oferecer segmentação à rede e trazer certa segurança, não garante integridade e confidencialidade, que são características exigidas na lei SOX8_.

De acordo com Rosen (2001), MPLS é uma tecnologia aberta, apresentada inicialmente como uma solução que possibilita a melhoria do desempenho na função de encaminhamento de pacotes IP, por meio de pequenos rótulos de tamanho fixo. Esses rótulos tem o tamanho de 32 bits, que são utilizados para identificar uma FEC (Forwarding

Equivalent Class), um grupo de pacotes IPs, que são equivalentes no mesmo trajeto e com o

mesmo tratamento de transmissão. Os pacotes são rotulados assim que entram na rede, e são encaminhados com base nesses rótulos. Conforme a Figura 10.

Figura 10: Exemplo de MPLS

Fonte: Adaptado de Mendonça (2012).

Segundo Mendonça (2012), os roteadores que são capazes de entender os pacotes MPLS são chamados de LSR (Label Switch Router). O caminho percorrido pelo pacote é denominado LSP (Label Switch Path) e o protocolo de comunicação entre os elementos de rede ou roteadores é chamado de LDP (Label Distribution Protocol).

2.3.2 Tecnologia GET VPN (Group Encrypted Transport VPN)

O GET VPN da Cisco introduz o conceito de grupo de confiança, baseando-se no protocolo GDOI (Group Domain of Interpretation) definido inicialmente na RFC 3547 e depois substituído pela RFC 6704. O seu objetivo é eliminar os túneis ponto-a-ponto da arquitetura original do IPSec.

8 SOX (Sarbanes-Oxley) é uma lei que foi editada com o objetivo de restaurar o equilíbrio dos mercados por meio de mecanismos que assegurem a responsabilidade da alta administração de uma empresa sobre a confiabilidade da informação por ela fornecida. Borgerth, 2007

(27)

Na estrutura do GET VPN os roteadores fazem parte de um grupo, onde passam a ser GM (Group Member) e compartilham de uma política de segurança comum, isso é conhecido como associação de segurança de grupo, permitindo assim que qualquer roteador deste grupo possa descriptografar a informação gerada por outro roteador que faça parte do mesmo grupo, tornando assim desnecessária a criação de túneis ponto-a-ponto entre os membros de um mesmo grupo. O KS (Key Server) é o elemento responsável por gerenciar a associação de grupo de forma centralizada, distribuindo entre os GMs as políticas e chaves de criptografia utilizadas. Partindo da premissa de que para intranets não é necessário se preocupar com a questão de esconder o endereçamento IP privado e a VPN é considerada uma rede intranet, quando utilizado o IPSec no modo túnel o GET VPN remove o cabeçalho introduzido pelo IPSec e o endereço IP original do pacote é colocado antes do ESP, como mostra a Figura 11, proporcionando assim, a capacidade de lidar com as ineficiências de replicação multicast, melhorando a latência e jitter para voz e vídeo numa rede.

Figura 11: Preservação do cabeçalho IP

Fonte: Moraes (2010).

2.3.2.1

GDOI (Group Domain of Interpretation)

Segundo Weis (2011), o GDOI (Group Domain of Interpretation) é um protocolo de gestão de chaves criptográficas e políticas de grupo, que estabelece SA (Security Association) entre membros de um grupo e trabalha com dois elementos: o Group Member e o Group

controller/Key Server. Essas chaves de criptografias são atualizadas periodicamente em todos

os GMs por meio do protocolo Rekey, esse processo é chamado de recodificação. Para um novo gateway se tornar um GM (Group Member), é preciso se autenticar com o KS (Key

Server), logo após essa autenticação o GM vai utilizar duas chaves para suas comunicações

(28)

Encryption Key) e outra chave para criptografar o tráfego TEK (Traffic Encryption Key). A

Figura 12 mostra todo processo de negociação das chaves.

Figura 12: Distribuição de chaves

Fonte: Adaptado do artigo CISCO, (2012).

2.3.2.2

GM (Group Member)

Segundo Weis (2011), o GM (Group Member) é um roteador/gateway responsável pela criptografia e descriptografia do tráfego real na rede GET VPN. Um roteador se torna um GM assim que é autenticado no KS (Key Server) e baixa todas as políticas de grupo e chaves de criptografia, criando assim a SA (Security Association) com os outros membros do grupo. Os GMs decidem qual chave deve usar ao criptografar o tráfego na rede GET VPN, em alguns casos as políticas fornecidas pelo KS podem ser sobrepostas localmente em um GM; pode ser citado como exemplo: quando poucos GMs em um grupo estiverem utilizando um protocolo de roteamento diferente, uma configuração local pode ser acrescentada a esses GMs em vez de definir configuração a nível global em um KS (Key Server).

2.3.2.3

KS (Key Server)

De acordo Weis (2011), o KS (Key Server ou servidor de chaves) é responsável pelo plano de controle do GET VPN, todas as políticas de criptografia, chaves de criptografia e associação de segurança são definidos no Key Server de forma centralizada e depois repassadas para os GMs. O Key Server também é responsável por atualizar e distribuir novas chaves. É importante ressaltar, que o Key Server está no plano de controle e não está no plano de tráfego, logo não é um gargalo para a rede, como ilustra a Figura 13.

(29)

Fonte: Adaptado do artigo Cisco, (2012).

O Key Server mantém o plano de controle, sendo assim um elemento muito importante na rede GET VPN. Quando a rede possui apenas um Key Server esse se torna um único ponto crítico da rede, e em caso de falha a rede GET VPN funciona até que ocorra a próxima renovação das chaves. O GET VPN suporta múltiplos Key Server, como mostra a Figura 14, sendo importante considerar essa redundância. A configuração do Group Member determina em qual Key Server irá se autenticar. Quando um COOP KS (Co-operative Key

Server) inicia, todos os Key Servers assumem um papel secundário e começa um processo de

eleição, o Key Server que tiver a maior prioridade definida é eleito como primário, os outros

Key Severs permanecem como secundários, um Group Members pode se registrar em

qualquer Key Server, porém apenas o Key Server primário é responsável pela criação e distribuição das chaves e políticas de grupo para todos os Group Members e sincronização dos outros Key Servers. A troca de mensagens entre o Key Server primário e os Key Servers secundários ocorrem a cada 20 segundos; se em um intervalo de 30 segundos o Key Server secundário não receba respostas de um Key Server primário o Key Server secundário tenta entrar em contato com o Key Server primário e solicita as atualizações; se depois de 60 segundos não houver resposta, uma nova eleição para Key Server primário é feita. Até oito

Key Servers podem ser configurados em um COOP KS (Co-operative Key Server), porém mais

do que quatro raramente são necessários.

(30)

2.4 DMVPN (Dynamic Multipoint Virtual Private Network)

Segundo Lewis (2006), o DMVPN é uma tecnologia aplicada hub-and-spoke9_que

reduz a quantidade de criação de túneis estáticos. Os túneis dinâmicos serão estabelecidos quando existir a necessidade entre dois spokes se comunicarem. O estabelecimento das conexões entre dois spokes diminuirá o consumo de processamento, latência do tráfego e consumo de banda no site central. Trabalha utilizando os protocolos IPSec para garantir autenticação e confiabilidade, o NHRP (Next Hop Resolution Protocol) que está descrita na RFC2332 e o GRE (Generic Routing Encapsulation) definida na RFC 2784.

O autor ressalta que o NHRP é um protocolo de comunicação que trabalha em redes que não propaga tráfego multicast, porém necessita trabalhar de forma multi-acess. O elemento hub dessa arquitetura opera como servidor, aprendendo e armazenando os endereços NBMA (Non-Broadcast Multiple Access) dos clientes spokes. O endereço armazenado será utilizado para descobrir os endereços IP roteáveis que serão utilizados para construção dos túneis spoke-to-spoke conforme a Figura 15.

Figura 15: Topologia de DMVPN

9 Hub-and-spoke é uma topologia de rede onde existe elemento que trabalha com um concentrador. Lewis, 2006

(31)

De acordo com Lewis (2006), o DMVPN trabalha com dois tipos de túneis: o túnel GRE que é criado de forma estática entre o spoke e o hub e o túnel mGRE (Multipoint Generic

Routing Encapsulation) que é estabelecido de forma dinâmica entre dois spokes. A criação de

túneis GRE dentro de túneis IPSec possibilita a comunicação multiprotocolos e tráfego

multicast, como ilustrado na Figura 16. A tecnologia DMVPN foi desenvolvida pela Cisco

Systems em parceira com a Juniper Networks, e tem como suas principais características: não realiza a criptografia dos dados, cria interfaces virtuais e dá suporte a tráfego IPv4 e IPv6.

(32)

O autor ainda enfatiza que, quando um spoke é iniciado, começa automaticamente a comunicação com hub para estabelecer um túnel GRE protegido pelo IPSec. Após o estabelecimento dessa comunicação será solicitado o registro no roteador NHS (Next Hop

Server). O hub que está configurado como NHS, registra as solicitações dos roteadores que

tenham a função de spoke, armazenando o endereço da interface física para a associação do endereço dos túneis mGRE e NHC (Next Hop Client). Como demostrado na Figura 17.

Figura 17: Estabelecimento de túnel fixo entre o hub e spoke

Caso o roteador A deseje enviar uma mensagem à rede do roteador B, onde o roteador só possua o endereço do túnel mGRE de B, primeiramente verificará em seu cache

(33)

se existem informações do IP roteável da rede B, caso não exista nenhuma informação, será solicitado o endereço ao hub. Conforme a Figura 18.

Figura 18: Criação de túnel dinâmico entes spokes.

(34)

3. MÉTODO CIENTÍFICO

“O termo “método” – do grego, metá (através de) e odós (caminho) – significa o caminho através do qual é possível encontrar a solução do problema proposto pela pesquisa.” (OLIVEIRA, 2008, p. 32).

“Na ciência existe a necessidade da utilização de ferramentas para aquisição e construção do conhecimento (método científico). Pode-se afirmar que o método é “uma maneira de como se fazer algo”. Dessa forma, em se tratando da prática científica, é necessária a existência e aplicação de um método.” (OLIVEIRA, 2008, p. 38).

De acordo com Oliveira (2008), o método comparativo estabelece procedimentos de comparação entres elementos para evidenciar as semelhanças e/ou diferenças. Este capítulo descreve o método de pesquisa utilizado para compreender e comparar os funcionamentos das tecnologias simulando em laboratório.

3.1Descrição do cenário

Para implementar as tecnologias GET VPN e DMVPN, foi utilizado o cenário como

backbone com quatro roteadores tendo o objetivo de simular um ISP (Internet Service Provider) que usa tecnologia baseada em rótulos (MPLS). Conforme a Figura 19.

Figura 19: Backbone MPLS

Fonte: Adaptado de Mendonça, (2012).

Para realizar as análises de comparação no laboratório foram necessários à utilização dos seguintes softwares:

 GNS3 – software emulador de sistemas operacionais de roteadores CISCO.  Wireshark – software de captura dos pacotes de rede para análise.

(35)

Com a utilização dos softwares especificados foram capturados os pacotes no estabelecimento da negociação entre os roteadores e durante o tráfego de informação entre

sites.

3.2 Elementos de configuração do GET VPN (Group Encrypt Transport VPN)

Para o ambiente foi usado o roteador de modelo Cisco 7200, em todos os ativos de redes (Key Server e Group Member), com sistema operacional IOS 15.1(4) M5 de pacote ADVENTERPRISEK9-M. No cenário utilizado como backbone, foram acrescentados três roteadores: um é o Key Server e dois são Group Members, conforme a Figura 20.

3.2.1 Configuração do KS (Key Server)

Inicialmente, foi necessário configurar as interfaces de conexão do Key Server com o

backbone MPLS. Conforme demostrado na Figura 20, onde o roteador Key Server é chamado

de CE11 e a interface conectada ao PE1 (roteador) é a serial 1/0. Foi atribuído um endereço IP para as interfaces loopback0 e outro para serial 1/0. Após a atribuição dos IPs é necessário habilitar a interface serial 1/0, conforme mostra o Quadro 1.

Quadro 1: Configuração das interfaces do roteador CE11

(36)

Figura 20: Backbone MPLS do GET VPN Fo n te : P ró p ri o s au to re s, ( 2 0 1 4 ).

(37)

Neste passo, conforme o Quadro 2, foi configurada a 1º fase do IPSec no roteador CE11, onde é atribuído a identificação da política, que no caso, é usado o identificador 11 (o identificador é necessário para saber que política está sendo utilizada). Foi atribuído e definido o método de autenticação “pre-share”, o algoritmo de criptografia “AES 128”, o grupo de criptografia “Diffie-Hellman” e o tempo de vida do SA (Security Association) que é de 3600 segundos.

Quadro 2: Configuração da fase 1º do IPSec.

Neste passo, conforme o Quadro 3 é gerada a chave ISAKMP (Internet Security

Association and Key Management Protocol) para os endereços de destino, no caso foi

informada uma chave para cada um dos GMs. Também é criada a chave de criptografia utilizada no SA (Security Association).

Quadro 3:Configuração de chaves

No Quadro 4, mostra a criação da diretiva, onde são definidos os parâmetros usados pelo IPSec, e a criação do perfil IPSec atribuindo a diretiva a este perfil.

(38)

Nesta etapa foi definido qual tráfego é protegido pelo IPSec por meio da configuração do IPSec, como mostra a Quadro 5, neste caso, o IPSec protege todo tráfego, logo, todos os pacotes irão ser encapsulados pelo ESP (Encapsulated Security Payload).

Quadro 5: Configuração das ACL

O Quadro 6 mostra a criação do servidor local de chaves e a definição do número de identificação que deve ser a mesma para todos os GMs e KS.

Quadro 6: Criação do servidor GDOI

Vale ressaltar, no Quadro 6, que o roteador responde com o log “GDOI is ON” afirmando que o protocolo GDOI está habilitado.

O Quadro 7 mostra a configuração do Rekey, que pode ser unicast ou multicast. No laboratório foi utilizado o método unicast.

(39)

Quadro 7: Configuração do Rekey

Pode-se observar no Quadro 7 que o roteador responde com o log “Transitione to

Unicast Rekey” afirmando que as renovações de chaves será pelo método unicast.

A crypto map é um conjunto de lista de acesso que é carregada junto com o IKE, devendo ser aplicada na interface do KS (Key Server) e dos GMs. A configuração do crypto

map é demostrada no Quadro 8.

Quadro 8: Configuração do crypto map

3.2.2

Configuração do GM (Group Member) CE22

Primeiramente, foi necessário configurar as interfaces de loopback e serial 1/0 para obter conexão do Group Member com o backbone MPLS. As configurações descritas neste tópico referem-se aos roteadores membros (GM), sendo necessário apenas modificar os endereços IPs das interfaces de cada roteador. Conforme mostra a Figura 20 (pag. 36), o roteador CE22 tem a interface serial 1/0 conectada com o PE2. Também foi atribuído o endereço IP da interface loopback0 e interface serial 1/0. Após a atribuição dos IPs é necessário habilitar a interface serial 1/0, conforme ilustra o Quadro 9.

(40)

O Quadro 10 demostra como foi configurado o IPSec no Group Member, onde é configurado a identificação da política, no caso foi usado o identificador 11. Neste passo também é definido o método de autenticação “pre-share”, o algoritmo de criptografia “AES128”, o grupo de criptografia 2 ou “Diffie-Hellman” e o tempo de vida do SA (Security

Association) que é de 3600 segundos.

Quadro 10: Configuração do IPSec

No Quadro 11 ilustra a configuração do Group Member para ingressar no grupo do GET VPN, onde é informada a chave gerada anteriormente no Key Server, junto com a identificação do grupo e o IP do servidor.

Quadro 11: Configuração para obter as chaves

(41)

A crypto map é um conjunto de lista de acesso que é carregada junto com o IKE, devendo ser aplicada na interface do Key Server e dos Group Members. A configuração do

crypto map é demonstrada no Quadro 12.

Quadro 12: Configuração do crypto map

Após a aplicação dessas configurações descritas, o log do roteador mostra que faz parte do grupo, tornando-se um Group Member.

3.2.3

Configuração do GM (Group Member) CE12

De acordo com o cenário mostrado na Figura 20 (pag. 36), existem um Key Server (CE11) e dois Group Members (CE12 e CE22). No tópico 3.2.2 foi configurado o roteador CE22 como Group Member e gerada uma chave para os dois Group Members deste cenário.

Para se tornar um Group Member, a configuração do roteador CE12 ocorre da mesma maneira que a configuração do roteador CE22, com exceção de alguns pontos que serão citados nesse tópico. O primeiro ponto é a configuração das interfaces, como mostra o Quadro 13.

Quadro 13: Configuração das interfaces do roteador CE12

(42)

O segundo ponto que deve ser modificado na configuração do roteador CE12, é o nome da chave que deve ser informado como “KEYCE12”, demostrado no Quadro 14.

Quadro 14: Configuração para obter as chaves do roteador CE12

3.2.4 Estabelecimento da VPN (Virtual Private Network)

Dando prosseguimento, este ponto descreve testes que comprovam o funcionamento da tecnologia GET VPN por meio de análises de pacotes e checagem das configurações dos elementos envolvidos no cenário.

Antes de aplicar o GET VPN nos roteadores do cenário, foi feito teste de conectividade por meio do comando “traceroute”, que mostra o caminho percorrido pelo pacote originado do roteador CE12 com destino a interface loopback0 do roteador CE22, o resultado é mostrado no Quadro 15.

(43)

Quadro 15: O comando traceroute antes de aplicar o GET VPN

Analisando o Quadro 15, pode-se confirmar que o pacote atravessa o backbone MPLS até chegar na interface loopback0 do roteador CE22.

Após aplicado o GET VPN, é executado novamente o comando “traceroute” com o mesmo destino. É possível notar a diferença do comando aplicado, agora o pacote tem apenas um salto até o destino, o Quadro 16 mostra que os roteadores estão diretamente conectados de maneira lógica.

Quadro 16: O comando traceroute depois de aplicar o GET VPN

3.2.4.1

Análise de pacotes da VPN (Virtual Private Network)

Utilizando o analisador de tráfego Wireshark, é possível visualizar que ao tentar comunicação por meio de um ping originado do roteador CE12 com destino ao roteador CE22, antes de aplicar o GET VPN, é relatado o recebimento de pacotes ICMP (Internet

(44)

Quadro 17: Pacotes ICMP antes do GET VPN.

No tópico 3.2.1, foi definido que todo tráfego será criptografado, logo, os pacotes do tipo ICMP também devem ser criptografados. Ao efetuar um ping do roteador CE12 com destino ao roteador CE22, depois de aplicar o GET VPN como mostra no Quadro 18, é possível visualizar que os pacotes chegam criptografados com o cabeçalho ESP do IPSec.

Quadro 18: Pacotes criptografados ESP.

(45)

3.2.5 Verificação das configurações do KS (Key Server)

Utilizando o comando “show crypto gdoi” no roteador C11, serão visualizadas as configurações aplicadas para o GDOI, como demostra no Quadro 19.

Quadro 19: Configuração do GDOI

3.2.6

Verificação das configurações dos GMs (Group Members)

Ao aplicar o comando “show crypto gdoi” pode-se visualizar as configurações aplicadas para o GDOI, de acordo com o Quadro 20.

(46)

(47)

3.2.7Análise de pacotes GDOI (Group Domain of Interpretation)

Com o uso do software Wireshark na interface serial1/0 do Key Server, foi possível observar que a troca de pacotes GDOI entre o Key Server e os Group Members de forma periódica como destacado na coluna Time do Quadro 21. Confirmando assim que as renovações de chaves estão funcionando.

Quadro 21: Captura de pacotes GDOI

Outra forma para confirmar a inclusão e renovação das chaves do Group Member é por meio do comando “show crypto gdoi”, como mostra no Quadro 22.

(48)

Os campos destacados mostram que o roteador CE22 tem o status registrado (Registred) como Group Member, e que já renovou as chaves de criptografia 3 vezes por meio do Rekey.

(49)

3.3 Elementos de configuração do DMVPN (Dynamic Multipoint VPN)

Para configurar o DMVPN foi necessário usar versões do IOS Release 12.2 (8) T ou posteriores. A utilizada no laboratório foi a versão 12.4 do modelo dos roteadores C7200. No cenário foi empregado um hub e dois spokes interligados por meio de um backbone MPLS formado por dois PEs e dois Ps, conforme a Figura 21.

3.3.1 Configuração

do Hub

Ao iniciar a

implantação do DMVPN, foi

necessário configurar as

interfaces de redes para que

haja a comunicação

entre o Hub e os Spokes. Logo

após, foi inserida uma

rota estática, informando que

todos os pacotes

destinados à redes diferentes

sejam encaminhados

para o roteador de borda do

MPLS, como mostra no Quadro 23. Quadro 23: Configurando interfaces do hub. Fo n te : P ró p ri o s au to re s, ( 2 0 1 4 ). Figura 21: Cenário do DMVPN

(50)

Após as configurações das interfaces do roteador, configura-se o protocolo IKE, que trabalha com o protocolo ISAKMP. O IKE é dividido em duas fases, onde na primeira fase foi definido o nível da política, o tipo do algoritmo de hash, criptografia, tipo da autenticação e também a chave utilizada na SA sendo disponibilizada para qualquer rede, como ilustra o Quadro 24.

Quadro 24: Configuração da 1º fase do IKE.

Em seguida, como mostra o Quadro 25, foi definido alguns parâmetros para a segunda fase do IKE, da qual foi configurado uma diretiva com alguns métodos de como o IPSec se comportará em seu uso, foi criado o perfil nomeado de “VPNPROF” e aplicada no perfil a diretiva criada.

Quadro 25: Configurando da segunda fase do IKE.

(51)

Dando prosseguimento a configuração do hub, foi configurada a interface tunnel0 (onde o número 0 é a identificação da interface), o IP para a comunicação com os Spokes e o protocolo NHRP que informa o mapeamento IP dos túneis de forma dinâmica e a identificação da rede (onde é necessário que essa identificação seja igual para todos os túneis). Em seguida, foi definido por qual interface física o túnel será originado (já que a interface túnel é virtual), o modo que o protocolo GRE trabalha (no caso multipoint) e a chave que foi usada, sendo iguais para todos os túneis. E por fim, foi aplicado na interface

tunnel0 o perfil IPSec configurado. Conforme a ilustra o Quadro 26.

Quadro 26: Configuração da interface tunnel0.

3.3.2 Configuração do Spoke1 e Spoke2

De acordo com a Figura 21 do cenário, foram utilizados dois Spokes (Spoke1 e Spoke2), onde a diferença da configuração entre os dois é o endereço IP configurado nas interfaces e a rota adicionada manualmente.

Iniciando a configuração foi definido o IP das interfaces serial 1/0 e loopback0 com o intuito de estabelecer a comunicação com backbone MPLS. Foi adicionada uma rota para que todos os pacotes destinados às redes diferentes sejam encaminhados para o roteador de borda do MPLS. No Quadro 27 mostra do Spoke1 e no Quadro 28, a do Spoke2.

(52)

Quadro 28:Configurando interfaces do Spoke2.

Iniciando a implantação do protocolo IKE, foram configuradas suas duas fases. Na primeira fase foi definida a política do protocolo ISAKMP, onde foi definido o algoritmo de

hash, criptografia e método de troca de chaves. Foi especificada a chave de criptografia

anteriormente configurada no hub. O Quadro 29 demostra o Spoke1 e o Quadro 30 o Spoke2.

Quadro 29: 1º fase do protocolo ISAKMP no Spoke1.

Fonte: Próprios autores, (2014)

(53)

Na segunda fase do protocolo IKE, é criada uma diretiva e um perfil IPSec. Na diretiva do perfil, informou qual o cabeçalho foi acrescentado no pacote IP, o algoritmo de autenticação e algoritmo de criptografia. Logo após, na criação do perfil, foi associada a diretiva criada, como mostra o Quadro 31 do Spoke1 e no Quadro 32 a do Spoke2.

Quadro 31: 2º fase do protocolo IKE no Spoke1.

Quadro 32: 2º fase do protocolo IKE no Spoke2.

Dando continuidade, como mostra no Quadro 33 (Spoke1) e o Quadro 34 (Spoke2), foi criada a interface tunnel0 e atribuído o endereço IP. Em seguida, foram definidos três parâmetros do NHRP: o mapeamento do IP público com o IP túnel do servidor, o identificador da interface de rede (onde deve ser igual para todos os equipamentos) e o servidor de próximo salto (NHS).

(54)

Na configuração do protocolo mGRE foi definida a interface de rede física que encaminha os dados, o modo de trabalho do mGRE e a configuração da chave que foi utilizada no túnel (a chave necessita ser igual para todos os túneis). E por fim, foi aplicado o perfil IPSec com o intuito de criptografar o túnel.

Quadro 34: Configuração da interface túnel e os protocolos utilizados no Spoke2.

Para verificar se os túneis foram fechados entre o Hub e os Spokes, foi utilizado o comando “show ip nhrp”, conforme Quadro 35. A resposta do comando mostra os túneis fechados, IP do Hub, quando foi criado e o tempo que falta para expirar. Na linha posterior informa o tipo de túnel, e por fim o IP da rede NBMA (Non-Broadcast Multiple Access) ou endereço público.

(55)

3.3.3 Captura de pacote da SA (Security Association) do ISAKMP e IPSec

Em uma análise de tráfego utilizando o wireshark na interface serial 1/0 do roteador denominado de Hub, com intuito de verificar o estabelecimento da SA (Security Association). Nesta análise foi capturado pacote do tipo ISAKMP originados no roteador Spoke1. No Quadro 36 demostra que foram trocadas as doze mensagens do IKE.

Quadro 36: Pacotes ISAKMP

Em uma nova análise, como mostra no Quadro 37, foi feita a captura de pacotes ICMP originados do Spoke1 com destino ao IP público do Spoke2, onde verificamos no campo destacado que os pacotes não foram criptografados.

(56)

Em seguida, em uma nova captura com destino a interface tunnel0 do roteador Spoke2, pode-se comprovar que os pacotes estão sendo criptografados na interface pois possui o cabeçalho ESP do IPSec. Demostrado no Quadro 38.

Quadro 38: Pacotes ESP

(57)

3.3.4 Verificando o funcionamento do DMVPN (Dynamic Multipoint VPN)

Para obter a confirmação que o DMVPN está funcionando de forma correta nos Spokes, foi criado um passo-a-passo para ter um melhor entendimento e funcionamento da tecnologia. Primeiro verifica-se quantos túneis estão fechados no Spoke1, este deverá possuir apenas um, o do hub. Como mostra no Quadro 39.

Quadro 39: Verificação de túneis antes de tráfego gerado entre Spokes

Logo após, através do comando “traceroute” do Spoke1 com destino ao Spoke2, mostra o caminho que o pacote percorre para chega ao destino, no primeiro contato deverá dar dois saltos, o primeiro ao Hub pedindo o IP público do Spoke2 e o segundo salto ao destino. Conforme o Quadro 40.

Quadro 40: Verificação do caminho do pacote antes do túnel dinâmico fechar

Sendo assim, verifica-se quantos túneis fechados existem, que agora deverá possuir dois túneis, pois foi fechado com o Spoke1 dinamicamente, como mostra o Quadro 41.

Quadro 41: Verificação de túneis fechado após tráfego gerado entre Spokes.

E por fim, por meio do comando “traceroute” no Spoke1 com destino ao Spoke2, para visualizar novamente por qual caminho o pacote percorreu para chegar ao destino. De

(58)

acordo com o Quadro 42, percorreu pelo túnel fechado dinamicamente com apenas um salto.

Quadro 42: Verificação do caminho do pacote após do túnel dinâmico fechar.

(59)

4.

ANÁLISE COMPARATIVA

Neste tópico serão abordadas as análises comparativas das principais características e protocolos utilizados visando vários aspectos com o propósito de alcançar os objetivos específicos do projeto por meio de pesquisas e laboratórios.

4.1 Comparação das principais características das tecnologias GET VPN e DMVPN

Baseado em estudos sobre as tecnologias GET VPN e DMVPN, foram verificadas as diferenças de suas características, onde o GET VPN foi criado com o propósito de prover segurança a redes MPLS, ao contrário da DMVPN que pode ser aplicada em vários cenários, podendo ser usado tanto em infraestrutura de rede públicas como privadas. A topologia utilizada pela tecnologia GET VPN é any-to-any, em contrapartida o DMVPN funciona com

hub-and-spoke e spoke-to-spoke. Os elementos encontrados no GETVPN são: Key Servers e Group Members, já o DMVPN possui como elementos o hub e o spoke.

Na tecnologia GET VPN para a comunicação entre os equipamentos na rede não é necessário a criação de túneis, já que a topologia do MPLS é um circuito malha completa onde todos estão conectados a todos, porém no DMVPN a troca de dados criptografados são por meio de túneis ponto-a-ponto.

A tecnologia GET VPN fornece criptografia para redes MPLS, mantendo a conectividade de malha completa, preservando o cabeçalho IP original do pacote, permitindo ser utilizado o caminho de roteamento do pacote original. Oferece flexibilidade de gestão, eliminando o gerenciamento complexo de chaves ponto a ponto, com chaves de criptografia de grupo. Simplifica a comunicação entre os elementos da rede, garantindo baixa latência, permitindo em tempo integral, a comunicação direta entre os elementos, sem a necessidade de transporte por meio de um hub central. Porém a tecnologia GET VPN é aplicada apenas em ambientes que utilizam WAN MPLS, tornando-se assim menos acessível, devido a maior complexidade exigida por uma infraestrutura MPLS.

Na tecnologia DMVPN quando há uma falha de conectividade decorrente de indisponibilidade do circuito de dados em algum elemento da topologia, o reestabelecimento ocorre de forma imediata, após a negociação da associação de segurança, porém na tecnologia GET VPN caso ocorra a falha de um GM da topologia e já tenha ocorrido a renovação da chaves, o GM aguardará a próxima renovação das chaves que ocorrerá pelo tempo determinado no protocolo Rekey ou atualização de alguma política de segurança.

Na utilização da tecnologia GET VPN nos ambientes coorporativos, é necessária a utilização de um link para a estrutura privada (MPLS) e outro link para a estrutura publica (Internet), o mesmo não ocorre com o uso do DMVPN, onde utiliza o circuito de dados da estrutura publica (Internet) para a construção da estrutura privada (túneis).

(60)

A tecnologia DMVPN tem propagações de multicast replicado por meio do hub, enquanto o GET VPN propaga multicast diretamente devido a sua malha completa, onde todos tem conexões com todos em tempo integral.

Segue no Quadro 43, a análise comparativa que elenca as características das tecnologias abordadas (GET VPN e DMVPN) de forma sintetizada com objetivos específicos.

Quadro 43: Análise comparativo

Características GET VPN DMVPN Principais características da tecnologia Estabelece a criptografia em IP para redes MPLS Disponibiliza túneis de forma dinâmica por meio do protocolo mGRE. Infraestrutura de Rede Privada Privada e pública

Topologia Full-mesh

Any-to-any

Hub-and spoke Spoke-to-spoke

(site-to-site) Roteamento Dinâmico por meio da

rede IP WAN

Dinâmico por meio de túneis

Tipo de Associação de Segurança

Associação de segurança de grupo através do cabeçalho ESP do IPSec

Ponto a ponto através do cabeçalho ESP do IPSec Peer-to-Peer

Protocolos Utilizados GDOI, IPSec NHRP, mGRE, IPSec Elementos de configuração Key Server (KS) e Group

Member (GM) Hub e spoke

Versões do IOS compatíveis

IOS image version:

12.4(15)T8 and 12.4(22)T2 IOS-XE image version: 12.2(33)XNC

IOS 15.1(4) M5 de nome ADVENTERPRISEK9-M.

IOS image version: 12.3(11)T02 ou versões posteriores.

Fonte: Adaptada Cisco, 2012

4.2 Comparação do funcionamento dos protocolos utilizados nas tecnologias GET VPN e DMVPN

Em relação aos protocolos utilizados pelas tecnologias, ambas utilizam o IPSec para prover segurança na comunicação entre os elementos. No DMVPN é estabelecido criptografia por meio de túneis, entretanto no GET VPN não se faz necessário à utilização de túneis para prover a criptografia nos dados. O DMVPN funciona tanto no modo transporte quanto no modo túnel do IPSec, já com o GET VPN é utilizado o modo de atuação transporte, pela característica da tecnologia preservar o cabeçalho IP do pacote original.

(61)

Para o funcionamento, as duas usam diferentes protocolos, no GET VPN o protocolo GDOI gerencia a criação e troca das chaves criptográficas, estabelecendo a segurança de grupo, em contrapartida DMVPN usa o NHRP é o protocolo de comunicação que faz a associação do IP público com o IP do túnel, e para estabelecimento de tuneis de forma estática é utilizado o GRE e o os tuneis construídos de forma dinâmica utilizam o protocolo mGRE.

4.3 Compatibilidade das versões do sistema operacional IOS

Para fazer uso das tecnologias GETVPN e DMVPN, é necessário que os equipamentos ativos (roteadores) tenham um sistema operacional (IOS, ou Internetwork Operating System) com suporte para os protocolos específicos de cada tecnologia. No caso do DMVPN é necessário que o sistema operacional dê suporte para pacotes de criptografia (IPSec) e possua recursos avançados IP (NHRP, mGRE) sendo disponibilizados a partir da versão do IOS 12.2(8)T com pacote Advanced Security (advsecurityk9-mz) ou superiores. Já para o uso da tecnologia GET VPN é importante que o sistema operacional também dê suporte a pacotes de criptografia (IPSec), recursos avançados de segurança (GDOI) e recursos de provedor de serviços (MPLS), sendo disponibilizados a partir das versões 12.4(15)T8 com o pacote

(62)

5.

CONCLUSÃO

O uso de VPN é a resposta a uma necessidade das empresas de estarem conectadas para compartilhamento de recursos e arquivos de forma segura, a fim de evitar a leitura dessas informações caso haja uma interceptação por pessoas que não estão devidamente autorizadas, afinal o meio de compartilhamento desses dados pode ocorrer através de um meio público

Nesta pesquisa, procurou-se entender os conceitos fundamentais de VPN e em quais cenários podem ser aplicados. Em seguida, foram analisados os dois modelos específicos de VPN (GET VPN e DMVPN), ambos utilizam IPSec para prover segurança.

Por meio de pesquisas e análises em laboratório, constatou-se que as tecnologias GET VPN e DMVPN são soluções que podem ser aplicadas em um ambiente coorporativo de forma que proporcione autenticidade, confiabilidade e integridade no compartilhamento de informações entre sites geograficamente separados. Foi provado que, de fato, estas tecnologiasrealizam a criptografia na transmissão dos dados.

Durante a configuração do laboratório verificou-se que a configuração do elemento concentrador do GET VPN (Key Server) é mais complexa e exige maiores aplicações de linhas de comando que o da tecnologia do DMVPN (Hub). Em contrapartida, os elementos clientes do GET VPN (Group Member) são mais simples e rápidos de configurar.

Durante a pesquisa constatou-se tambémque a tecnologia GET VPN funciona apenas em ambientes que têm toda sua estrutura baseada em soluções desenvolvidas pela Cisco Systems e essa tecnologia não pode ser utilizada por outro fabricante. Outros fabricantes podem fazer uso de associação de grupo com o GDOI, que é um protocolo aberto, porém o nome GET VPN é exclusivo da Cisco Systems que foi a primeira a desenvolver esse tipo de tecnologia.

Já a tecnologia DMVPN por ser desenvolvida em conjunto pela Cisco Systems com a Juniper Networks, proporciona aplicação em um ambiente mais heterógeno por não ser limitada a um único fabricante.

Ainda durante pesquisas, foi constatado que o protocolo GRE utilizado pelo DMPVN que está descrito na RFC 2784, porém a variação do protocolo GRE que proporciona múltiplas conexões em uma única interface conhecido como mGRE não estar descrita nessa RFC, o que demandou uma pesquisa mais abrangente para o entendimento do protocolo.

Portanto, pode-se concluir que a tecnologia DMVPN, desenvolvida pela Cisco com parceria da Juniper, é a melhor tecnologia por ser aplicável, por funcionar em todos os ambientes WAN, incluindo redes MPLS, apesar de perder parte da característica de malha

(63)

completa do MPLS. Porém, mantém autenticidade, confiabilidade e integridade por meio de criptografia de dados na troca de informação em sites geograficamente separados. Garantindo assim, que ao implementar esta tecnologia, não se restringe a um único fabricante ou a uma única tecnologia de rede WAN, permitindo a implementação de VPN IPSec em redes de pequenas, médias e grandes empresas de forma simples e rápida.

(64)

6.

REFERÊNCIAS

Livros

ALBUQUERQUE, Fernando. TCP/IP – Internet: Protocolos & Tecnologias. 3ª ed. RJ: Axcel Books, 2001.

BORGERTH, Vânia Maria da Costa. SOX Entendendo a Lei Sarbanes-Oxley. 1ª ed. SP: Thomson, 2007.

FOROUZAN, Behrouz A e FEGAN, Sophia Chung. Protocolo TCP/IP. 3ª ed. SP: McGraw-Hill, 2008.

KUROSE, James F. Redes de Computadores e a Internet: Uma Abordagem Top-Down. 3ª ed. SP: Person, 2006.

LEINWAND, Allan e PINSKY, Brunce. Como Configurar Roteadores Cisco. RJ: Ciência Moderna, 2002

LEWIS, Mark. Comparing, Designing, and Deploying VPNs. USA: Cisco Press, 2006. MENDONÇA, Roberto. et al. MPLS – Fundamentos e Aplicações. RJ: Brasport, 2012. MORAES, Alexandre Fernandes de. Segurança em Redes: Fundamentos. SP: Érica, 2010. NAKAMURA, Emilio Tissato e GEUS, Paulo Lício de. Segurança de Redes Em Ambientes Cooperativos. SP: Novatec, 2007.

NORTHCUTT, Stephen. et al. Inside Network Perimeter Security. USA: Sams Publishing, 2005. OLIVEIRA NETTO, Alvim Antônio de. Metodologia da Pesquisa Cientifica Guia Prático para Apresentação de Trabalhos Acadêmicos. 3ª ed. SC: Visual Books, 2008.

ODOM, Wendell. CCNA ICND2 – Guia Oficial de Cerificação do Exame. 2ª ed. RJ: Alta Books, 2008.

STALLINGS, William. Criptografia e Segurança de Redes: Princípios e Práticas. 4ª ed. SP: Pearson, 2008.

WILKINS, Sean. SMITH III, Franklin H. CCNP Security SECURE 642-637 Official Cert Guide. USA: Cisco Press, 2011.

Material da Internet

DYNAMIC Multipoint VPN (DMVPN) Design Guide. 2006 Disponível em: <https://www.cisco.com/application/pdf/en/us/guest/netsol/ns171/c649/ccmigration_0918 6a008075ea98.pdf>. Acesso em: 02 de mar. de 2014.