OpenVPN ปฏิเสธบรรทัดแรกหรือไม่ ไฟล์น่าจะเป็น UTF-16

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

ความเชื่อผิด: โปรแกรมแก้ไขแสดงไฟล์ให้คุณเห็น

โปรแกรมแก้ไขข้อความถอดรหัสไบต์เป็นอักขระด้วยการเข้ารหัสที่มันตรวจพบหรือเดาขึ้นมา เมื่อมันเดาว่าเป็น UTF-16 ไฟล์ดูสมบูรณ์บนหน้าจอ ขณะที่ไบต์ข้างใต้เป็นคู่ โดยมีไบต์ศูนย์ตามหลังตัวอักษรละตินทุกตัว OpenVPN อ่านไบต์เหล่านั้นเป็นอักขระ และความไม่ตรงกันจะปรากฏที่คำสั่งแรกที่มันพยายามแยกวิเคราะห์

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

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

ไบต์แรกบอกอะไรจริงๆ

อ่านไบต์แทนอักขระ สองคำสั่งเล็กๆ ตัดสินเรื่องนี้ได้ในไม่กี่วินาที และทั้งสองไม่ต้องเปิดไฟล์ในแอปที่อาจเปลี่ยนแปลงมัน:

file client.ovpn
head -c 24 client.ovpn | od -An -tx1

รูปแบบที่คุณกำลังมองหาคือไบต์นำสองไบต์ตามด้วยข้อความที่ไบต์เว้นไบต์เป็นศูนย์ FF FE หมายถึง UTF-16 ลิตเทิลเอนเดียน FE FF หมายถึงบิกเอนเดียน และ EF BB BF หมายถึง UTF-8 ที่มีเครื่องหมายลำดับไบต์ ไฟล์ UTF-8 ธรรมดาที่ไม่มีเครื่องหมายจะเริ่มด้วยไบต์ของตัวอักษรตัวแรกโดยตรง

ไบต์ศูนย์ระหว่างตัวอักษรคือเบาะแส ใน UTF-16 ลิตเทิลเอนเดียน คำว่า client ใช้พื้นที่สิบสองไบต์แทนที่จะเป็นหก เพราะอักขระ ASCII ทุกตัวมีศูนย์ตามหลัง โครงสร้างนั้นหน้าจอของโปรแกรมแก้ไขแสดงให้คุณเห็นไม่ได้ และการลบสองไบต์ก็ลบมันออกไม่ได้

ที่นี่มีจุดละเอียดอ่อนสำคัญ: ตัวอ่านการกำหนดค่าของ OpenVPN ข้ามเครื่องหมายลำดับไบต์ UTF-8 ที่ต้นไฟล์จริง ตามที่ ตัวอ่านการกำหนดค่า 2.6 แสดง ความผ่อนปรนนั้นเฉพาะกับเครื่องหมายนั้น และไม่ทำอะไรกับไฟล์ UTF-16 ที่ตัวอักษรถูกเติมด้วยศูนย์ การถือว่าเครื่องหมายทั้งสองเป็นปัญหาเดียวกันคือครึ่งหลังของความเชื่อผิด

การแปลงคือบันทึกเป็น ไม่ใช่ลบ

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

จากนั้นทำการแปลงการเข้ารหัสจริง ไม่ว่าจะผ่านเมนูการเข้ารหัสที่ชัดเจนของโปรแกรมแก้ไข หรือด้วยตัวแปลงที่ระบุการเข้ารหัสขาเข้าและขาออก:

iconv -f UTF-16 -t UTF-8 client.ovpn > client-utf8.ovpn
file client-utf8.ovpn

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

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

สิ่งที่การเข้ารหัสที่แก้แล้วไม่ได้แก้

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

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

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