Le tunnel VPN SPARSWAN entre deux instances AWS ne se connectera pas

Question

J'essaie de mettre en place un tunnel VPN à l'aide de STUDSWAN 5.1.2 entre deux instances Amazon AWS EC2 exécutant Ubuntu 14.04.2 LTS. Avant d'utiliser STUDSWAN, j'ai utilisé Open (Libre) Swan sur une Amazon Redhat Ami, qui a bien fonctionné. Pour une raison quelconque, je ne peux même pas obtenir Ike de travailler ici pour STUDSWAN. Je triple j'ai vérifié mes configurations AWS, et tout va bien, cela doit donc être un problème de configuration de STRATSWAN.

Comme vous le verrez ci-dessous, l'erreur que je reçois est "Erreur écrit à la prise: argument invalide". J'ai regardé en ligne et je ne trouve vraiment pas la solution à cela. Je suis convaincu que mon STUDSEC.CONF est incorrectement configuré.

Voici ce que je travaille avec:

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 est le / etc/ipsec.conf (Ceci est de l'Oregon, mais il est identique à l'instance N.Virginia, à l'exception de la gauche | Les valeurs de 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 est le /etc/ipsec.secrets * (inversé pour une autre instance, évidemment):

54.X.X.X 52.Y.Y.Y : PSK "Key_inserted_here"

Ci-dessous est le /etc/strongswan.conf:

charon { load_modular = yes plugins { include strongswan.d/charon/*.conf } }

Ci-dessous est le /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/journal/syslog ( Il semble que le problème ici est "Erreur écrit à la prise: argument invalide; après tout ce que j'ai essayé, je continue à obtenir ça 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

Vous trouverez ci-dessous ce que j'ai essayé jusqu'à présent:

1) couche vérifiée 3

2) Machines redémarrées

3) essayé d'ajouter en rougetid =

4) Essayé de faire la mise à jour IPsec puis IPsec Redémarrez

5) a essayé d'ajouter NAT_TRAVERSAL = OUI sous Configuration Configuration (Notez que cela ne devrait pas avoir d'importance car IPsec StatutTouille vérifiée à l'aide de IKEV2, qui, selon la documentation, utilise automatiquement NAT_TRAVERSAL)

6) Essayé d'ometter virtual_private <- a été utilisé conformément à la documentation AWS OpenSwan, donc je l'ai inclus dans la configuration STRATSWAN.

7) Essayé désactivé net.ipv4.conf.all.send_redirects = 0 et net.ipv4.conf.all.accept_redirects = 0 in /etc/sysctl.conf

8) Essayé d'utiliser une adresse IP privée au lieu d'EIPS. Je ne reçois plus l'erreur de socket, mais évidemment, les deux IP ne peuvent pas communiquer mutuellement à regarder ...

9) J'ai essayé d'ajouter ceci à STRATSWAN.CONF: LOAD = AES DES SHA1 SHA2 MD5 MD5 MD5 GMP NONCE SANSCE HMAC Kernel-NetLink Socket par défaut

10) essayé d'utiliser la gauchefirewall = Oui, je n'ai pas fonctionné

S'il vous plaît aider! Merci!

( Edit # 1:

La réponse de Michael a effacé le problème initial, mais j'ai un nouveau problème lié au routage. Les deux cas VPN sont incapables de ping l'un de l'autre. En outre, lorsque j'essaie de ping d'une instance aléatoire dans un sous-réseau, à une autre instance aléatoire ou à l'instance VPN FORE END, je reçois 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 (probablement due à la table de routage de la configuration ou d'instance STRAT) puisque l'hôte 10.194.0.80 du sous-réseau Oregon est capable de recevoir une réponse de l'instance VPN de l'Oregon. Table de route + traceroute par exemple:

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 ne m'a pas demandé de modifier manuellement la table de routage de chaque instance.

Voici la table de routage de l'instance d'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 soulevé.

( Edit # 2:

On dirait que le routage entre les instances VPN n'est peut-être pas le problème:/var/log/syslog Affiche les paquets reçus d'une instance VPN Public IP à 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)

On dirait que c'est 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 N ° 3: Problème résolu (euh, voir réellement Modifier # 4 ci-dessous ...) **

Problème fixe.

1) Je n'ai pas suivi correctement les instructions de configuration de Michael. J'ai également configuré un ensemble de RightSourceIP et de LEFTSOURCEIP, provoquant ainsi les deux cas croient qu'ils étaient les deux initiateurs. Je suis assuré que l'un était un initiateur et que l'un était un demandeur; Cela corrige le problème Ike.

2) Je pensais que j'ai également dû 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 toujours être défini pour que l'instance sache à utiliser ESP OR AH (mais pas à la fois ). J'ai fini par utiliser AES128-SHA1-MODP32048.

J'espère que cette publication aide le prochain débutant de Linux se mettre en place !!

À votre santé!

(( Edit n ° 4: problème (pas vraiment) résolu

Tout en dépannage d'un problème distinct relié à STRATSWAN, j'ai changé le paramètre "gaucheFireWall", testé, n'a pas corrigé mon problème distinct, puis revenait à la configuration origicielle à l'avance (a commenté la gauchefirewall). J'ai ensuite remarqué que je ne pouvais plus ping dans le tunnel. Après avoir été folle 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 sur le tunnel! <- Donc, il y a une possibilité qu'il existe des fantômes ipsec qui courent autour de moi et que le paramètre ESP n'est pas vraiment le correctif des erreurs TS_Unacceptables (bien que d'autres ressources en ligne State le paramètre ESP est la solution ...)

( Edition # 5: Problème entièrement résolu

J'ai fini par déplacer tout dans un environnement de test et à partir de zéro. J'ai installé à partir de la source en utilisant la dernière version (5.3.2) plutôt que la version plus ancienne dans le repo Ubuntu (5.1.2). Cela a effacé le problème que j'avais au-dessus et la connectivité vérifiée de couche 7 à l'aide de Netcat (excellent outil !!) entre plusieurs sous-réseaux sur le tunnel VPN.

Aussi: c'est [~ # ~] non [~ # ~] requis pour activer les noms d'hôte DNS pour le VPC (comme on vous a mal à mal à croire par Amazon), fyi>

J'espère que tout aident !!!!!!

modifier supplémentaire 2/11/2017 :

Selon la demande de Justangland, copier la configuration de travail ci-dessous (laissant un certain nombre de détails afin de prévenir 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"

Michael - sqlbot · Accepted Answer

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. Le argument non valide est probablement causé par une tentative de source de trafic directement à partir de l'adresse IP publique, qui n'est pas connue de votre instance.

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

lobi · Answer