Mostrando postagens com marcador WAN. Mostrar todas as postagens
Mostrando postagens com marcador WAN. 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.

quarta-feira, 13 de julho de 2016

Configuração de MultiLink PPP em Roteadores Cisco

Olá Pessoal,

O MultiLink PPP (MLPPP) é uma tecnologia padronizada na RFC 1990 e na RFC 2686 que permite agregar múltiplos links físicos de longa distância (do tipo PPP) através de uma única interface lógica equivalente à soma das capacidades dos links individuais. Trata-se, portanto, de um recurso interessante para obter um link lógico de alta velocidade e com maior disponibilidade a partir de múltiplos links de baixa velocidade. Uma vez que o MLPPP requer configuração coerente em ambas as pontas com a informação de quais interfaces físicas devem ser logicamente agrupadas, não é possível utilizar esse recurso para agregar múltiplos links físicos que sejam providos por diferentes operadoras.

O pré-requisito óbvio para configurar MLPPP é a existência dos links físicos PPP. A configuração do MLPPP é bastante simples, já que basta criar uma interface virtual do tipo multilink que receberá o endereço IP da rede ponto-a-ponto, além de ser referenciada como grupo lógico em cada uma das interfaces físicas. Tomando por base a topologia ilustrada na figura acima, as configurações necessárias estão destacadas abaixo em amarelo. As demais configurações consistem no estabelecimento dos links PPP, assunto abordado em outro artigo intitulado "Configuração de Link WAN PPP em Roteadores Cisco"

R1(config)# username R2 password SENHA
R1(config)# interface s2/0
R1(config-if)# encapsulation ppp
R1(config-if)# ppp authentication chap
R1(config-if)# ppp multilink
R1(config-if)# ppp multilink group 1
R1(config-if)# no shut
R1(config-if)# interface s2/1
R1(config-if)# encapsulation ppp
R1(config-if)# ppp authentication chap
R1(config-if)# ppp multilink
R1(config-if)# ppp multilink group 1
R1(config-if)# no shut
R1(config-if)# interface multilink 1
R1(config-if)# ppp multilink
R1(config-if)# ip address 203.0.113.1 255.255.255.252

R2(config)# username R1 password SENHA
R2(config)# interface s2/0
R2(config-if)# encapsulation ppp
R2(config-if)# ppp authentication chap
R2(config-if)# ppp multilink
R2(config-if)# ppp multilink group 1
R2(config-if)# no shut
R2(config-if)# interface s2/1
R2(config-if)# encapsulation ppp
R2(config-if)# ppp authentication chap
R2(config-if)# ppp multilink
R2(config-if)# ppp multilink group 1
R2(config-if)# no shut
R2(config-if)# interface multilink 1
R2(config-if)# ppp multilink
R2(config-if)# ip address 203.0.113.2 255.255.255.252

Depois de realizadas as configurações do MLPPP, é possível observar que uma nova interface virtual do tipo multilink passa a compor a relação de interfaces do roteador. Também é possível observar na tabela de roteamento que a rede ponto-a-ponto entre os dois roteadores está diretamente conectada através da interface lógica multilink, ao invés das interfaces físicas do tipo serial.

R1# show ip route
Codes: (...)
Gateway of last resort is not set

     203.0.113.0/24 is variably subnetted, 2 subnets, 2 masks
C       203.0.113.2/32 is directly connected, Multilink1
C       203.0.113.0/30 is directly connected, Multilink1

O comando abaixo é específico para MLPPP e bastante útil para identificar quais interfaces físicas compõem o agrupamento lógico multilink, além de apresentar o status dessas interfaces. Nesse exemplo, é possível observar que ambas as interfaces físicas seriais estão operacionais.

R1# show ppp multilink 
Multilink1, bundle name is R2
  Username is R2
  Endpoint discriminator is R2
  Bundle up for 00:01:22, total bandwidth 3088, load 1/255
  Receive buffer limit 24000 bytes, frag timeout 1000 ms
    0/0 fragments/bytes in reassembly list
    0 lost fragments, 6 reordered
    0/0 discarded fragments/bytes, 0 lost received
    0x16 received sequence, 0x17 sent sequence
  Member links: 2 active, 0 inactive (max not set, min not set)
    Se2/0, since 00:03:25
    Se2/1, since 00:02:22
No inactive multilink interfaces

Para verificar a disponibilidade do agrupamento lógico, basta desativar qualquer uma das interfaces físicas seriais para simular um falha qualquer no link. Mesmo em caso de queda de um dos links físicos, a interface lógica se mantém disponível através do(s) outro(s) link(s) físico(s). Por exemplo, temos a seguinte saída após desativar a interface s2/1 em R2:

R1# show ppp multilink
Multilink1, bundle name is R2
  Username is R2
  Endpoint discriminator is R2
  Bundle up for 00:03:16, total bandwidth 1544, load 1/255
  Receive buffer limit 12000 bytes, frag timeout 1000 ms
    0/0 fragments/bytes in reassembly list
    0 lost fragments, 12 reordered
    0/0 discarded fragments/bytes, 0 lost received
    0x22 received sequence, 0x39 sent sequence
  Member links: 1 active, 1 inactive (max not set, min not set)
    Se2/0, since 00:05:20
    Se2/1 (inactive)
No inactive multilink interfaces

Façam seus testes...

Samuel.

terça-feira, 5 de julho de 2016

Configuração de Link WAN PPP em Roteadores Cisco

Olá Pessoal,

PPP (Point-to-Point Protocol) é uma tecnologia padronizada na RFC 1661 e que consiste em um conjunto de protocolos da camada de enlace (layer-2) para controle de links de longa distância. Assim como a tecnologia Ethernet possui protocolos adicionais de suporte no contexto das redes locais (por ex. STP), a tecnologia PPP possui vários outros protocolos complementares. As duas principais categorias de protocolos complementares são:

  • Link Control Protocol (LCP): Esse protocolo implementa as funções de controle em nível de enlace (layer-2) de maneira totalmente independente do protocolo de rede utilizado nas camadas superiores, afinal o PPP é independente da tecnologia de rede utilizada em layer-3. As funções de controle estão relacionadas a diversos aspectos da conexão que envolvem o estabelecimento, configuração e verificação do link, além da autenticação (opcional);

  • Network Control Protocol (NCP): Na realidade o NCP é uma categoria de protocolos de controle que contém vários sub-protocolos, de forma que cada sub-protocolo está associado com uma tecnologia de rede layer-3 específica. Exemplos comuns de sub-protocolos dessa categoria são o IP Control Protocol (IPCP), o IPv6 Control Protocol (IPv6CP) e o Cisco Discovery Protocol Control Protocol (CDPCP).

Outra característica importante do PPP é a autenticação das partes envolvidas na comunicação. No contexto de um link de longa distância (WAN), o processo de autenticação é importante para que as interfaces seriais de dois roteadores provem suas identidades antes de estabelecer o link. Dois protocolos de autenticação utilizados em conjunto com o PPP são o PAP e o CHAP, sendo que o procedimento de configuração de ambos é basicamente o mesmo. O PAP não é seguro porque faz o envio do usuário e da senha como texto simples (sem criptografia), enquanto que o CHAP é considerado mais seguro pela forma como faz a troca de mensagens entre as partes (hash MD5).

A topologia exibida na figura abaixo será utilizada para exemplificar a configuração de um link WAN PPP entre dois roteadores Cisco. Observem que propositalmente os dois roteadores serão configurados com endereços IP pertencentes a diferentes sub-redes, algo que a princípio faz parecer impossível a comunicação entre os dois roteadores. No entanto, a surpresa é que depois de configurado o link WAN PPP entre R1 e R2 a comunicação ocorre com sucesso. Por que isso acontece?


Antes de responder essa questão, vamos às configurações necessárias para estabelecer o link PPP. Um detalhe na configuração da autenticação é que em R1 deve ser criado um usuário na base local equivalente ao hostname de R2 e vice-versa. O nome do usuário a ser autenticado deve ser exatamente o nome de host que foi configurado no roteador da outra ponta, caso contrário a autenticação falhará.

R1(config)# username R2 password SENHA
R1(config)# interface s0/3/0
R1(config-if)# ip address 203.0.113.1 255.255.255.255
R1(config-if)# encapsulation ppp
R1(config-if)# ppp authentication chap
R1(config-if)# no shut

R2(config)# username R1 password SENHA
R2(config)# interface s0/3/0
R2(config-if)# ip address 198.51.100.1 255.255.255.255
R2(config-if)# encapsulation ppp
R2(config-if)# ppp authentication chap
R2(config-if)# no shut

Uma vez configurado o laboratório proposto, agora podemos voltar à discussão das razões pelas quais o ping entre os dois roteadores funciona mesmo quando as interfaces seriais são configuradas com endereços em diferentes sub-redes. Se utilizássemos o mesmo cenário para configurar uma WAN entre os roteadores R1 e R2 através de links seriais com encapsulamento HDLC (padrão), o ping não funcionaria com as duas interfaces seriais configuradas com endereços em sub-redes diferentes. Isso ocorreria porque os roteadores R1 e R2 não teriam uma rota diretamente conectada que fosse comum a ambos, ou seja, seria impossível direcionar a saída do tráfego ponto a ponto. 

Esse comportamento padrão muda bastante quando configuramos o encapsulamento para PPP, já que os protocolos de controle da categoria NCP são responsáveis por tratar automaticamente das informações de roteamento. No contexto do IPv4, o IPCP do PPP automaticamente adiciona uma rota de host (/32) apontando para o endereço IP do roteador vizinho. Essa característica pode ser observada nos destaques em amarelo das tabelas de roteamento listadas abaixo. 

Em R1 o PPP criou uma rota de host apontando para R2 (198.51.100.1/32):

R1> show ip route
Codes: (...) Códigos Omitidos

Gateway of last resort is not set

198.51.100.0/32 is subnetted, 1 subnets
C 198.51.100.1/32 is directly connected, Serial0/3/0
203.0.113.0/24 is variably subnetted, 2 subnets, 2 masks
C 203.0.113.0/30 is directly connected, Serial0/3/0
L 203.0.113.1/32 is directly connected, Serial0/3/0

R1> ping 198.51.100.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 198.51.100.1, timeout is 2 seconds:
!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/6/8 ms

Em R2 o PPP criou uma rota de host apontando para R1 (203.0.113.1/32):

R2> show ip route
Codes: (...) Códigos Omitidos

Gateway of last resort is not set

198.51.100.0/24 is variably subnetted, 2 subnets, 2 masks
C 198.51.100.0/30 is directly connected, Serial0/3/0
L 198.51.100.1/32 is directly connected, Serial0/3/0
203.0.113.0/32 is subnetted, 1 subnets
C 203.0.113.1/32 is directly connected, Serial0/3/0

R2> ping 203.0.113.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 203.0.113.1, timeout is 2 seconds:
!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/7 ms

Apesar de ser possível utilizar endereços em sub-redes diferentes, essa prática não é recomendada. Um problema decorrente dessa prática não recomendada é que não será possível executar protocolos de roteamento dinâmico entre R1 e R2, já que para formar a vizinhança de roteamento é necessário que os roteadores compartilhem a mesma sub-rede. Ou seja, sua rede não estará totalmente operacional mesmo que o resultado do ping seja um sucesso! Esse recurso do PPP  é denominado Peer Neighbor Route e pode ser manualmente desativado em sub-modo de configuração da interface serial através do comando "no peer neighbor route". Tenham cuidado com esse detalhe e procurem seguir as boas práticas que recomendam utilizar uma sub-rede /30 em links ponto-a-ponto.

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.

quarta-feira, 28 de agosto de 2013

Configuração de Cliente PPPoE em Roteadores Cisco

Olá Pessoal.

Um dos novos tópicos adicionados ao novo currículo CCNA R&S no que tange às tecnologias de longa distância é a configuração de PPPoE (Point-to-Point Protocol over Ethernet) no lado cliente, uma prática comum entre algumas operadoras que ofertam conexões à Internet via xDSL.

A tecnologia PPPoE é bastante utilizada com DSL porque o protocolo PPP é a opção natural para permitir a autenticação do usuário e o transporte das mais diversas tecnologias através das redes de transporte das operadoras, de forma que, por exemplo, quadros Ethernet encapsulados dentro de quadros PPP podem trafegar através das redes legadas ATM (Asynchronous Transfer Mode) que ainda possam existir em virtude do alto custo de implantação. Atualmente o maior motivador para uso do PPPoE é a possibilidade de autenticar o usuário com CHAP, um sub-protocolo nativo do PPP.

Nessas situações é comum a operadora disponibilizar um software de autenticação no lado do cliente, através do qual o usuário fornece suas credenciais (login e senha) para estabelecer a conexão com a Internet. Em pequenas empresas ou mesmo em ambientes residenciais que tenham várias máquinas ligadas em rede é mais conveniente transferir a responsabilidade de autenticação para um dispositivo central, de forma que o processo de conexão fica totalmente transparente para o usuário final. Esse dispositivo responsável pela autenticação pode ser o próprio roteador. Para exemplificar como seria o processo de configuração de uma conexão cliente PPPoE em roteadores Cisco estaremos considerando o cenário apresentado na figura abaixo.


A interface f0/0 está conectada na rede local (LAN), sendo que seu IP 192.168.0.254 será configurado como gateway da rede. A interface f0/1 está diretamente conectada ao modem da operadora instalado na casa do usuário, também chamado de CPE (Customer Premises Equipment). No lado da operadora existe um dispositivo chamado DSLAM que faz a agregação de vários modens DSL dos clientes e que, por sua vez, está conectado à rede da operadora que possui saída para a Internet. A seguir são apresentados os comandos para configurar o roteador como cliente PPPoE e, em seguida, são feitas algumas observações relevantes.

01. Router# conf t
02. Router(config)# interface f0/0
03. Router(config-if)# ip address 192.168.0.254 255.255.255.0
04. Router(config-if)# ip nat inside
05. Router(config-if)# no shut
06. Router(config-if)# interface f0/1
07. Router(config-if)# pppoe-client dial-pool-number 1
08. Router(config-if)# exit
09. Router(config)# interface dialer1
10. Router(config-if)# mtu 1492
11. Router(config-if)# encapsulation ppp
12. Router(config-if)# ip address negotiated
13. Router(config-if)# ppp authentication chap 
14. Router(config-if)# ppp chap hostname LOGIN
15. Router(config-if)# ppp chap password SENHA
16. Router(config-if)# dialer pool 1 
17. Router(config-if)# ip nat outside
18. Router(config-if)# dialer-group 1
19. Router(config-if)# exit
20. Router(config)# dialer-list 1 protocol ip permit
21. Router(config)# ip nat inside source list 1 interface dialer1 overload
22. Router(config)# access-list 1 permit 192.168.0.0 0.0.0.255
23. Router(config)# ip route 0.0.0.0 0.0.0.0 dialer 1

A configuração do PPPoE em roteadores consiste em criar e vincular uma nova interface virtual do tipo dialer à interface ethernet que está fisicamente conectada ao modem da operadora, processo realizado nas linhas 07, 09 e 16 da configuração anterior. Todas as demais configurações relacionadas ao PPP propriamente dito são realizadas na interface virtual dialer, já que esse tipo de interface tem suporte ao encapsulamento PPP. Ou seja, esse processo não passa de um mecanismo de tunelamento...

Em conexões DSL é comum a operadora atribuir dinamicamente os endereços dos usuários através de um servidor DHCP, no entanto é necessário o uso do protocolo IPCP (IP Configuration Protocol) no contexto do link PPP para que essa atribuição funcione. Por isso na linha 12 foi utilizado o comando "ip address negotiated" para habilitar o IPCP. 

Outra configuração extremamente importante é setar o tamanho máximo do quadro (MTU) para 1492 bytes (linha 10), uma vez que o novo cabeçalho PPP possui 8 bytes e o limite máximo do quadro Ethernet é 1500 bytes. Logo, para não estourar o limite do quadro Ethernet é necessário subtrair esses 8 bytes do PPP para que os quadros Ethernet não ultrapassem 1492 bytes antes de receber o cabeçalho PPP de 8 bytes. Todo processo de resolução de problemas em conexões PPPoE deve começar por essa observação, para assegurar que o MTU foi configurado para 1492, caso contrário a comunicação não é estabelecida.

Por fim, nas linhas 13, 14 e 15 são configuradas as credenciais de autenticação do usuário. Reparem que também já estamos fazendo a configuração do NAT, considerando a interface f0/0 como o lado inside e a interface dialer1 como o lado outside. O objetivo desse artigo não é mostrar o processo de configuração do NAT, por isso os leitores que tiverem dúvida nessa configuração podem consultar o Lab10 do livro "Laboratórios de Tecnologias Cisco em Infraestrutura de Redes".

Como complemento, as linhas 18 e 20 trazem uma configuração adicional de segurança que restringe o tráfego na interface dialer para aceitar apenas conteúdo IP, uma prática que não é cobrada no novo exame CCNA R&S (por isso não há destaque em amarelo). A linha 23 cria uma rota padrão apontando que todo o conteúdo direcionado à Internet deve sair através dessa interface virtual que tem conectividade com a operadora.

A título de informação, recentemente criei uma nova categoria no blog com a palavra-chave 200-120, onde estou agrupando todos os artigos relacionados aos tópicos adicionados no novo exame CCNA R&S. Recomendo aos leitores interessados no novo exame CCNA R&S que façam uma busca pela palavra-chave 200-120 porque em outras oportunidades já escrevi vários artigos falando sobre tópicos que foram acrescentados recentemente, a saber: SSH, SNMP, Syslog, NTP, NetFlow, IOS 15, etc.

Abraço.

Samuel.