ProHoster > Blog > Administração > 1.5 esquemas em IPsec VPN nacional. Testando versões demo

1.5 esquemas em IPsec VPN nacional. Testando versões demo

1.5 esquemas em IPsec VPN nacional. Testando versões demo

Situação

Recebi a versão demo dos produtos S-Terra VPN versão 4.3 por três meses. Quero entender se minha vida como engenheiro ficará mais fácil após a migração para a nova versão.

Hoje, não é difícil; um sachê de café solúvel 3 em 1 deve ser suficiente. Vou explicar como obter as versões demo. Tentarei montar esquemas GRE-over-IPsec e IPsec-over-GRE.

Como obter a versão demo

1.5 esquemas em IPsec VPN nacional. Testando versões demo

A partir do desenho, fica claro que para obter a versão demo, é necessário:

  • Escrever um e-mail para presale@s-terra.ru a partir do endereço corporativo;
  • No e-mail, indicar o CNPJ da sua organização;
  • Listar os produtos e suas quantidades.

As versões demo são válidas por três meses. O fornecedor não limita sua funcionalidade.

Estou implantando a imagem

A versão demo do gateway de segurança é uma imagem de máquina virtual. Estou usando o VMWare Workstation. A lista completa de hipervisores suportados e ambientes de virtualização está disponível no site do fornecedor.

Antes de iniciar as ações ativas, observe que a imagem da máquina virtual não possui interfaces de rede por padrão:

1.5 esquemas em IPsec VPN nacional. Testando versões demo

A lógica é clara; o usuário deve adicionar tantas interfaces quantas forem necessárias. Vou adicionar quatro de uma vez:

1.5 esquemas em IPsec VPN nacional. Testando versões demo

Agora estou iniciando a máquina virtual. Logo após a inicialização, o gateway solicita login e senha.

No S-Terra Gateway, existem várias consoles com diferentes contas. Contarei o número delas em um artigo separado. Por ora:
Entrar como: administrador
Senha: s-terra

Estou inicializando o gateway. A inicialização é uma sequência de ações: inserção da licença, configuração do gerador biológico de números aleatórios (o simulador de teclado – meu recorde é de 27 segundos) e criação do mapa de interfaces de rede.

Mapa de interfaces de rede. Fica mais fácil

A versão 4.2 acolhia o usuário ativo com mensagens:

Iniciando o daemon IPsec..... falhou
ERRO: Não foi possível estabelecer conexão com o daemon

Um usuário ativo (segundo um engenheiro anônimo) é aquele capaz de configurar qualquer coisa rapidamente e sem documentação.

Algo estava errado, mesmo antes de tentar configurar o endereço IP na interface. Tudo se deve ao mapa de interfaces de rede. Foi necessário realizar:

/bin/netifcfg enum > /home/map
/bin/netifcfg map /home/map
reiniciar o serviço de rede

Como resultado, é criado um mapa de interfaces de rede que contém a correspondência dos nomes das interfaces físicas (0000:02:03.0) e suas designações lógicas no sistema operacional (eth0) e no console semelhante ao Cisco (FastEthernet0/0):

#Unique ID iface type OS name Cisco-like name

0000:02:03.0 phye eth0 FastEthernet0/0

As designações lógicas das interfaces são chamadas de aliases. Os aliases são armazenados no arquivo /etc/ifaliases.cf.
Na versão 4.3, ao iniciar a máquina virtual pela primeira vez, o mapa de interfaces é criado automaticamente. Se você alterar o número de interfaces de rede na virtualização, será necessário criar o mapa de interfaces novamente:

/bin/netifcfg enum > /home/map
/bin/netifcfg map /home/map
systemctl restart networking

Diagrama 1: GRE sobre IPsec

Estou implementando dois gateways virtuais, conectando-os conforme mostrado na figura:

1.5 esquemas em IPsec VPN nacional. Testando versões demo

Passo 1. Configurando endereços IP e rotas

VG1(config) #
interface fa0/0
ip address 172.16.1.253 255.255.255.0
no shutdown
interface fa0/1
ip address 192.168.1.253 255.255.255.0
no shutdown
ip route 0.0.0.0 0.0.0.0 172.16.1.254

VG2(config) #
interface fa0/0
ip address 172.16.1.254 255.255.255.0
no shutdown
interface fa0/1
ip address 192.168.2.254 255.255.255.0
no shutdown
ip route 0.0.0.0 0.0.0.0 172.16.1.253

Verifico a conectividade IP:

root@VG1:~# ping 172.16.1.254 -c 4
PING 172.16.1.254 (172.16.1.254) 56(84) bytes of data.
64 bytes from 172.16.1.254: icmp_seq=1 ttl=64 time=0.545 ms
64 bytes from 172.16.1.254: icmp_seq=2 ttl=64 time=0.657 ms
64 bytes from 172.16.1.254: icmp_seq=3 ttl=64 time=0.687 ms
64 bytes from 172.16.1.254: icmp_seq=4 ttl=64 time=0.273 ms

--- 172.16.1.254 Ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 0.273/0.540/0.687/0.164 ms

Passo 2. Configurando GRE

O exemplo de configuração do GRE é retirado dos cenários oficiais. Crio o arquivo gre1 no diretório /etc/network/interfaces.d com o seguinte conteúdo.

Para VG1:

auto gre1
iface gre1 inet static
address 1.1.1.1
netmask 255.255.255.252
pre-up ip tunnel add gre1 mode gre remote 172.16.1.254 local 172.16.1.253 key 1 ttl 64 tos inherit
pre-up ethtool -K gre1 tx off > /dev/null
pre-up ip link set gre1 mtu 1400
post-down ip link del gre1

Para VG2:

auto gre1
iface gre1 inet static
address 1.1.1.2
netmask 255.255.255.252
pre-up ip tunnel add gre1 mode gre remote 172.16.1.253 local 172.16.1.254 key 1 ttl 64 tos inherit
pre-up ethtool -K gre1 tx off > /dev/null
pre-up ip link set gre1 mtu 1400
post-down ip link del gre1

Ativo a interface no sistema:

root@VG1:~# ifup gre1
root@VG2:~# ifup gre1

Verifico:

root@VG1:~# ip address show
8: gre1@NONE:  mtu 1400 qdisc noqueue state UNKNOWN group default qlen 1
    link/gre 172.16.1.253 peer 172.16.1.254
    inet 1.1.1.1/30 brd 1.1.1.3 scope global gre1
       valid_lft forever preferred_lft forever

root@VG1:~# ip tunnel show
gre0: gre/ip remote any local any ttl inherit nopmtudisc
gre1: gre/ip remote 172.16.1.254 local 172.16.1.253 ttl 64 tos inherit key 1

No S-Terra Gateway, há um sniffer de pacotes embutido — tcpdump. Vou gravar um dump de tráfego em um arquivo pcap:

root@VG2:~# tcpdump -i eth0 -w /home/dump.pcap

Início o ping entre as interfaces GRE:

root@VG1:~# ping 1.1.1.2 -c 4
PING 1.1.1.2 (1.1.1.2) 56(84) bytes of data.
64 bytes from 1.1.1.2: icmp_seq=1 ttl=64 time=0.918 ms
64 bytes from 1.1.1.2: icmp_seq=2 ttl=64 time=0.850 ms
64 bytes from 1.1.1.2: icmp_seq=3 ttl=64 time=0.918 ms
64 bytes from 1.1.1.2: icmp_seq=4 ttl=64 time=0.974 ms

--- 1.1.1.2 estatísticas do ping ---
4 pacotes transmitidos, 4 recebidos, 0% de perda de pacotes, tempo 3006ms
rtt min/avg/max/mdev = 0.850/0.915/0.974/0.043 ms

O túnel GRE está ativo e funcionando:

1.5 esquemas em IPsec VPN nacional. Testando versões demo

Passo 3. Criptografando GRE com GOST

Defino o tipo de identificação – por endereço. A autenticação é feita por chave pré-definida (de acordo com as Regras de Uso, é necessário usar certificados digitais):

VG1(config)#
crypto isakmp identity address
crypto isakmp key KEY address 172.16.1.254

Definindo os parâmetros da Fase I do IPsec:

VG1(config)#
crypto isakmp policy 1
encr gost
hash gost3411-256-tc26
auth pre-share
group vko2

Definindo os parâmetros da Fase II do IPsec:

VG1(config)#
crypto ipsec transform-set TSET esp-gost28147-4m-imit
mode tunnel

Criando a lista de acesso para criptografia. Tráfego de destino — GRE:

VG1(config)#
ip access-list extended LIST
permit gre host 172.16.1.253 host 172.16.1.254

Criando o mapa criptográfico e vinculando-o à interface WAN:

VG1(config)#
crypto map CMAP 1 ipsec-isakmp
match address LIST
set transform-set TSET
set peer 172.16.1.253
interface fa0/0
  crypto map CMAP

Para a VG2, a configuração é espelho, com diferenças:

VG2(config)#
crypto isakmp key KEY address 172.16.1.253
ip access-list extended LIST
permit gre host 172.16.1.254 host 172.16.1.253
crypto map CMAP 1 ipsec-isakmp
set peer 172.16.1.254

Verifico:

root@VG2:~# tcpdump -i eth0 -w /home/dump2.pcap
root@VG1:~# ping 1.1.1.2 -c 4
PING 1.1.1.2 (1.1.1.2) 56(84) bytes of data.
64 bytes from 1.1.1.2: icmp_seq=1 ttl=64 time=1128 ms
64 bytes from 1.1.1.2: icmp_seq=2 ttl=64 time=126 ms
64 bytes from 1.1.1.2: icmp_seq=3 ttl=64 time=1.07 ms
64 bytes from 1.1.1.2: icmp_seq=4 ttl=64 time=1.12 ms

--- Estatísticas do ping de 1.1.1.2 ---
4 pacotes transmitidos, 4 recebidos, 0% de perda de pacotes, tempo 3006ms
rtt min/avg/max/mdev = 1.077/314.271/1128.419/472.826 ms, pipe 2

Estatísticas ISAKMP/IPsec:

root@VG1:~# sa_mgr show
Sessões ISAKMP: 0 iniciadas, 0 respondidas

Conexões ISAKMP:
Num Conn-id (Endereço Local, Porta)-(Endereço Remoto, Porta) Estado Enviado Recebido
1 1 (172.16.1.253,500)-(172.16.1.254,500) ativo 1086 1014

Conexões IPsec:
Num Conn-id (Endereço Local, Porta)-(Endereço Remoto, Porta) Protocolo Ação Tipo Enviado Recebido
1 1 (172.16.1.253,*)-(172.16.1.254,*) 47 ESP tunn 480 480

Não há pacotes GRE no dump de tráfego:

1.5 esquemas em IPsec VPN nacional. Testando versões demo

Resultado: o esquema GRE-over-IPsec está funcionando corretamente.

Esquema 1.5: IPsec-over-GRE

Não pretendo usar IPsec-over-GRE na rede. Estou coletando apenas por vontade.

1.5 esquemas em IPsec VPN nacional. Testando versões demo

Para inverter o esquema GRE-over-IPsec, é necessário:

  • Corrigir a lista de acesso para criptografia — tráfego de destino do LAN1 para o LAN2 e vice-versa;
  • Configurar o roteamento através do GRE;
  • Vincular o mapa criptográfico à interface GRE.

Por padrão, não há interface GRE no console semelhante ao Cisco. Ela existe apenas no sistema operacional.

Adicionando a interface GRE ao console semelhante ao Cisco. Para isso, edito o arquivo /etc/ifaliases.cf:

interface (name="FastEthernet0/0" pattern="eth0")
interface (name="FastEthernet0/1" pattern="eth1")
interface (name="FastEthernet0/2" pattern="eth2")
interface (name="FastEthernet0/3" pattern="eth3")
interface (name="Tunnel0" pattern="gre1")
interface (name="default" pattern="*")

onde gre1 é a designação da interface no sistema operacional, Tunnel0 é a designação da interface no console semelhante ao Cisco.

Recalculando o hash do arquivo:

root@VG1:~# integr_mgr calc -f /etc/ifaliases.cf

SUCESSO: A operação foi bem-sucedida.

Agora a interface Tunnel0 apareceu no console semelhante ao Cisco:

VG1# show run
interface Tunnel0
ip address 1.1.1.1 255.255.255.252
mtu 1400

Corrigindo a lista de acesso para criptografia:

VG1(config)#
ip access-list extended LIST
permit ip 192.168.1.0 0.0.0.255 192.168.3.0 0.0.0.255

Configurando o roteamento através do GRE:

VG1(config)#
no ip route 0.0.0.0 0.0.0.0 172.16.1.254
ip route 192.168.3.0 255.255.255.0 1.1.1.2

Removendo o cartão criptográfico de Fa0/0 e vinculando ao interface GRE:

VG1(config)#
interface Tunnel0
crypto map CMAP

Para VG2 é semelhante.

Verifico:

root@VG2:~# tcpdump -i eth0 -w /home/dump3.pcap

root@VG1:~# ping 192.168.2.254 -I 192.168.1.253 -c 4
PING 192.168.2.254 (192.168.2.254) from 192.168.1.253 : 56(84) bytes of data.
64 bytes from 192.168.2.254: icmp_seq=1 ttl=64 time=492 ms
64 bytes from 192.168.2.254: icmp_seq=2 ttl=64 time=1.08 ms
64 bytes from 192.168.2.254: icmp_seq=3 ttl=64 time=1.06 ms
64 bytes from 192.168.2.254: icmp_seq=4 ttl=64 time=1.07 ms

--- 192.168.2.254 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3006ms
rtt min/avg/max/mdev = 1.064/124.048/492.972/212.998 ms

Estatísticas ISAKMP/IPsec:

root@VG1:~# sa_mgr show
ISAKMP sessions: 0 initiated, 0 responded

ISAKMP connections:
Num Conn-id (Endereço Local,Porta)-(Endereço Remoto,Porta) Estado Enviado Recebido
1 2 (172.16.1.253,500)-(172.16.1.254,500) ativo 1094 1022

Conexões IPsec:
Num Conn-id (Endereço Local,Porta)-(Endereço Remoto,Porta) Protocolo Ação Tipo Enviado Recebido
1 2 (192.168.1.0-192.168.1.255,*)-(192.168.2.0-192.168.2.255,*) * ESP tunn 352 352

No dump de tráfego, pacotes ESP encapsulados em GRE:

1.5 esquemas em IPsec VPN nacional. Testando versões demo

Saída: IPsec-over-GRE funciona corretamente.

Resultados

Uma xícara de café foi suficiente. Preparei uma instrução para obter a versão demo. Configurei GRE-over-IPsec e implementei ao contrário.

O mapa de interfaces de rede na versão 4.3 é automático! Continuo testando.

Engenheiro anônimo
t.me/anonimous_engineer

Fonte: habr.com

Compre hospedagem confiável para sites com proteção contra DDoS, servidores VPS VDS 🔥 Compre hospedagem confiável para sites com proteção contra DDoS, servidores VPS VDS | ProHoster