Utilizando o script vpnautomatica

Quem trabalha com firewalls Linux interconectados por circuitos privados, sabe que não é simples provisionar um meio de backup rápido e eficiente que não seja a aquisição de um link extra, nesse artigo mostro como fazer uma contingência usando uma VPN IPsec pela internet.

[ Hits: 7.930 ]

Por: Sergei Martao em 12/07/2017


Cenário complexo



A imagem abaixo foi baseada no cenário anterior, porém adicionando alguns componentes.
Site A (São Paulo):
  • Rede de desktops: 172.16.10.0/24
  • Rede de servidores: 172.16.11.0/24
  • Rede Cliente A1: 10.10.10.0/24
  • Rede Cliente A2: 10.10.110./24
  • IP de internet: 200.2.2.2

Site B (Paraná):
  • Rede de desktops: 172.16.20.0/24
  • Rede de servidores: 172.16.22.0/24
  • Rede Cliente B1: 10.10.20.0/24
  • IP de internet: 189.9.9.9

Site C (Rio de Janeiro):
  • Rede de desktops: 172.16.30.0/24
  • IP de internet: 187.8.8.8

Resumidamente todas as redes da empresa XPTO devem se comunicar, no entanto devemos impedir que redes de clientes se comuniquem, ou seja, caso haja falha em um dos links e ativarmos a contingência (script vpn automática) não poderá existir um túnel do Cliente A1 (10.10.10.0/24) para o Cliente B1 (10.10.20.0/24), imagine se o Cliente A1 descobre que consegue ver a rede do Cliente B1 que por sinal é seu concorrente, seria engraçado se não fosse trágico.

Novamente imaginando que ocorre uma falha na ponta A do link MPLS e é necessário prover a contingência o quanto antes para toda rede da empresa. Se todas as premissas para o funcionamento do script já foram atendidas (veremos nas próximas páginas), bastaria executar os passos abaixo.

1. Baixar o script para um servidor ou qualquer um dos firewalls, nesse exemplo será copiado para o firewall do site A no diretório /etc/vpnautomatica.

2. Tornar o script executável.

# chmod 755 /etc/vpnautomatica/vpnautomatica.sh

3. Criar o arquivo com as configurações de rede do site A.

# vim 1.sitea.redes

Adicionar as linhas:

linux=1
left=200.2.2.2
leftnexthop=200.2.2.1
172.16.10.0/24#INTERNADESKTOPSSITEA
172.16.11.0/24#INTERNASERVIDORESSITEA
10.10.10.0/24#CLIENTEA1
10.10.110.0/24#CLIENTEA2

4. Criar o arquivo com as configurações de rede do site B.

# vim 2.siteb.redes

Adicionar as linhas:

linux=1
left=189.9.9.9
leftnexthop=189.9.9.1
172.16.20.0/24#INTERNADESKTOPSSITEB
172.16.22.0/24#INTERNASERVIDORESSITEB
10.10.20.0/24#CLIENTEB1

5. Criar o arquivo com as configurações de rede do site C:

# vim 3.sitec.redes

Adicionar as linhas:

linux=1
left=187.8.8.8
leftnexthop=188.8.8.1
172.16.30.0/24#INTERNADESKTOPSSITEC

6. Executar o script:

# ./vpnautomaitca.sh

Escolher a opção que deseja, nesse caso é subir a contingência.
Escolher o site que caiu.
Esperar a execução do script.
6. Validando se os túneis estão no ar.

# IPsec auto --status
A imagem acima exibe que os túneis foram fechado sem problemas na fase 1 e na fase 2.

Caso queira uma visão mais específica use o grep mais o comentário utilizado no arquivo redes.

# IPsec auto --status | grep -iE "sitea|clientea" --color
Com esse comando conseguimos inclusive checar qual rede pode acessar o que e assim validar se o pré requisito de impedir um túnel entre dois clientes está em conformidade.

Validando quais redes podem acessar os clientes A.

# IPsec auto --status | grep -i clientea --color
Validando quais redes podem acessar o cliente B.

# IPsec auto --status | grep -i clienteb --color
7. Testando todos os acessos.

Aqui estão alguns tracerts mostrando que a VPN funcionou.

Traceroute do site A, rede desktops (172.16.10.0/24) para o site B, rede servdiores (172.16.22.0/24)
Traceroute do site A, rede desktops (172.16.10.0/24) para o site B, rede cliente B1 (10.10.20.0/24)
Traceroute do site A, rede desktops (172.16.10.0/24) para o site C, rede desktops (172.16.30.0/24)
Traceroute do site B, rede desktops (172.16.20.0/24) para o site A, rede cliente A1 (10.10.10.0/24)
Como a contingência foi ativada apenas para o site A, a comunicação entre os sites B e C devem ocorrer pelo circuito MPLS normalmente.

Traceroute do site B, rede desktops (172.16.20.0/24) para site C, rede desktops (172.16.30.0/24)
Traceroute do site C, rede desktops (172.16.30.0/24) para o site B, cliente B1 (10.10.20.0/24)
Após subir a contingência da Ponta A existe a possibilidade de um segundo link cair (ponta B ou ponta C).

Nesse caso é necessário validar qual ponta caiu, normalmente é possível identificar usando um tracert e após isso repetir os passos anteriores para subir uma segunda VPN.

Quando a operadora informar que um dos link for restabelecido, basta remover a contingência como visto anteriormente.

Agora que temos uma boa noção do que o script é capaz de fazer vamos entender o que é necessário para o funcionamento do mesmo.

Página anterior     Próxima página

Páginas do artigo
   1. Introdução
   2. Cenário complexo
   3. Premissas para funcionamento
   4. Recursos e Troubleshooting
Outros artigos deste autor

Simulando redes com o GNS

Openswan - Configurando uma conexão VPN Site-to-Site e simulando com GNS3

Configurando o segundo default gateway para um link de entrada específico

Planejando e migrando softwares do Windows para o Linux

Criando um template customizado para o CACTI

Leitura recomendada

Implementando Servidor NTP no Debian

Proxy Squid com SquidGuard + Controle de Banda e Autenticação NTLM no Samba 4 (CentOS 6.5 - 64 bits Minimal)

Configuração de serviço do Nagios para monitorar o APT do Ubuntu

Site Survey Plan

Monitorando Rede com Zabbix no Debian 7

  
Comentários
[1] Comentário enviado por marcoaurelio22 em 12/07/2017 - 19:47h

Muito bom o artigo, Parabéns.
Já utilizei por um bom tempo algo parecido, atualmente utilizo strongswan + quagga(bgp), fazendo redundancia e balanceamento entre a MPLS + 2 VPNS e hoje o tempo de virada esta em 2 segundos, praticamente transparente para o usuario. é uma ótima alternativa.

[2] Comentário enviado por fabio_cirino em 13/07/2017 - 14:20h

Parabéns.... Ficou muito bom seu artigo.

[3] Comentário enviado por sergeimartao em 14/07/2017 - 14:13h


[1] Comentário enviado por marcoaurelio22 em 12/07/2017 - 19:47h

Muito bom o artigo, Parabéns.
Já utilizei por um bom tempo algo parecido, atualmente utilizo strongswan + quagga(bgp), fazendo redundancia e balanceamento entre a MPLS + 2 VPNS e hoje o tempo de virada esta em 2 segundos, praticamente transparente para o usuario. é uma ótima alternativa.



Não tinha ideia que daria pra fazer isso também usando o quagga, muito interessante, quando sai um artigo mostrando essa solução?! rs
Vlw!

[4] Comentário enviado por sergeimartao em 14/07/2017 - 14:14h


[2] Comentário enviado por fabio_cirino em 13/07/2017 - 14:20h

Parabéns.... Ficou muito bom seu artigo.


Vlw Cirino!!


Contribuir com comentário




Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts