☰

Strongswan VPN-Tunnel zwischen zwei AWS-Instanzen stellt keine Verbindung her

tag-icon • tag-icon vpn amazon-web-services ipsec ubuntu-14.04 strongswan
Strongswan VPN-Tunnel zwischen zwei AWS-Instanzen stellt keine Verbindung her

Ich versuche, mit StrongSwan 5.1.2 einen VPN-Tunnel zwischen zwei Amazon AWS EC2-Instanzen mit Ubuntu 14.04.2 LTS einzurichten. Vor der Verwendung von StrongSwan habe ich open(libre)swan auf einem Amazon RedHat AMI verwendet, was gut funktioniert hat. Aus irgendeinem Grund kann ich IKE hier nicht einmal für StrongSwan zum Laufen bringen. Ich habe meine AWS-Konfigurationen dreimal überprüft und alles sieht gut aus, also muss es ein Problem mit der StrongSwan-Konfiguration sein.

Wie Sie unten sehen werden, ist der Fehler, den ich bekomme„Fehler beim Schreiben in den Socket: Ungültiges Argument“. Ich habe online gesucht und kann wirklich keine Lösung dafür finden. Ich bin überzeugt, dass meine strongswan ipsec.conf falsch konfiguriert ist.

Hier ist, womit ich arbeite:

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

Die (einfache) Topologie ist wie folgt:

[ Instance #1 within N.Virginia VPC <-> Public internet <-> Instance #2 within Oregon VPC ]

Ich habe überprüft, dass die folgenden AWS-Konfigurationen korrekt sind:

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)

Unten ist die/etc/ipsec.conf (das ist aus Oregon, es ist jedoch dasselbe wie im Fall von N.Virginia, außer dass die Werte links|rechts vertauscht sind):

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

Unten ist /etc/ipsec.secrets * (für andere Instanzen natürlich umgekehrt):

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

Unten ist die Datei /etc/strongswan.conf:

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

Unten ist die Datei /etc/sysctl.conf:

net.ipv4.ip_forward=1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0

Hier ist die Debug-Ausgabe von /var/log/syslogEs scheint, dass das Problem hier "Fehler beim Schreiben in den Socket: Ungültiges Argument" ist. Nach allem, was ich versucht habe, erhalte ich weiterhin denselben Fehler.:

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

Nachfolgend finden Sie, was ich bisher versucht habe:

1) Verifizierte Schicht 3

2) Maschinen neu gestartet

3) Habe versucht, leftid= hinzuzufügen

4) Habe versucht, ein IPSec-Update und dann einen IPSec-Neustart durchzuführen

5) Habe versucht, nat_traversal=yes unter Confif-Setup hinzuzufügen (beachten Sie, dass dies keine Rolle spielen sollte, da IPSec Statusall mit IKEv2 überprüft wurde, das gemäß Dokumentation automatisch nat_traversal verwendet)

6) Habe versucht, virtual_private wegzulassen <-- Wurde gemäß der AWS OpenSwan-Dokumentation verwendet, also habe ich es in die Strongswan-Konfiguration aufgenommen.

7) Habe versucht, net.ipv4.conf.all.send_redirects = 0 und net.ipv4.conf.all.accept_redirects = 0 in /etc/sysctl.conf zu deaktivieren.

8) Habe versucht, private IPs statt EIPs zu verwenden. Ich bekomme den Socket-Fehler nicht mehr, aber offensichtlich können die beiden IPs nicht miteinander kommunizieren ...

9) Habe versucht, dies zu strongswan.conf hinzuzufügen: load = aes des sha1 sha2 md5 gmp random nonce hmac stroke kernel-netlink socket-default updown

10) Habe versucht, leftfirewall=yes zu verwenden, hat nicht funktioniert

Bitte helfen Sie! Danke!

BEARBEITEN #1:

Michaels Antwort hat das ursprüngliche Problem behoben, ich habe jedoch ein neues Problem im Zusammenhang mit dem Routing. Beide VPN-Instanzen können sich nicht gegenseitig anpingen. Wenn ich außerdem versuche, von einer zufälligen Instanz in einem der Subnetze aus entweder eine andere zufällige Instanz oder die VPN-Instanz am anderen Ende anzupingen, erhalte ich die folgende Ping-Antwort:

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)

Offensichtlich muss dies ein Routing-Problem zwischen den beiden VPN-Instanzen sein (höchstwahrscheinlich aufgrund der Strongswan-Konfiguration oder der Routing-Tabelle der Instanz), da der Host 10.194.0.80 im Oregon-Subnetz eine Antwort von der Oregon-VPN-Instanz empfangen kann. Routing-Tabelle + Traceroute auf Instanz:

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

Als ich Openswan verwendete, musste ich keine manuellen Änderungen an der Routing-Tabelle der einzelnen Instanzen vornehmen.

Hier ist die Routing-Tabelle der Oregon VPN-Instanz:

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

Ich bin etwas ratlos.

BEARBEITEN #2:

Das Routing zwischen den VPN-Instanzen scheint nicht das Problem zu sein: /var/log/syslog zeigt Pakete, die von der öffentlichen IP einer VPN-Instanz an die andere VPN-Instanz gesendet werden.

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)

Es scheint sich um ein Problem zu handeln, das mit den Child Security Associations zusammenhängt:

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: Problem gelöst (äh, siehe eigentlich EDIT #4 unten...)****

Problem gelöst.

1) Ich habe Michaels Konfigurationsanweisungen nicht richtig befolgt. Ich habe auch eine RightSourceIP und eine LeftSourceIP zusammen konfiguriert, wodurch beide Instanzen dachten, sie seien beide Initiatoren. Ich habe sichergestellt, dass einer ein Initiator und einer ein Anforderer war; dadurch wurde das IKE-Problem behoben.

2) Ich habe herausgefunden, dass ich auch den esp-Parameter explizit festlegen musste. Obwohl es bereits einen Standard gibt (aes128-sha1,3des-sha1), muss der esp-Parameter trotzdem festgelegt werden, damit die Instanz weiß, ob sie esp ODER ah verwenden soll (aber nicht beides). Ich habe am Ende aes128-sha1-modp2048 verwendet.

Hoffe, dieser Beitrag hilft dem nächsten Linux-Neuling bei der Einrichtung!!

Prost!

EDIT #4: Problem (nicht wirklich) gelöst

Während ich ein separates Problem im Zusammenhang mit Strongswan behob, änderte ich den Parameter „leftfirewall“, testete, behob mein separates Problem nicht und kehrte dann zur ursprünglichen Konfiguration zurück (leftfirewall auskommentiert). Dann bemerkte ich, dass ich jetzt nicht mehr über den Tunnel pingen konnte. Nachdem ich stundenlang wie verrückt versucht hatte, herauszufinden, was passiert war, kommentierte ich den esp-Parameter aus, um zu sehen, was passieren würde: ICH KANN JETZT WIEDER ÜBER DEN TUNNEL PINEN! <- es besteht also die Möglichkeit, dass einige IPSec-Geister herumlaufen und mir Streiche spielen und dass der esp-Parameter nicht wirklich die Lösung für die TS_UNACCEPTABLE-Fehler ist (obwohl andere Online-Ressourcen angeben, dass der esp-Parameter die Lösung ist...)

EDIT #5: Problem vollständig gelöst

Am Ende habe ich alles in eine Testumgebung verschoben und von vorne angefangen. Ich habe die neueste Version (5.3.2) aus dem Quellcode installiert und nicht die ältere Version aus dem Ubuntu-Repo (5.1.2). Dadurch wurde das oben beschriebene Problem behoben und die Layer-7-Konnektivität mit Netcat (tolles Tool!!) zwischen mehreren Subnetzen über den VPN-Tunnel überprüft.

Außerdem: Es istNICHTerforderlich, um DNS-Hostnamen für die VPC zu aktivieren (wie Amazon mir fälschlicherweise glauben machte), FYI>

Hoffe, das hilft alles!!!!!!

Zusätzliche Bearbeitung 11.02.2017:

Gemäß der Anfrage von JustEngland wird die funktionierende Konfiguration unten kopiert (wobei bestimmte Details weggelassen werden, um eine Identifizierung in jeglicher Weise zu verhindern):

Seite 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"

Seite 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"

Antwort1

In VPC ist die öffentliche IP-Adresse einer Instanz nie an den Stack der Instanz gebunden, daher müssen Sie sowohl die interne private Adresse als auch die externe öffentliche Adresse konfigurieren. Dieungültiges Argumentwird vermutlich durch den Versuch verursacht, Datenverkehr direkt von der öffentlichen IP-Adresse zu beziehen, die Ihrer Instanz nicht bekannt ist.

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

Antwort2

Problem gelöst.

1) Ich habe Michaels Konfigurationsanweisungen nicht richtig befolgt. Ich habe auch eine RightSourceIP und eine LeftSourceIP zusammen konfiguriert, wodurch beide Instanzen dachten, sie seien beide Initiatoren. Ich habe sichergestellt, dass einer ein Initiator und einer ein Anforderer war; dadurch wurde das IKE-Problem behoben.

2) Ich habe herausgefunden, dass ich auch den esp-Parameter explizit festlegen musste. Obwohl es bereits einen Standard gibt (aes128-sha1,3des-sha1), muss der esp-Parameter trotzdem festgelegt werden, damit die Instanz weiß, ob sie esp ODER ah verwenden soll (aber nicht beides). Ich habe am Ende aes128-sha1-modp2048 verwendet.

verwandte Informationen