Configurar IPsec VPN (puerta de enlace a puerta de enlace) mediante Strongswan
Strongswan admite los tipos de VPN Gateway-to-Gateway (sitio a sitio) y Road warrior. En el primer tipo, el tráfico de red se cifra / descifra en la puerta de enlace (entrada / salida) de una organización. Sin embargo, en el caso de Road warrior, el tráfico se cifra desde el cliente final (máquina) hasta la puerta de enlace remota.
En este artículo, explicaremos la creación de un túnel entre dos sitios de una organización para asegurar la comunicación. La ubicación del servidor / puerta de enlace VPN basada en Strongswan se muestra en la siguiente figura. Queremos asegurar la comunicación entre las redes de organización 10.1.0.0/16 y 11.1.0.0/16.
Como se muestra en la figura anterior, estamos interesados en asegurar la comunicación de A a B y viceversa. Es importante asegurarse de que el enrutamiento de Puertas de enlace VPN basadas en Strongswan en la red de la organización. Suponemos que la máquina de la oficina A puede hacer ping a una máquina en la red de la oficina B. Esto garantizará la conectividad de los dispositivos en la red.
En nuestro anterior, hemos instalado el strongswan en la máquina virtual. Sin embargo, en el entorno de producción, strongswan se instala en el hardware para un mejor rendimiento. En este artículo, usamos VM para mostrar la creación del túnel entre dos sitios.
De forma predeterminada, la configuración de strongswan está en / usr / local / etc / directorio que se muestra en la siguiente figura.
Túnel de puerta de enlace a puerta de enlace (clave precompartida)
En este túnel, estamos usando un secreto compartido entre dos máquinas. Estos secretos compartidos utilizados por el algoritmo Diffie-Hellman para la autenticación mutua antes de compartir la clave para el algoritmo de cifrado simétrico.
Configuración de Stronswan en la máquina local (izquierda) (lado A)
Ipsec.conf es el archivo de configuración principal de strongswan. En este archivo, definimos parámetros de política para el túnel como algoritmos de cifrado, algoritmo hash, etc.
config setup charondebug="all" uniqueids=yes strictcrlpolicy=no conn %default conn tunnel # left=192.168.1.10 leftsubnet=10.1.0.0/16 right=192.168.1.11 rightsubnet=11.1.0.0/16 ike=aes256-sha2_256-modp1024! esp=aes256-sha2_256! keyingtries=0 ikelifetime=1h lifetime=8h dpddelay=30 dpdtimeout=120 dpdaction=clear authby=secret auto=start keyexchange=ikev2 type=tunnel
El archivo ipsec.secrets contiene la información secreta, como la clave compartida, el pin de las tarjetas inteligentes y la contraseña de la clave privada, etc. En nuestro caso, la clave precompartida entre A y B es secreto compartido
192.168.1.10 192.168.1.11 : PSK 'sharedsecret'
Configuración de Strongswan en la máquina remota (derecha) (lado B)
config setup charondebug="all" uniqueids=yes strictcrlpolicy=no conn %default conn tunnel # left=192.168.1.11 leftsubnet=11.1.0.0/16 right=192.168.1.10 rightsubnet=10.1.0.0/16 ike=aes256-sha2_256-modp1024! esp=aes256-sha2_256! keyingtries=0 ikelifetime=1h lifetime=8h dpddelay=30 dpdtimeout=120 dpdaction=clear authby=secret auto=start keyexchange=ikev2 type=tunnel
y el contenido de ipsec.secrets del sitio remoto es
192.168.1.11 192.168.1.10 : PSK 'sharedsecret'
Después de los cambios en ambos lados, ejecute el siguiente comando para la creación del túnel.
# ipsec restart
Para verificar el estado del túnel en ambas máquinas, ejecute el siguiente comando en la terminal. La salida del comando para la máquina local y remota se muestra a continuación.
#ipsec statusall
Salida de ipsec statusall en VM A
Status of IKE charon daemon (strongSwan 5.2.1, Linux 3.13.0-24-generic, x86_64):
uptime: 8 minutes, since Jan 03 13:44:32 2015
malloc: sbrk 1351680, mmap 0, used 250048, free 1101632
worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 5
loaded plugins: charon pkcs11 aes des rc2 sha1 sha2 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem fips-prf gmp xcbc cmac hmac attr kernel-netlink resolve socket-default stroke updown xauth-generic
Listening IP addresses:
192.168.1.10
Connections:
tunnel: 192.168.1.10...192.168.1.11 IKEv2, dpddelay=30s
tunnel: local: [192.168.1.10] uses pre-shared key authentication
tunnel: remote: [192.168.1.11] uses pre-shared key authentication
tunnel: child: 10.1.0.0/16 === 11.1.0.0/16 TUNNEL, dpdaction=clear
Security Associations (1 up, 0 connecting):
tunnel[1]: ESTABLISHED 8 minutes ago, 192.168.1.10[192.168.1.10]...192.168.1.11[192.168.1.11]
tunnel[1]: IKEv2 SPIs: cafdf24210e8e503_i* 7ee6557a1d297e35_r, pre-shared key reauthentication in 25 minutes
tunnel[1]: IKE proposal: AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024
tunnel{1}: INSTALLED, TUNNEL, ESP SPIs: cbd51ed8_i c7243b49_o
tunnel{1}: AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 0 bytes_o, rekeying in 7 hours
tunnel{1}: 10.1.0.0/16 === 11.1.0.0/16
Salida de ipsec statusall en VM B
Status of IKE charon daemon (strongSwan 5.2.1, Linux 3.13.0-24-generic, x86_64):
uptime: 6 minutes, since Jan 03 13:44:21 2015
malloc: sbrk 1351680, mmap 0, used 250944, free 1100736
worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 8
loaded plugins: charon pkcs11 aes des rc2 sha1 sha2 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem fips-prf gmp xcbc cmac hmac attr kernel-netlink resolve socket-default stroke updown xauth-generic
Listening IP addresses:
192.168.1.11
Connections:
tunnel: 192.168.1.11...192.168.1.10 IKEv2, dpddelay=30s
tunnel: local: [192.168.1.11] uses pre-shared key authentication
tunnel: remote: [192.168.1.10] uses pre-shared key authentication
tunnel: child: 11.1.0.0/16 === 10.1.0.0/16 TUNNEL, dpdaction=clear
Security Associations (1 up, 0 connecting):
tunnel[3]: ESTABLISHED 6 minutes ago, 192.168.1.11[192.168.1.11]...192.168.1.10[192.168.1.10]
tunnel[3]: IKEv2 SPIs: cafdf24210e8e503_i 7ee6557a1d297e35_r*, pre-shared key reauthentication in 36 minutes
tunnel[3]: IKE proposal: AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024
tunnel{3}: INSTALLED, TUNNEL, ESP SPIs: c7243b49_i cbd51ed8_o
tunnel{3}: AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 0 bytes_o, rekeying in 7 hours
tunnel{3}: 11.1.0.0/16 === 10.1.0.0/16
El comando ip con el parámetro xfrm se puede utilizar para ver las políticas y los estados del túnel ipsec en la caja de Linux. Salida del comando estados ip xfrm en ambos dispositivos se muestra a continuación.
Salida del comando ip xfrm state en la VM A
src 192.168.1.10 dst 192.168.1.11 proto esp spi 0xc7243b49 reqid 1 mode tunnel replay-window 32 flag af-unspec auth-trunc hmac(sha256) 0x3077c888d622b899532a5f1b8e9399efe65684ffa694bf072ea4de8a44898b2f 128 enc cbc(aes) 0x8fafb23d824c1e898dc42f6d59b14c52e6a33b2183c0c9c762de8cacfd355a6f src 192.168.1.11 dst 192.168.1.10 proto esp spi 0xcbd51ed8 reqid 1 mode tunnel replay-window 32 flag af-unspec auth-trunc hmac(sha256) 0x50b63121299e97339cf2a78bb86b958ae0c3e594b1c535a0a12ce0a165d4e0ef 128 enc cbc(aes) 0x41447fea3021a3b13838f076dbe72139389be93960a641664bb7e1e6fc34b01a
Salida del comando ip xfrm state en VM B
src 192.168.1.11 dst 192.168.1.10 proto esp spi 0xcbd51ed8 reqid 3 mode tunnel replay-window 32 flag af-unspec auth-trunc hmac(sha256) 0x50b63121299e97339cf2a78bb86b958ae0c3e594b1c535a0a12ce0a165d4e0ef 128 enc cbc(aes) 0x41447fea3021a3b13838f076dbe72139389be93960a641664bb7e1e6fc34b01a src 192.168.1.10 dst 192.168.1.11 proto esp spi 0xc7243b49 reqid 3 mode tunnel replay-window 32 flag af-unspec auth-trunc hmac(sha256) 0x3077c888d622b899532a5f1b8e9399efe65684ffa694bf072ea4de8a44898b2f 128 enc cbc(aes) 0x8fafb23d824c1e898dc42f6d59b14c52e6a33b2183c0c9c762de8cacfd355a6f
Como se muestra en la figura, el comando XFRM muestra información confidencial (claves). Por lo tanto, evite estos comandos en el servidor de producción strongswan.