Score:0

ไม่สามารถเริ่มการเชื่อมต่อ IKEv2 VPN กับ surfshark ผ่าน NetworkManager

ธง us

ฉันพยายามเชื่อมต่อกับผู้ให้บริการ surfshark VPN ผ่าน IKEv2 ด้วยตนเอง นี่คือบันทึก

 charon-nm[5070]: 05[CFG] ได้รับการเริ่มต้นสำหรับการเชื่อมต่อ NetworkManager Surfshark IKE2
 charon-nm[5070]: 05[CFG] โดยใช้ข้อมูลประจำตัวของเกตเวย์ 'ru-mos.prod.surfshark.com'
 charon-nm[5070]: 05[IKE] เริ่มต้น IKE_SA Surfshark IKE2[1] เป็น 92.38.138.139
 charon-nm[5070]: 05[ENC] กำลังสร้างคำขอ IKE_SA_INIT 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
 charon-nm[5070]: 05[NET] ส่งแพ็คเก็ต: จาก 192.168.2.35[35071] ถึง 92.38.138.139[500] (1096 ไบต์)
 NetworkManager[4583]: <info> [1636055533.4566] vpn-connection[0x56150178a510,6c89b390-d6ee-47d8-a547-346f75797487,"Surfshark IKE2",0]: ปลั๊กอิน VPN: เปลี่ยนสถานะแล้ว: เริ่มต้น (3)
 charon-nm[5070]: 15[NET] ได้รับแพ็กเก็ต: จาก 92.38.138.139[500] ถึง 192.168.2.35[35071] (38 ไบต์)
 charon-nm[5070]: 15[ENC] แยกวิเคราะห์การตอบสนอง IKE_SA_INIT 0 [ N(INVAL_KE) ]
 charon-nm[5070]: 15 [IKE] เพียร์ไม่ยอมรับกลุ่ม DH ECP_256 มันร้องขอ ECP_521
 charon-nm[5070]: 15[IKE] เริ่มต้น IKE_SA Surfshark IKE2[1] เป็น 92.38.138.139
 charon-nm[5070]: 15[ENC] กำลังสร้างคำขอ IKE_SA_INIT 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
 charon-nm[5070]: 15[NET] ส่งแพ็คเก็ต: จาก 192.168.2.35[35071] ถึง 92.38.138.139[500] (1164 ไบต์)
 charon-nm[5070]: 01[NET] ได้รับแพ็กเก็ต: จาก 92.38.138.139[500] ถึง 192.168.2.35[35071] (332 ไบต์)
 charon-nm[5070]: 01[ENC] แยกวิเคราะห์การตอบสนอง IKE_SA_INIT 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(MULT_AUTH) ]
 charon-nm[5070]: 01[CFG] ข้อเสนอที่เลือก: IKE:AES_GCM_16_256/PRF_HMAC_SHA2_256/ECP_521
 charon-nm[5070]: โลคัลโฮสต์ 01[IKE] อยู่เบื้องหลัง NAT กำลังส่ง Keep Lives
 charon-nm[5070]: 01[IKE] กำลังส่งคำขอใบรับรองสำหรับ "C=VG, O=Surfshark, CN=Surfshark Root CA"
 charon-nm[5070]: 01[IKE] กำลังสร้าง CHILD_SA Surfshark IKE2{1}
 charon-nm[5070]: 01[ENC] กำลังสร้างคำขอ 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] ส่งแพ็คเก็ต: จาก 192.168.2.35[58480] ถึง 92.38.138.139[4500] (438 ไบต์)
 charon-nm[5070]: 07[NET] ได้รับแพ็กเก็ต: จาก 92.38.138.139[4500] ถึง 192.168.2.35[58480] (1248 ไบต์)
 charon-nm[5070]: 07[ENC] แยกวิเคราะห์การตอบสนอง IKE_AUTH 1 [ EF(1/3) ]
 charon-nm[5070]: 07[ENC] ได้รับแฟรกเมนต์ #1 จาก 3 กำลังรอข้อความ IKE ที่สมบูรณ์
 charon-nm[5070]: 08[NET] ได้รับแพ็กเก็ต: จาก 92.38.138.139[4500] ถึง 192.168.2.35[58480] (1248 ไบต์)
 charon-nm[5070]: 08[ENC] แยกวิเคราะห์การตอบสนอง IKE_AUTH 1 [ EF(2/3) ]
 charon-nm[5070]: 08[ENC] ได้รับแฟรกเมนต์ #2 จาก 3 กำลังรอข้อความ IKE ที่สมบูรณ์
 charon-nm[5070]: 09[NET] ได้รับแพ็กเก็ต: จาก 92.38.138.139[4500] ถึง 192.168.2.35[58480] (579 ไบต์)
 charon-nm[5070]: 09[ENC] แยกวิเคราะห์การตอบสนอง IKE_AUTH 1 [ EF(3/3) ]
 charon-nm[5070]: 09[ENC] ได้รับแฟรกเมนต์ #3 จาก 3 ประกอบข้อความ IKE ที่แยกส่วนแล้ว (2949 ไบต์)
 charon-nm[5070]: 09[ENC] แยกวิเคราะห์การตอบสนอง IKE_AUTH 1 [ IDr CERT CERT AUTH EAP/REQ/ID ]
 charon-nm[5070]: 09[IKE] ได้รับใบรับรองเอนทิตีปลายทาง "CN=ru-mos.prod.surfshark.com"
 charon-nm[5070]: 09[IKE] ได้รับใบรับรองผู้ออก "C=VG, O=Surfshark, CN=Surfshark Intermediate CA"
 charon-nm[5070]: 09[CFG] โดยใช้ใบรับรอง "CN=ru-mos.prod.surfshark.com"
 charon-nm[5070]: 09[CFG] โดยใช้ใบรับรองระดับกลางที่ไม่น่าเชื่อถือ "C=VG, O=Surfshark, CN=Surfshark Intermediate CA"
 charon-nm[5070]: 09[CFG] กำลังตรวจสอบสถานะใบรับรองของ "CN=ru-mos.prod.surfshark.com"
 charon-nm[5070]: ไม่มีสถานะใบรับรอง 09[CFG]
 charon-nm[5070]: 09[CFG] โดยใช้ใบรับรอง ca ที่เชื่อถือได้ "C=VG, O=Surfshark, CN=Surfshark Root CA"
 charon-nm[5070]: 09[CFG] กำลังตรวจสอบสถานะใบรับรองของ "C=VG, O=Surfshark, CN=Surfshark Intermediate CA"
 charon-nm[5070]: ไม่มีสถานะใบรับรอง 09[CFG]
 charon-nm[5070]: 09[CFG] ถึง root ca ที่ลงนามด้วยตนเองโดยมีความยาวพาธ 1
 charon-nm[5070]: 09[IKE] รับรองความถูกต้องของ 'ru-mos.prod.surfshark.com' ด้วย RSA_EMSA_PKCS1_SHA2_256 สำเร็จ
 charon-nm[5070]: เซิร์ฟเวอร์ 09[IKE] ขอ EAP_IDENTITY (id 0x00) ส่ง 'mYidENtitY'
 charon-nm[5070]: 09[ENC] กำลังสร้างคำขอ IKE_AUTH 2 [ EAP/RES/ID ]
 charon-nm[5070]: 09[NET] ส่งแพ็คเก็ต: จาก 192.168.2.35[58480] ถึง 92.38.138.139[4500] (90 ไบต์)
 charon-nm[5070]: 10[NET] ได้รับแพ็กเก็ต: จาก 92.38.138.139[4500] ถึง 192.168.2.35[58480] (67 ไบต์)
 charon-nm[5070]: 10[ENC] แยกวิเคราะห์การตอบสนอง IKE_AUTH 2 [ EAP/REQ/PEAP ]
 charon-nm[5070]: เซิร์ฟเวอร์ 10 [IKE] ขอการรับรองความถูกต้อง EAP_PEAP (id 0x01)
 charon-nm[5070]: 10[TLS] รุ่น EAP_PEAP คือ v0
 charon-nm[5070]: 10[ENC] กำลังสร้างคำขอ IKE_AUTH 3 [ EAP/RES/PEAP ]
 charon-nm[5070]: 10[NET] ส่งแพ็กเก็ต: จาก 192.168.2.35[58480] ถึง 92.38.138.139[4500] (275 ไบต์)
 charon-nm[5070]: 11[NET] ได้รับแพ็กเก็ต: จาก 92.38.138.139[4500] ถึง 192.168.2.35[58480] (1065 ไบต์)
 charon-nm[5070]: 11[ENC] แยกวิเคราะห์การตอบสนอง IKE_AUTH 3 [ EAP/REQ/PEAP ]
 charon-nm[5070]: 11[TLS] เจรจา TLS 1.2 โดยใช้ชุด TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
 charon-nm[5070]: 11[ENC] กำลังสร้างคำขอ IKE_AUTH 4 [ EAP/RES/PEAP ]
 charon-nm[5070]: 11[NET] ส่งแพ็คเก็ต: จาก 192.168.2.35[58480] ถึง 92.38.138.139[4500] (67 ไบต์)
 charon-nm[5070]: 12[NET] ได้รับแพ็กเก็ต: จาก 92.38.138.139[4500] ถึง 192.168.2.35[58480] (1061 ไบต์)
 charon-nm[5070]: 12[ENC] แยกวิเคราะห์การตอบสนอง IKE_AUTH 4 [ EAP/REQ/PEAP ]
 charon-nm[5070]: 12[ENC] กำลังสร้างคำขอ IKE_AUTH 5 [ EAP/RES/PEAP ]
 charon-nm[5070]: 12[NET] ส่งแพ็คเก็ต: จาก 192.168.2.35[58480] ถึง 92.38.138.139[4500] (67 ไบต์)
 charon-nm[5070]: 13[NET] ได้รับแพ็กเก็ต: จาก 92.38.138.139[4500] ถึง 192.168.2.35[58480] (747 ไบต์)
 charon-nm[5070]: 13[ENC] แยกวิเคราะห์การตอบสนอง IKE_AUTH 5 [ EAP/REQ/PEAP ]
 charon-nm[5070]: 13[TLS] ได้รับใบรับรองเซิร์ฟเวอร์ TLS 'C=FR, ST=Radius, O=Example Inc., CN=Example Server Certificate, [email protected]'
 charon-nm[5070]: 13[TLS] ได้รับใบรับรองระดับกลาง TLS 'C=FR, ST=Radius, L=Somewhere, O=Example Inc., [email protected], CN=Example Certificate Authority'
 charon-nm[5070]: 13[CFG] โดยใช้ใบรับรอง "C=FR, ST=Radius, O=Example Inc., CN=Example Server Certificate, [email protected]"
 charon-nm[5070]: 13[CFG] โดยใช้ใบรับรองระดับกลางที่ไม่น่าเชื่อถือ "C=FR, ST=Radius, L=Somewhere, O=Example Inc., [email protected], CN=Example Certificate Authority"
 charon-nm[5070]: ใบรับรองเรื่อง 13[CFG] ไม่ถูกต้อง (ใช้ได้ตั้งแต่ 12 เม.ย. 17:41:01 น. 2021 ถึง 11 มิ.ย. 17:41:01 2021)
 charon-nm[5070]: 13[TLS] ไม่พบคีย์สาธารณะ TLS สำหรับเซิร์ฟเวอร์ '%any'
 charon-nm[5070]: 13[TLS] ส่งการแจ้งเตือน TLS ที่ร้ายแรง 'ใบรับรองที่ไม่รู้จัก'
 charon-nm[5070]: 13[ENC] กำลังสร้างคำขอ IKE_AUTH 6 [ EAP/RES/PEAP ]
 charon-nm[5070]: 13[NET] ส่งแพ็คเก็ต: จาก 192.168.2.35[58480] ถึง 92.38.138.139[4500] (74 ไบต์)
 charon-nm[5070]: 14[NET] ได้รับแพ็กเก็ต: จาก 92.38.138.139[4500] ถึง 192.168.2.35[58480] (65 ไบต์)
 charon-nm[5070]: 14[ENC] แยกวิเคราะห์การตอบสนอง IKE_AUTH 6 [ EAP/FAIL ]
 charon-nm[5070]: 14[IKE] ได้รับ EAP_FAILURE การตรวจสอบสิทธิ์ EAP ล้มเหลว

ทุกอย่างดูดีจนกระทั่งเมื่อตอบกลับ 5 ฉันได้รับใบรับรองแปลก ๆ ฉันไม่รู้ว่าโปรโตคอล PEAP ทำงานอย่างไร และควรจะเกิดอะไรขึ้นในขั้นตอนนั้น แต่การเชื่อมต่อใช้งานได้บน windows ดังนั้นฉันจึงถือว่ามีปัญหาที่ฝั่งของฉัน

Score:1
ธง cn
charon-nm[5070]: ใบรับรองเรื่อง 13[CFG] ไม่ถูกต้อง (ใช้ได้ตั้งแต่ 12 เม.ย. 17:41:01 น. 2021 ถึง 11 มิ.ย. 17:41:01 2021)

เห็นได้ชัดว่าใบรับรองของเซิร์ฟเวอร์ RADIUS ที่ร้องขอ EAP-PEAP หมดอายุแล้ว แต่หัวเรื่องที่มีเนื้อหา "ตัวอย่าง" ทั้งหมดนั้นดูแปลก ๆ อยู่ดี (เว้นแต่คุณจะแก้ไข) ทำไม Windows ถึงยอมรับเช่นนั้น ถ้ามันใช้ EAP-PEAP จริง ๆ ฉันก็ไม่รู้

คุณสามารถลองปิดการใช้งาน eap-peap ปลั๊กอินและหวังว่าเซิร์ฟเวอร์จะสนับสนุนวิธี EAP อื่นๆ (เช่น EAP-MD5 หรือ EAP-MSCHAPv2) ในการดำเนินการดังกล่าวให้เพิ่มสิ่งต่อไปนี้ strongswan.conf:

ชารอน-นาโนเมตร {
  ปลั๊กอิน {
    eap-peap {
      โหลด = ไม่
    }
  }
}
us flag
ใช่ การปิดใช้งาน eap-peap ได้ผล โดยพื้นฐานแล้วโปรโตคอลอื่น ๆ ใช้งานได้ อาจมีเหตุผลว่าทำไมการกำหนดค่า eap-peap โดยเฉพาะจึงใช้งานไม่ได้ ฉันไม่คิดว่าพวกเขาทำมันโดยเจตนา นอกจากนี้ยังมีวิธีปิดใช้งานปลั๊กอินสำหรับการเชื่อมต่อเพียงครั้งเดียวหรือไม่ รู้สึกผิดที่จะปิดการใช้งานทั้งระบบสำหรับเซิร์ฟเวอร์เพียงเครื่องเดียว ไม่สำคัญสำหรับฉัน เนื่องจากฉันไม่ได้วางแผนที่จะสร้างการเชื่อมต่อ IKEv2 อื่นๆ แต่ถึงกระนั้น
cn flag
สิ่งที่ "ตัวอย่าง" นั้นดูเหมือนใบรับรองการทดสอบ ดังนั้นพวกเขาอาจไม่รู้ด้วยซ้ำว่ายังเปิดใช้งานอยู่หรือกำหนดค่าผิด (เป็นไปได้ว่าไคลเอ็นต์ใช้งานได้กับไคลเอ็นต์อื่นเท่านั้น อาจเป็นเพราะพวกเขาเพิกเฉยต่อใบรับรองหรือไม่รองรับ EAP-PEAP) เป็นวิธีแรกที่เซิร์ฟเวอร์ร้องขอ แต่ไม่ใช่ว่าขอวิธีอื่นและไคลเอ็นต์ต้องการเปลี่ยนไปใช้ เมธอด EAP อื่นๆ (เช่น ฉันระบุไว้ด้านบน) ไม่ใช้ใบรับรองบนเซิร์ฟเวอร์ RADIUS ดังนั้น... และไม่ เมธอด EAP ไม่สามารถปิดใช้งานได้ต่อการเชื่อมต่อ สามารถเลือกวิธีการในการกำหนดค่าการเชื่อมต่อได้ แต่เลือกผ่าน NM ไม่ได้

โพสต์คำตอบ

คนส่วนใหญ่ไม่เข้าใจว่าการถามคำถามมากมายจะปลดล็อกการเรียนรู้และปรับปรุงความสัมพันธ์ระหว่างบุคคล ตัวอย่างเช่น ในการศึกษาของ Alison แม้ว่าผู้คนจะจำได้อย่างแม่นยำว่ามีคำถามกี่ข้อที่ถูกถามในการสนทนา แต่พวกเขาไม่เข้าใจความเชื่อมโยงระหว่างคำถามและความชอบ จากการศึกษาทั้ง 4 เรื่องที่ผู้เข้าร่วมมีส่วนร่วมในการสนทนาด้วยตนเองหรืออ่านบันทึกการสนทนาของผู้อื่น ผู้คนมักไม่ตระหนักว่าการถามคำถามจะมีอิทธิพลหรือมีอิทธิพลต่อระดับมิตรภาพระหว่างผู้สนทนา