Mostrando postagens com marcador VPN. Mostrar todas as postagens
Mostrando postagens com marcador VPN. Mostrar todas as postagens

quarta-feira, 1 de março de 2017

VPN IPSec Site-to-Site no Debian GNU/Linux

Olá Pessoal,

No Lab27 do livro Laboratórios de Tecnologias Cisco explico ao leitor como configurar dois roteadores Cisco para estabelecer uma VPN IPSec  e conectar duas redes locais (LAN) remotamente através da Internet (site-to-site). Neste artigo trago um laboratório bastante similar com base na topologia apresentada na figura abaixo, só que dessa vez irei fazê-lo através de utilização de dois servidores instalados com o Debian 8 GNU/Linux que serão configurados como roteadores VPN


Antes de abordar as configurações, é importante um pouco de discussão sobre a escolha de uma solução de VPN para ambientes Linux. Por se tratar de um ambiente aberto, no Linux existe uma grande diversidade de soluções que podem ser utilizadas para implementar uma VPN para fins de estabelecimento de um túnel virtual privativo entre duas (ou mais) unidades remotas. Além de existirem várias ferramentas, também existem diferentes tipos de soluções para implementação da VPN, o que faz com que o primeiro desafio de um administrador seja a escolha da solução mais adequada no contexto do seu ambiente.

As VPNs são tradicionalmente implementadas através de túneis IPSec (solução padronizada em RFC) ou de túneis SSL/TLS. As duas abordagens trazem excelentes resultados, mas é importante ter em mente que a solução IPSec é implementada em nível de rede, enquanto que a solução TLS é implementada em nível de aplicação. De maneira simplista isso quer dizer que uma VPN IPSec é implementada diretamente entre os roteadores (em nível de rede), enquanto que uma VPN TLS é implementada entre os softwares servidor/cliente (em nível de aplicação).

Cada uma dessas modalidades tem vantagens e desvantagens. Por exemplo, como a VPN TLS é estabelecida entre as aplicações (e não entre as máquinas), normalmente ela é mais atrativa para a criação de VPNs do tipo client-to-site, em que o objetivo é que um cliente em casa ou outro local fora da empresa possa se conectar aos recursos da infraestrutura de rede da empresa, afinal o próprio software cliente da máquina do usuário se encarrega de esconder do usuário toda a complexidade de configuração da VPN. Por outro lado, a principal vantagem de implementar uma VPN através do IPSec em nível de rede, ao invés do SSL em nível de aplicação, é que existe interoperabilidade entre as soluções de diferentes fabricantes.

Obs.: Reocmendo a leitura do artigo no link abaixo caso o leitor tenha interesse em estabelecer uma VPN através da integração de uma ponta que possui um roteador Cisco (baseado no IOS) e outra ponta que possui um servidor Linux Debian (baseado no strongSwan):

http://www.cisco.com/c/pt_br/support/docs/ip/internet-key-exchange-ike/117258-config-l2l.html

Particularmente neste artigo o objetivo é trazer os procedimentos de configuração de uma VPN IPSec para interconexão de duas unidades remotas de uma empresa através de um túnel virtual. Mesmo depois de tomada essa decisão, ainda existem várias ferramentas no Linux que podem ser utilizadas para esse fim, por exemplo: strongSwan, OpenSwan, LibreSwan, etc... Uma das soluções mais tradicionais é o strongSwan, já que seu desenvolvimento ainda é bastante ativo e por isso a ferramenta é repleta de novos recursos, diferente do OpenSwan que parece estar estagnado apenas para versões antigas do kernel.


Abaixo baixo trago as configurações básicas de rede que foram utilizadas em cada um dos roteadores Debian, seguindo a lógica da topologia apresentada no início do artigo. Além das configurações abaixo, também é importante alterar para 1 a flag do kernel que indica ao sistema que ele tem permissão para fazer roteamento entre redes, o que pode ser feito através do comando: sysctl -w net.ipv4.ip_forward=1

###--- Router-Site1: /etc/network/interfaces

# Interface Loopback
auto lo
iface lo inet loopack

# Conexao WAN (Internet)
auto eth0
iface eth0 inet static
    address 203.0.113.2
    netmask 255.255.255.252
    gateway 203.0.113.1

# Conexao LAN
auto eth1
iface eth1 inet static
    address 192.168.100.1
    netmask 255.255.255.0



###--- Router-Site2: /etc/network/interfaces

# Interface Loopback
auto lo
iface lo inet loopack

# Conexao WAN (Internet)
auto eth0
iface eth0 inet static
    address 198.51.100.2
    netmask 255.255.255.252
    gateway 198.51.100.1

# Conexao LAN
auto eth1
iface eth1 inet static
    address 192.168.200.1
    netmask 255.255.255.0

Vamos à configuração da VPN IPSec...

1) Instalação do Serviço strongSwan de VPN IPSec

Feita essa breve contextualização, vamos à instalação da ferramenta strongSwan. Assim como nos outros artigos do blog, estou considerando que os servidores estão instalados com a distribuição Debian GNU/Linux (ou seus derivados, como o Ubuntu). A primeira etapa consiste na instalação do pacote denominado strongswam para que os servidores Linux possam ser posterirmente configurados como roteadores VPN. Essa tarefa é simples e rápida através do APT:

root@Router-SiteA:/# apt-get update
root@Router-SiteA:/# apt-get install strongswan

root@Router-SiteB:/# apt-get update
root@Router-SiteB:/# apt-get install strongswan

2) Edição do Arquivo de Configuração e Definição da(s) VPN(s)

Dois dos arquivos mais importantes de configuração do strongSwan ficam localizados em /etc/ipsec.conf e /etc/ipsec.secrets.  O arquivo ipsec.conf é responsável pelas configurações gerais, além das configurações específicas de cada uma das conexões VPN. Logo, devemos editar esse arquivo em ambos os roteadores com as seguintes configurações para criar uma VPN coerente entre os pares:

###--- Router-Site1: /etc/ipsec.conf (strongSean IPSec config file)

###--- Configuracoes Gerais
config setup
        charondebug="all"
        uniqueids=yes
        strictcrlpolicy=no

###--- Definicao da(s) VPN(s)
conn VPN-Site1-to-Site2
        left=203.0.113.2
        leftsubnet=192.168.100.0/24
        right=198.51.100.2
        rightsubnet=192.168.200.0/24
        ike=aes256-sha2_256-modp1024!
        esp=aes256-sha2_256!
        keyingtries=0
        ikelifetime=1h
        lifetime=8h
        dpddelay=30
        dpdtimeout=120
        dpdaction=restart
        authby=secret
        auto=start
        keyexchange=ikev2
        type=tunnel
     


###--- Router-Site2: /etc/ipsec.conf (strongSean IPSec config file)

###--- Configuracoes Gerais
config setup
        charondebug="all"
        uniqueids=yes
        strictcrlpolicy=no

###--- Definicao da(s) VPN(s)
conn VPN-Site1-to-Site2
        left=198.51.100.2
        leftsubnet=192.168.200.0/24
        right=203.0.113.2
        rightsubnet=192.168.100.0/24
        ike=aes256-sha2_256-modp1024!
        esp=aes256-sha2_256!
        keyingtries=0
        ikelifetime=1h
        lifetime=8h
        dpddelay=30
        dpdtimeout=120
        dpdaction=restart
        authby=secret
        auto=start
        keyexchange=ikev2
        type=tunnel

Obsrevem nas linhas destacadas em amarelo que os parâmetros left e right fazem referência às pontas da VPN. Para facilitar o processo de cópia do arquivo de configuração nos dois roteadores Linux não faz diferença qual ponta será associada com o parâmetro left ou right, uma vez que o sistema observa as configurações das interfaces de rede para identificar a ponta local. No entanto, é interessante manter as infomações organizadas de forma a utilizar o parâmetro left para fazer referência ao ponto local, enquanto que o parâmetro right fica reservado para o ponto remoto. O leitor interessado em detalhes sobre os demais parâmetros pode obter mais informações na documentação oficial do strongSwan, disponível no link abaixo:

https://wiki.strongswan.org/projects/strongswan/wiki/ConnSection

3) Definição da Chave Pré-Compartilhada (PSK)

O segundo arquivo importante de configuração do strongSwan é o /etc/ipsec.secrets, responsável por armazenar a(s) chave(s) pré-compartilhadas que será(ão) utilizada(s) durante o processo de associação dos pares nas fases prévias de estabelecimento da VPN.  Devemos editar esse arquivo em ambos os roteadores com as seguintes configurações para criar uma VPN coerente entre os pares:

###--- Router-Site1: /etc/ipsec.secrets
203.0.113.2 198.51.100.2 : PSK : 'senha13579senha02468'

###--- Router-Site2: /etc/ipsec.secrets
198.51.100.2 203.0.113.2 : PSK : 'senha13579senha02468'

Obs.: Para fins de simplicidade, neste artigo foi utilizada uma chave pré-compartilhada entre os roteadores VPN. No entanto, também é possível a utilização de certificados digitais e chaves privada/pública para adicionar mais segurança ao processo de estabelecimento do túnel. A configuração de uma VPN com uso de certificados/chaves no strongSwan não é complicada, embora demande alguns passos adicionais. Caso haja interesse dos leitores, essa configuração pode ser objeto  de um próximo artigo no blog.

4) Manipulação e Checagem do Serviço da VPN IPSec

Depois de realizadas as configurações anteriores, a VPN IPSec está devidamente configurada para entrar em operação. Para ativá-la basta utilizar o comando ipsec restart e para visualizar seu status basta utilizar os comandos ipsec status ou ipsec statusall, conforme pode ser observado nas saídas trazidas abaixo:

Router-Site1:/# ipsec statusall
Status of IKE charon daemon (strongSwan 5.2.1, Linux 3.16.0-4-586, i686):
(...) Saída Omitida
Connections:
VPN-Site1-to-Site2:  203.0.113.2...198.51.100.2  IKEv2, dpddelay=30s
VPN-Site1-to-Site2:   local:  [203.0.113.2] uses pre-shared key authentication
VPN-Site1-to-Site2:   remote: [198.51.100.2] uses pre-shared key authentication
VPN-Site1-to-Site2:   child:  192.168.100.0/24 === 192.168.200.0/24 TUNNEL, dpdaction=restart
Security Associations (1 up, 0 connecting):
VPN-Site1-to-Site2[1]: ESTABLISHED 14 seconds ago, 203.0.113.2[203.0.113.2]...198.51.100.2[198.51.100.2]
(...) Saída Omitida
VPN-Site1-to-Site2{1}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 0 bytes_o, rekeying in 7 hours
VPN-Site1-to-Site2{1}:   192.168.100.0/24 === 192.168.200.0/24 

O leitor pode constatar que a configuração de uma VPN IPSec no Linux não é tão difícil quanto alguns dizem. Na realidade, possivelmente essa informação seja decorrente da comparação da configuração de uma VPN IPSec com uma VPN TLS através do OpenVPN que é reconhecida por ser mais rápida e simples.

Ainda é importante destacar que caso os roteadores Debian GNU/Linux estejam conectados atrás de um firewall de borda, é importante liberar as portas 500/UDP (utilizada na troca de chaves do ISAKMP) e 4500/UDP (utilizada pelo NAT-T). Além disso, os pacotes IPSec usam dois numéros dedicados de protocolos na camada de rede: 50 (ESP) e 51 (AH).

Por exemplo, supondo que os roteadores estejam atrás de um firewall baseado em iptables, então é necessário aceitar os pacotes nessas portas e traduzir o endereço público de destino (do firewall de borda) para o endereço privado do roteador VPN, de forma que as regras para liberação do tráfego IPSec seriam as seguintes:

iptables -t nat -A PREROUTING -p udp -d <IP_WAN> --dport  500 -j DNAT --to <IP>
iptables -t nat -A PREROUTING -p udp -d <IP_WAN> --dport 4500 -j DNAT --to <IP>

Caso o roteador Debian GNU/Linux seja o próprio firewall, o que é comum em ambientes menores, então é necessário apenas uma regra de entrada para o ISAKMP, já que não ocorre tradução (NAT-T):

iptables -t filter -A INPUT  -p udp --dport 500 -j ACCEPT

Façam seus testes...

Samuel.

domingo, 12 de janeiro de 2014

VPN Dinâmica Multiponto (DMVPN) em Roteadores Cisco

Olá Pessoal.

Através das VPNs tradicionais acaba sendo inviável implementar uma topologia full-mesh para estabelecimento de todos os links possíveis entre as unidades remotas de uma empresa porque sua complexidade é de ordem exponencial, matematicamente expressada através da fórmula (n²-n)/2. Por exemplo, uma empresa que tenha 5 unidades teria que configurar 10 VPNs para conectar essas unidades através de todas as ligações possíveis: (5²-5)/2 = (25 - 5)/2 = 20/2 = 10.

Uma solução comum para contornar essa complexidade é a implementação de uma topologia hub-and-spoke, de forma que cada filial é conectada apenas com a matriz (ponto central concentrador), o que reduz a quantidade de ligações necessárias à quantidade de unidades remotas. A figura abaixo traz uma imagem comparando essas duas topologias.


Embora a topologia hub-and-spoke resolva o problema da complexidade, ela implica em pior desempenho caso duas filiais queiram se comunicar entre si, uma vez que será necessário trafegar os dados pelo ponto central. Do ponto de vista de desempenho seria mais interessante que as duas filiais tivessem uma VPN diretamente configurada entre elas. A tecnologia de DMVPN (Dynamic Multipoint VPNprovê uma solução escalável para configuração de túneis dinâmicos em ambientes que possuem diversos sites. A vantagem dessa solução é que ela é "simples" de configurar como a topologia hub-and-spoke, mas tem o desempenho otimizado da topologia full-mesh. 

Na configuração de DMVPN é necessário criar VPNs apenas entre as filiais e a matriz (unidade central), no entanto, quando há comunicação entre duas filiais, essa solução estabelece dinamicamente uma VPN temporária para que o tráfego entre as unidades não tenha que passar pelo ponto central. Por conta do overhead inerente a todo processo dinâmico, é recomendado que essa solução seja implementada tendo em mente a regra 80/20, onde 80% do tráfego ocorra entre filiais e matriz e os demais 20% ocorram entre as filiais.

O processo de configuração da DMVPN combina as seguintes tecnologias: Túneis GRE (Generic Routing Encapsulation), IPSec e Protocolo NHRP (Next Hop Resolution Protocol). Para exemplificar sua configuração estarei utilizando como base o cenário apresentado na figura abaixo, onde existem 3 unidades remotas conectadas na Internet. Observem no cenário que R1 representa o ponto central (hub), enquanto que R2 e R3 são spokes.


A principal diferença na configuração de uma DMVPN em relação a uma VPN tradicional é que o roteador no ponto central (hub) irá executar uma instância servidora do protocolo NHRP. As filiais executam uma instância cliente do NHRP, informando automaticamente seus endereços públicos para manter a tabela de pontos (spokes) do servidor sempre atualizada. Quando duas filiais (spokes) vão se comunicar o roteador da filial de origem do tráfego faz uma busca ao servidor NHRP (roteador da matriz) para saber o endereço público de destino da outra ponta. Depois disso já é possível iniciar o processo de estabelecimento de um túnel dinâmico temporário através de uma interface mGRE (multipoint GRE).

Então vamos à configuração de R1 (hub):

01. R1(config)# crypto isakmp policy 10
02. R1(config-isakmp)# hash md5
03. R1(config-isakmp)# authentication pre-share
04. R1(config-isakmp)# exit
05. R1(config)# crypto isakmp key SENHA address 0.0.0.0 0.0.0.0
06. R1(config)# crypto ipsec transform-set NOME esp-3des esp-md5-hmac 
07. R1(cfg-crypto-trans)# exit
08. R1(config)# crypto ipsec profile DMVPN
09. R1(ipsec-profile)# set security-association lifetime seconds 120
10. R1(ipsec-profile)# set transform-set NOME
11. R1(ipsec-profile)# exit
12. R1(config)# int tunnel 0
13. R1(config-if)# ip address 192.168.0.1 255.255.255.0
14. R1(config-if)# ip mtu 1440
15. R1(config-if)# ip nhrp authentication SENHA
16. R1(config-if)# ip nhrp map multicast dynamic
17. R1(config-if)# ip nhrp network-id 1
18. R1(config-if)# tunnel source f0/0
19. R1(config-if)# tunnel mode gre multipoint
20. R1(config-if)# tunnel key 0
21. R1(config-if)# tunnel protection ipsec profile DMVPN
22. R1(config-if)# exit
23. R1(config)# ip route 192.168.2.0 255.255.255.0 192.168.0.2
24. R1(config)# ip route 192.168.3.0 255.255.255.0 192.168.0.3

Em relação à configuração, reparem que o servidor NHRP foi ativado nas linhas 15, 16 e 17; e que o modo do túnel é "gre multipoint" (linha 19). Apenas para constar, as linhas 23 e 24 são rotas estáticas necessárias para direcionar o tráfego destinado às redes locais (LAN) através do endereço do respectivo roteador na VPN Multiponto.

Agora vamos à configuração de R2 e R3 (spokes):

01. R2(config)# crypto isakmp policy 10
02. R2(config-isakmp)# hash md5
03. R2(config-isakmp)# authentication pre-share
04. R2(config-isakmp)# exit
05. R2(config)# crypto isakmp key SENHA address 0.0.0.0 0.0.0.0
06. R2(config)# crypto ipsec transform-set NOME esp-3des esp-md5-hmac
07. R2(cfg-crypto-trans)# exit
08. R2(config)# crypto ipsec profile DMVPN
09. R2(ipsec-profile)# set security-association lifetime seconds 120
10. R2(ipsec-profile)# set transform-set NOME
11. R2(ipsec-profile)# int tunnel 0
12. R2(config-if)# ip address 192.168.0.2 255.255.255.0
13. R2(config-if)# ip mtu 1440
14. R2(config-if)# ip nhrp authentication SENHA
15. R2(config-if)# ip nhrp map multicast dynamic
16. R2(config-if)# ip nhrp map 192.168.0.1 203.0.113.2
17. R2(config-if)# ip nhrp map multicast 203.0.113.2    
18. R2(config-if)# ip nhrp network-id 1
19. R2(config-if)# ip nhrp nhs 192.168.0.1
20. R2(config-if)# tunnel source f0/0
21. R2(config-if)# tunnel mode gre multipoint
22. R2(config-if)# tunnel key 0
23. R2(config-if)# tunnel protection ipsec profile DMVPN
24. R2(config-if)# exit
25. R2(config)# ip route 192.168.1.0 255.255.255.0 192.168.0.1
26. R2(config)# ip route 192.168.3.0 255.255.255.0 192.168.0.3

***

R3(config)#
01. R3(config)# crypto isakmp policy 10
02. R3(config-isakmp)# hash md5
03. R3(config-isakmp)# authentication pre-share
04. R3(config-isakmp)# exit
05. R3(config)# crypto isakmp key SENHA address 0.0.0.0 0.0.0.0
06. R3(config)# crypto ipsec transform-set NOME esp-3des esp-md5-hmac
07. R3(cfg-crypto-trans)# exit
08. R3(config)# crypto ipsec profile DMVPN
09. R3(ipsec-profile)# set security-association lifetime seconds 120
10. R3(ipsec-profile)# set transform-set NOME
11. R3(ipsec-profile)# int tunnel 0
12. R3(config-if)# ip address 192.168.0.3 255.255.255.0
13. R3(config-if)# ip mtu 1440
14. R3(config-if)# ip nhrp authentication SENHA
15. R3(config-if)# ip nhrp map multicast dynamic
16. R3(config-if)# ip nhrp map 192.168.0.1 203.0.113.2
17. R3(config-if)# ip nhrp map multicast 203.0.113.2    
18. R3(config-if)# ip nhrp network-id 1
19. R3(config-if)# ip nhrp nhs 192.168.0.1
20. R3(config-if)# tunnel source f0/0
21. R3(config-if)# tunnel mode gre multipoint
22. R3(config-if)# tunnel key 0
23. R3(config-if)# tunnel protection ipsec profile DMVPN
24. R3(config-if)# exit
25. R3(config)# ip route 192.168.1.0 255.255.255.0 192.168.0.1
26. R3(config)# ip route 192.168.2.0 255.255.255.0 192.168.0.2

Em relação às configurações das filiais (spokes), vale observar que a configuração do NHRP mudou porque agora os roteadores são clientes, por isso a necessidade de fazer manualmente o mapeamento entre o IP da DMVPN com o endereço público de R1 (203.0.113.2). Alguns comandos interessantes para verificar se as configurações estão funcionando são:

Router# show crypto isakmp sa
Router# show crypto ipsec sa
Router# show ip nhrp

Nesse exemplo, sempre que R2 e R3 forem se comunicar, então antes será estabelecida uma VPN dinâmica entre eles, de forma que o tráfego entre R2 e R3 não tenha que ser intermediado por R1. Depois de um tempo sem tráfego entre R2 e R3 o túnel é desativado para economizar recursos dos roteadores, já que as associações criptográficas demandam bastante processamento. 

Abraço.

Samuel.

sábado, 29 de junho de 2013

VPN Site-to-Site Baseada em IPv6

Olá Pessoal.


Essa 25/06/2013 participei de mais um evento "IPv6 no Café da Manhã" realizado pelos colegas do NIC.br. Nessa edição o formato foi de um mini-tutorial com a equipe do IPv6.br e o tema foi "Endereçamento e Planejamento de Redes IPv6". Foi mais um evento de grande qualidade e me lembro de que naquela oportunidade surgiu uma discussão interessante sobre o estabelecimento de túneis virtuais privativos (VPN) em redes IPv6.

Como não houve tempo hábil para detalharmos aquela discussão, então achei por bem continuar essa sequência de artigos sobre IPv6 que venho escrevendo no blog e que seria conveniente registrar um novo artigo mostrando como seria o processo de configuração de uma VPN site-to-site em redes IPv6.

É comum o estabelecimento de VPNs para a comunicação entre unidades remotas de uma empresa (site-to-site), afinal seu custo é convidativo porque a infraestrutura da Internet pública já existente é aproveitada para viabilizar a criação de uma rede privativa virtual, como se a empresa tivesse um link privativo de longa distância, o que não seria barato. Para exemplificar esse processo vamos considerar o cenário apresentado na figura abaixo (clique na imagem para ampliar). Cabe apenas mencionar que a configuração das políticas de segurança do IPSec em VPNs IPv6 é basicamente a mesma que já era realizada em VPNs IPv4 - a solução em si não mudou!


No cenário existem roteadores de borda representando duas unidades de uma empresa, uma localizada em São Paulo (SP) e outra no Rio de Janeiro (RJ). A unidade de SP está conectada à Internet através do link 2001:DB8:AAAA:: e também está conectada à rede local 2001:DB8:CAFE::1/64, enquanto que a unidade do RJ está conectada à Internet através do link 2001:DB8:BBBB:: e também a sua rede local 2001:DB8:CAFE:2::/64.

Com os comandos abaixo será configurada uma VPN através do túnel FD00:CAFE::A/127 (FD00:CAFE::A e FD00:CAFE::B). Reparem que estamos utilizando endereços /127 no túnel porque se trata de um link ponto-a-ponto, além disso também estamos fazendo uso dos endereços privados unique-local (ULA), afinal se trata de um link privativo entre as unidades e que existe “camuflado” por trás dos links com a Internet pública.

> Configuração do Roteador de São Paulo:

01. SP(config)# ipv6 unicast-routing
02. SP(config)# ipv6 route ::/0 2001:db8:aaaa::f
03. SP(config)# interface f0/0
04. SP(config)# description Link-ISP
05. SP(config-if)# ipv6 enable
06. SP(config-if)# ipv6 address 2001:db8:aaaa::1/64
07. SP(config-if)# no shutdown
08. SP(config-if)# exit
09. SP(config-if)# interface f1/0
10. SP(config-if)# description LAN-CAFE-1
11. SP(config-if)# ipv6 enable
12. SP(config-if)# ipv6 address 2001:Db8:cafe:1::1/64
13. SP(config-if)# no shutdown
14. SP(config-if)# exit
15. SP(config)# crypto isakmp key 0 SENHA address ipv6 ::/0
16. SP(config)# crypto isakmp policy 1
17. SP(config-isakmp)# encryption aes 128
18. SP(config-isakmp)# authentication pre-share
19. SP(config-isakmp)# exit
20. SP(config)# crypto ipsec transform-set VPNv6 esp-aes 128 esp-sha-hmac
21. SP(cfg-crypto-trans)# mode tunnel
22. SP(cfg-crypto-trans)# exit
23. SP(config)# crypto ipsec profile VPNv6
24. SP(ipsec-profile)# set transform-set VPNv6
25. SP(ipsec-profile)# exit
26. SP(config)# interface tunnel 0
27. SP(config-if)# description VPN-to-RJ
28. SP(config-if)# ipv6 enable
29. SP(config-if)# ipv6 address fd00:cafe::a/127
30. SP(config-if)# tunnel source f0/0
31. SP(config-if)# tunnel destination 2001:db8:bbbb::1
32. SP(config-if)# tunnel mode ipsec ipv6
33. SP(config-if)# tunnel protection ipsec profile VPNv6

34. SP(config-if)# exit
35. SP(config)# ipv6 route 2001:db8:cafe:2::/64 tunnel 0
 

Os comandos das linhas de 01 até 13 representam apenas as configurações básicas para assegurar conectividade entre as unidades através da Internet, nada que mereça destaque no contexto da configuração de uma VPN IPv6. Nas linhas de 14 a 24 são definidas as políticas de segurança onde informamos a chave compartilhada (SENHA) que será utilizada nas pontas, escolhemos o algoritmo de criptografia (AES de 128 bits), etc. 

 Nas linhas de 25 a 33 é criada uma interface lógica do tipo túnel que representa a VPN propriamente dita, sendo que nessa interface temos que vincular nossa rede privativa com a Internet pública (endereços de origem e destino). Por fim, na linha 34 é criada uma rota estática apontando para rede local da unidade remota através do túnel virtual recém criado. As configurações do roteador localizado no RJ são exatamente a mesmas, mudando apenas os endereços.

> Configuração do Roteador do Rio de Janeiro:

RJ(config)# ipv6 unicast-routing
RJ (config)# ipv6 route ::/0 2001:db8:bbbb::f
RJ(config)# interface f0/0
RJ(config)# description Link-ISP
RJ(config-if)# ipv6 enable
RJ(config-if)# ipv6 address 2001:db8:bbbb::1/64
RJ(config-if)# no shutdown
RJ(config-if)# exit
RJ(config-if)# interface f1/0
RJ(config-if)# description LAN-CAFE-2
RJ(config-if)# ipv6 enable
RJ(config-if)# ipv6 address 2001:db8:cafe:2::1/64
RJ(config-if)# no shutdown
RJ(config-if)# exit
RJ(config)# crypto isakmp key 0 SENHA address ipv6 ::/0
RJ(config)# crypto isakmp policy 1
RJ(config-isakmp)# encryption aes 128
RJ(config-isakmp)# authentication pre-share
RJ(config-isakmp)# exit
RJ(config)# crypto ipsec transform-set VPNv6 esp-aes 128 esp-sha-hmac
RJ(cfg-crypto-trans)# mode tunnel
RJ(cfg-crypto-trans)# exit
RJ(config)# crypto ipsec profile VPNv6
RJ(ipsec-profile)# set transform-set VPNv6
RJ(ipsec-profile)# exit
RJ(config)# interface tunnel 0
RJ(config-if)# description VPN-to-SP
RJ(config-if)# ipv6 enable
RJ(config-if)# ipv6 address fd00:cafe::b/127
RJ(config-if)# tunnel source f0/0
RJ(config-if)# tunnel destination 2001:db8:aaaa::1
RJ(config-if)# tunnel mode ipsec ipv6
RJ(config-if)# tunnel protection ipsec profile VPNv6

RJ(config-if)# exit
RJ(config)# ipv6 route 2001:db8:cafe:1::/64 tunnel 0

Acredito que esse é um caso em que a prática ajuda no entendimento dos conceitos por trás do processo de estabelecimento do túnel em redes baseadas no IPv6. Na opotunidade do evento eu e o colega Antonio Moreiras (do NIC.br) nos esforçamos para tentar explicar esse conceito em tempo mínimo (o assunto não era foco do evento), mas tenho certeza que não ficou claro para todos que estavam presentes ou acompanhando via Internet. Por isso espero que esse artigo possa ajudá-los...

Abraço.

Samuel.

segunda-feira, 17 de junho de 2013

Túnel Manual 6over4 (6in4) no Simulador Packet Tracer

Olá Pessoal.

No Laboratório 17 do livro "Laboratórios de Tecnologias Cisco" eu explico ao leitor como configurar um túnel manual 6over4 (6in4), um cenário que será comum na fase de transição do IPv4 para IPv6, principalmente para ambientes com redes IPv6 que somente tenham trânsito para a Internet via IPv4. 

Naquela oportunidade do livro foi utilizado o emulador GNS3 para tornar possível a configuração desse cenário, afinal até então o simulador Packet Tracer da Cisco não tinha suporte a esse recurso. Acontece que esse recurso passou a ser suportado a partir do Packet Tracer 6.0.0 (Beta) e continua funcional no PT 6.0.1.

Estive fazendo os testes para realmente garantir que esse recurso está funcional e por isso vou compartilhar o cenário e o processo de configuração para aqueles que queiram fazer o experimento em casa e não têm muita afinidade com o GNS3. O cenário que utilizei é ilustrado na figura abaixo, basicamente uma reprodução daquilo que já havia no livro com apenas algumas mudanças nos endereços.


As configurações dos roteadores de SP e RJ são basicamente idênticas, com mudanças apenas nos seus endereços. Reparem que nas linhas de 01 até 08 estamos fazendo apenas as configurações básicas das interfaces e, somente então, vamos efetivamente criar o túnel com encapsulamento 6in4 para que o tráfego IPv6 das duas unidades possa trafegar via Internet IPv4. Nas linhas de 09 a 14 criamos o túnel manual utilizando encapsulamento 6in4 (ipv6ip), na linha 15 ativamos o roteamento IPv6 e na linha 16 criamos uma rota estática apontando todo tráfego direcionado à rede da unidade remota através do túnel.

01. Roteador-SP(config)# int serial 0/0/0
02. Roteador-SP(config-if)# clock 500000 
03. Roteador-SP(config-if)# ip address 203.0.113.1 255.255.255.252
04. Roteador-SP(config-if)# no shut
05. Roteador-SP(config-if)# interface g0/0
06. Roteador-SP(config-if)# ipv6 enable
07. Roteador-SP(config-if)# ipv6 address 2001:db8:cafe:1::1/64
08. Roteador-SP(config-if)# no shut
09. Roteador-SP(config-if)# int tunnel 0
10. Roteador-SP(config-if)# ipv6 address fd00:cafe::0/127
11. Roteador-SP(config-if)# tunnel source s0/0/0
12. Roteador-SP(config-if)# tunnel destination 203.0.113.2
13. Roteador-SP(config-if)# tunnel mode ipv6ip
14. Roteador-SP(config-if)# exit
15. Roteador-SP(config)# ipv6 unicast-routing
16. Roteador-SP(config)# ipv6 route 2001:db8:cafe:2::/64 fd00:cafe::1


Roteador-RJ(config)# int serial 0/0/0
Roteador-RJ(config-if)# ip address 203.0.113.2 255.255.255.252
Roteador-RJ(config-if)# no shut
Roteador-RJ(config-if)# interface g0/0
Roteador-RJ(config-if)# ipv6 enable
Roteador-RJ(config-if)# ipv6 address 2001:db8:cafe:2::1/64
Roteador-RJ(config-if)# no shut
Roteador-RJ(config-if)# int tunnel 0
Roteador-RJ(config-if)# ipv6 address fd00:cafe::1/127
Roteador-RJ(config-if)# tunnel source s0/0/0
Roteador-RJ(config-if)# tunnel destination 203.0.113.1
Roteador-RJ(config-if)# tunnel mode ipv6ip
Roteador-RJ(config-if)# exit
Roteador-RJ(config)# ipv6 unicast-routing
Roteador-RJ(config)# ipv6 route 2001:db8:cafe:1::/64 fd00:cafe::0

Depois de configurado o cenário, observem na figura abaixo (clique na imagem para ampliar) que o simulador nos mostra que os pacotes IPv6 gerados nas redes das unidades é reencapsulado em um novo pacote IPv4 (encapsulamento 6in4) que recebe o código PROTO 41 (0x29 em Hexadecimal). Ou seja, tudo funcionando!


Vocês devem ter observado que recentemente tenho escrito vários artigos relacionados a IPv6, isso porque em breve será lançado um novo livro meu especificamente sobre IPv6 e essa é uma maneira para vocês se "aquecerem" até que o livro seja publicado - o que deve ocorrer já nos próximos meses!

O livro foi escrito com uma abordagem bastante didática e está repleto de ilustrações para facilitar o entendimento dos conceitos, além de trazer vários exemplos de configuração. Será mais uma publicação da Editora Novatec, grande parceira que trabalhou comigo na publicação do livro "Laboratórios de Tecnologias Cisco". Além disso, o livro é baseado no programa educacional mundial do IPv6 Forum, sendo que o prefácio foi escrito pelo próprio fundador/presidente do fórum internacional!!! 

Tenho certeza que vocês vão gostar! ;-)
Abraço.

Samuel.

quarta-feira, 16 de janeiro de 2013

Configuração da Nuvem MPLS em Provedores

Olá Pessoal.

Esse post traz um assunto relevante no contexto atual das telecomunicações que é o MPLS. Atualmente a tecnologia MPLS (Multi-Protocol Label Switching) é comumente utilizada pelas operadoras de telecomunicações (ISP) como solução de conectividade de longa distância.

E antes de entrar na discussão técnica, uma primeira observação importante é que a configuração dessa tecnologia no ambiente corporativo (enterprise) é totalmente diferente da configuração na nuvem da operadora (ISP). 

Aliás, quem possui um link MPLS na empresa sabe bem que ela é transparente, já que você simplesmente recebe a conectividade da operadora e pronto - é como se houvesse um link privado entra as unidades remotamente conectadas... Bom, então se a coisa é simples assim qual seria a razão da "novela" que se faz acerca dessa tecnologia?

A simplicidade de uns é a complexidade de outros! Os roteadores instalados na empresa cliente normalmente sequer têm noção do que é MPLS e por isso toda a complexidade da infraestrutura está na nuvem da operadora.

Diferente de outras tecnologias de Camada 2 (HDLC, ATM e Frame-Relay) que eram tradicionalmente utilizadas na longa distância (e ainda são), o MPLS surgiu como uma tecnologia de Camada 2¹/² que traz uma abordagem de operação totalmente nova: o chamado roteamento baseado em rótulos.

Essa tecnologia não utiliza mais o cabeçalho do datagrama IP na decisão de roteamento, fazendo o reencapsulamento do datagrama com um novo cabeçalho de 4 bytes que possui um rótulo de 20 bits. Toda a decisão de encaminhamento dos pacotes é determinada com base nesse rótulo, o que agiliza o processo de roteamento e permite a implementação de técnicas de engenharia de tráfego, entre outras coisas mais.

O assunto é extenso e obviamente que o meu objetivo não é substituir um bom livro sobre o assunto - por isso serei o mais objetivo possível e o foco é que vocês consigam reproduzir um cenário prático de MPLS. Vamos trabalhar com o  cenário observado na figura abaixo. 



Antes de partir para a configuração, existem vários conceitos fundamentais que o leitor precisa ter em mente para entender o papel dos elementos envolvidos no cenário. Então que tal começar pelo começo? Parece razoável... ;-)

O Custormer Edge (CE) é o equipamento instalado nas unidades remotas da empresa que irão receber a solução de conectividade provida pela operadora. Outro elemento importante é o Provider Edge (PE) que se trata do roteador da operadora diretamente conectado a um (ou mais) roteador(es) do(s) cliente(s), ou seja, PEs são conectados a CEs. Por fim, o elemento P (Provider) são os demais roteadores distribuídos pela nuvem MPLS que representa a infraestrutura de rede da operadora.

Outro conceito fundamental é a tecnologia VRF (Virtual Routing and Forwarding) que traz consigo outros dois elementos igualmente importantes: o RD (Route Distinguisher) e o RT (Route Target). Através do VRF é possível criar múltiplas instâncias da tabela de roteamento, sendo que cada uma dessas tabelas virtuais é totalmente independente das demais. No contexto do MPLS é comum que cada cliente tenha sua própria VRF porque essa prática traz mais segurança e flexibilidade

Sem as VRFs individuais o tráfego entre as sub-redes de todos os clientes da operadora iriam compor uma única tabela de roteamento, o que seria péssimo do ponto de vista de segurança. Outro benefício comum é que se torna possível que os clientes utilizem endereços de redes iguais, já que as instâncias VRF são independentes. E é muito comum que as empresas utilizem endereços privados da RFC1918 (192.168 /16, 172.16 /12 e 10 /8).

No entanto, em algum momento é necessário que as rotas entre o roteador da empresa (CE) e o roteador da operadora (PE) sejam redistribuídas para um processo BGP no PE. Isso porque deve existir um pareamento iBGP entre um PE e outro PE remoto para viabilizar na prática a chamada VPN MPLS, um túnel abstrato que só existe nas bordas da rede MPLS, já que os roteadores P sequer conhecem as várias VPNs.

Eis que surge um problema: Fica claro que é possível ter endereços repetidos através das VRFs porque elas representam tabelas de roteamento distintas, mas como fica a redistribuição das rotas iguais para o processo BGP!!!??? Isso só é possível através da adição de um identificador nas rotas para torná-las únicas que é denominado RD (Route Distinguisher). Também existe o RT (Route Target), uma community BGP que indica o membro de uma VPN, permitindo que rotas sejam importadas e exportadas das VRFs no processo de redistribuição

Há alguns formatos para o RD/RT, sendo que sua forma mais comum consiste em:  
ASN de 16 Bits + Número de 32 Bits ; Ex.: 65000:100. 

No cenário apresentado nesse post teremos duas VRFs denominadas Cliente1 e Cliente2 que serão identificadas da seguinte forma:

- VRF Cliente 1, RD 65001:111, RT 65001:1
- VRF Cliente 2, RD 65002:222, RT 65002:2

Mesmo com "toda" essa carga teórica, acreditem que fui bastante sucinto e fiz o possível para "suavizar" essa postagem apresentando apenas os conceitos fundamentais. Como o processo de configuração consiste em várias linhas de comando, estarei dividindo o processo de configuração nas seguintes etapas: 

  1. Configuração Básica das Interfaces e Endereços IP
  2. Roteamento IGP (EIGRP) na Nuvem da Operadora (AS 200)
  3. Criação e Associação da VRF e Configuração do RD/RT
  4. Configuração do Roteamento EIGRP no PE e CE
  5. Configuração da Redistribuição de Rotas EIGRP e BGP
  6. Configuração do MP-BGP no(s) PE

As etapas 1 e 2 não dizem respeito à configuração do MPLS propriamente dito, no entanto são pré-requisitos para o cenário funcionar devidamente. Como os roteadores da empresa (CE) nao têm ciência do MPLS, eles possuem apenas configurações básicas.

1) Configuração Básica das Interfaces e Endereços IP

A única configuração que merece destaque nessa primeira etapa é que estamos habilitando o encapsulamento MPLS na interface que se conecta a outro roteador da nuvem da operadora. Reparem que as interfaces que se conectam aos roteadores CE não têm essa configuração, já que o tráfego até o PE é puramente IP.

PE1(config)# int lo 1
PE1(config-if)# ip address 1.1.1.1 255.255.255.255
PE1(config-if)# int f0/0
PE1(config-if)# ip address 172.16.5.2 255.255.255.252
PE1(config-if)# mpls ip
PE1(config-if)# int s1/0
PE1(config-if)# clock rate 64000
PE1(config-if)# ip address 172.16.1.1 255.255.255.252
PE1(config-if)# no shut
PE1(config-if)# int s2/0
PE1(config-if)# clock rate 64000
PE1(config-if)# ip address 172.16.2.1 255.255.255.252
PE1(config-if)# no shut

PE2(config)# int lo 1
PE2(config-if)# ip address 2.2.2.2 255.255.255.255
PE2(config-if)# int f0/0
PE2(config-if)# ip address 172.16.6.2 255.255.255.252
PE2(config-if)# mpls ip
PE2(config-if)# int s1/0
PE2(config-if)# clock rate 64000
PE2(config-if)# ip address 172.16.3.1 255.255.255.252
PE2(config-if)# no shut
PE2(config-if)# int s2/0
PE2(config-if)# clock rate 64000
PE2(config-if)# ip address 172.16.4.1 255.255.255.252
PE2(config-if)# no shut

P(config)# int lo 1
P(config-if)# ip address 3.3.3.3 255.255.255.255
P(config-if)# int f0/0
P(config-if)# ip address 172.16.5.1 255.255.255.252
P(config-if)# mpls ip
P(config-if)# int f1/0
P(config-if)# ip address 172.16.6.1 255.255.255.252
P(config-if)# mpls ip
P(config-if)# no shut

2) Roteamento IGP (EIGRP) na Nuvem da Operadora (AS 200)

Essa segunda etapa também é bem básica, consistindo apenas na configuração de um protocolo de roteamento IGP qualquer na nuvem da operadora. Não há nenhum destaque especial, então apenas trarei os comandos:

PE1(config)# router eigrp 200
PE1(config-router)# network 172.16.0.0
PE1(config-router)# network 1.1.1.1
PE1(config-router)# no auto-summary

PE2(config)# router eigrp 200
PE2(config-router)# network 172.16.0.0
PE2(config-router)# network 2.2.2.2  
PE2(config-router)# no auto-summry

P(config)# router eigrp 200
P(config-router)# network 172.16.0.0
P(config-router)# network 3.3.3.3 
P(config-router)# no auto-summary 

3) Criação e Associação da VRF e Configuração do RD/RT

A configuração abaixo é necessária apenas nos roteadores de borda (PE), já que os roteadores da empresa (CE) não têm ciência do MPLS. Reparem que em cada roteador de borda criamos duas VRFs e informamos os valores RD/RT previamente definidos. Por fim, associamos cada VRF com sua respectiva interface (cliente).

PE1(config)#ip vrf Cliente1
PE1(config-vrf)#rd 65001:111
PE1(config-vrf)#route-target both 65001:1
PE1(config-vrf)#exit
PE1(config)#ip vrf Cliente2
PE1(config-vrf)#rd 65002:222
PE1(config-vrf)#route-target both 65002:2
PE1(config-vrf)#exit
PE1(config)#int s2/0
PE1(config-if)#ip vrf forwarding Cliente1
% Interface Serial2/0 IP address 172.16.1.1 removed due to enabling VRF Cliente1
PE1(config-if)#ip address 172.16.1.1 255.255.255.252
PE1(config-if)#exit
PE1(config)#int s2/1
PE1(config-if)#ip vrf forwarding Cliente2
% Interface Serial2/1 IP address 172.16.2.1 removed due to enabling VRF Cliente2
PE1(config-if)#ip address 172.16.2.1 255.255.255.252
PE1(config-if)#exit


PE2(config)#ip vrf Cliente1
PE2(config-vrf)#rd 65001:111
PE2(config-vrf)#route-target both 65001:1
PE2(config-vrf)#exit
PE2(config)#ip vrf Cliente2
PE2(config-vrf)#rd 65002:222
PE2(config-vrf)#route-target both 65002:2
PE2(config-vrf)#exit
PE2(config)#int s2/0
PE2(config-if)#ip vrf forwarding Cliente1
% Interface Serial2/0 IP address 172.16.3.1 removed due to enabling VRF Cliente1
PE2(config-if)#ip address 172.16.3.1 255.255.255.252
PE2(config-if)#int s2/1
PE2(config-if)#ip vrf forwarding Cliente2
% Interface Serial2/1 IP address 172.16.4.1 removed due to enabling VRF Cliente2
PE2(config-if)#ip address 172.16.4.1 255.255.255.252
PE2(config-if)#exit



4) Configuração do Roteamento EIGRP no PE e CE

A próxima etapa consiste na configuração de um protocolo de roteamento entre a empresa para que o provedor possa conhecer as rotas anunciadas pela empresa. Esse processo de configuração é bem simples nos roteadores da empresa (CE), no entanto há alguns comandos adicionais nos roteadores do provedor (PE) que são necessários para associar as rotas de cada cliente com sua respectiva VRF anteriormente criada. 

Talvez a observação mais importante aqui é que o número de AS utilizado nos processos EIGRP do CE e PE não precisam ser iguais, uma vez que na configuração EIGRP do PE há uma sub-seção de configuração para cada VRF em que devemos informar o mesmo número utilizado no processo do roteador remoto (CE). Caso contrário, as rotas dos diversos clientes seriam todas compartilhadas na tabela de roteamento padrão, o que não é desejado...

CE1A(config)#router eigrp 65001
CE1A(config-router)#network 192.168.1.0
CE1A(config-router)#network 172.16.0.0
CE1A(config-router)#no auto-summary


CE2A(config)#router eigrp 65002
CE2A(config-router)#network 192.168.1.0
CE2A(config-router)#network 172.16.0.0
CE2A(config-router)#no auto-summary  


PE1(config)#router eigrp 1
PE1(config-router)#address-family ipv4 vrf Cliente1
PE1(config-router-af)#autonomous-system 65001
PE1(config-router-af)#network 172.16.0.0
PE1(config-router-af)#no auto-summary
PE1(config-router-af)#

PE1(config-router-af)#address-family ipv4 vrf Cliente2
PE1(config-router-af)#autonomous-system 65002
PE1(config-router-af)#network 172.16.0.0
PE1(config-router-af)#no auto-summary


***

CE1B(config)#router eigrp 65001
CE1B(config-router)#network 192.168.2.0
CE1B(config-router)#network 172.16.0.0
CE1B(config-router)#no auto-summary


CE2B(config)#router eigrp 65002
CE2B(config-router)#network 192.168.2.0
CE2B(config-router)#network 172.16.0.0
CE2B(config-router)#no auto-summary  


PE2(config)#router eigrp 1
PE2(config-router)#address-family ipv4 vrf Cliente1
PE2(config-router-af)#autonomous-system 65001
PE2(config-router-af)#network 172.16.0.0
PE2(config-router-af)#no auto-summary
PE2(config-router-af)#

PE2(config-router-af)#address-family ipv4 vrf Cliente2
PE2(config-router-af)#autonomous-system 65002
PE2(config-router-af)#network 172.16.0.0
PE2(config-router-af)#no auto-summary


(*) Obs.: No processo EIGRP dos roteadores PE que irão estabelecer vizinhança com os roteadores CE utilizamos o AS 1 para não misturar as rotas dos clientes com o processo EIGRP 200 que utilizamos nas primeiras etapas para trocar as rotas internas entre os roteadores da nuvem MPLS.  

5) Configuração da Redistribuição de Rotas EIGRP e BGP

Até agora os roteadores PE já aprenderam as rotas dos clientes diretamente conectados, no entanto não existe uma ligação entre as unidades remotas dos clientes porque o PE1 não está diretamente ligado ao PE2. Ou seja, PE1 conhece as rotas anunciadas por CE1A, mas não é capaz de receber as rotas de CE1B. 

Na próxima etapa a gente vai configurar um pareamento iBGP entre PE1 e PE2 para criar a abstração do túnel da VPN/MPLS. No entanto, antes temos que configurar a redistribuição mútua entre o EIGRP estabelecido com os roteadores CE e o BGP que estará em execução nos roteadores PE.

PE1(config)# router bgp 200
PE1(config-router)# address-family  ipv4 vrf Cliente1
PE1(config-router-af)# redistribute eigrp 65001
PE1(config-router-af)# exit
PE1(config-router)# address-family ipv4 vrf Cliente2
PE1(config-router-af)# redistribute eigrp 65002
PE1(config-router-af)# exit
PE1(config-router)# exit
PE1(config)# router eigrp 1
PE1(config-router)# address-family ipv4 vrf Cliente1
PE1(config-router-af)# redistribute bgp 200 metric 10000 1000 255 1 1500
PE1(config-router-af)# exit
PE1(config-router)# address-family ipv4 vrf Cliente2
PE1(config-router-af)# redistribute bgp 200 metric 10000 1000 255 1 1500


PE2(config)# router bgp 200
PE2(config-router)# address-family ipv4 vrf Cliente1
PE2(config-router-af)# redistribute eigrp 65001
PE2(config-router-af)# exit
PE2(config-router)# address-family ipv4 vrf Cliente2
PE2(config-router-af)# redistribute eigrp 65002
PE2(config-router-af)# exit
PE2(config-router)# exit
PE2(config)# router eigrp 1
PE2(config-router)# address-family ipv4 vrf Cliente1
PE2(config-router-af)# redistribute bgp 200 metric 10000 1000 255 1 1500
PE2(config-router-af)# exit
PE2(config-router)# address-family ipv4 vrf Cliente2
PE2(config-router-af)# redistribute bgp 200 metric 10000 1000 255 1 1500



6) Configuração do MP-BGP no(s) PE
   
O último passo consiste no estabelecimento do túnel virtual entre as unidades remotas da empresa para prover ao cliente a abstração de que existe uma conexão privada de longa distância (WAN) entre as unidades. Assim que essa configuração for feita, os roteadores CE1A e CE1B vão conhecer as rotas uns dos outros e a empresa terá conectividade remota!

PE1(config)#router bgp 200
PE1(config-router)#neighbor 2.2.2.2 remote-as 200
PE1(config-router)#neighbor 2.2.2.2 update-source lo1
PE1(config-router)#address-family vpnv4
PE1(config-router-af)#neighbor 2.2.2.2 activate
PE1(config-router-af)#neighbor 2.2.2.2 send-community


PE2(config)#router bgp 200
PE2(config-router)#neighbor 1.1.1.1 remote-as 200
PE2(config-router)#neighbor 1.1.1.1 update-source lo1
PE2(config-router)#address-family vpnv4
PE2(config-router-af)#neighbor 1.1.1.1 activate
PE2(config-router-af)#neighbor 1.1.1.1 send-community


Pronto! Depois de MUITAS linhas de comando já temos uma implementação básica de VPN/MPLS funcionando entre duas empresas clientes, cada uma com apenas duas unidades remotas. Ao visualizar a tabela de roteamento VRF Cliente1 no roteador PE1 é possível observar que a rota 192.168.2.0/24 da unidade remota foi aprendida via BGP.

PE1#show ip route vrf Cliente1

Routing Table: Cliente1
Codes: C - connected, S - static, 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
       i - IS-IS, su - IS-IS summary, 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 not set

     172.16.0.0/30 is subnetted, 2 subnets
C       172.16.1.0 is directly connected, Serial2/0
B       172.16.3.0 [200/0] via 2.2.2.2, 00:02:37
D    192.168.1.0/24 [90/2172416] via 172.16.1.2, 00:42:44, Serial2/0
B    192.168.2.0/24 [200/2172416] via 2.2.2.2, 00:02:37

Também vamos aproveitar que tivemos todo esse trabalho para observar a tabela BGP do PE1, já que assim fica evidente a importância do identificador RD.

PE1#show ip bgp vpnv4 all
BGP table version is 17, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 65001:111 (default for vrf Cliente1)
*> 172.16.1.0/30    0.0.0.0                  0         32768 ?
*>i172.16.3.0/30    2.2.2.2                  0    100      0 ?
*> 192.168.1.0      172.16.1.2         2172416         32768 ?
*>i192.168.2.0      2.2.2.2            2172416    100      0 ?
Route Distinguisher: 65002:222 (default for vrf Cliente2)
*> 172.16.2.0/30    0.0.0.0                  0         32768 ?
*>i172.16.4.0/30    2.2.2.2                  0    100      0 ?
*> 192.168.1.0      172.16.2.2         2172416         32768 ?
*>i192.168.2.0      2.2.2.2            2172416    100      0 ?


Agora vamos observar a tabela de roteamento do roteador CE1A instalado na empresa. Observem que ele apenas conhece a rota remota como se as unidades estivessem diretamente conectadas entre si. Essa é a grande vantagem da implementação VPN do MPLS, afinal o cliente não enxerga a nuvem MPLS.

CE1A#show ip route
Codes: C - connected, S - static, 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
       i - IS-IS, su - IS-IS summary, 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 not set

     172.16.0.0/30 is subnetted, 2 subnets
C       172.16.1.0 is directly connected, Serial2/0
D       172.16.3.0 [90/2681856] via 172.16.1.1, 00:08:33, Serial2/0
C    192.168.1.0/24 is directly connected, FastEthernet0/0
D    192.168.2.0/24 [90/2684416] via 172.16.1.1, 00:08:34, Serial2/0

 

Para finalizar esse post (que já está extenso demais), há vários comandos de exibição (show) que podemos utilizar para verificar o efeito de todas as configurações realizadas em cada uma das etapas.  Por isso deixo registrada uma relação de comandos de exibição caso o leitor queira reproduzir o cenário e sugiro uma observação detalhada das tabelas VRF e BGP.

PE1# show ip route
PE1# show ip route vrf Cliente1
PE1# show ip route vrf Cliente2
PE1# show ip bgp 
PE1# show ip bgp summary
PE1# show ip bgp vpnv4 all  
PE1# show ip eigrp vrf Cliente1 neighbors
PE1# show ip eigrp vrf Cliente2 neighbors
PE1# show ip eigrp vrf Cliente1 topology
PE1# show ip eigrp vrf Cliente2 topology   

Abraço.

Samuel.