1.5 esquemas en VPN IPsec doméstica. Probar demostraciones

Situación

Recibí una versión de prueba de tres meses de C-Terra VPN versión 4.3. Quiero saber si mi vida como ingeniero será más fácil después de actualizar a la nueva versión.



Hoy no es difícil, un paquete de café instantáneo 3 en 1 debería ser suficiente. Te diré cómo conseguir las demos. Intentaré combinar los esquemas GRE-over-IPsec e IPsec-over-GRE.

Cómo obtener una demostración

De la figura que sigue para obtener una demostración que necesita:

• Escriba una carta a presale@s-terra.ru desde la dirección corporativa;
• En la carta, indique el TIN de su organización;
• Enumere los productos y su cantidad.

Las demostraciones tienen una validez de tres meses. El proveedor no limita su funcionalidad.

Expandir la imagen

La demostración de Security Gateway es una imagen de máquina virtual. Estoy usando VMWare Workstation. Una lista completa de hipervisores y entornos de virtualización compatibles está disponible en el sitio web del proveedor.



Antes de comenzar con los pasos activos, tenga en cuenta que no hay interfaces de red en la imagen de la máquina virtual predeterminada:







la lógica es clara, el usuario debe agregar tantas interfaces como necesite. Agregaré cuatro a la vez:







ahora inicio la máquina virtual. Inmediatamente después de comenzar, la puerta de enlace requiere un nombre de usuario y una contraseña.

C-Terra Gateway tiene varias consolas con diferentes cuentas. Contaré su número en un artículo aparte. Hasta entonces:

Login as: administrator

Password: s-terra

Inicializando la puerta de enlace. La inicialización es una secuencia de acciones: ingresar una licencia, configurar un generador de números aleatorios biológicos (simulador de teclado, mi registro es de 27 segundos) y crear un mapa de interfaz de red.

Tarjeta de interfaz de red. Se hizo más fácil

La versión 4.2 recibió al usuario activo con los siguientes mensajes: Un usuario activo (según el ingeniero anónimo) es un usuario que puede configurar cualquier cosa rápidamente y sin documentación. Algo salió mal, incluso antes de intentar configurar una dirección IP en la interfaz. Se trata del mapa de la interfaz de red. Era necesario hacer: Como resultado, se crea un mapa de interfaz de red, que contiene un 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 similar a Cisco (FastEthernet0 / 0): Las designaciones lógicas de las interfaces se denominan alias ... Los alias se almacenan en el archivo /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





En la versión 4.3, el mapa de interfaz se crea automáticamente cuando la máquina virtual se inicia por primera vez. Si cambia la cantidad de interfaces de red en la máquina virtual, cree el mapa de interfaz nuevamente:



/bin/netifcfg enum > /home/map

/bin/netifcfg map /home/map

systemctl restart networking

Figura 1: GRE sobre IPsec

Implemento dos puertas de enlace virtuales, las cambio como se muestra en la figura:







Paso 1. Configure las direcciones y 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

Comprobación de 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

--- 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. Configuración de GRE



Un ejemplo de configuración de GRE se toma de los scripts oficiales. Cree el archivo gre1 en el directorio /etc/network/interfaces.d con 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

Abro la interfaz en el sistema:

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

Compruebo:

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 tiene un rastreador de paquetes integrado: tcpdump. Volcaré el tráfico en un archivo pcap:

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

Hago 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

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

El túnel GRE está activo y en funcionamiento:







Paso 3. Cifrar con GRE GRE



Establecer el tipo de identificación, por dirección. Autenticación mediante una clave predefinida (de acuerdo con los Términos de uso, debe utilizar certificados digitales):

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

Configuré los parámetros de la fase I de IPsec:

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

Configuré los parámetros para IPsec Phase II:

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

Creo una 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

Creo un mapa criptográfico y lo vinculo 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 se refleja, las diferencias 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

Compruebo:

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

Estadísticas de 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

No hay paquetes en el volcado de tráfico GRE:







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

Figura 1.5: IPsec sobre GRE

No planeo utilizar IPsec-over-GRE en la red. Cobro porque quiero.







Para implementar el esquema GRE-over-IPsec por el contrario, necesita:

• Arregle la lista de acceso para el cifrado - tráfico de destino de LAN1 a LAN2 y viceversa;
• Configurar el enrutamiento a través de GRE;
• Cuelgue el mapa de cifrado en la interfaz GRE.

De forma predeterminada, la consola de puerta de enlace similar a Cisco no tiene una interfaz GRE. Solo existe en el sistema operativo.



Agrego la interfaz GRE a la consola tipo Cisco. Para hacer esto, edite 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 interfaz en el sistema operativo, Tunnel0 es la designación de interfaz en la consola similar a Cisco.



Calculo el hash del archivo:

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

SUCCESS:  Operation was successful.

Ahora la interfaz Tunnel0 ha aparecido en la consola similar a Cisco:

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

Corrección de 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

Configuración de 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

Elimino el mapa criptográfico de Fa0 / 0 y lo vinculo a la interfaz GRE:

VG1(config)#
interface Tunnel0
crypto map CMAP

Lo mismo ocurre con VG2.



Compruebo:

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

Estadísticas de 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

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







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

Salir

Una taza de café fue suficiente. Esbozó las instrucciones sobre cómo obtener la demostración. Configuré GRE-over-IPsec y se implementó al revés.



¡El mapa de la interfaz de red en la versión 4.3 es automático! Estoy probando más.



Ingeniero anónimo

t.me/anonimous_engineer