🥇1.5 esquemas en VPN IPsec nacional. Pruebo versiones de demostración

Situación

Recibí una versión de demostración de los productos de C-Terra VPN versión 4.3 por tres meses. Quiero averiguar si mi vida de ingeniero será más fácil después de pasar a la nueva versión.

Hoy no es difícil, un paquete de café soluble 3 en 1 debería ser suficiente. explicaré cómo obtener versiones de demostración. Intentaré recopilar esquemas GRE-over-IPsec e IPsec-over-GRE.

Cómo obtener una versión de demostración

Del diagrama se deduce que para obtener una versión de demostración es necesario:

Enviar un correo a presale@s-terra.ru desde una dirección corporativa;
En el correo indicar el NIF de su organización;
Enumerar los productos y su cantidad.

Las versiones de demostración son válidas por tres meses. El proveedor no limita su funcionalidad.

Despliego la imagen

La versión de demostración del gateway de seguridad es una imagen de máquina virtual. Estoy utilizando VMWare Workstation. La lista completa de hipervisor y entornos de virtualización compatibles está disponible en el sitio del proveedor.

Antes de comenzar acciones activas, tenga en cuenta que en la imagen de la máquina virtual por defecto no hay interfaces de red:

La lógica es clara, el usuario debe añadir tantas interfaces como necesite. Añadiré cuatro de inmediato:

Ahora inicio la máquina virtual. Justo después de iniciar, el gateway requiere un nombre de usuario y una contraseña.

En C-Terra Gateway hay varias consolas con diferentes cuentas. Contaré su número en un artículo separado. Pero por ahora:
Iniciar sesión como: administrador Contraseña: s-terra

Inicializo el gateway. La inicialización es una secuencia de acciones: ingresar la licencia, configurar un generador biológico de números aleatorios (el simulador de teclado – mi récord es 27 segundos) y crear un mapa de interfaces de red.

Mapa de interfaces de red. Ha sido más fácil.

La versión 4.2 saludaba al usuario activo con mensajes:

Iniciando el daemon IPsec….. fallido ERROR: No se pudo establecer conexión con el daemon

El usuario activo (según un ingeniero anónimo) es un usuario capaz de configurar cualquier cosa de manera rápida y sin documentación.

Algo iba mal, incluso antes de intentar configurar la dirección IP en la interfaz. Todo se debe al mapa de interfaces de red. Debía realizar las siguientes acciones:

/bin/netifcfg enum > /home/map /bin/netifcfg map /home/map reiniciar el servicio de red

Como resultado, se crea un mapa de interfaces de red que contiene el mapeo de los nombres de las interfaces físicas (0000:02:03.0) y sus designaciones lógicas en el sistema operativo (eth0) y la consola tipo Cisco (FastEthernet0/0):

#Unique ID iface type OS name Cisco-like name

0000:02:03.0 phye eth0 FastEthernet0/0

Las designaciones lógicas de las interfaces se llaman alias. Los alias se almacenan en el archivo /etc/ifaliases.cf.
En la versión 4.3, al iniciar la máquina virtual por primera vez, se crea automáticamente el mapa de interfaces. Si cambias la cantidad de interfaces de red en la máquina virtual, por favor crea el mapa de interfaces nuevamente:

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

Esquema 1: GRE sobre IPsec

Despliego dos gateways virtuales, conectando como se muestra en la imagen:

Paso 1. Configuro direcciones IP y rutas

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 la conectividad 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

--- Estadísticas de ping 172.16.1.254 ---
4 paquetes transmitidos, 4 recibidos, 0% de pérdida de paquetes, tiempo 3005ms
rtt min/avg/max/mdev = 0.273/0.540/0.687/0.164 ms

Paso 2. Configuro GRE

Tomo el ejemplo de configuración de GRE de los guiones oficiales. Creo el archivo gre1 en el directorio /etc/network/interfaces.d con el contenido.

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

Levanto la interfaz en el 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

En el Gate de C-Terra hay un sniffer de paquetes integrado: tcpdump. Grabo el tráfico en un archivo pcap:

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

Inicio ping entre las 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

--- Estadísticas de ping 1.1.1.2 ---
4 paquetes transmitidos, 4 recibidos, 0% de pérdida de paquetes, tiempo 3006ms
rtt min/avg/max/mdev = 0.850/0.915/0.974/0.043 ms

El túnel GRE está activo y funcionando:

Paso 3. Ciframos GRE con GOST

Establezco el tipo de identificación – por dirección. Autenticación con clave predefinida (según las Normas de Uso se deben utilizar certificados digitales):

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

Estableciendo parámetros de IPsec Fase I:

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

Estableciendo parámetros de IPsec Fase II:

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

Creando lista de acceso para cifrado. Tráfico objetivo — GRE:

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

Creando un mapa criptográfico y vinculándolo a la interfaz 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, la configuración es simétrica, diferencias:

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

--- 1.1.1.2 estadísticas de ping ---
4 paquetes transmitidos, 4 recibidos, 0% de pérdida de paquetes, tiempo 3006ms
rtt min/avg/max/mdev = 1.077/314.271/1128.419/472.826 ms, pipe 2

Estadísticas de ISAKMP/IPsec:

root@VG1:~# sa_mgr show
Sesiones ISAKMP: 0 iniciadas, 0 respondidas

Conexiones ISAKMP:
Num Conn-id (Dirección Local,Puerto)-(Dirección Remota,Puerto) Estado Enviado Recibido
1 1 (172.16.1.253,500)-(172.16.1.254,500) activo 1086 1014

Conexiones IPsec:
Num Conn-id (Dirección Local,Puerto)-(Dirección Remota,Puerto) Protocolo Acción Tipo Enviado Recibido
1 1 (172.16.1.253,*)-(172.16.1.254,*) 47 ESP tunn 480 480

En el volcado de tráfico no hay paquetes GRE:

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

Esquema 1.5: IPsec-over-GRE

No planeo utilizar IPsec-over-GRE en la red. Estoy configurando porque lo deseo.

Para desplegar el esquema GRE-over-IPsec al revés necesito:

Corregir la lista de acceso para cifrado — tráfico objetivo de LAN1 a LAN2 y viceversa;
Configurar el enrutamiento a través de GRE;
Vincular el mapa criptográfico a la interfaz GRE.

Por defecto, en la consola tipo Cisco del gateway no hay interfaz GRE. Solo existe en el sistema operativo.

Agregando la interfaz GRE a la consola tipo Cisco. Para esto, edito el archivo /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="*")

donde gre1 es la designación de la interfaz en el sistema operativo, Tunnel0 es la designación de la interfaz en la consola tipo Cisco.

Recalculando el hash del archivo:

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

ÉXITO: La operación fue exitosa.

Ahora la interfaz Tunnel0 apareció en la consola tipo Cisco:

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

Corrigiendo la lista de acceso para 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

Configurando el enrutamiento 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

Retiro la tarjeta criptográfica del Fa0/0 y la vinculo a la interfaz GRE:

VG1(config)#
interface Tunnel0
crypto map CMAP

Para VG2 es lo mismo.

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) desde 192.168.1.253: 56(84) bytes de datos.
64 bytes desde 192.168.2.254: icmp_seq=1 ttl=64 tiempo=492 ms
64 bytes desde 192.168.2.254: icmp_seq=2 ttl=64 tiempo=1.08 ms
64 bytes desde 192.168.2.254: icmp_seq=3 ttl=64 tiempo=1.06 ms
64 bytes desde 192.168.2.254: icmp_seq=4 ttl=64 tiempo=1.07 ms

--- estadísticas de ping de 192.168.2.254 ---
4 paquetes transmitidos, 4 recibidos, 0% pérdida de paquetes, tiempo 3006ms
rtt min/prom/max/mdev = 1.064/124.048/492.972/212.998 ms

Estadísticas de ISAKMP/IPsec:

root@VG1:~# sa_mgr show
Sesiones ISAKMP: 0 iniciadas, 0 respondidas

Conexiones ISAKMP:
Num Conn-id (Dirección Local,Puerto)-(Dirección Remota,Puerto) Estado Enviado Recibido
1 2 (172.16.1.253,500)-(172.16.1.254,500) activa 1094 1022

Conexiones IPsec:
Num Conn-id (Dirección Local,Puerto)-(Dirección Remota,Puerto) Protocolo Acción Tipo Enviado Recibido
1 2 (192.168.1.0-192.168.1.255,*)-(192.168.2.0-192.168.2.255,*) * ESP tunel 352 352

En el volcado de tráfico, paquetes ESP encapsulados en GRE:

Salida: IPsec sobre GRE funciona correctamente.