Esquemas 1.5 en VPN IPsec doméstica. Demos de proba

A situación

Recibín unha versión de demostración dos produtos VPN C-Terra versión 4.3 durante tres meses. Quero saber se a miña vida de enxeñeiro será máis fácil despois de cambiar á nova versión.

Hoxe non é difícil, unha bolsa de café instantáneo 3 en 1 debería ser suficiente. Vouche dicir como conseguir demostracións. Intentarei construír os esquemas GRE-sobre-IPsec e IPsec-sobre-GRE.

Como conseguir unha demo

Da figura despréndese que para obter unha demostración cómpre:

• Escribe unha carta a [protexido por correo electrónico] desde un enderezo corporativo;
• Na carta, indique o TIN da súa organización;
• Enumera os produtos e as súas cantidades.

As demostracións son válidas durante tres meses. O vendedor non limita a súa funcionalidade.

Ampliando a imaxe

A demostración de Security Gateway é unha imaxe de máquina virtual. Estou usando VMWare Workstation. No sitio web do provedor está dispoñible unha lista completa de hipervisores e contornos de virtualización compatibles.

Antes de comezar, teña en conta que non hai interfaces de rede na imaxe da máquina virtual predeterminada:

A lóxica é clara, o usuario debe engadir tantas interfaces como necesite. Engadirei catro á vez:

Agora inicio a máquina virtual. Inmediatamente despois do lanzamento, a pasarela require un nome de usuario e un contrasinal.

Hai varias consolas en S-Terra Gateway con diferentes contas. Contarei o seu número nun artigo separado. Por agora:
Login as: administrator
Password: s-terra

Estou inicializando a pasarela. A inicialización é unha secuencia de accións: introducir unha licenza, configurar un xerador de números aleatorios biolóxicos (simulador de teclado: o meu rexistro é de 27 segundos) e crear un mapa de interface de rede.

Mapa de interfaces de rede. Fíxose máis doado

A versión 4.2 saudou ao usuario activo con mensaxes:

Starting IPsec daemon….. failed
ERROR: Could not establish connection with daemon

Un usuario activo (segundo un enxeñeiro anónimo) é un usuario que pode configurar calquera cousa rapidamente e sen documentación.

Algo estaba a fallar antes de tentar configurar un enderezo IP na interface. Trátase do mapa da interface de rede. Era necesario facer:

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

Como resultado, créase un mapa de interface de rede que contén a asignación de nomes de interface física (0000:02:03.0) e as súas designacións lóxicas no sistema operativo (eth0) e na consola tipo Cisco (FastEthernet0/0):

#Unique ID iface type OS name Cisco-like name

0000:02:03.0 phye eth0 FastEthernet0/0

As designacións lóxicas das interfaces chámanse alias. Os alias gárdanse no ficheiro /etc/ifaliases.cf.
Na versión 4.3, cando se inicia a máquina virtual, créase automaticamente un mapa de interface. Se cambia o número de interfaces de rede na máquina virtual, recrea o mapa de interfaces:

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

Escenario 1: GRE sobre IPsec

Imprego dúas pasarelas virtuais, cambio como se mostra na figura:

Paso 1. Configura enderezos e rutas IP

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

Comprobando 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

Paso 2: configurar GRE

Tomo un exemplo de configuración de GRE a partir de guións oficiais. Creo un ficheiro gre1 no directorio /etc/network/interfaces.d cos contidos.

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

Levo a interface no sistema:

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

Comprobación:

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

C-Terra Gateway ten un detector de paquetes integrado - tcpdump. Vou escribir un volcado de tráfico nun ficheiro pcap:

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

Comezo a facer 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á en funcionamento:

Paso 3. Cifrar con GOST GRE

Definei o tipo de identificación: por enderezo. Autenticación cunha clave predefinida (segundo as Condicións de uso, débense utilizar certificados dixitais):

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

Establecei os parámetros IPsec Phase I:

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

Establecei os parámetros IPsec Phase II:

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

Creo unha lista de acceso para o cifrado. Tráfico dirixido - GRE:

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

Creo un mapa criptográfico e uno á 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 configuración é espellada, as diferenzas son:

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

Comprobación:

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

Non hai paquetes no volcado de tráfico GRE:

Conclusión: o esquema GRE sobre IPsec funciona correctamente.

Figura 1.5: IPsec sobre GRE

Non penso usar IPsec-over-GRE na rede. Colecciono porque quero.

Para implementar o esquema GRE sobre IPsec ao revés:

• Corrixir a lista de acceso de cifrado: tráfico dirixido de LAN1 a LAN2 e viceversa;
• Configurar o enrutamento a través de GRE;
• Colgar un criptomapa na interface GRE.

De forma predeterminada, non hai unha interface GRE na consola de pasarela tipo Cisco. Existe só no sistema operativo.

Engado a interface GRE á consola tipo Cisco. Para iso, edito o ficheiro /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 designación da interface no sistema operativo, Tunnel0 é a designación da interface na consola tipo Cisco.

Recalculo o hash do ficheiro:

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

SUCCESS:  Operation was successful.

Agora apareceu a interface Tunnel0 na consola tipo Cisco:

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

Corrixindo a lista de acceso para o cifrado:

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

Configuro o enrutamento a través de 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

Quito o criptomapa de Fa0 / 0 e únoo á interface GRE:

VG1(config)#
interface Tunnel0
crypto map CMAP

Para VG2 é semellante.

Comprobación:

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 volcado de tráfico ESP, os paquetes encapsulados en GRE:

Conclusión: IPsec-over-GRE funciona correctamente.

Resultados de

Unha cunca de café foi suficiente. Esbocei instrucións para obter unha versión de demostración. Configurado GRE sobre IPsec e despregado viceversa.

O mapa de interfaces de rede na versión 4.3 é automático! Estou probando máis.

Enxeñeiro anónimo
t.me/enxeñeiro_anónimo

Fonte: www.habr.com