Estoy intentando configurar un túnel VPN usando StrongSwan 5.1.2 entre dos instancias Amazon AWS EC2 que ejecutan Ubuntu 14.04.2 LTS. Antes de usar StrongSwan, usé open(libre)swan en una AMI de Amazon RedHat, que funcionó bien. Por alguna razón ni siquiera puedo conseguir que IKE trabaje aquí para StrongSwan. Revisé tres veces mis configuraciones de AWS y todo se ve bien, por lo que debe ser un problema con la configuración de StrongSwan.
Como verá a continuación, el error que recibo es"Error al escribir en el socket: argumento no válido". He buscado en línea y realmente no puedo encontrar la solución a esto. Estoy convencido de que mi strongswan ipsec.conf no está configurado correctamente.
Esto es con lo que estoy trabajando:
Instance #1: N.Virginia - 10.198.0.164 with public EIP 54.X.X.X
Instance #2: Oregon - 10.194.0.176 with public EIP 52.Y.Y.Y
La topología (simple) es la siguiente:
[ Instance #1 within N.Virginia VPC <-> Public internet <-> Instance #2 within Oregon VPC ]
Verifiqué que las siguientes configuraciones de AWS son correctas:
Security groups permit all
IP information is correct
Src/Dest disabled on both instances
ACLs permit all
routes are present and correct (route to 10.x will point to that local instance in order to be routed out to the VPN tunnel)
abajo esta el/etc/ipsec.conf (Esto es de Oregón, sin embargo, es lo mismo en la instancia de N.Virginia excepto que los valores izquierda|derecha están invertidos):
config setup
charondebug="dmn 2, mgr 2, ike 2, chd 2, job 2, cfg 2, knl 2, net 2, enc 2, lib 2"
conn aws1oexternal-aws1nvexternal
left=52.Y.Y.Y (EIP)
leftsubnet=10.194.0.0/16
right=54.X.X.X (EIP)
rightsubnet=10.198.0.0/16
auto=start
authby=secret
type=tunnel
mobike=no
dpdaction=restart
A continuación se muestra el /etc/ipsec.secrets * (obviamente, al revés para otros casos):
54.X.X.X 52.Y.Y.Y : PSK "Key_inserted_here"
A continuación se muestra /etc/strongswan.conf:
charon {
load_modular = yes
plugins {
include strongswan.d/charon/*.conf
}
}
A continuación se muestra /etc/sysctl.conf:
net.ipv4.ip_forward=1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
Aquí está el resultado de depuración de /var/log/syslogParece que el problema aquí es "error al escribir en el socket: argumento no válido; después de todo lo que intenté, sigo recibiendo el mismo error:
Jun 17 17:34:48 ip-10-198-0-164 charon: 13[IKE] retransmit 5 of request with message ID 0
Jun 17 17:34:48 ip-10-198-0-164 charon: 13[NET] sending packet: from 54.X.X.X[500] to 52.Y.Y.Y[500] (1212 bytes)
Jun 17 17:34:48 ip-10-198-0-164 charon: 03[JOB] next event in 75s 581ms, waiting]
Jun 17 17:34:48 ip-10-198-0-164 charon: 16[NET] sending packet: from 54.X.X.X[500] to 52.Y.Y.Y[500]
Jun 17 17:34:48 ip-10-198-0-164 charon: 13[MGR] checkin IKE_SA aws1vexternal-aws1oexternal[1]
Jun 17 17:34:48 ip-10-198-0-164 charon: 13[MGR] check-in of IKE_SA successful.
Jun 17 17:34:48 ip-10-198-0-164 charon: 16[NET] error writing to socket: Invalid argument
Jun 17 17:36:04 ip-10-198-0-164 charon: 03[JOB] got event, queuing job for execution
Jun 17 17:36:04 ip-10-198-0-164 charon: 03[JOB] no events, waiting
Jun 17 17:36:04 ip-10-198-0-164 charon: 08[MGR] checkout IKE_SA
Jun 17 17:36:04 ip-10-198-0-164 charon: 08[MGR] IKE_SA aws1vexternal-aws1oexternal[1] successfully checked out
Jun 17 17:36:04 ip-10-198-0-164 charon: 08[IKE] giving up after 5 retransmits
Jun 17 17:36:04 ip-10-198-0-164 charon: 08[IKE] establishing IKE_SA failed, peer not responding
Jun 17 17:36:04 ip-10-198-0-164 charon: 08[MGR] checkin and destroy IKE_SA aws1vexternal-aws1oexternal[1]
Jun 17 17:36:04 ip-10-198-0-164 charon: 08[IKE] IKE_SA aws1vexternal-aws1oexternal[1] state change: CONNECTING => DESTROYING
Jun 17 17:36:04 ip-10-198-0-164 charon: 08[MGR] check-in and destroy of IKE_SA successful
A continuación se muestra lo que he probado hasta ahora:
1) Capa verificada 3
2) máquinas reiniciadas
3) Intenté agregar leftid =
4) Intenté actualizar ipsec y luego reiniciar ipsec
5) Intenté agregar nat_traversal=yes en la configuración de configuración (tenga en cuenta que esto no debería importar ya que el estado de ipsec se verifica usando IKEv2, que según la documentación usa automáticamente nat_traversal)
6) Intenté omitir virtual_private <-- Se usó de acuerdo con la documentación de AWS openswan, así que lo incluí en la configuración de strongswan.
7) Intenté deshabilitar net.ipv4.conf.all.send_redirects = 0 y net.ipv4.conf.all.accept_redirects = 0 en /etc/sysctl.conf
8) Intenté utilizar IP privada en lugar de EIP. Ya no recibo el error de socket, sin embargo, obviamente las dos IP no pueden comunicarse entre sí para conectarse...
9) Intenté agregar esto a strongswan.conf: load = aes des sha1 sha2 md5 gmp random nonce hmac Stroke kernel-netlink socket-default updown
10) Intenté usar leftfirewall=sí, no funcionó
¡Por favor ayuda! ¡Gracias!
EDITAR #1:
La respuesta de Michael solucionó el problema original; sin embargo, tengo un nuevo problema relacionado con el enrutamiento. Ambas instancias de VPN no pueden hacer ping entre sí. Además, cuando intento hacer ping desde una instancia aleatoria en cualquier subred, ya sea a otra instancia aleatoria o a la instancia VPN del extremo remoto, obtengo la siguiente respuesta de ping:
root@ip-10-194-0-80:~# ping 10.198.0.164
PING 10.198.0.164 (10.198.0.164) 56(84) bytes of data.
From 10.194.0.176: icmp_seq=1 Redirect Host(New nexthop: 10.194.0.176)
From 10.194.0.176: icmp_seq=2 Redirect Host(New nexthop: 10.194.0.176)
From 10.194.0.176: icmp_seq=3 Redirect Host(New nexthop: 10.194.0.176)
From 10.194.0.176: icmp_seq=4 Redirect Host(New nexthop: 10.194.0.176)
Obviamente, esto debe ser un problema de enrutamiento entre las dos instancias de VPN (probablemente debido a la configuración de strongswan o a la tabla de enrutamiento de instancias), ya que el host 10.194.0.80 en la subred de Oregon puede recibir una respuesta de la instancia de VPN de Oregon. Tabla de rutas + traceroute en la instancia:
root@ip-10-194-0-80:~# netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
0.0.0.0 10.194.0.1 0.0.0.0 UG 0 0 0 eth0
10.194.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
root@ip-10-194-0-80:~# traceroute 10.198.0.164
traceroute to 10.198.0.164 (10.198.0.164), 30 hops max, 60 byte packets
1 10.194.0.176 (10.194.0.176) 0.441 ms 0.425 ms 0.409 ms^C
Cuando usaba openswan, no era necesario realizar modificaciones manuales en la tabla de enrutamiento de cada instancia.
Aquí está la tabla de enrutamiento de la instancia de VPN de Oregon:
root@ip-10-194-0-176:~# netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
0.0.0.0 10.194.0.1 0.0.0.0 UG 0 0 0 eth0
10.194.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
Estoy un poco perplejo.
EDITAR #2:
Parece que el enrutamiento entre las instancias de VPN podría no ser el problema: /var/log/syslog muestra los paquetes que se reciben desde la IP pública de una instancia de VPN a la otra instancia de VPN.
Jun 23 19:57:49 ip-10-194-0-176 charon: 10[NET] received packet: from 54.X.X.X[4500] to 10.194.0.176[4500] (76 bytes)
Parece que es un problema relacionado con las asociaciones de seguridad infantil:
aws1oexternal-aws1nvexternal: child: 10.194.0.0/16 === 10.198.0.0/16 TUNNEL, dpdaction=restart
Security Associations (1 up, 0 **connecting**):
/var/log/syslog:
Jun 23 19:52:19 ip-10-194-0-176 charon: 02[IKE] failed to establish CHILD_SA, keeping IKE_SA
Jun 23 19:52:48 ip-10-194-0-176 charon: 11[IKE] queueing CHILD_CREATE task
Jun 23 19:52:48 ip-10-194-0-176 charon: 11[IKE] activating CHILD_CREATE task
Jun 23 19:52:48 ip-10-194-0-176 charon: 06[IKE] establishing CHILD_SA aws1oexternal-aws1nvexternal
Jun 23 19:52:48 ip-10-194-0-176 charon: 10[IKE] received FAILED_CP_REQUIRED notify, no CHILD_SA built
Jun 23 19:52:48 ip-10-194-0-176 charon: 10[IKE] failed to establish CHILD_SA, keeping IKE_SA
Jun 23 19:52:49 ip-10-194-0-176 charon: 14[CFG] looking for a child config for 10.194.0.0/16 === 10.198.0.0/16
Jun 23 19:52:49 ip-10-194-0-176 charon: 14[CFG] found matching child config "aws1oexternal-aws1nvexternal" with prio 10
Jun 23 19:52:49 ip-10-194-0-176 charon: 14[IKE] configuration payload negotiation failed, no CHILD_SA built
Jun 23 19:52:49 ip-10-194-0-176 charon: 14[IKE] failed to establish CHILD_SA, keeping IKE_SA
***EDICIÓN n.° 3: Problema resuelto (uhh, en realidad consulte la EDICIÓN n.° 4 a continuación...)****
Problema fijo.
1) No seguí correctamente las instrucciones de configuración de Michael. También configuré un rightsourceip y un leftsourceip juntos, lo que provocó que ambas instancias creyeran que ambas eran iniciadores. Me aseguré de que uno fuera el iniciador y el otro el solicitante; esto solucionó el problema de IKE.
2) Descubrí que también tenía que configurar explícitamente el parámetro esp. Aunque ya existe un valor predeterminado (aes128-sha1,3des-sha1), el parámetro esp aún debe configurarse para que la instancia sepa usar esp O ah (pero no ambos). Terminé usando aes128-sha1-modp2048.
¡Espero que esta publicación ayude al próximo novato de Linux a configurar esto!
¡Salud!
EDITAR #4: Problema (no realmente) resuelto
Mientras solucionaba un problema separado relacionado con strongswan, cambié el parámetro "leftfirewall", lo probé, no solucioné mi problema separado y luego volví a la configuración original de antemano (comenté leftfirewall). Entonces me di cuenta de que ahora no podía cruzar el túnel. Después de volverme loco durante horas tratando de descubrir qué pasó, comenté el parámetro esp para ver qué pasaba: ¡AHORA PUEDO HACER PING A TRAVÉS DEL TÚNEL OTRA VEZ! <- entonces, existe la posibilidad de que haya algunos fantasmas de ipsec corriendo por ahí engañándome y que el parámetro esp no sea realmente la solución para los errores TS_UNACCEPTABLE (aunque otros recursos en línea afirman que el parámetro esp es la solución...)
EDITAR #5: Problema completamente resuelto
Terminé trasladando todo a un entorno de prueba y comenzando desde cero. Lo instalé desde la fuente usando la última versión (5.3.2) en lugar de la versión anterior que estaba en el repositorio de Ubuntu (5.1.2). Esto solucionó el problema que tenía arriba y verificó la conectividad de la capa 7 usando netcat (¡gran herramienta!) entre múltiples subredes a través del túnel VPN.
Además: esNOrequerido para habilitar nombres de host DNS para la VPC (como Amazon me hizo creer incorrectamente), FYI>
Espero que todo esto ayude!!!!!!
Edición adicional 11/02/2017:
Según la solicitud de JustEngland, copie la configuración de trabajo a continuación (omitiendo ciertos detalles para evitar cualquier identificación):
Lado a:
# ipsec.conf - strongSwan IPsec configuration file
# basic configuration
config setup
# Add connections here.
conn %default
ikelifetime= You choose; must match other side
keylife= You choose; must match other side
rekeymargin= You choose; must match other side
keyingtries=1
keyexchange= You choose; must match other side
authby=secret
mobike=no
conn side-a
left=10.198.0.124
leftsubnet=10.198.0.0/16
leftid=54.y.y.y
leftsourceip=10.198.0.124
right=52.x.x.x
rightsubnet=10.194.0.0/16
auto=start
type=tunnel
# Add connections here.
root@x:~# cat /etc/ipsec.secrets
A.A.A.A B.B.B.B : PSK "Your Password"
Lado B:
# ipsec.conf - strongSwan IPsec configuration file
# basic configuration
config setup
conn %default
ikelifetime= You choose; must match other side
keylife= You choose; must match other side
rekeymargin= You choose; must match other side
keyingtries=1
keyexchange= You choose; must match other side
authby=secret
mobike=no
conn side-b
left=10.194.0.129
leftsubnet=10.194.0.0/16
leftid=52.x.x.x
right=54.y.y.y
rightsubnet=10.198.0.0/16
rightsourceip=10.198.0.124
auto=start
type=tunnel
root@x:~# cat /etc/ipsec.secrets
B.B.B.B A.A.A.A : PSK "Your Password"
Respuesta1
En VPC, la dirección IP pública de una instancia nunca está vinculada a la pila de la instancia, por lo que debe configurar tanto la dirección privada interna como la dirección pública externa. Elargumento no válidoEs de suponer que se debe a que se intenta obtener tráfico directamente desde la dirección IP pública, que su instancia no conoce.
left=10.10.10.10 # instance private IP of local system
leftsourceip=10.10.10.10 # instance private IP of local system
leftid=203.x.x.x # elastic IP of local system
leftsubnet=10.x.x.x/xx
rightsubnet=10.x.x.x/xx
right=198.x.x.x # elastic IP of remote system
Respuesta2
Problema fijo.
1) No seguí correctamente las instrucciones de configuración de Michael. También configuré un rightsourceip y un leftsourceip juntos, lo que provocó que ambas instancias creyeran que ambas eran iniciadores. Me aseguré de que uno fuera el iniciador y el otro el solicitante; esto solucionó el problema de IKE.
2) Descubrí que también tenía que configurar explícitamente el parámetro esp. Aunque ya existe un valor predeterminado (aes128-sha1,3des-sha1), el parámetro esp aún debe configurarse para que la instancia sepa usar esp O ah (pero no ambos). Terminé usando aes128-sha1-modp2048.