Sto cercando di impostare un tunnel VPN utilizzando StrongSwan 5.1.2 tra due istanze Amazon AWS EC2 che eseguono Ubuntu 14.04.2 LTS. Prima di usare StrongSwan, ho usato un cigno aperto (libero) su un AMI Amazon RedHat, che ha funzionato bene. Per qualche motivo non riesco nemmeno a far funzionare IKE qui per StrongSwan. Ho controllato tre volte le mie configurazioni AWS e sembra tutto a posto, quindi deve essere un problema con la configurazione StrongSwan.
Come vedrai di seguito, l'errore che sto ricevendo è "Errore durante la scrittura nel socket: argomento non valido" . Ho cercato online e non riesco davvero a trovare la soluzione. Sono convinto che il mio strongswan ipsec.conf sia configurato in modo errato.
Ecco cosa sto lavorando con:
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 topologia (semplice) è la seguente:
[ Instance #1 within N.Virginia VPC <-> Public internet <-> Instance #2 within Oregon VPC ]
Ho verificato che le seguenti configurazioni AWS sono corrette:
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)
Di seguito è riportato il file /etc/ipsec.conf (questo è dell'Oregon, tuttavia è lo stesso sull'istanza N.Virginia, tranne per il fatto che i valori left | right sono invertiti) :
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
Di seguito è riportato il /etc/ipsec.secrets * (invertito per altre istanze, ovviamente):
54.X.X.X 52.Y.Y.Y : PSK "Key_inserted_here"
Di seguito è /etc/strongswan.conf:
charon {
load_modular = yes
plugins {
include strongswan.d/charon/*.conf
}
}
Di seguito è /etc/sysctl.conf:
net.ipv4.ip_forward=1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
Ecco l'output di debug da / var / log / syslog Sembra che il problema qui sia "errore durante la scrittura nel socket: argomento non valido; dopo tutto quello che ho provato, continuo a ottenere lo stesso errore :
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
Di seguito è quello che ho provato finora:
1) Livello verificato 3
2) macchine riavviate
3) Ho provato ad aggiungere in leftid =
4) Ho provato a fare l'aggiornamento ipsec, quindi riavviare ipsec
5) Ho provato ad aggiungere nat_traversal = yes in confif setup (nota che questo non dovrebbe importare dal momento che lo stato di ipsec è stato verificato usando IKEv2, che secondo la documentazione usa automaticamente nat_traversal)
6) Ho provato a omettere virtual_private <- È stato utilizzato secondo la documentazione di AWS OpenSwan quindi l'ho incluso nella configurazione di strongswan.
7) Ho provato a disabilitare net.ipv4.conf.all.send_redirects = 0 e net.ipv4.conf.all.accept_redirects = 0 in /etc/sysctl.conf
8) Ho provato a usare l'IP privato invece degli EIP. Non ricevo più l'errore del socket, tuttavia ovviamente i due IP non possono comunicare tra loro per peer ...
9) Ho provato ad aggiungere questo a strongswan.conf: load = aes des sha1 sha2 md5 gmp random nonce hmac stroke kernel-netlink socket-default updown
10) Ho provato a usare leftfirewall = yes, non ha funzionato
Per favore aiuto! Grazie!
EDIT # 1:
La risposta di Michael ha risolto il problema originale, tuttavia ho un nuovo problema relativo al routing. Entrambe le istanze VPN non sono in grado di eseguire il ping a vicenda. Inoltre, quando provo a eseguire il ping da un'istanza casuale in una sottorete, a un'altra istanza casuale o all'istanza VPN remota, ottengo la seguente risposta 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)
Ovviamente questo deve essere un problema di routing tra le due istanze VPN (molto probabilmente a causa della configurazione strongswan o della tabella di routing delle istanze) poiché l'host 10.194.0.80 nella sottorete dell'Oregon è in grado di ricevere una risposta dall'istanza VPN dell'Oregon. Tabella di instradamento + traceroute sull'istanza:
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
Quando stavo usando openswan, non mi richiedeva alcuna modifica manuale alla tabella di routing di ciascuna istanza.
Ecco la tabella di routing dell'istanza VPN 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
Sono un po 'perplesso.
EDIT # 2:
Sembra che il routing tra le istanze VPN non sia il problema: / var / log / syslog mostra i pacchetti ricevuti da un IP pubblico di un'istanza VPN all'altra istanza 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)
Sembra che si tratti di un problema relativo alle Associazioni per la sicurezza dei minori:
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: Problema risolto (uhh, in realtà vedi EDIT # 4 di seguito ...) ****
Problema risolto.
1) Non ho seguito correttamente le indicazioni di configurazione di Michael. Ho anche configurato insieme rightsourceip e leftsourceip, facendo credere a entrambi i casi di essere entrambi iniziatori. Ho assicurato che uno era un iniziatore e uno era un richiedente; questo risolto il problema IKE.
2) Ho capito che dovevo anche impostare esplicitamente il parametro esp. Anche se esiste già un valore predefinito (aes128-sha1,3des-sha1), il parametro esp deve ancora essere impostato affinché l'istanza sappia usare esp OR ah (ma non entrambi). Ho finito per usare aes128-sha1-modp2048.
Spero che questo post aiuti il nuovo novizio di Linux a configurarlo !!
Saluti!
EDIT # 4: Problema (non proprio) risolto
Durante la risoluzione di un problema separato relativo a strongswan, ho modificato il parametro "leftfirewall", testato, non ho risolto il mio problema separato, quindi sono tornato alla configurazione di orig in precedenza (commentato leftfirewall). Poi ho notato che ora non potevo fare il ping attraverso il tunnel. Dopo essere impazzito per ore cercando di capire cosa è successo, ho commentato il parametro esp per vedere cosa sarebbe successo: POSSO ORA ANCORA TROVARE IL TUNNEL! <- quindi, c'è la possibilità che ci siano alcuni fantasmi ipsec che corrono giocando con me e che il parametro esp non è in realtà la correzione degli errori TS_UNACCEPTABLE (anche se altre risorse online indicano che il parametro esp è la correzione ...)
EDIT # 5: Problema completamente risolto
Ho finito per spostare tutto in un ambiente di test e iniziare da zero. Ho installato dal sorgente usando l'ultima versione (5.3.2) piuttosto che la versione precedente che era nel repository Ubuntu (5.1.2). Ciò ha risolto il problema che avevo riscontrato in precedenza e verificato la connettività di livello 7 utilizzando netcat (ottimo strumento !!) tra più subnet sul tunnel VPN.
Inoltre: NON è necessario abilitare i nomi host DNS per il VPC (come mi è stato erroneamente indotto a credere da Amazon), FYI>
Spero che tutto ciò aiuti !!!!!!
Modifica aggiuntiva 2/11/2017:
Come da richiesta di JustEngland, copiando la configurazione di lavoro di seguito (tralasciando alcuni dettagli per impedire l'identificazione in alcun modo):
Lato 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"
Lato 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"