Điểm:0

Không thể bắt đầu kết nối VPN IKEv2 với Surfshark qua NetworkManager

lá cờ us

Tôi cố gắng kết nối với nhà cung cấp VPN surfshark thông qua IKEv2 theo cách thủ công. Đây là nhật ký

 charon-nm[5070]: 05[CFG] được khởi tạo cho kết nối Trình quản lý mạng Surfshark IKE2
 charon-nm[5070]: 05[CFG] sử dụng danh tính cổng 'ru-mos.prod.surfshark.com'
 charon-nm[5070]: 05[IKE] khởi tạo IKE_SA Surfshark IKE2[1] tới 92.38.138.139
 charon-nm[5070]: 05[ENC] tạo yêu cầu IKE_SA_INIT 0 [ SA KE Không N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
 charon-nm[5070]: 05[NET] gửi gói: từ 192.168.2.35[35071] đến 92.38.138.139[500] (1096 byte)
 Trình quản lý mạng[4583]: <thông tin> [1636055533.4566] kết nối vpn[0x56150178a510,6c89b390-d6ee-47d8-a547-346f75797487,"Surfshark IKE2",0]: plugin VPN: trạng thái đã thay đổi: bắt đầu (3)
 charon-nm[5070]: 15[NET] gói đã nhận: từ 92.38.138.139[500] đến 192.168.2.35[35071] (38 byte)
 charon-nm[5070]: 15[ENC] đã phân tích cú pháp phản hồi IKE_SA_INIT 0 [ N(INVAL_KE) ]
 charon-nm[5070]: 15[IKE] ngang hàng không chấp nhận nhóm DH ECP_256, nó đã yêu cầu ECP_521
 charon-nm[5070]: 15[IKE] khởi tạo IKE_SA Surfshark IKE2[1] tới 92.38.138.139
 charon-nm[5070]: 15[ENC] tạo yêu cầu IKE_SA_INIT 0 [ SA KE Không N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
 charon-nm[5070]: 15[NET] gửi gói: từ 192.168.2.35[35071] đến 92.38.138.139[500] (1164 byte)
 charon-nm[5070]: 01[NET] gói đã nhận: từ 92.38.138.139[500] đến 192.168.2.35[35071] (332 byte)
 charon-nm[5070]: 01[ENC] đã phân tích cú pháp phản hồi IKE_SA_INIT 0 [ SA KE Không N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(MULT_AUTH) ]
 charon-nm[5070]: 01[CFG] đề xuất đã chọn: IKE:AES_GCM_16_256/PRF_HMAC_SHA2_256/ECP_521
 charon-nm[5070]: 01[IKE] máy chủ lưu trữ cục bộ đứng sau NAT, đang gửi các bản cập nhật liên tục
 charon-nm[5070]: 01[IKE] đang gửi yêu cầu chứng chỉ cho "C=VG, O=Surfshark, CN=Surfshark Root CA"
 charon-nm[5070]: 01[IKE] thiết lập CHILD_SA Surfshark IKE2{1}
 charon-nm[5070]: 01[ENC] tạo yêu cầu IKE_AUTH 1 [ IDi N(INIT_CONTACT) CERTREQ SA TSi TSr N(MOBIKE_SUP) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_6_ADDR) N(MULT_AUTH) N(EAP_ONLY) N (MSG_ID_SYN_SUP) ]
 charon-nm[5070]: 01[NET] gửi gói: từ 192.168.2.35[58480] đến 92.38.138.139[4500] (438 byte)
 charon-nm[5070]: 07[NET] gói đã nhận: từ 92.38.138.139[4500] đến 192.168.2.35[58480] (1248 byte)
 charon-nm[5070]: 07[ENC] đã phân tích cú pháp phản hồi IKE_AUTH 1 [ EF(1/3) ]
 charon-nm[5070]: 07[ENC] đã nhận được đoạn số 1 trên 3, đang chờ thông báo IKE hoàn chỉnh
 charon-nm[5070]: 08[NET] gói đã nhận: từ 92.38.138.139[4500] đến 192.168.2.35[58480] (1248 byte)
 charon-nm[5070]: 08[ENC] đã phân tích cú pháp phản hồi IKE_AUTH 1 [ EF(2/3) ]
 charon-nm[5070]: 08[ENC] đã nhận được đoạn #2 trên 3, đang chờ thông báo IKE hoàn chỉnh
 charon-nm[5070]: 09[NET] gói đã nhận: từ 92.38.138.139[4500] đến 192.168.2.35[58480] (579 byte)
 charon-nm[5070]: 09[ENC] đã phân tích cú pháp phản hồi IKE_AUTH 1 [ EF(3/3) ]
 charon-nm[5070]: 09[ENC] đã nhận được đoạn số 3 trên 3, đã ghép lại thông báo IKE bị phân mảnh (2949 byte)
 charon-nm[5070]: 09[ENC] đã phân tích cú pháp phản hồi IKE_AUTH 1 [ IDr CERT CERT AUTH EAP/REQ/ID ]
 charon-nm[5070]: 09[IKE] đã nhận được chứng chỉ thực thể cuối "CN=ru-mos.prod.surfshark.com"
 charon-nm[5070]: 09[IKE] đã nhận được chứng nhận của nhà phát hành "C=VG, O=Surfshark, CN=Surfshark Trung cấp CA"
 charon-nm[5070]: 09[CFG] sử dụng chứng chỉ "CN=ru-mos.prod.surfshark.com"
 charon-nm[5070]: 09[CFG] sử dụng chứng chỉ trung gian không đáng tin cậy "C=VG, O=Surfshark, CN=Surfshark CA trung gian"
 charon-nm[5070]: 09[CFG] kiểm tra trạng thái chứng chỉ của "CN=ru-mos.prod.surfshark.com"
 charon-nm[5070]: 09[CFG] trạng thái chứng chỉ không khả dụng
 charon-nm[5070]: 09[CFG] sử dụng chứng chỉ ca đáng tin cậy "C=VG, O=Surfshark, CN=Surfshark Root CA"
 charon-nm[5070]: 09[CFG] kiểm tra trạng thái chứng chỉ của "C=VG, O=Surfshark, CN=Surfshark CA trung gian"
 charon-nm[5070]: 09[CFG] trạng thái chứng chỉ không khả dụng
 charon-nm[5070]: 09[CFG] đã đạt đến gốc ca tự ký với độ dài đường dẫn là 1
 charon-nm[5070]: 09[IKE] xác thực 'ru-mos.prod.surfshark.com' với RSA_EMSA_PKCS1_SHA2_256 thành công
 charon-nm[5070]: 09[IKE] máy chủ yêu cầu EAP_IDENTITY (id 0x00), gửi 'mYidENTitY'
 charon-nm[5070]: 09[ENC] tạo yêu cầu IKE_AUTH 2 [ EAP/RES/ID ]
 charon-nm[5070]: 09[NET] gửi gói: từ 192.168.2.35[58480] đến 92.38.138.139[4500] (90 byte)
 charon-nm[5070]: 10[NET] gói đã nhận: từ 92.38.138.139[4500] đến 192.168.2.35[58480] (67 byte)
 charon-nm[5070]: 10[ENC] đã phân tích cú pháp phản hồi IKE_AUTH 2 [ EAP/REQ/PEAP ]
 charon-nm[5070]: 10[IKE] máy chủ đã yêu cầu xác thực EAP_PEAP (id 0x01)
 charon-nm[5070]: 10[TLS] Phiên bản EAP_PEAP là v0
 charon-nm[5070]: 10[ENC] tạo yêu cầu IKE_AUTH 3 [ EAP/RES/PEAP ]
 charon-nm[5070]: 10[NET] gửi gói: từ 192.168.2.35[58480] đến 92.38.138.139[4500] (275 byte)
 charon-nm[5070]: 11[NET] gói đã nhận: từ 92.38.138.139[4500] đến 192.168.2.35[58480] (1065 byte)
 charon-nm[5070]: 11[ENC] đã phân tích cú pháp phản hồi IKE_AUTH 3 [ EAP/REQ/PEAP ]
 charon-nm[5070]: 11[TLS] đã thương lượng TLS 1.2 bằng bộ TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
 charon-nm[5070]: 11[ENC] tạo yêu cầu IKE_AUTH 4 [ EAP/RES/PEAP ]
 charon-nm[5070]: 11[NET] gửi gói: từ 192.168.2.35[58480] đến 92.38.138.139[4500] (67 byte)
 charon-nm[5070]: 12[NET] gói đã nhận: từ 92.38.138.139[4500] đến 192.168.2.35[58480] (1061 byte)
 charon-nm[5070]: 12[ENC] đã phân tích cú pháp phản hồi IKE_AUTH 4 [ EAP/REQ/PEAP ]
 charon-nm[5070]: 12[ENC] tạo yêu cầu IKE_AUTH 5 [ EAP/RES/PEAP ]
 charon-nm[5070]: 12[NET] gửi gói: từ 192.168.2.35[58480] đến 92.38.138.139[4500] (67 byte)
 charon-nm[5070]: 13[NET] gói đã nhận: từ 92.38.138.139[4500] đến 192.168.2.35[58480] (747 byte)
 charon-nm[5070]: 13[ENC] đã phân tích cú pháp phản hồi IKE_AUTH 5 [ EAP/REQ/PEAP ]
 charon-nm[5070]: 13[TLS] đã nhận chứng chỉ máy chủ TLS 'C=FR, ST=Radius, O=Example Inc., CN=Example Server Certificate, [email protected]'
 charon-nm[5070]: 13[TLS] đã nhận được chứng chỉ trung gian TLS 'C=FR, ST=Radius, L=Somewhere, O=Example Inc., [email protected], CN=Cơ quan cấp chứng chỉ mẫu'
 charon-nm[5070]: 13[CFG] sử dụng chứng chỉ "C=FR, ST=Radius, O=Example Inc., CN=Chứng chỉ máy chủ mẫu, [email protected]"
 charon-nm[5070]: 13[CFG] sử dụng chứng chỉ trung gian không tin cậy "C=FR, ST=Radius, L=Somewhere, O=Example Inc., [email protected], CN=Example Certificate Authority"
 charon-nm[5070]: 13[CFG] chứng chỉ đối tượng không hợp lệ (có hiệu lực từ ngày 12 tháng 4 17:41:01 năm 2021 đến ngày 11 tháng 6 17:41:01 năm 2021)
 charon-nm[5070]: 13[TLS] không tìm thấy khóa công khai TLS cho máy chủ '%any'
 charon-nm[5070]: 13[TLS] gửi cảnh báo TLS nghiêm trọng 'chứng chỉ không xác định'
 charon-nm[5070]: 13[ENC] tạo yêu cầu IKE_AUTH 6 [ EAP/RES/PEAP ]
 charon-nm[5070]: 13[NET] gửi gói: từ 192.168.2.35[58480] đến 92.38.138.139[4500] (74 byte)
 charon-nm[5070]: 14[NET] gói đã nhận: từ 92.38.138.139[4500] đến 192.168.2.35[58480] (65 byte)
 charon-nm[5070]: 14[ENC] đã phân tích phản hồi IKE_AUTH 6 [ EAP/FAIL ]
 charon-nm[5070]: 14[IKE] đã nhận EAP_FAILURE, xác thực EAP không thành công

Mọi thứ có vẻ ổn cho đến khi phản hồi 5, tôi nhận được một số chứng chỉ kỳ lạ. Tôi không biết chính xác giao thức PEAP hoạt động như thế nào và điều gì sẽ xảy ra ở bước đó, nhưng kết nối hoạt động trên windows, vì vậy tôi cho rằng có vấn đề ở phía tôi.

Điểm:1
lá cờ cn
charon-nm[5070]: 13[CFG] chứng chỉ đối tượng không hợp lệ (có hiệu lực từ ngày 12 tháng 4 17:41:01 năm 2021 đến ngày 11 tháng 6 17:41:01 năm 2021)

Rõ ràng, chứng chỉ của máy chủ RADIUS yêu cầu EAP-PEAP đã hết hạn, nhưng chủ đề với tất cả nội dung "ví dụ" đó trông có vẻ kỳ lạ (trừ khi bạn đã sửa đổi điều đó). Tại sao Windows lại chấp nhận điều đó, nếu nó thực sự sử dụng EAP-PEAP thì tôi không biết.

Bạn có thể thử vô hiệu hóa eap-peap plugin và hy vọng máy chủ hỗ trợ các phương thức EAP khác (ví dụ: EAP-MD5 hoặc EAP-MSCHAPv2). Để làm như vậy, hãy thêm phần sau vào Strongswan.conf:

charon-nm {
  bổ sung {
    eap-peap {
      tải = không
    }
  }
}
lá cờ us
Đúng, vô hiệu hóa eap-peap đã hoạt động. Về cơ bản, mọi giao thức khác đều hoạt động. Có thể có lý do tại sao cấu hình eap-peap cụ thể bị hỏng không? Tôi không nghĩ họ cố tình làm vậy. Ngoài ra, có cách nào để tắt plugin chỉ cho một kết nối không? Thật sai lầm khi vô hiệu hóa nó trên toàn hệ thống chỉ cho một máy chủ. Điều đó không thành vấn đề đối với tôi, vì tôi không định tạo các kết nối IKEv2 khác, nhưng vẫn vậy.
lá cờ cn
Công cụ "ví dụ" đó trông giống như chứng chỉ kiểm tra. Vì vậy, có thể họ thậm chí không biết rằng nó vẫn được bật hoặc định cấu hình sai (có thể nó chỉ hoạt động với các ứng dụng khách khác, vì họ bỏ qua chứng chỉ hoặc họ không hỗ trợ EAP-PEAP). Tuy nhiên, đó là phương thức đầu tiên mà máy chủ yêu cầu, không phải là nó yêu cầu một phương thức khác và máy khách yêu cầu chuyển sang phương thức đó. Các phương thức EAP khác (ví dụ: những phương thức tôi đã liệt kê ở trên) không sử dụng chứng chỉ trên máy chủ RADIUS, vì vậy... Và không, không thể tắt các phương thức EAP trên mỗi kết nối. Có thể chọn một phương thức trong cấu hình kết nối, nhưng không thể chọn qua NM.

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.