J'essaie de configurer un tunnel VPN à l'aide de StrongSwan 5.1.2 entre deux instances Amazon AWS EC2 exécutant Ubuntu 14.04.2 LTS. Avant d'utiliser StrongSwan, j'ai utilisé un cygne ouvert (libre) sur une AMI Amazon RedHat, qui fonctionnait bien. Pour une raison quelconque, je ne peux même pas faire travailler IKE pour StrongSwan. J'ai vérifié trois fois mes configurations AWS, et tout semble bon, donc cela doit être un problème avec la configuration StrongSwan.
Comme vous le verrez ci-dessous, l'erreur que j'obtiens est "Erreur d'écriture dans socket: argument non valide" . J'ai regardé en ligne et je ne trouve vraiment pas la solution à cela. Je suis convaincu que mon strongswan ipsec.conf est mal configuré.
Voici avec quoi je travaille:
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 topologie (simple) est la suivante:
[ Instance #1 within N.Virginia VPC <-> Public internet <-> Instance #2 within Oregon VPC ]
J'ai vérifié que les configurations AWS suivantes sont correctes:
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)
Ci-dessous se trouve le fichier /etc/ipsec.conf (il s'agit de l'Oregon, mais il en va de même sur l'instance de N.Virginia, sauf que les valeurs gauche | droite sont inversées) :
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
Ci-dessous se trouve le /etc/ipsec.secrets * (inversé pour les autres instances, évidemment):
54.X.X.X 52.Y.Y.Y : PSK "Key_inserted_here"
Ci-dessous se trouve le /etc/strongswan.conf:
charon {
load_modular = yes
plugins {
include strongswan.d/charon/*.conf
}
}
Ci-dessous se trouve le fichier /etc/sysctl.conf:
net.ipv4.ip_forward=1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
Voici la sortie de débogage de / var / log / syslog Il semble que le problème ici soit "erreur d'écriture sur socket: argument non valide; après tout ce que j'ai essayé, je continue à obtenir cette même erreur :
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
Voici ce que j'ai essayé jusqu'à présent:
1) Couche vérifiée 3
2) machines redémarrées
3) J'ai essayé d'ajouter dans leftid =
4) J'ai essayé de faire la mise à jour ipsec puis le redémarrage ipsec
5) J'ai essayé d'ajouter nat_traversal = yes dans la configuration confif (notez que cela ne devrait pas avoir d'importance car ipsec statusall vérifié à l'aide d'IKEv2, qui selon la documentation utilise automatiquement nat_traversal)
6) J'ai essayé d'omettre virtual_private <- A été utilisé selon la documentation AWS openswan, donc je l'ai inclus dans la configuration de strongswan.
7) J'ai essayé de désactiver net.ipv4.conf.all.send_redirects = 0 et net.ipv4.conf.all.accept_redirects = 0 dans /etc/sysctl.conf
8) J'ai essayé d'utiliser une adresse IP privée au lieu des EIP. Je ne reçois plus l'erreur de socket, mais de toute évidence, les deux IP ne peuvent pas communiquer entre elles pour homologue ...
9) J'ai essayé d'ajouter ceci à strongswan.conf: load = aes des sha1 sha2 md5 gmp random nonce hmac stroke kernel-netlink socket-default updown
10) Essayé avec leftfirewall = oui, n'a pas fonctionné
Aidez-moi! Merci!
EDIT # 1:
La réponse de Michael a résolu le problème d'origine, mais j'ai un nouveau problème lié au routage. Les deux instances VPN ne peuvent pas se pinguer l'une l'autre. En outre, lorsque j'essaie d'envoyer une requête ping à partir d'une instance aléatoire dans l'un des sous-réseaux, vers une autre instance aléatoire ou l'instance VPN distante, j'obtiens la réponse ping suivante:
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)
Évidemment, cela doit être un problème de routage entre les deux instances VPN (très probablement en raison de la configuration Strongswan ou de la table de routage d'instance) car l'hôte 10.194.0.80 du sous-réseau Oregon est en mesure de recevoir une réponse de l'instance VPN Oregon. Table de routage + traceroute sur l'instance:
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
Lorsque j'utilisais openswan, il n'était pas nécessaire que j'apporte des modifications manuelles à la table de routage de chaque instance.
Voici la table de routage de l'instance Oregon VPN:
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
Je suis un peu perplexe.
EDIT # 2:
Il semble que le routage entre les instances VPN ne soit pas le problème: / var / log / syslog affiche les paquets reçus d'une IP publique d'instance VPN vers l'autre instance 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)
Il semble que ce soit un problème lié aux associations de sécurité des enfants:
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
*** EDIT # 3: Problème résolu (euh, en fait voir EDIT # 4 ci-dessous ...) ****
Problème résolu.
1) Je n'ai pas correctement suivi les instructions de configuration de Michael. J'ai également configuré un droitsourceip et un leftsourceip ensemble, faisant ainsi croire aux deux instances qu'ils étaient tous les deux des initiateurs. J'ai veillé à ce que l'un soit un initiateur et l'autre un demandeur; cela a résolu le problème IKE.
2) J'ai compris que je devais également définir explicitement le paramètre esp. Même s'il existe déjà une valeur par défaut (aes128-sha1,3des-sha1), le paramètre esp doit encore être défini pour que l'instance sache utiliser esp OR ah (mais pas les deux). J'ai fini par utiliser aes128-sha1-modp2048.
J'espère que cette publication aidera le nouveau débutant linux à mettre cela en place !!
À votre santé!
EDIT # 4: Problème (pas vraiment) résolu
Lors du dépannage d'un problème distinct lié à strongswan, j'ai changé le paramètre "leftfirewall", testé, je n'ai pas résolu mon problème séparé, puis je suis revenu à la configuration d'origine au préalable (commenté leftfirewall). J'ai alors remarqué que je ne pouvais plus cingler à travers le tunnel. Après être devenu fou pendant des heures à essayer de comprendre ce qui s'est passé, j'ai commenté le paramètre esp pour voir ce qui se passerait: JE PEUX MAINTENANT PING À TRAVERS LE TUNNEL ENCORE! <- donc, il y a une possibilité qu'il y ait des fantômes ipsec qui me jouent des tours et que le paramètre esp ne soit pas vraiment le correctif pour les erreurs TS_UNACCEPTABLE (bien que d'autres ressources en ligne indiquent que le paramètre esp est le correctif ...)
EDIT # 5: Problème entièrement résolu
J'ai fini par tout déplacer dans un environnement de test et à partir de zéro. J'ai installé à partir des sources en utilisant la dernière version (5.3.2) plutôt que l'ancienne version qui était dans le repo Ubuntu (5.1.2). Cela a résolu le problème que j'avais ci-dessus et vérifié la connectivité de la couche 7 à l'aide de netcat (excellent outil !!) entre plusieurs sous-réseaux sur le tunnel VPN.
En outre: il n'est PAS nécessaire d'activer les noms d'hôte DNS pour le VPC (comme je l'ai été incorrectement amené à croire par Amazon), FYI>
J'espère que tout cela aide !!!!!!
Édition supplémentaire 2/11/2017:
Conformément à la demande de JustEngland, copie de la configuration de travail ci-dessous (en omettant certains détails afin d'empêcher l'identification de quelque manière que ce soit):
Face 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"
Côté 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"
Réponses:
Dans VPC, l'adresse IP publique d'une instance n'est jamais liée à la pile de l'instance, vous devez donc configurer à la fois l'adresse privée interne et l'adresse publique externe. L' argument non valide est probablement dû à la tentative de source de trafic directement à partir de l'adresse IP publique, qui n'est pas connue de votre instance.
la source
Problème résolu.
1) Je n'ai pas correctement suivi les instructions de configuration de Michael. J'ai également configuré un droitsourceip et un leftsourceip ensemble, faisant ainsi croire aux deux instances qu'ils étaient tous les deux des initiateurs. J'ai veillé à ce que l'un soit un initiateur et l'autre un demandeur; cela a résolu le problème IKE.
2) J'ai compris que je devais également définir explicitement le paramètre esp. Même s'il existe déjà une valeur par défaut (aes128-sha1,3des-sha1), le paramètre esp doit encore être défini pour que l'instance sache utiliser esp OR ah (mais pas les deux). J'ai fini par utiliser aes128-sha1-modp2048.
la source