1.5 esquemas em VPN IPsec doméstica. Testando demos





Situação



Recebi uma versão de teste de três meses do C-Terra VPN versão 4.3. Quero descobrir se minha vida de engenheiro se tornará mais fácil depois de atualizar para a nova versão.



Hoje não é difícil, um pacote de café instantâneo 3 em 1 deve ser suficiente. Vou te dizer como obter as demos. Vou tentar reunir os esquemas GRE-over-IPsec e IPsec-over-GRE.



Como obter uma demonstração







A partir da figura, segue para obter uma demonstração de que você precisa:



  • Escreva uma carta para presale@s-terra.ru do endereço corporativo;
  • Na carta, indique o NIF da sua organização;
  • Liste os produtos e suas quantidades.


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



Expanda a imagem



O Security Gateway Demo é uma imagem de máquina virtual. Estou usando o VMWare Workstation. Uma lista completa de hipervisores e ambientes de virtualização com suporte está disponível no site do fornecedor.



Antes de iniciar as etapas ativas, observe que não há interfaces de rede na imagem da máquina virtual padrão:







A lógica é clara, o usuário deve adicionar quantas interfaces precisar. Vou adicionar quatro de uma vez:







agora eu inicio a máquina virtual. Imediatamente após o início, o gateway requer um nome de usuário e uma senha.



C-Terra Gateway possui vários consoles com diferentes contas. Vou contar seu número em um artigo separado. Até então:

Login as: administrator

Password: s-terra


Inicializando o gateway. A inicialização é uma sequência de ações: inserir uma licença, configurar um gerador de números aleatórios biológicos (simulador de teclado - meu registro é de 27 segundos) e criar um mapa de interface de rede.



Placa de interface de rede. Ficou mais facil



A versão 4.2 saudou um usuário ativo com as seguintes mensagens: Um usuário ativo (de acordo com um engenheiro anônimo) é um usuário que pode configurar qualquer coisa rapidamente e sem documentação. Algo deu errado antes mesmo de tentar configurar um endereço IP na interface. É tudo sobre o mapa da interface de rede. Foi necessário fazer: Como resultado, é criado um mapa de interfaces de rede, que contém um mapeamento dos nomes das interfaces físicas (0000: 02: 03.0) e suas designações lógicas no sistema operacional (eth0) e no console semelhante a Cisco (FastEthernet0 / 0): As designações lógicas das interfaces são chamadas de aliases ... Os aliases são armazenados no arquivo /etc/ifaliases.cf.



Starting IPsec daemon….. failed

ERROR: Could not establish connection with daemon












/bin/netifcfg enum > /home/map

/bin/netifcfg map /home/map

service networking restart








#Unique ID iface type OS name Cisco-like name



0000:02:03.0 phye eth0 FastEthernet0/0






Na versão 4.3, o mapa de interface é criado automaticamente quando a máquina virtual é iniciada pela primeira vez. Se você alterar o número de interfaces de rede na máquina virtual, crie o mapa de interface novamente:



/bin/netifcfg enum > /home/map

/bin/netifcfg map /home/map

systemctl restart networking




Figura 1: GRE-over-IPsec



Eu implanto dois gateways virtuais, troco-os conforme mostrado na figura:







Etapa 1. Configurar 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


Verificando 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




Etapa 2. Configurando o GRE



Um exemplo de configuração do GRE é retirado dos scripts oficiais. Crie o arquivo gre1 no diretório /etc/network/interfaces.d com 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


Eu abro a interface no sistema:



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


Eu verifico:



root@VG1:~# ip address show
8: gre1@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> 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


O C-Terra Gateway possui um sniffer de pacotes integrado - tcpdump. Vou despejar o tráfego em um arquivo pcap:



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


Faço ping entre 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 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3006ms
rtt min/avg/max/mdev = 0.850/0.915/0.974/0.043 ms


O túnel GRE está ativo e funcionando:







Etapa 3. Criptografar com GRE GRE



Defina o tipo de identificação - por endereço. Autenticação usando uma chave predefinida (de acordo com os Termos de Uso, você deve usar certificados digitais):



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


Eu defino os parâmetros IPsec Fase I:



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


Eu defino os parâmetros IPsec Fase II:



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


Eu crio uma lista de acesso para criptografia. Tráfego alvo - GRE:



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


Eu crio um mapa criptográfico e o vinculo à 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 VG2, a configuração é espelhada, as diferenças são:



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


Eu 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

--- 1.1.1.2 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 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
ISAKMP sessions: 0 initiated, 0 responded

ISAKMP connections:
Num Conn-id (Local Addr,Port)-(Remote Addr,Port) State Sent Rcvd
1 1 (172.16.1.253,500)-(172.16.1.254,500) active 1086 1014

IPsec connections:
Num Conn-id (Local Addr,Port)-(Remote Addr,Port) Protocol Action Type Sent Rcvd
1 1 (172.16.1.253,*)-(172.16.1.254,*) 47 ESP tunn 480 480


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







Conclusão: O esquema GRE-sobre-IPsec funciona corretamente.



Figura 1.5: IPsec-over-GRE



Não pretendo usar IPsec-over-GRE na rede. Eu coleciono porque quero.







Para implantar o esquema GRE-over-IPsec, ao contrário, você precisa:



  • Corrija a lista de acesso para criptografia - direcione o tráfego de LAN1 para LAN2 e vice-versa;
  • Configure o roteamento via GRE;
  • Desligue o mapa criptográfico na interface GRE.


Por padrão, o console de gateway semelhante ao Cisco não tem uma interface GRE. Ele existe apenas no sistema operacional.



Eu adiciono a interface GRE ao console semelhante a Cisco. Para fazer isso, edite 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 a Cisco.



Eu recalculo o hash do arquivo:



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

SUCCESS:  Operation was successful.


Agora, a interface Tunnel0 apareceu no console semelhante a 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 via 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


Eu removo o mapa criptográfico de Fa0 / 0 e o vinculo à interface GRE:



VG1(config)#
interface Tunnel0
crypto map CMAP


Da mesma forma para VG2.



Eu 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 (Local Addr,Port)-(Remote Addr,Port) State Sent Rcvd
1 2 (172.16.1.253,500)-(172.16.1.254,500) active 1094 1022

IPsec connections:
Num Conn-id (Local Addr,Port)-(Remote Addr,Port) Protocol Action Type Sent Rcvd
1 2 (192.168.1.0-192.168.1.255,*)-(192.168.2.0-192.168.2.255,*) * ESP tunn 352 352


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







Conclusão: IPsec-over-GRE está funcionando corretamente.



Resultado



Uma xícara de café foi o suficiente. Esboçou as instruções sobre como obter a demonstração. Configurou GRE-over-IPsec e implantou ao contrário.



O mapa da interface de rede na versão 4.3 é automático! Estou testando mais.



Engenheiro anônimo

t.me/anonimous_engineer



All Articles