Đường hầm VPN Strongswan giữa hai phiên bản AWS sẽ không kết nối


10

Tôi đang cố gắng thiết lập đường hầm VPN bằng StrongSwan 5.1.2 giữa hai phiên bản Amazon AWS EC2 chạy Ubuntu 14.04.2 LTS. Trước khi sử dụng StrongSwan, tôi đã sử dụng thiên nga mở (libre) trên Amazon RedHat AMI, hoạt động tốt. Vì một số lý do, tôi thậm chí không thể khiến IKE làm việc ở đây cho StrongSwan. Tôi đã kiểm tra ba lần cấu hình AWS của mình và tất cả đều có vẻ tốt, vì vậy nó phải là một vấn đề với cấu hình StrongSwan.

Như bạn sẽ thấy bên dưới, lỗi tôi gặp là "Lỗi ghi vào socket: Đối số không hợp lệ" . Tôi đã xem trực tuyến và thực sự không thể tìm thấy giải pháp cho vấn đề này. Tôi tin rằng ipsec.conf mạnh mẽ của tôi được cấu hình không đúng.

Đây là những gì tôi đang làm việc với:

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

Cấu trúc liên kết (đơn giản) như sau:

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

Tôi đã xác minh rằng các cấu hình AWS sau là chính xác:

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)

Dưới đây là /etc/ipsec.conf (đây là từ Oregon, tuy nhiên nó cũng giống với trường hợp N.Virginia ngoại trừ các giá trị bên trái | phải được đảo ngược) :

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

Dưới đây là /etc/ipsec.secrets * (rõ ràng là đảo ngược cho trường hợp khác):

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

Dưới đây là /etc/strongswan.conf:

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

Dưới đây là /etc/sysctl.conf:

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

Đây là đầu ra gỡ lỗi từ / var / log / syslog Có vẻ như vấn đề ở đây là "lỗi ghi vào socket: Đối số không hợp lệ; sau tất cả mọi thứ tôi đã thử, tôi tiếp tục gặp lỗi tương tự :

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

Dưới đây là những gì tôi đã cố gắng cho đến nay:

1) Đã xác minh lớp 3

2) máy được khởi động lại

3) Đã thử thêm vào leftid =

4) Đã thử thực hiện cập nhật ipsec sau đó khởi động lại ipsec

5) Đã thử thêm nat_traversal = yes trong cài đặt confif (lưu ý rằng điều này không quan trọng vì trạng thái ipsec được xác minh bằng IKEv2, theo tài liệu tự động sử dụng nat_traversal)

6) Đã thử bỏ qua virtual_private <- Được sử dụng theo tài liệu của AWS openswan vì vậy tôi đã đưa nó vào cấu hình Strongswan.

7) Đã thử vô hiệu hóa net.ipv4.conf.all.send_redirects = 0 và net.ipv4.conf.all.accept_redirects = 0 trong /etc/sysctl.conf

8) Đã thử sử dụng IP riêng thay vì EIP. Tôi không còn gặp phải lỗi socket, tuy nhiên rõ ràng hai IP không thể liên lạc với nhau để ...

9) Đã thử thêm phần này vào strongswan.conf: load = aes des sha1 sha2 md5 gmp ngẫu nhiên nonce hmac Stroke kernel-netlink socket-default updateown

10) Đã thử sử dụng leftfirewall = có, không hoạt động

Xin vui lòng giúp đỡ! Cảm ơn!

EDIT # 1:

Phản ứng của Michael đã xóa vấn đề ban đầu, tuy nhiên tôi có một vấn đề mới liên quan đến định tuyến. Cả hai trường hợp VPN không thể ping nhau. Hơn nữa, khi tôi cố gắng ping từ một cá thể ngẫu nhiên trong một mạng con, sang một thể hiện ngẫu nhiên khác hoặc cá thể VPN ở xa, tôi nhận được phản hồi ping sau:

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)

Rõ ràng đây phải là sự cố định tuyến giữa hai phiên bản VPN (rất có thể là do cấu hình mạnh hoặc bảng định tuyến cá thể) do máy chủ 10.194.0.80 trong mạng con Oregon có thể nhận được phản hồi từ phiên bản VPN của Oregon. Bảng tuyến đường + traceroute trên ví dụ:

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

Khi tôi đang sử dụng openswan, nó không yêu cầu tôi thực hiện bất kỳ sửa đổi thủ công nào đối với bảng định tuyến của mỗi trường hợp.

Dưới đây là bảng định tuyến của cá thể 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

Tôi hơi bối rối.

EDIT # 2:

Có vẻ như việc định tuyến giữa các phiên bản VPN có thể không phải là vấn đề: / var / log / syslog hiển thị các gói được nhận từ một IP công khai của một cá thể VPN sang phiên bản VPN khác

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)

Có vẻ như đây là một vấn đề liên quan đến Hiệp hội An ninh Trẻ em:

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: Vấn đề đã được giải quyết (uhh, thực sự thấy EDIT # 4 bên dưới ...) ****

Vấn đề cố định.

1) Tôi đã không thực hiện đúng hướng dẫn cấu hình của Michael. Tôi cũng đã cấu hình Rightsourceip và leftsourceip cùng nhau, do đó khiến cả hai trường hợp tin rằng cả hai đều là người khởi xướng. Tôi đảm bảo rằng một người là người khởi xướng và một người là người yêu cầu; Điều này đã khắc phục sự cố IKE.

2) Tôi nhận ra rằng tôi cũng phải đặt rõ ràng tham số đặc biệt. Mặc dù đã có mặc định (aes128-sha1,3des-sha1), tham số đặc biệt vẫn phải được đặt để cá thể biết sử dụng đặc biệt OR OR ah (nhưng không phải cả hai). Tôi đã kết thúc bằng cách sử dụng aes128-sha1-modp2048.

Hy vọng bài đăng này sẽ giúp người mới linux tiếp theo thiết lập điều này !!

Chúc mừng!

EDIT # 4: Vấn đề (không thực sự) đã được giải quyết

Trong khi khắc phục sự cố riêng biệt liên quan đến Strongswan, tôi đã thay đổi tham số "leftfirewall", đã kiểm tra, không khắc phục sự cố riêng biệt của mình, sau đó quay lại cấu hình orig trước đó (đã nhận xét bên trái). Sau đó tôi nhận thấy rằng bây giờ tôi không thể ping qua đường hầm. Sau khi phát điên trong nhiều giờ cố gắng tìm hiểu chuyện gì đã xảy ra, tôi đã nhận xét thông số đặc biệt để xem điều gì sẽ xảy ra: TÔI CÓ THỂ BẮT ĐẦU RA KHỎI TUNNEL LẠI! <- vì vậy, có khả năng có một số bóng ma ipsec đang chạy xung quanh chơi trò lừa đảo với tôi và tham số đặc biệt đó không thực sự là sửa lỗi cho TS_UNACCEPTABLE (mặc dù các tài nguyên trực tuyến khác nêu rõ tham số đặc biệt là sửa chữa ...)

EDIT # 5: Vấn đề được giải quyết đầy đủ

Cuối cùng tôi đã chuyển mọi thứ vào một môi trường thử nghiệm và bắt đầu lại từ đầu. Tôi đã cài đặt từ nguồn bằng phiên bản mới nhất (5.3.2) thay vì phiên bản cũ hơn trong repo Ubuntu (5.1.2). Điều này đã xóa vấn đề tôi gặp phải ở trên và xác minh kết nối lớp 7 bằng cách sử dụng netcat (công cụ tuyệt vời !!) giữa nhiều mạng con qua đường hầm VPN.

Ngoài ra: KHÔNG bắt buộc phải bật tên máy chủ DNS cho VPC (vì tôi đã bị Amazon dẫn đến tin tưởng không chính xác), FYI>

Hy vọng tất cả điều này sẽ giúp !!!!!!

Chỉnh sửa bổ sung 2/11/2017:

Theo yêu cầu của JustEngland, sao chép cấu hình hoạt động bên dưới (bỏ qua một số chi tiết nhất định để ngăn nhận dạng theo bất kỳ cách nào):

Bên một:

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

Bên 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"

Bạn có thể gửi cấu hình làm việc.
JustEngland

chắc chắn, sẽ thêm cấu hình như một chỉnh sửa vào bài đăng câu hỏi ban đầu của tôi. Xin lưu ý rằng tôi không còn có quyền truy cập vào thiết lập, vì vậy tôi không thể xác minh 100% nếu cấu hình đúng; tuy nhiên, chúng nên là :)
lobi

Câu trả lời:


7

Trong VPC, địa chỉ IP công cộng của một cá thể không bao giờ bị ràng buộc với ngăn xếp của cá thể, vì vậy bạn phải định cấu hình cả địa chỉ riêng bên trong và địa chỉ công cộng bên ngoài. Đối số không hợp lệ có lẽ là do cố gắng lấy lưu lượng truy cập trực tiếp từ địa chỉ IP công cộng, không được biết đến với thể hiện của bạn.

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

Xin chào Michael, điều này đã khắc phục sự cố ban đầu, tuy nhiên hiện tại có vẻ như đã xảy ra sự cố định tuyến do cấu hình mạnh mẽ. Tôi không thể ping từ một phiên bản VPN này sang phiên bản VPN khác (hết thời gian chờ) và nếu tôi cố gắng ping từ một phiên bản khác từ trong mạng con, tôi nhận được thông tin sau: Từ 10.194.0.176: icmp_seq = 4 Máy chủ chuyển hướng (Mới nexthop: 10.194.0.176)
lobi

Tôi đã chỉnh sửa bài viết gốc của mình
lobi

Tìm ra. Tôi đã không triển khai cấu hình của Michaels một cách chính xác (tôi cũng bao gồm Rightsourceip, do đó nhầm lẫn cái nào là người khởi xướng và cái nào là người yêu cầu). Tôi cũng cần thiết để thiết lập rõ ràng tham số đặc biệt.
lobi

1

Vấn đề cố định.

1) Tôi đã không thực hiện đúng hướng dẫn cấu hình của Michael. Tôi cũng đã cấu hình Rightsourceip và leftsourceip cùng nhau, do đó khiến cả hai trường hợp tin rằng cả hai đều là người khởi xướng. Tôi đảm bảo rằng một người là người khởi xướng và một người là người yêu cầu; Điều này đã khắc phục sự cố IKE.

2) Tôi nhận ra rằng tôi cũng phải đặt rõ ràng tham số đặc biệt. Mặc dù đã có mặc định (aes128-sha1,3des-sha1), tham số đặc biệt vẫn phải được đặt để cá thể biết sử dụng đặc biệt OR OR ah (nhưng không phải cả hai). Tôi đã kết thúc bằng cách sử dụng aes128-sha1-modp2048.


Không chắc chắn nếu điều này là cố định 100%. Xem chỉnh sửa số 4 trong bài viết gốc.
lobi 6/07/2015
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.