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

10

Ich versuche, mit StrongSwan 5.1.2 einen VPN-Tunnel zwischen zwei Amazon AWS EC2-Instanzen unter 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 nicht einmal dazu bringen, hier für StrongSwan zu arbeiten. Ich habe meine AWS-Konfigurationen dreimal überprüft, und alles sieht gut aus. Daher muss es ein Problem mit der StrongSwan-Konfiguration sein.

Wie Sie unten sehen werden, erhalte ich den Fehler "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 nicht richtig 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 lautet wie folgt:

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

Ich habe überprüft, ob 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 (diese stammt aus Oregon, ist jedoch in der N. Virginia-Instanz dieselbe, außer dass die Werte für links | rechts umgekehrt 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 die /etc/ipsec.secrets * (natürlich für andere Fälle umgekehrt):

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

Unten ist die /etc/strongswan.conf:

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

Unten ist die /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 / syslog. Es 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

Folgendes habe ich bisher versucht:

1) Verifizierte Schicht 3

2) Computer neu gestartet

3) Versucht, leftid = hinzuzufügen

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

5) Versucht, nat_traversal = yes unter Confif-Setup hinzuzufügen (beachten Sie, dass dies keine Rolle spielen sollte, da der IPSec-Status mit IKEv2 überprüft wurde, das laut Dokumentation automatisch nat_traversal verwendet).

6) Versucht, virtual_private wegzulassen <- Wurde gemäß der AWS openswan-Dokumentation verwendet, daher habe ich es in die strongswan-Konfiguration aufgenommen.

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

8) Versucht mit privater IP anstelle von EIPs. Ich erhalte den Socket-Fehler nicht mehr, aber offensichtlich können die beiden IPs nicht miteinander kommunizieren, um Peer zu werden ...

9) Versucht, dies zu strongswan.conf hinzuzufügen: load = aes des sha1 sha2 md5 gmp zufällige nonce hmac Schlaganfall Kernel-Netlink Socket-Standard-Updown

10) Versucht mit leftfirewall = ja, hat nicht funktioniert

Bitte helfen Sie! Vielen Dank!

EDIT # 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 versuche, von einer zufälligen Instanz in einem der Subnetze zu einer anderen zufälligen Instanz oder zur VPN-Instanz am fernen Ende zu pingen, erhalte ich außerdem 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 Instanz-Routing-Tabelle), da der Host 10.194.0.80 im Oregon-Subnetz eine Antwort von der Oregon-VPN-Instanz empfangen kann. Routentabelle + 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 jeder Instanz 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 ein bisschen ratlos.

EDIT # 2:

Das Routing zwischen den VPN-Instanzen scheint nicht das Problem zu sein: / var / log / syslog zeigt Pakete an, die von einer öffentlichen IP-Adresse einer VPN-Instanz zur anderen VPN-Instanz empfangen 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 sieht so aus, als ob es sich um ein Problem im Zusammenhang mit Child Security Associations handelt:

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 (ähm, siehe EDIT # 4 unten ...) ****

Problem gelöst.

1) Ich habe Michaels Konfigurationsanweisungen nicht richtig befolgt. Ich habe auch einen Rightsourceip und einen Leftsourceip zusammen konfiguriert, wodurch beide Instanzen glauben, sie seien beide Initiatoren. Ich stellte sicher, dass einer ein Initiator und einer ein Antragsteller war; Dies hat das IKE-Problem behoben.

2) Ich habe herausgefunden, dass ich auch den esp-Parameter explizit setzen musste. Obwohl es bereits eine Standardeinstellung gibt (aes128-sha1,3des-sha1), muss der Parameter esp noch festgelegt werden, damit die Instanz weiß, dass sie esp OR ah verwendet (aber nicht beide). Am Ende habe ich aes128-sha1-modp2048 verwendet.

Hoffe, dieser Beitrag hilft dem nächsten Linux-Neuling, dies einzurichten !!

Prost!

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

Während der Fehlerbehebung bei einem separaten Problem im Zusammenhang mit strongswan habe ich den Parameter "leftfirewall" geändert, getestet, mein separates Problem nicht behoben und bin dann zuvor zur ursprünglichen Konfiguration zurückgekehrt (auskommentierte linke Firewall). Dann bemerkte ich, dass ich jetzt nicht über den Tunnel pingen konnte. Nachdem ich stundenlang verrückt geworden war, um herauszufinden, was passiert war, habe ich den Parameter esp auskommentiert, um zu sehen, was passieren würde: Ich kann jetzt wieder über den Tunnel pingen! <- Es besteht also die Möglichkeit, dass einige IPSec-Geister herumlaufen und mir Streiche spielen und dass der esp-Parameter nicht wirklich die Korrektur für die TS_UNACCEPTABLE-Fehler ist (obwohl andere Online-Ressourcen angeben, dass der esp-Parameter die Korrektur ist ...)

EDIT # 5: Problem vollständig gelöst

Am Ende habe ich alles in eine Testumgebung verschoben und von vorne angefangen. Ich habe von der Quelle mit der neuesten Version (5.3.2) installiert und nicht mit der älteren Version, die im Ubuntu-Repo (5.1.2) enthalten war. Dadurch wurde das oben beschriebene Problem behoben und die Layer 7-Konnektivität mithilfe von Netcat (großartiges Tool !!) zwischen mehreren Subnetzen über den VPN-Tunnel überprüft.

Außerdem: Es ist NICHT erforderlich, DNS-Hostnamen für die VPC zu aktivieren (da ich von Amazon fälschlicherweise zu der Annahme gebracht wurde)

Hoffe das alles hilft !!!!!!

Zusätzliche Bearbeitung 11.02.2017:

Kopieren Sie gemäß der Anfrage von JustEngland die folgende Arbeitskonfiguration (lassen Sie bestimmte Details weg, um eine Identifizierung in irgendeiner 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"
Lobi
quelle
Könnten Sie die Arbeitskonfiguration posten?
JustEngland
Natürlich wird die Konfiguration als Bearbeitung zu meinem ursprünglichen Fragenbeitrag hinzugefügt. Bitte beachten Sie, dass ich keinen Zugriff mehr auf das Setup habe und daher nicht 100% überprüfen kann, ob die Konfigurationen korrekt sind. Sie sollten jedoch sein :)
Lobi

Antworten:

7

In VPC ist die öffentliche IP-Adresse einer Instanz niemals an den Stapel der Instanz gebunden, daher müssen Sie sowohl die interne private Adresse als auch die externe öffentliche Adresse konfigurieren. Das ungültige Argument wird 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
Michael - sqlbot
quelle
Hallo Michael, dies hat das ursprüngliche Problem behoben, aber jetzt scheint es ein Routing-Problem zu geben, das durch die strongswan-Konfiguration verursacht wird. Ich kann nicht von einer VPN-Instanz zur anderen VPN-Instanz pingen (Zeitüberschreitungen). Wenn ich versuche, innerhalb des Subnetzes von einer anderen Instanz aus zu pingen, wird Folgendes angezeigt: Ab 10.194.0.176: icmp_seq = 4 Host umleiten (neu Nexthop: 10.194.0.176)
Lobi
Ich habe meinen ursprünglichen Beitrag bearbeitet
Lobi
Herausgefunden. Ich habe Michaels 'Konfiguration nicht korrekt implementiert (ich habe auch rightsourceip eingefügt, wodurch verwirrt wurde, welcher Initiator und welcher Anforderer war). Ich musste auch explizit den Parameter esp setzen.
Lobi
1

Problem gelöst.

1) Ich habe Michaels Konfigurationsanweisungen nicht richtig befolgt. Ich habe auch einen Rightsourceip und einen Leftsourceip zusammen konfiguriert, wodurch beide Instanzen glauben, sie seien beide Initiatoren. Ich stellte sicher, dass einer ein Initiator und einer ein Antragsteller war; Dies hat das IKE-Problem behoben.

2) Ich habe herausgefunden, dass ich auch den esp-Parameter explizit setzen musste. Obwohl es bereits eine Standardeinstellung gibt (aes128-sha1,3des-sha1), muss der Parameter esp noch festgelegt werden, damit die Instanz weiß, dass sie esp OR ah verwendet (aber nicht beide). Am Ende habe ich aes128-sha1-modp2048 verwendet.

Lobi
quelle
Ich bin mir nicht sicher, ob dies zu 100% behoben ist. Siehe Bearbeitung Nr. 4 im Originalbeitrag.
Lobi