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

sexta-feira, 17 de junho de 2016

Engenharia de Tráfego de Entrada no Protocolo BGP

Olá Pessoal,

Vimos em artigos anteriores que manipular os atributos do protoclo BGP para forçar o balanceamento do tráfego de saída ou mesmo para aplicar outras políticas de engenharia de tráfego é uma ação bastante objetiva, uma vez que a origem do tráfego será algum roteador no nosso próprio AS e que, portanto, está sob nosso domínio administrativo. No entanto, é bem mais subjetiva a tarefa de balancear o tráfego de entrada que vem da Internet, já que nesse caso não temos controle sobre o tráfego entrante que está sob gestão de outras entidades externas. 

Este é mais um artigo sobre configuração do protocolo BGP e novamente, por conveniência, irei me basear no laboratório 33 do livro LabCisco (2a Edição), cuja topologia adapatada pode ser observada na figura abaixo. Dessa vez o objetivo é apresentar os procedimentos necessários para dividir o prefixo da empresa em duas metades mais específicas que serão anunciadas por dois provedores (upstream) para forçar o balanceamento de tráfego de entrada. 


Vamos assumir que o AS 60 possui o prefixo 198.51.16.0/21 para anunciar na Internet. Observem que o referido AS está conectado através de dois provedores (upstream), representados pelo AS 40 e AS 50. Sob a ótica do roteador R1 (no AS 123) que receberá os anúncios vindos do AS 60, o comportamento padrão do BGP é que teremos dois caminhos possíveis para alcançar o prefixo anunciado, sendo um através de R4 (vizinho eBGP) e outro através de R3 (vizinho iBGP) indo para R5 (vizinho eBGP de R3). 

Os dois caminhos possíveis irão constar na tabela BGP de R1, no entanto o BGP escolherá como melhor caminho aquela rota aprendida pelo vizinho eBGP, o que fará com que todo tráfego de saída destinado ao AS 60 passe unicamente pelo AS 40. Do ponto de vista do R6 no AS 60, todo o tráfego de entrada chegará apenas através de um dos upstreams disponíveis, ou seja, sem nenhum balanceamento. 

Para contornar essa limitação, é possível explorar uma característica comum dos protocolos de roteamento que sempre preferem aquelas rotas mais específicas com prefixos maiores. Por exemplo, tomando esse comportamento padrão como base, os prefixos 203.0.113.0/25 e 203.0.113.128/25 sempre serão preferidos do que a agregação deles no bloco 203.0.113.0/24. É possível utilizar essa lógica no contexto do cenário proposto e forçar o balanceamento do tráfego de entrada apenas fazendo a "quebra" do prefixo 198.51.16.0/21 em duas metades /22, ou seja, em 198.51.16.0/22 e 198.51.20.0/22. Depois de dividir o prefixo original em duas metades, o R6 deve ser configurado da forma apresentada abaixo para anunciar uma metade /22 em cada upstream, forçando o restante da Internet a buscar os destinos da empresa através de dois caminhos, ainda que de forma assimétrica em termos de carga de tráfego. 

01. R6(config)# ip prefix-list to-AS40 permit 198.51.16.0/21 
02. R6(config)# ip prefix-list to-AS40 permit 198.51.16.0/22
03. R6(config)# ip prefix-list to-AS50 permit 198.51.16.0/21
04. R6(config)# ip prefix-list to-AS50 permit 198.51.20.0/22
05. R6(config)# router bgp 60
06. R6(config-router)# network 198.51.16.0 mask 255.255.248.0
07. R6(config-router)# network 198.51.16.0 mask 255.255.252.0
08. R6(config-router)# network 198.51.20.0 mask 255.255.252.0
09. R6(config-router)# neighbor 10.0.6.1 remote-as 40
10. R6(config-router)# neighbor 10.0.6.1 prefix-list to-AS40 out
11. R6(config-router)# neighbor 10.0.7.1 remote-as 50
12. R6(config-router)# neighbor 10.0.7.1 prefix-list to-AS50 out
13. R6(config-router)# end
14. R6# clear ip bgp all 40 soft
15. R6# clear ip bgp all 50 soft

Depois de realizadas essas configurações em R6, é possível visualizar apenas aqueles anúncios que estão sendo enviados para os vizinhos R4 (no AS 40) e R5 (no AS 50). Observem que cada vizinho recebe apenas uma metade /22 do bloco completo /21 para forçar o balanceamento do tráfego de entrada, já que os roteadores da Internet irão optar por alcançar os destinos correspondentes à primeira metade 198.51.16.0/22 através do AS 40 e por alcançar os destinos correspondentes à segunda metade 198.51.20.0/22 através do AS 50. Observem, ainda, que para fins de disponibilidade o bloco completo /21 é anunciado para os dois upstreams, o que garante que haverá alcançabilidade a todos os destinos mesmo em caso de falha de um dos upstreams

R6# show ip bgp neighbor 10.0.6.1 advertised-route
BGP table version is 20, local router ID is 6.6.6.6

   Network          Next Hop            Metric LocPrf Weight Path
*> 198.51.16.0/22   0.0.0.0                  0         32768 i
*> 198.51.16.0/21   0.0.0.0                  0         32768 i

Total number of prefixes 2 



R6# show ip bgp neighbor 10.0.7.1 advertised-route

BGP table version is 20, local router ID is 6.6.6.6

   Network          Next Hop            Metric LocPrf Weight Path
*> 198.51.16.0/21   0.0.0.0                  0         32768 i
*> 198.51.20.0/22   0.0.0.0                  0         32768 i

Total number of prefixes 2 


Em R2 no AS 123 é possível observar como os demais roteadores da "Internet" lidam com os anúncios que configuramos em R6. Na tabela BGP de R2 fica evidente que cada metade /22 pode ser alcançada através de diferentes caminhos, o que força o balanceamento do tráfego de entrada em R6. Também é possível observar a existência do bloco completo /21 na tabela BGP. Nesse ponto é importante lembrar que a lógica dos protocolos de roteamento dinâmico é que caminhos mais específicos sempre serão preferidos em detrimento a prefixos menores que foram agregados. Ou seja, mesmo que o bloco /21 exista na tabela BGP de R2, a preferência será por alcançar os IPs de destino a partir das rotas /22 que são mais específicas.

R2> show ip bgp
BGP table version is 30, local router ID is 2.2.2.2

   Network          Next Hop            Metric LocPrf Weight Path
*>i198.51.16.0/22   10.0.1.1                 0    100      0 40 60 i
* i198.51.16.0/21   10.0.2.2                 0    100      0 50 60 i
*>i                 10.0.1.1                 0    100      0 40 60 i
*>i198.51.20.0/22   10.0.2.2                 0    100      0 50 60 i

Façam seus testes...

Samuel.

terça-feira, 7 de junho de 2016

Boas Práticas de Filtragem BGP em IPv4 e IPv6

Olá Pessoal,

Este artigo tem por objetivo chamar a atenção para algumas recomendações e exemplos de boas práticas de filtragem de prefixos no BGP que são de grande interesse para aqueles responsáveis por um AS e que queiram impedir o recebimento de rotas inesperadas que sequer deveriam existir na Internet, mas que podem aparecer em decorrência de erros de configuração ou mesmo de ataques. A topologia abaixo é bastante simples, mas suficiente para exemplificar as configurações deste artigo.

Na tabela abaixo o leitor encontra uma relação das redes reservadas no IPv4 e que, portanto, devem ser filtradas nos filtros de entrada do BGP. Na tabela há uma breve descrição da finalidade de cada rede reservada, além do link para as respectivas RFCs com as aplicações das redes reservadas.

|------------------|---------------|------|
| Endereço         | Descrição     | RFC# |
|------------------|---------------|------|
| 0.0.0.0      /08 | Rede Zero     | 6890 |
| 10.0.0.0     /08 | Privado       | 1918 |
| 100.64.0.0   /10 | CGNAT         | 6598 |
| 127.0.0.0    /08 | Loopback      | 6890 |
| 169.254.0.0  /16 | Link Local    | 3927 |
| 172.16.0.0   /12 | Privado       | 1918 |
| 192.0.0.0    /24 | IETF          | 6890 |
| 192.0.2.0    /24 | Documentação  | 5737 |
| 192.168.0.0  /16 | Privado       | 1918 |
| 198.18.0.0   /15 | Benchmark     | 2544 |
| 198.51.100.0 /24 | Documentação  | 5737 |
| 203.0.113.0  /24 | Documentação  | 5737 |
| 224.0.0.0    /04 | Multicast     | 5771 |
| 240.0.0.0    /04 | Classe E      | 1700 |
|------------------|---------------|------|

Na sequência trago os comandos necessários para criar uma prefix-list denominada FILTRO-ENTRADA em que é negada a recepção de qulaquer uma dessas redes reservadas ou mesmo sub-redes geradas a partir delas. É comum utilizar prefix-list para esse fim pela flexibilidade de informar não apenas os prefixos exatos, mas também uma faixa de prefixos que sejam menores ou igual (le) do que determinado valor de referência. A última regra permite o recebimento de qualquer prefixo menor do que /24 (0.0.0.0/0 le 24), uma prática recomenda porque impede o recebimento de anúncios fragmentados que sejam maiores do que /24. Depois de criar a lista em R1, é necessário aplicá-la na entrada da vizinhança BGP com R4.

!-- Criação do Filtro via Prefix-List
R1(config)# ip prefix-list FILTRO-ENTRADA deny   0.0.0.0/8       le 32
R1(config)# ip prefix-list FILTRO-ENTRADA deny   10.0.0.0/8      le 32
R1(config)# ip prefix-list FILTRO-ENTRADA deny   100.64.0.0/10   le 32
R1(config)# ip prefix-list FILTRO-ENTRADA deny   127.0.0.0/8     le 32
R1(config)# ip prefix-list FILTRO-ENTRADA deny   169.254.0.0/16  le 32
R1(config)# ip prefix-list FILTRO-ENTRADA deny   172.16.0.0/12   le 32
R1(config)# ip prefix-list FILTRO-ENTRADA deny   192.0.0.0/24    le 32
R1(config)# ip prefix-list FILTRO-ENTRADA deny   192.0.2.0/24    le 32
R1(config)# ip prefix-list FILTRO-ENTRADA deny   192.168.0.0/16  le 32
R1(config)# ip prefix-list FILTRO-ENTRADA deny   198.18.0.0/15   le 32
R1(config)# ip prefix-list FILTRO-ENTRADA deny   198.51.100.0/24 le 32
R1(config)# ip prefix-list FILTRO-ENTRADA deny   203.0.113.0/24  le 32
R1(config)# ip prefix-list FILTRO-ENTRADA deny   224.0.0.0/4     le 32
R1(config)# ip prefix-list FILTRO-ENTRADA deny   240.0.0.0/4     le 32
R1(config)# ip prefix-list FILTRO-ENTRADA permit 0.0.0.0/0       le 24

!-- Aplicação do Filtro no Vizinho eBGP
R1(config)# router bgp 100
R1(config-router)# neighbor 203.0.113.2 remote-as 200
R1(config-router)# neighbor 203.0.113.2 prefix-list FILTRO-ENTRADA in
R1(config-router)# end
R1# clear bgp all 200 soft

É interessante aproveitar o assunto e fazer um paralelo com esse mesmo procedimento no contexto do protocolo IPv6. Na tabela abaixo o leitor encontra uma relação das redes reservadas no IPv6 e que, portanto, devem ser filtradas nos filtros de entrada do BGP. Na tabela há uma breve descrição da finalidade de cada rede reservada, além do link para as respectivas RFCs com as aplicações das redes reservadas.

|------------------|---------------|------|
| Endereço         | Descrição     | RFC# |
|------------------|---------------|------|
| ::          /0   | Default       |      |
| ::          /128 | Sem Endereço  | 4291 |
| ::1         /128 | Loopback      | 4291 |
| ::ffff:0:0  /96  | IPv4 Mapeado  | 4291 |
| 0100::      /64  | Descarte      | 6666 |
| 2000::      /3   | Global        | 3587 |
| 2001::      /32  | Teredo        | 4380 |
| 2001:10::   /28  | ORCHID        | 4843 |
| 2001:db8::  /32  | Documentação  | 3849 |
| 2002::      /16  | 6to4          | 3056 |
| fc00::      /7   | Unique Local  | 4193 |
| fe80::      /10  | Link-Local    | 4291 |
| ff00::      /8   | Multicast     | 4291 |
|------------------|---------------|------|

Na sequência trago os comandos necessários para criar uma prefix-list denominada FILTRO-ENTRADA-v6 em que é negada a recepção de qulaquer uma dessas redes reservadas ou mesmo sub-redes geradas a partir delas. Observem nos comandos abaixo que nem todas as redes reservadas da tabela acima aparecem explicitamente nas regras, já que a sequência de permissões e negações apresentada é suficiente para garantir a filtragem delas. Com base no filtro abaixo, somente são permitidos prefixos IPv6 iguais ou menores do que /48, uma boa prática para evitar o recebimento de prefixos fragmentados.

ipv6 prefix-list FILTRO-ENTRADA-v6 deny   2001:db8::/32  le 128
ipv6 prefix-list FILTRO-ENTRADA-v6 permit 2001::/32
ipv6 prefix-list FILTRO-ENTRADA-v6 deny   2001::/32      le 128
ipv6 prefix-list FILTRO-ENTRADA-v6 permit 2002::/16   
ipv6 prefix-list FILTRO-ENTRADA-v6 deny   2002::/16      le 128
ipv6 prefix-list FILTRO-ENTRADA-v6 deny   3ffe::/16      le 128
ipv6 prefix-list FILTRO-ENTRADA-v6 permit 2000::/3       le 48   
ipv6 prefix-list FILTRO-ENTRADA-v6 deny   ::/0           le 128

Caso o laboratório estivesse configurado com endereços IPv6, essa prefix-list poderia ser aplicada em um vizinho eBGP (2001:db8:cafe::40) através dos comandos abaixo. Uma diferença no contexto do IPv6 é que as políticas do BGP devem ser aplicadas no sub-modo de configuração da address-family IPv6. O leitor interessado na configuração de BGP através de IPv6 pode recorrer ao laboratório 34 do livro ou mesmo ao artigo intitulado "Peering IPv6 no Roteamento BGP".

!-- Exemplo de Aplicação do Filtro na Address Family IPv6
R1(config)# ipv6 unicast-routing
R1(config)# router bgp 100
R1(config-router)# neighbor 2001:DB8::2 remote-as 200
R1(config-router)# address-family ipv6 unicast
R1(config-router-af)# neighbor 2001:DB8::2 prefix-list FILTRO-ENTRADA-v6 in
R1(config-router-af)# neighbor 2001:DB8::2 activate

Há várias fontes de distribuição de filtros pradrões na Internet que tem por objetivo tornar a Internet um espaço mais seguro. Uma fonte interessante é do Team Cymru que atualiza sua relação de prefixos a cada 4 horas e que contempla, inclusive, aqueles prefixos alocados às  autoridades regionais da Internet (RIR) que ainda não foram atribuídos para nenhum AS. Vale à pena conferir o link abaixo...


Façam seus testes...

Samuel.

quarta-feira, 1 de junho de 2016

Limitando o Aprendizado de Prefixos no Protocolo BGP

Olá Pessoal,

Este é mais um artigo sobre configuração do protocolo BGP e novamente, por conveniência, irei me basear no laboratório 33 do livro LabCisco (2a Edição), cuja topologia pode ser observada na figura abaixo. Dessa vez o objetivo é apresentar os procedimentos de configuração necessários para limitar o aprendizado de prefixos a partir de um vizinho qualquer. 

Essa ação é importante porque a tabela de roteamento da Internet possui aproximadamente 600.000 prefixos atualmente. Esteja ciente de que a tabela completa terá milhares de entradas porque é muito comum existirem múltiplas rotas em direção ao mesmo prefixo. Além disso, caso uma empresa esteja conectada à Internet através de dois links, ou seja, esteja pareada simultaneamente com dois ISPs, então seu roteador de borda receberá duas vezes mais rotas aprendidas através de diferentes roteadores.

Por conta dessa grande quantidade de rotas, para receber a tabela completa seria recomendado, por exemplo, um Cisco 3925 ou preferencialmente um ASR 1002-X. Esses equipamentos não são baratos, principalmente os roteadores da família ASR. A escolha final vai depender não apenas da capacidade em armazenar e processar a tabela de roteamento, mas também da vazão dos links que implica na quantidade de pacotes por segundo (pps) que trafegarão através das interfaces do roteador. Por isso é importante estar atento às especificações do roteador para ter certeza de que o equipamento será adequado para as necessidades da empresa.

A recomendação para amenizar o "problema"do custo dos reoteadores é que o ISP envie apenas uma rota default, caso a empresa não tenha interesse em praticar engenharia de tráfego, ou apenas a tabela parcial com aquelas rotas originadas pelo próprio provedor. O que aconteceria se repentinamente, por qualquer motivo, a operadora começasse a anunciar mais rotas do que estava previsto para sua caixa aguentar? É nesse contexto que a limitação de aprendizado de prefixos pode ser um recurso bem útil!

Obs: Esse problema também poderia ser facilmente resolvido através da inserção de um filtro de entrada que permita apenas aquelas rotas previamente previstas de serem anunciadas pelo ISP.

Como o cenário é mais complexo do que realmente seria necessário para demonstrar essa simples configuração, utilizarei como referência apenas o roteador R1 da empresa detentora do AS 123. As linhas apresentadas abaixo são necessárias para limitar o aprendizado de prefixos em R1 através de R4 .

R1(config)# router bgp 123
R1(config-router)# neighbor 10.0.4.2 remote-as 40
R1(config-router)# neighbor 10.0.4.2 maximum-prefix 10 50 restart 2
R1(config-router)# end

Observem no destaque em amarelo que o primeiro parâmetro de maximum-prefix representa o limite de prefixos que será permitido na vizinhança, de forma que em caso de violação desse limite o roteador será forçado a terminar a sessão BGP. Neste exemplo, limitamos o aprendizado a 10 prefixos, lembrando que no laboratório há 7 prefixos sendo anunciados por R6. O segundo parâmetro define uma porcentagem que, quando atingida, fará com que o roteador passe a registrar mensagens de log alertando que a quantidade de prefixos recebidos está próxima do limite anteriormente definido. Por fim, o parâmetro restart define o tempo (em minutos) para que uma nova sessão BGP seja restabelecida depois de uma queda por motivo de violação ao limite de prefixos. 

Após essa configuração, o roteador R1 está recebendo 7 prefixos do limite de 10, condição que corresponde a mais que 50% e implica no registro de mensagens de log para alertar o administrador. Neste ponto, o sistema do R1 passa a exibir a seguinte mensagem no console:

%BGP-4-MAXPFX: No. of prefix received from 10.0.4.2 (afi 0) reaches 7, max 10

Na sequência, apenas para mostrar que a configuração funciona, adicionarei e anunciarei novas rotas em R6 (omitido), para que o limite de anúncios em R1 seja propositalmente violado. Observem abaixo a saída das mensagens de console em R1 quando o vizinho BGP ultrapassa o limite de anúncios permitidos.

%BGP-3-MAXPFXEXCEED: No. of prefix received from 10.0.4.2 (afi 0): 11 exceed limit 10
%BGP-5-ADJCHANGE: neighbor 10.0.4.2 Down BGP Notification sent

Obs.: Também é possível adicionar o parâmetro warning-only para que apenas mensagens de log sejam exibidas e/ou registradas pelo sistema, sem que a vizinhança BGP seja terminada. No entanto, a ação de terminar a sessão BGP ao receber rotas além daquilo que foi pré-definido pelo administrador é importante para não comprometer o desempenho do roteador. Lembrem-se de que a recepção repentina de milhares de rotas certamente demandaria uso de memória e de processamento, sendo a capacidade da caixa pode não ser adequada para lidar com rotas além da previsão. 

Simples assim, façam seus testes...

Samuel.

quarta-feira, 25 de maio de 2016

Anúncio de Rota Default via Protocolo BGP

Olá Pessoal,

Quando um AS contrata conexão com uma operadora de telecomunicações, há necessidade de que seja estabelecida uma sessão BGP entre as partes para que a empresa possa anunciar seus próprios prefixos e receber as informações de roteamento que permitam alcançar toda a Internet. Nesse contexto é comum a operadora oferecer ao seu cliente a possibilidade de escolher se deseja receber a tabela completa de rotas (full route), a tabela parcial de rotas (partial route) ou apenas uma rota padrão (default route).

  • Default Route: Basicamente a operadora anuncia apenas uma rota padrão (default) para seu cliente, apontando que todo tráfego de saída para qualquer prefixo na Internet deve ser direcionado através dela. Essa ação é comum, por exemplo, quando a empresa está conectada à Internet a partir de uma única operadora, mas utiliza BGP porque é um AS e tem seus próprios recursos públicos para anunciar. Também é comum quando a empresa não tem interesse nenhum em definir políticas de engenharia de tráfego;
  • Partial Route: Além de anunciar uma rota padrão para qualquer prefixo na Internet, a operadora também anuncia rotas específicas para seus próprios prefixos com o intuito de otimizar a alcançabilidade destes, a fim de evitar que seu cliente tente alcançar seus prefixos por outro caminho que certamente seria uma opção pior; 
  • Full Route: A operadora anuncia a tabela BGP completa com todos os prefixos da Internet, ação que certamente requer equipamentos de borda com poder de memória e processamento para lidar com aproximadamente 600.000 prefixos IPv4 (atualmente), além de milhares de rotas, já que podem existir múltiplas rotas apontando para o mesmo prefixo.




Não existe uma regra "mágica" que diga qual é a melhor opção, já que a escolha por uma dessas opções vai depender do interesse da empresa em aplicar suas próprias políticas de engenharia de tráfego, da competência técnica dos seus recursos humanos em configurar o BGP, dos equipamentos disponíveis, do orçamento para aquisição de novos equipamentos, etc.

Através do mesmo laboratório utilizado no artigo anterior, oportunidade em que expliquei o processo de configuração de atributos e filtros no BGP (cliqe aqui para ler), já vimos que há duas fontes de aprendizado dos prefixos nos roteadores de borda R1 (conectado ao R4 do ISP no AS 40) e R3 (conectado ao R5 do ISP no AS 50), sendo um aprendizado através do vizinho interno iBGP e outro através do vizinho externo. O BGP dá preferência pelo aprendizado eBGP, ou seja, em R1 haverá preferência por escoar o tráfego através de R4, enquanto que em R3 haverá preferência por escoar o tráfego através de R5. Antes qualquer configuração, convém verificar as tabelas BGP dos roteadores da empresa:


R1> show ip bgp
BGP table version is 15, local router ID is 1.1.1.1

   Network          Next Hop            Metric LocPrf Weight Path

*> 36.0.0.0         10.0.4.2                               0 40 60 i
* i                 10.0.3.2                 0    100      0 50 60 i
*> 37.0.0.0         10.0.4.2                               0 40 60 i
* i                 10.0.3.2                 0    100      0 50 60 i
*> 38.0.0.0         10.0.4.2                               0 40 60 i
* i                 10.0.3.2                 0    100      0 50 60 i
*> 39.0.0.0         10.0.4.2                               0 40 60 i
* i                 10.0.3.2                 0    100      0 50 60 i
*> 40.0.0.0         10.0.4.2                               0 40 60 i
* i                 10.0.3.2                 0    100      0 50 60 i
*> 41.0.0.0         10.0.4.2                               0 40 60 i
* i                 10.0.3.2                 0    100      0 50 60 i
*> 42.0.0.0         10.0.4.2                               0 40 60 i
* i                 10.0.3.2                 0    100      0 50 60 i


R3> show ip bgp
BGP table version is 8, local router ID is 3.3.3.3

   Network          Next Hop            Metric LocPrf Weight Path

* i36.0.0.0         10.0.3.1                 0    100      0 40 60 i
*>                  10.0.5.2                               0 50 60 i
* i37.0.0.0         10.0.3.1                 0    100      0 40 60 i
*>                  10.0.5.2                               0 50 60 i
* i38.0.0.0         10.0.3.1                 0    100      0 40 60 i
*>                  10.0.5.2                               0 50 60 i
* i39.0.0.0         10.0.3.1                 0    100      0 40 60 i
*>                  10.0.5.2                               0 50 60 i
* i40.0.0.0         10.0.3.1                 0    100      0 40 60 i
*>                  10.0.5.2                               0 50 60 i
* i41.0.0.0         10.0.3.1                 0    100      0 40 60 i
*>                  10.0.5.2                               0 50 60 i
* i42.0.0.0         10.0.3.1                 0    100      0 40 60 i
*>                  10.0.5.2                               0 50 60 i

Já  em R2 que está posicinado atrás de R1 e R3, podemos observar o aprendizado de duas rotas para cada um dos prefixos anunciados através dos pareamentos iBGP com seus vizinhos no mesmo AS. 

R2> show ip bgp
BGP table version is 15, local router ID is 2.2.2.2

   Network          Next Hop            Metric LocPrf Weight Path
*>i36.0.0.0         10.0.1.1                 0    100      0 40 60 i
* i                 10.0.2.2                 0    100      0 50 60 i
*>i37.0.0.0         10.0.1.1                 0    100      0 40 60 i
* i                 10.0.2.2                 0    100      0 50 60 i
*>i38.0.0.0         10.0.1.1                 0    100      0 40 60 i
* i                 10.0.2.2                 0    100      0 50 60 i
*>i39.0.0.0         10.0.1.1                 0    100      0 40 60 i
* i                 10.0.2.2                 0    100      0 50 60 i
*>i40.0.0.0         10.0.1.1                 0    100      0 40 60 i
* i                 10.0.2.2                 0    100      0 50 60 i
*>i41.0.0.0         10.0.1.1                 0    100      0 40 60 i
* i                 10.0.2.2                 0    100      0 50 60 i
*>i42.0.0.0         10.0.1.1                 0    100      0 40 60 i
* i                 10.0.2.2                 0    100      0 50 60 i

Neste artigo assumiremos que a empresa cliente não deseja receber a tabela BGP completa ou parcial, de forma que seus provedores serão configurados para anunciar apenas a rota padrão. Esse procedimento pode ser realizado através dos comandos listados abaixo:

!-- Configuração de R4 no AS 40
01. R4(config)# ip access-list standard TUDO
02. R4(config-std-nacl)# permit any
03. R4(config-std-nacl)# exit
04. R4(config)# route-map BGP-FILTRO deny 10
05. R4(config-route-map)# match ip address TUDO
06. R4(config-route-map)# route-map BGP-FILTRO permit 20
07. R4(config-route-map)# exit
08. R4(config)# router bgp 40
09. R4(config-router)# neighbor 10.0.4.1 route-map BGP-FILTRO out
10. R4(config-router)# neighbor 10.0.4.1 default-originate
11. R4(config-router)# end
12. R4# clear bgp all 123 soft

!-- Configuração de R5 no AS 50
01. R5(config)# ip access-list standard TUDO
02. R5(config-std-nacl)# permit any
03. R5(config-std-nacl)# exit
04. R5(config)# route-map BGP-FILTRO deny 10
05. R5(config-route-map)# match ip address TUDO
06. R5(config-route-map)# route-map BGP-FILTRO permit 20
07. R5(config-route-map)# exit
08. R5(config)# router bgp 50
09. R5(config-router)# neighbor 10.0.5.1 route-map BGP-FILTRO out
10. R5(config-router)# neighbor 10.0.5.1 default-originate
11. R5(config-router)# end
12. R5# clear bgp all 123 soft

Nas linhas de 01-07 criamos um filtro negando TODOS os prefixos que posteriormente (linha 9) foi aplicado no sentido sainte (out) da vizinhanga eBGP dos ISPs com o respsectivo roteador de borda no AS 123. Ou seja, o ISP responsável pela configuração de R4 aplicou o filtro na saída da vizinhança com R1 para negar que qualquer prefixo seja anunciado para a empresa. O mesmo procedimento foi feito pelo ISP responsável por R5 em relação a R3. 

Se as configurações cessassem nesse ponto, os roteadores do AS 123 não receberiam absolutamente nenhum anúncio dos provedores. É por isso que na linha 10 os ISPs configuram seus roteadores para que façam o anúncio de uma rota default (0.0.0.0/0) para que todo o tráfego de saída seja direcionado pelo seu AS. Embora haja outros métodos para anunciar a rota padrão, utilizar o parâmetro default-originate é uma boa solução porque injeta artificialmente uma rota default na tabela BGP de um vizinho específico, sem interferir nas demais vizinhanças. 

Obs.: Outra opção para anunciar uma rota padrão na tabela BGP seria utiliar o comando "network 0.0.0.0", desde que a rota padrão exista previamente na tabela de roteamento. Também é possível redistribuir a rota padrão a partir de outro protocolo de roteamento, mais uma vez desde que essa rota exista previamente na tabela de roteamento. Uma terceira possibilidade seria utiliar o parâmetro default-information originate de maneira global nas sub-configurações do BGP, uma estratégia que nem sempre é desejável porque faria o BGP injetar artificialmente uma rota padrão em todos os seus vizinhos BGP. A solução utilizada neste artigo é a mais flexível porque permite injetar artificialmente a rota padrão apenas para um vizinho específico, de maneira que todos os demais prefixos podem ser filtrados na saída sem afetar a rota artificial.

Uma vez que o procedimento de anunciar apenas a rota padrão foi realizado por ambos os provedores, os roteadores da empresa no AS 123 selecionam aquela saída que entendem ser a melhor, conforme observado nas tabelas abaixo. Seguindo a lógica do BGP, os roteadores R1 e R3 preferem a rota padrão do vizinho eBGP (por R4 em R1 e por R5 em R3), enquanto que o roteador R2 prefere a rota padrão do vizinho iBGP com menor router-ID (através de R1). 

R1> show ip bgp
BGP table version is 23, local router ID is 1.1.1.1

   Network          Next Hop            Metric LocPrf Weight Path
* i0.0.0.0          10.0.3.2                 0    100      0 50 i
*>                  10.0.4.2                 0             0 40 i



R2> show ip bgp
BGP table version is 23, local router ID is 2.2.2.2

   Network          Next Hop            Metric LocPrf Weight Path
* i0.0.0.0          10.0.2.2                 0    100      0 50 i
*>i                 10.0.1.1                 0    100      0 40 i



R3> show ip bgp
BGP table version is 17, local router ID is 3.3.3.3

   Network          Next Hop            Metric LocPrf Weight Path
*> 0.0.0.0          10.0.5.2                 0             0 50 i
* i                 10.0.3.1                 0    100      0 40 i


Reparem que depois das configurações realizadas nos provedores (AS 40 e AS 50), os roteadores da empresa (no AS 123) não aprendem mais todos os prefixos individualmente, o que certamente alivia bastante a exigência de memória e processamento dos equipamentos de borda. Por outro lado, a empresa perde de aplicar qualquer ação no sentido de definir suas próprias políticas de engenharia de tráfego. 

Façam seus testes...

Samuel.