ตัวเรียกสองตัวเปิดโปรไฟล์เดียวกันบนเครื่องเดียว และมีเพียง GUI ที่เชื่อมต่อได้ ไฟล์ยังสมบูรณ์และตัวติดตั้งน่าจะปกติดี สิ่งที่ต่างกันคือบริบทที่ตัวเรียกแต่ละตัวมอบให้ openvpn.exe ไดเรกทอรีทำงาน ตัวตนของบัญชี และแอตทริบิวต์ของไฟล์ ล้วนเดินทางไปกับบริบทนั้น ตรวจตามลำดับนั้นแล้วหยุดที่จุดแรกที่อธิบายข้อผิดพลาดได้

ยืนยันว่าตัวเรียกตัวไหนล้มเหลว

เริ่มจากการพิสูจน์ความแตกต่างก่อน ถ้า GUI เชื่อมต่อได้แต่เซอร์วิสเชื่อมไม่ได้ด้วยพาธโปรไฟล์เดียวกัน แปลว่ามีใครบางคนอ่านไฟล์ได้ และคำถามก็กลายเป็นว่าใครอ่านและอ่านจากที่ไหน ถ้าทั้งคู่ล้มเหลว โปรไฟล์เสียและทั้งหมดนี้ใช้ไม่ได้ จดชื่อเซอร์วิสและโปรไฟล์ที่มันถูกสั่งให้โหลดไว้ให้แน่ชัด

เซอร์วิสที่ชี้ไปยังไดเรกทอรีเริ่มต้นอัตโนมัติของตัวเองอาจไม่ได้โหลดไฟล์ที่คุณเปิดค้างไว้ในเอดิเตอร์ เปรียบเทียบพาธในการตั้งค่าเซอร์วิสกับพาธใน GUI ทีละอักขระ เพราะชื่อโฟลเดอร์ที่ต่อท้ายหรืออักษรไดรฟ์ที่ต่างกันก็เพียงพอจะพาคุณไปผิดทาง

พาธแบบสัมพัทธ์ถูกแปลงที่ใด

โปรไฟล์ที่อ้างถึง ca.crt หรือสคริปต์ตัวช่วยด้วยชื่อเปล่าๆ จะขอให้ค้นหาโดยอิงจากที่ที่โปรเซสอยู่ GUI เริ่มในโฟลเดอร์การตั้งค่า ชื่อเหล่านั้นจึงแปลงได้ เซอร์วิสที่ผู้จัดการเซอร์วิสเริ่มให้ไม่มีจุดเริ่มต้นแบบนั้น และการค้นหาจะล้มเหลวก่อนที่จะได้อ่านใบรับรองใดๆ นั่นคือเหตุผลที่โปรไฟล์เดียวกันใช้ได้กับตัวเรียกตัวหนึ่งแต่ไม่ใช่กับอีกตัว

กำหนดไดเรกทอรีเริ่มต้นให้ตัวห่อ หรือทำให้ทุกการอ้างอิงเป็นแบบสมบูรณ์ การจำลองบริบทของ GUI บนบรรทัดคำสั่งมีหน้าตาแบบนี้:

openvpn --cd "C:\VPN\profiles\office" --config "C:\VPN\profiles\office\office.ovpn"

การเพิ่มระดับความละเอียดให้คำสั่งนั้นจะแสดงพาธที่ถูกพยายามใช้จริง ทำก่อนจะเปลี่ยนสิทธิ์ เพราะไฟล์ที่หายไปกับการอ่านที่ถูกปฏิเสธต้องแก้ต่างกัน บันทึกเริ่มต้นแยกสองอย่างนี้ไม่ออก ธงเพิ่มอีกหนึ่งตัวช่วยประหยัดเวลาคาดเดาได้หนึ่งชั่วโมง

เมื่อตัวตนของเซอร์วิสอ่านไฟล์ไม่ได้

เซอร์วิสทำงานภายใต้ตัวตนของระบบ ไม่ใช่ตัวตนของคุณ ACL ที่ให้สิทธิ์ควบคุมเต็มแก่ผู้ใช้ของคุณและไม่ให้ใครอื่นจะล้มเหลวตรงนั้น ทั้งที่ทำงานสมบูรณ์ในเซสชันของคุณ โปรไฟล์ที่เก็บไว้บนไดรฟ์ที่เมานต์ไว้หรือแชร์ที่ต้องพิสูจน์ตัวตนก็ล้มเหลวด้วยเหตุผลเดียวกัน ยืนยันสิทธิ์ของไฟล์ก่อนจะไปดูอย่างอื่น

การตรวจคือการอ่านสิทธิ์ที่มีผลจริง บวกกับการลองอ่านในฐานะตัวตนของเซอร์วิส รันส่วนแรกจากพรอมต์ที่ยกระดับสิทธิ์:

icacls "C:\VPN\profiles\office\office.ovpn"

จากนั้นลองอ่านแบบเดียวกันในฐานะตัวตนของเซอร์วิส เช่นด้วย psexec -s -i จาก Sysinternals แล้วดูว่าไฟล์เปิดได้หรือไม่ ถ้าเปิดไม่ได้ การแก้พาธใดๆ ก็ไม่ช่วย แก้ ACL หรือย้ายโปรไฟล์ไปยังตำแหน่งที่ตัวตนของเซอร์วิสอ่านได้

การเข้ารหัสระดับไฟล์เป็นกรณีที่สองที่พบได้น้อยกว่า โปรไฟล์ที่ติดแอตทริบิวต์ Encrypting File System จะถูกถอดรหัสอย่างโปร่งใสสำหรับผู้ใช้ที่เข้ารหัสมัน และยังอ่านไม่ได้สำหรับบัญชีเซอร์วิส นั่นคือเหตุผลที่ไฟล์เดียวกันเปิดได้ในเอดิเตอร์ของคุณแต่ไม่เปิดภายใต้เซอร์วิส

แอตทริบิวต์นี้มองเห็นได้จากพรอมต์ที่ยกระดับสิทธิ์ และการตรวจมันไม่ทำให้โปรไฟล์ถูกเปิด รันทั้งสองคำสั่งแล้วอ่านผลลัพธ์:

cipher /s:"C:\VPN\profiles\office"
attrib "C:\VPN\profiles\office\office.ovpn"

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

การตัดสินว่าใครเป็นเจ้าของอุโมงค์

GUI ขอรหัสผ่านได้และอ่านใบรับรองจากที่เก็บของผู้ใช้คุณได้ เซอร์วิสทำได้ทั้งสองอย่างไม่ได้ ดังนั้นโปรไฟล์ที่พึ่งความลับแบบโต้ตอบจะไม่มีวันเริ่มโดยไม่มีคนเฝ้า ไม่ว่าจะแก้พาธอย่างไรก็ตาม ขีดจำกัดนั้นเป็นการตัดสินใจเชิงออกแบบ ไม่ใช่ข้อบกพร่องที่ต้องหลบเลี่ยง เลือกเจ้าของเพียงรายเดียวก่อนจะแก้อะไรอื่น

ถ้าอุโมงค์ต้องพร้อมก่อนเข้าสู่ระบบ ให้เซอร์วิสมีแหล่งข้อมูลรับรองที่ไม่ต้องมีคนเฝ้าและมีสำเนาโปรไฟล์ของตัวเอง ถ้าต้องการให้มีอยู่เฉพาะตอนคุณอยู่ที่โต๊ะ ให้เก็บไว้ใน GUI และลบสำเนาของเซอร์วิสออก การมีทั้งสองอย่างพร้อมกันคือการตั้งค่าที่ก่อให้เกิดการชนกันของอะแดปเตอร์และเส้นทางซ้ำ

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

ตัวห่อของเซอร์วิสเริ่มอะไรจริงๆ

จุดเข้าเริ่มทำงานของเซอร์วิสคือตัวห่อเล็กๆ ที่อ่านพารามิเตอร์ที่เก็บไว้เองแล้วจึงเริ่ม openvpn.exe เมื่อบรรทัดคำสั่งในบันทึกเหตุการณ์ไม่ตรงกับที่คุณคาด ค่าเหล่านั้นคือสิ่งที่ต้องตรวจ การติดตั้งใหม่จะรีเซ็ตกลับเป็นค่าเริ่มต้นและทำลายหลักฐาน อ่านค่าพวกนั้นก่อน

ค่าเหล่านี้อยู่ในรีจิสทรีภายใต้คีย์ของเซอร์วิสเอง และ sc qc แสดงพาธไบนารีที่ผู้จัดการเซอร์วิสจะเริ่ม เปรียบเทียบพาธนั้นกับการตั้งค่าที่เก็บไว้ของตัวห่อก่อนจะแก้ไขอันใดอันหนึ่ง

การแทนตัวห่อด้วยสคริปต์ที่คุณควบคุมเองนั้นรุกล้ำกว่า แต่จะยุบบรรทัดคำสั่งที่มีผลจริงให้เหลือไฟล์เดียวที่อ่านได้ จบด้วยการรีสตาร์ต แล้วอ่านบันทึกของแต่ละโปรไฟล์จนกว่าบรรทัดเริ่มทำงานสำเร็จบรรทัดแรกจะปรากฏ สถานะเซอร์วิสแบบ “กำลังทำงาน” บอกเพียงว่าตัวห่อยังไม่จบการทำงาน ซึ่งก็เป็นจริงเช่นกันเมื่อโปรเซสลูกของมันตายทันที

บทความที่เกี่ยวข้อง