Estoy tratando de 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, utilicé el cisne abierto (libre) en un Amazon RedHat AMI, que funcionó bien. Por alguna razón, ni siquiera puedo conseguir que IKE trabaje aquí para StrongSwan. Verifiqué 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 obtengo 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 está configurado incorrectamente.
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)
A continuación se muestra /etc/ipsec.conf (esto es de Oregon, sin embargo, es el mismo en la instancia de N.Virginia, excepto que los valores izquierda | derecha se invierten) :
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 /etc/ipsec.secrets * (invertido para otra instancia, obviamente):
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á la salida de depuración de / var / log / syslog Parece que el problema aquí es "error al escribir en el socket: argumento no válido; después de todo lo que intenté, sigo obteniendo este 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 intentado hasta ahora:
1) Capa verificada 3
2) máquinas reiniciadas
3) Intenté agregar en leftid =
4) Intenté actualizar ipsec y luego reiniciar ipsec
5) Intenté agregar nat_traversal = yes en la configuración confif (tenga en cuenta que esto no debería importar, ya que el estado de ipsec se verificó mediante IKEv2, que según la documentación usa nat_traversal automáticamente)
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é usar IP privada en lugar de EIP. Ya no recibo el error del socket, sin embargo, obviamente, las dos IP no pueden comunicarse entre sí para mirar ...
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 despejó 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 trato de hacer ping desde una instancia aleatoria en cualquiera de las subredes, ya sea a otra instancia aleatoria o a la instancia VPN del otro extremo, 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 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 ruta + traceroute, por ejemplo:
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 estaba usando openswan, no me obligaba a realizar modificaciones manuales en la tabla de enrutamiento de cada instancia.
Aquí está la tabla de enrutamiento de la instancia 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 de una IP pública de 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
*** EDITAR # 3: Problema resuelto (uhh, ver EDITAR # 4 a continuación ...) ****
Problema fijo.
1) No seguí correctamente las instrucciones de configuración de Michael. También configuré un rightourceip y leftsourceip juntos, lo que causó que ambas instancias creyeran que ambos eran iniciadores. Me aseguré de que uno fuera un iniciador y otro un solicitante; Esto solucionó el problema IKE.
2) Descubrí que también tenía que establecer explícitamente el parámetro esp. Aunque ya existe un valor predeterminado (aes128-sha1,3des-sha1), el parámetro esp aún debe establecerse para que la instancia sepa que debe usar esp OR 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", probé, no solucioné mi problema por separado, luego volví a la configuración original de antemano (comenté leftfirewall). Entonces noté que ahora no podía hacer ping a través del túnel. Después de volverme loco durante horas tratando de averiguar qué sucedió, comenté el parámetro esp para ver qué pasaría: ¡AHORA PUEDO PING ENTRE EL TÚNEL! <- entonces, existe la posibilidad de que haya algunos fantasmas de ipsec jugando conmigo y que el parámetro esp no sea realmente la solución para los errores TS_UNACCEPTABLE (aunque otros recursos en línea indican que el parámetro esp es la solución ...)
EDITAR # 5: Problema completamente resuelto
Terminé moviendo todo a un entorno de prueba y comenzando desde cero. 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: NO es necesario habilitar los 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, copiando la configuración de trabajo a continuación (dejando de lado ciertos detalles para evitar la identificación de alguna manera):
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"
Respuestas:
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. El argumento no válido se debe presumiblemente al intentar generar tráfico directamente desde la dirección IP pública, que su instancia desconoce.
fuente
Problema fijo.
1) No seguí correctamente las instrucciones de configuración de Michael. También configuré un rightourceip y leftsourceip juntos, lo que causó que ambas instancias creyeran que ambos eran iniciadores. Me aseguré de que uno fuera un iniciador y otro un solicitante; Esto solucionó el problema IKE.
2) Descubrí que también tenía que establecer explícitamente el parámetro esp. Aunque ya existe un valor predeterminado (aes128-sha1,3des-sha1), el parámetro esp aún debe establecerse para que la instancia sepa que debe usar esp OR ah (pero no ambos). Terminé usando aes128-sha1-modp2048.
fuente