Saya mencoba untuk membuat terowongan VPN menggunakan StrongSwan 5.1.2 antara dua instance Amazon AWS EC2 yang menjalankan Ubuntu 14.04.2 LTS. Sebelum menggunakan StrongSwan, saya menggunakan open (libre) swan di Amazon RedHat AMI, yang berfungsi dengan baik. Untuk beberapa alasan saya bahkan tidak dapat membuat IKE bekerja di sini untuk StrongSwan. Saya triple memeriksa konfigurasi AWS saya, dan semuanya terlihat bagus, jadi pasti ada masalah dengan konfigurasi StrongSwan.
Seperti yang akan Anda lihat di bawah, kesalahan yang saya dapatkan adalah "Kesalahan menulis ke soket: Argumen tidak valid" . Saya telah mencari online dan benar-benar tidak dapat menemukan solusi untuk ini. Saya yakin ipsec.conf strongswan saya tidak terkonfigurasi dengan benar.
Inilah yang saya kerjakan:
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
Topologi (sederhana) adalah sebagai berikut:
[ Instance #1 within N.Virginia VPC <-> Public internet <-> Instance #2 within Oregon VPC ]
Saya memverifikasi bahwa konfigurasi AWS berikut ini benar:
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 bawah ini adalah /etc/ipsec.conf (ini dari Oregon, namun sama pada turunan N.Virginia kecuali nilai kiri | kanan dibalik) :
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 bawah ini adalah /etc/ipsec.secrets * (jelas dibalik untuk contoh lain):
54.X.X.X 52.Y.Y.Y : PSK "Key_inserted_here"
Di bawah ini adalah /etc/strongswan.conf:
charon {
load_modular = yes
plugins {
include strongswan.d/charon/*.conf
}
}
Di bawah ini adalah /etc/sysctl.conf:
net.ipv4.ip_forward=1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
Berikut ini adalah hasil debug dari / var / log / syslog Tampaknya masalah di sini adalah "penulisan kesalahan ke soket: Argumen tidak valid; setelah semua yang saya coba, saya terus mendapatkan kesalahan yang sama :
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 bawah ini adalah apa yang saya coba sejauh ini:
1) Lapisan terverifikasi 3
2) mesin reboot
3) Mencoba menambahkan dalam leftid =
4) Mencoba melakukan pembaruan ipsec kemudian ipsec restart
5) Mencoba menambahkan nat_traversal = ya di bawah konfigurasi confif (perhatikan bahwa ini tidak masalah karena status ipsec diverifikasi menggunakan IKEv2, yang menurut dokumentasi secara otomatis menggunakan nat_traversal)
6) Mencoba menghilangkan virtual_private <- Digunakan sesuai dengan dokumentasi AWS openswan jadi saya memasukkannya ke dalam konfigurasi strongswan.
7) Mencoba menonaktifkan net.ipv4.conf.all.send_redirects = 0 dan net.ipv4.conf.all.accept_redirects = 0 di /etc/sysctl.conf
8) Mencoba menggunakan IP pribadi, bukan EIP. Saya tidak lagi mendapatkan kesalahan soket, namun jelas kedua IP tidak dapat berkomunikasi satu sama lain ke ...
9) Mencoba menambahkan ini ke strongswan.conf: load = aes des sha1 sha2 md5 gmp acak nonce hmac stroke kernel-netlink socket-default updown
10) Mencoba menggunakan leftfirewall = ya, tidak berhasil
Tolong bantu! Terima kasih!
EDIT # 1:
Tanggapan Michael menyelesaikan masalah aslinya, namun saya memiliki masalah baru terkait perutean. Kedua instance VPN tidak dapat melakukan ping satu sama lain. Lebih jauh, ketika saya mencoba melakukan ping dari instance acak di salah satu subnet, ke instance acak lain atau instance VPN ujung jauh, saya mendapatkan respons ping berikut:
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)
Jelas ini harus menjadi masalah perutean antara dua instance VPN (kemungkinan besar karena konfigurasi Strongswan atau tabel perutean instance) karena host 10.194.0.80 di subnet Oregon dapat menerima respons dari instance Oregon VPN. Tabel rute + traceroute misalnya:
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
Ketika saya menggunakan openswan, itu tidak mengharuskan saya untuk membuat modifikasi manual ke tabel routing setiap instance.
Berikut adalah tabel perutean 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
Saya agak bingung.
EDIT # 2:
Sepertinya perutean di antara instance VPN mungkin bukan masalahnya: / var / log / syslog menunjukkan paket yang diterima dari satu IP publik IP publik ke instance VPN lainnya
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)
Sepertinya ini adalah masalah yang terkait dengan Asosiasi Keamanan Anak:
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: Masalah terpecahkan (uhh, sebenarnya lihat EDIT # 4 di bawah ...) ****
Masalah diperbaiki.
1) Saya tidak mengikuti petunjuk konfigurasi Michael dengan benar. Saya juga mengkonfigurasi sumber daya hak dan leftsourceip bersama-sama, sehingga menyebabkan kedua contoh percaya bahwa mereka berdua adalah inisiator. Saya memastikan bahwa yang satu adalah pemrakarsa dan yang lain adalah pemohon; ini memperbaiki masalah IKE.
2) Saya tahu bahwa saya juga harus secara eksplisit mengatur parameter esp. Meskipun sudah ada default (aes128-sha1, 3des-sha1), parameter esp masih harus diatur agar instance tahu untuk menggunakan esp ATAU ah (tapi tidak keduanya). Saya akhirnya menggunakan aes128-sha1-modp2048.
Semoga posting ini membantu pemula linux berikutnya mengatur ini !!
Bersulang!
EDIT # 4: Masalah (tidak benar-benar) terpecahkan
Sementara memecahkan masalah yang terpisah terkait dengan strongswan, saya mengubah parameter "leftfirewall", diuji, tidak memperbaiki masalah saya yang terpisah, lalu kembali ke konfigurasi asal sebelumnya (berkomentar di sebelah kirifirewall). Saya kemudian memperhatikan bahwa sekarang saya tidak bisa melakukan ping melintasi terowongan. Setelah menjadi gila selama berjam-jam mencoba mencari tahu apa yang terjadi, saya berkomentar parameter khusus untuk melihat apa yang akan terjadi: SAYA BISA SEKARANG PING DI SELURUH TUNNEL LAGI! <- jadi, ada kemungkinan ada beberapa hantu ipsec berkeliaran mempermainkanku dan bahwa parameter esp tidak benar-benar memperbaiki kesalahan TS_UNACCEPTABLE (meskipun sumber daya lain online menyatakan parameter esp adalah memperbaiki ...)
EDIT # 5: Masalah terpecahkan sepenuhnya
Saya akhirnya memindahkan semuanya ke lingkungan pengujian dan mulai dari awal. Saya menginstal dari sumber menggunakan versi terbaru (5.3.2) daripada versi lama yang ada di repo Ubuntu (5.1.2). Ini menyelesaikan masalah yang saya alami di atas, dan memverifikasi konektivitas lapisan 7 menggunakan netcat (alat hebat !!) antara beberapa subnet melalui terowongan VPN.
Juga: TIDAK diharuskan untuk mengaktifkan nama host DNS untuk VPC (karena saya salah dipercaya oleh Amazon), FYI>
Semoga ini semua membantu !!!!!!
Suntingan tambahan 2/11/2017:
Sesuai permintaan JustEngland, menyalin konfigurasi yang berfungsi di bawah ini (meninggalkan detail tertentu untuk mencegah identifikasi dengan cara apa pun):
Sisi 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"
Sisi 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"
Jawaban:
Di VPC, alamat IP publik dari sebuah instance tidak pernah terikat pada stack instance, jadi Anda harus mengonfigurasi alamat privat internal dan alamat publik eksternal. The argumen yang tidak valid ini mungkin disebabkan oleh mencoba untuk sumber lalu lintas langsung dari alamat IP publik, yang tidak diketahui Misalnya Anda.
sumber
Masalah diperbaiki.
1) Saya tidak mengikuti petunjuk konfigurasi Michael dengan benar. Saya juga mengkonfigurasi sumber daya hak dan leftsourceip bersama-sama, sehingga menyebabkan kedua contoh percaya bahwa mereka berdua adalah inisiator. Saya memastikan bahwa yang satu adalah pemrakarsa dan yang lain adalah pemohon; ini memperbaiki masalah IKE.
2) Saya tahu bahwa saya juga harus secara eksplisit mengatur parameter esp. Meskipun sudah ada default (aes128-sha1, 3des-sha1), parameter esp masih harus diatur agar instance tahu untuk menggunakan esp ATAU ah (tapi tidak keduanya). Saya akhirnya menggunakan aes128-sha1-modp2048.
sumber