Terowongan Strongswan VPN antara dua instance AWS tidak akan terhubung


10

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"

Bisakah Anda memposting konfigurasi yang berfungsi.
JustEngland

yakin, akan menambahkan konfigurasi sebagai edit ke posting pertanyaan asli saya. Harap dicatat bahwa saya tidak lagi memiliki akses ke pengaturan, jadi saya tidak dapat memverifikasi 100% jika konfigurasi sudah benar; Namun, mereka harus :)
lobi

Jawaban:


7

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.

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

Hai Michael, ini memperbaiki masalah aslinya, namun sekarang tampaknya ada masalah routing yang disebabkan oleh konfigurasi strongswan. Saya tidak dapat melakukan ping dari satu instance VPN ke instance VPN lainnya (waktu habis), dan jika saya mencoba melakukan ping dari instance yang berbeda dari dalam subnet, saya mendapatkan yang berikut: Dari 10.194.0.176: icmp_seq = 4 Redirect Host (Baru nexthop: 10.194.0.176)
Lobi

Saya mengedit posting asli saya
lobi

Menemukannya. Saya tidak mengimplementasikan konfigurasi Michaels dengan benar (saya juga memasukkan hak cipta, sehingga membingungkan yang mana adalah pemrakarsa dan yang mana pemohon). Saya juga perlu mengatur parameter esp secara eksplisit.
lobi

1

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.


Tidak yakin apakah ini sudah diperbaiki 100%. Lihat edit # 4 di posting asli.
lobi
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.