ทำไม OpenVPN ยังขอไฟล์คีย์ส่วนตัวทั้งที่มีโทเค็น
โปรไฟล์อาจไม่เคยระบุโทเค็นเลย แยกไลบรารีของผู้ให้บริการออกจากตัวตนที่ทำให้เป็นอนุกรมของใบรับรอง แล้วทดสอบจากโปรเซสที่เชื่อมต่อ
คุณเสียบโทเค็น เครื่องมือของผู้ให้บริการเองมองเห็นมัน แต่ไคลเอนต์ VPN ยังคงขอไฟล์คีย์ส่วนตัว การขอเช่นนั้นไม่ใช่หลักฐานว่าโทเค็นไม่รองรับ โดยปกติหมายความว่าโปรไฟล์ไม่เคยบอกไคลเอนต์ให้ใช้โทเค็นเลย จึงย้อนกลับไปที่ช่องป้อนใบรับรองและคีย์ที่คาดไว้ตามค่าเริ่มต้น
ค่าสองอย่างที่แยกจากกันต้องถูกต้องก่อนการย้อนกลับนั้นจะหยุด: ผู้ให้บริการที่เปิดเผยโทเค็น และตัวตนของใบรับรองที่อยู่ข้างใน ทั้งสองถูกกำหนดด้วยออปชันต่างกันและทำให้สับสนได้ง่าย
ไคลเอนต์ขอไฟล์เพราะโปรไฟล์สั่งไว้
โปรไฟล์เริ่มต้นคาดว่าจะมีไฟล์ใบรับรองและไฟล์คีย์ส่วนตัว หรือแพ็กเกจ PKCS#12 เดียว เมื่อช่องป้อนเหล่านั้นหายไป ไคลเอนต์ก็ไม่มีอะไรจะโหลด และ ทำงานแทบจะเหมือนกรณีไฟล์หาย จึงทำให้อาการถูกอ่านเป็นเส้นทางที่เสียหายมากกว่ากลไกที่หายไป เส้นทาง PKCS#11 เข้าแทนที่ช่องป้อนเหล่านั้นแทนที่จะเสริม จึงทำให้โปรไฟล์ที่ยังระบุไฟล์คีย์จะยังคงใช้ไฟล์นั้นต่อไป จงเอาช่องป้อนไฟล์ออกอย่างตั้งใจและปล่อยให้โทเค็นจัดหาทั้งสองส่วน
ออปชันของผู้ให้บริการระบุชื่อไลบรารีมิดเดิลแวร์ ไม่ใช่อุปกรณ์และไม่ใช่ใบรับรอง การที่ไคลเอนต์ที่แพ็กเกจมาจะโหลดไลบรารีนั้นได้หรือไม่ขึ้นกับวิธีที่มันถูกสร้าง รวมถึงการรองรับ p11-kit แบบเลือกได้ที่บางบิลด์เปิดใช้และบางบิลด์ละไว้ บทช่วยสอนทั่วไปไม่สามารถบอกได้ว่าแพ็กเกจของคุณมีการจัดวางแบบใด
ตัวตนที่ทำให้เป็นอนุกรมเป็นค่าที่ต่างออกไป
ตัวตนของใบรับรองคือสตริงที่ทำให้เป็นอนุกรมยาว ๆ ซึ่งกระบวนการค้นหาสร้างขึ้น และไม่ใช่เส้นทางไลบรารี ไม่ใช่ PIN ของโทเค็น และไม่ใช่ชื่อบัญชี VPN มันมักมีอักขระที่ต้องใส่เครื่องหมายคำพูด และค่าที่ไม่ใส่เครื่องหมายคำพูดอาจถูกตัดหรืออ่านผิดโดยไม่มีข้อผิดพลาดชัดเจน ใช้ออปชัน การค้นหาตัวตน ของไคลเอนต์เองเพื่อแสดงรายการสิ่งที่โทเค็นเปิดเผย แล้วคัดลอกข้อมูลที่ต้องการอย่างแม่นยำ การเลือกวัตถุแรกในรายการคือวิธีที่อุปกรณ์ลงเอยด้วยการนำเสนอใบรับรองผิดใบ
ผลลัพธ์ของการค้นหายังตอบคำถามก่อนหน้าด้วย: โทเค็นมองเห็นผ่านผู้ให้บริการนั้นหรือไม่เลย หากไม่แสดงรายการอะไรเลย ปัญหาอยู่เหนือไคลเอนต์ VPN และเป็นของมิดเดิลแวร์
โปรเซสที่เชื่อมต่อต้องเข้าถึงโทเค็นได้
การทำงานกับโทเค็นที่สำเร็จในเซสชันเดสก์ท็อปของคุณไม่ได้พิสูจน์อะไรเกี่ยวกับบริการของระบบ บริการอาจทำงานในชื่อผู้ใช้อื่น ในเนมสเปซการเมานต์อื่น ด้วยเส้นทางโมดูลที่ละไลบรารีของผู้ให้บริการ หรือไม่มีสิทธิ์เปิดโหนดของอุปกรณ์ ระบุว่าโปรเซสใดถือการเชื่อมต่ออยู่จริงและทดสอบจากบริบทนั้น
การจัดการ PIN สมควรได้รับการตัดสินใจแยกต่างหาก การอ้างอิงการใช้งานมีแคช PIN และเส้นทางการพิสูจน์ตัวตนที่ได้รับการป้องกัน และทั้งสองมีอยู่เพื่อให้ผู้ปฏิบัติงานเลือกเวิร์กโฟลว์แทนที่จะคิดค้นขึ้นมาเอง อย่าเปลี่ยนข้อกำหนดที่ไม่ต้องมีคนเฝ้าให้เป็น PIN แบบข้อความธรรมดาในโปรไฟล์ที่แชร์ เพราะนั่นแลกการปกป้องของโทเค็นกับความสะดวก ในกรณีที่โทเค็นห้ามส่งออกคีย์ การลงลายมือชื่อจะเกิดขึ้นบนอุปกรณ์และ PIN คือความลับภายในเครื่องเดียว ควรปฏิบัติต่อมันด้วยความระมัดระวังตามที่ควร
สิ่งที่โทเค็นไม่ได้แทนที่
โทเค็นพิสูจน์ตัวตนไคลเอนต์ภายใต้นโยบายที่ปรับใช้ และไม่ได้แทนที่การตรวจสอบของไคลเอนต์ต่อเซิร์ฟเวอร์ ใบรับรองที่เลือกได้สำเร็จไม่ใช่สิทธิ์ในการยอมรับใบรับรองเกตเวย์ที่ไม่คาดคิด และการตรวจสอบทั้งสองปกป้องทิศทางตรงกันข้าม
การลงทะเบียนยังต้องเกิดขึ้นที่ผู้ออก และเกตเวย์ยังต้องอนุญาตตัวตนนั้น
สำหรับการยอมรับ ให้แยกขั้นตอน: ผู้ให้บริการโหลด ใบรับรองที่ต้องการถูกพบ คีย์ส่วนตัวถูกใช้ด้วยสิทธิ์ภายในเครื่อง VPN พิสูจน์ตัวตน และการดำเนินการกับทรัพยากรสำเร็จ หยุดที่ขั้นตอนแรกที่ล้มเหลวแทนที่จะวนผ่านรหัสผ่านและติดตั้งสแตกการเข้ารหัสใหม่
บันทึกเวอร์ชัน ความเป็นเจ้าของโมดูล ตัวระบุสาธารณะที่เลือก และข้อผิดพลาดที่ทำความสะอาดแล้ว และเก็บ PIN กับชุดข้อมูลรับรองไว้นอกบันทึกนั้น