วิธีแก้ไขปัญหา “การตรวจสอบหลักฐาน WOPI ล้มเหลว” ใน Collabora Online

เริ่มจากระบบที่บันทึกความล้มเหลวไว้

ข้อความ “การตรวจสอบความถูกต้องของหลักฐาน WOPI ล้มเหลว” หมายความว่าโฮสต์ WOPI ไม่สามารถตรวจสอบคำขอที่ลงนามแล้วจาก Collabora Online ได้ ในการตั้งค่า Nextcloud Office ทั่วไป Nextcloud จะเป็นโฮสต์ WOPI และ Collabora จะเป็นไคลเอ็นต์ WOPI: Collabora จะส่งคำขอที่ลงนามแล้ว และโฮสต์จะตรวจสอบ ข้อความที่แสดงอาจแตกต่างกันไปตามการผสานรวมและเวอร์ชัน ดังนั้นจึงต้องระบุส่วนประกอบที่ส่งข้อความนี้ก่อน และคำขอใดที่ล้มเหลว

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

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

ตารางการวินิจฉัยอย่างรวดเร็ว

1. ยืนยันว่าการค้นพบนี้เปิดเผยคีย์สาธารณะปัจจุบัน

Collabora เผยแพร่ความสามารถ WOPI และข้อมูลรหัสยืนยันที่จุดเชื่อมต่อการค้นหา จากเครื่องที่สามารถเข้าถึง URL ของ Collabora ที่เซิร์ฟเวอร์จัดเก็บข้อมูลของคุณใช้ ให้ตรวจสอบ:

curl -fsS https://office.example.com/hosting/discovery

ตรวจสอบในไฟล์ XML เพื่อหาproof-keyองค์ประกอบที่มีข้อมูลปัจจุบันvalueและหากมีอยู่ ให้มีข้อมูลเพิ่มเติมด้วยoldvalueอย่าสับสนข้อมูลสาธารณะนี้กับคีย์ส่วนตัวที่จัดเก็บไว้บนเซิร์ฟเวอร์ Collabora การเปรียบเทียบที่มีประโยชน์ที่สุดคือการตอบสนองการค้นหาที่ดึงมาจากโฮสต์ WOPI เอง เนื่องจากเบราว์เซอร์หรือเวิร์กสเตชันของผู้ดูแลระบบอาจได้รับการตอบสนองที่แตกต่างกันผ่าน DNS, พร็อกซี หรือแคช

ตรวจสอบแล้ว:การผสานรวม WOPI ของ Collabora ใช้ลายเซ็นพิสูจน์ และคีย์สาธารณะจะพร้อมใช้งานผ่านการค้นหาการดำเนินการ:ดึงข้อมูลการค้นหาจากโฮสต์/คอนเทนเนอร์จริงที่ตรวจสอบคำขอ จากนั้นยืนยันว่า XML นั้นถูกต้องและตรงกับปลายทาง Collabora ที่กำหนดค่าไว้ในแพลตฟอร์มจัดเก็บข้อมูลคู่มือการผูก Collabora กับ SharePointอธิบายถึงการสร้างคีย์พิสูจน์และพฤติกรรมการค้นหา

2. ตรวจสอบว่าคีย์ส่วนตัวมีอยู่จริงและสามารถอ่านได้หรือไม่

บน Collabora ให้ตรวจสอบบันทึกการเริ่มต้นระบบเพื่อหาคำเตือนว่าไฟล์ proof-key หายไปหรืออ่านไม่ได้ บริการ Collabora ต้องสามารถอ่าน private key เพื่อใช้ในการลงนามได้ สำหรับการติดตั้งแบบแพ็กเกจ เส้นทางการกำหนดค่าและบัญชีบริการอาจแตกต่างกันไป ตรวจสอบไดเร็กทอรีที่กำหนดค่าไว้ของบริการและการเชื่อมต่อวอลุ่มคอนเทนเนอร์แทนที่จะสันนิษฐานจากเส้นทางโฮสต์

เอกสารของ Collabora coolconfig generate-proof-keyอธิบายกรณีที่การตั้งค่าคีย์อัตโนมัติไม่ทำงาน อย่าใช้คำสั่งนี้เป็นคำสั่งแก้ไขปัญหาประจำบนคลัสเตอร์ที่ทำงานได้ปกติ การสร้างคีย์ใหม่จะเปลี่ยนข้อมูลประจำตัวในการลงนาม หากฝั่งจัดเก็บข้อมูลยังคงเชื่อถือการตอบสนองการค้นหาที่เก่ากว่า คำขออาจยังคงล้มเหลวต่อไปจนกว่าโฮสต์จะรีเฟรชคีย์สาธารณะที่ใช้งานอยู่

sudo coolconfig generate-proof-key

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

3. ตรวจสอบความไม่ตรงกันของคีย์ระหว่างโหนดหรือแคช

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

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

4. เปรียบเทียบ URL ที่ลงชื่อแล้วกับ URL ที่โฮสต์ตรวจสอบความถูกต้อง

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

ขั้นตอนการดำเนินการ:เชื่อมโยงคำขอที่ล้มเหลวหนึ่งรายการในระดับพร็อกซีและระดับแอปพลิเคชัน เปรียบเทียบรูปแบบ ชื่อโฮสต์ พอร์ตที่ระบุ เส้นทาง และอักขระที่เข้ารหัสที่ตัวตรวจสอบเห็นกับ URL ที่ใช้ในโค้ดการตรวจสอบความถูกต้อง ตรวจสอบการจัดการ forwarded-host และ forwarded-proto เฉพาะในกรณีที่แอปพลิเคชันพึ่งพาเฮดเดอร์เหล่านั้น รักษา URL ของคำขอจริงไว้ อย่า "แก้ไข" ปัญหาโดยการปิดใช้งานการตรวจสอบลายเซ็นหรือเชื่อถือเฮดเดอร์ที่ส่งต่อโดยพลการ

5. ตรวจสอบความถูกต้องของการประทับเวลาและการจัดการไบต์

การตรวจสอบ WOPI ประกอบด้วยX-WOPI-TimeStamp. ในข้อกำหนด WOPI ของ Microsoft ส่วนหัวนี้เป็นจำนวนเต็ม 64 บิตที่วัดในช่วงเวลา 100 นาโนวินาที นับตั้งแต่วันที่ 1 มกราคม 0001 ไม่ใช่การประทับเวลาแบบ Unix ในหน่วยวินาที ตัวตรวจสอบความถูกต้องแบบกำหนดเองที่แยกวิเคราะห์เป็นวินาทีแบบ Unix ตัดตัวเลขบางส่วน เปลี่ยนการเข้ารหัส หรือประกอบไบต์ที่ลงนามไม่ถูกต้อง อาจปฏิเสธคำขอที่ถูกต้องได้

ความคลาดเคลื่อนของเวลาอาจเป็นสาเหตุหนึ่งเมื่อโฮสต์บังคับใช้ช่วงเวลาตรวจสอบความทันสมัยของข้อมูล แต่ค่าความคลาดเคลื่อนที่ยอมรับได้นั้นขึ้นอยู่กับการใช้งานการตรวจสอบนั้นๆ คำแนะนำของ Microsoft สำหรับ Microsoft 365 บนเว็บใช้การตรวจสอบความทันสมัยของข้อมูลทุกๆ 20 นาที อย่าคิดว่าตัวเลขนี้ใช้ได้กับการผสานรวม Collabora ทุกกรณีการดำเนินการ:ตรวจสอบการซิงโครไนซ์ NTP และเวลา UTC บนระบบ Collabora และระบบจัดเก็บข้อมูล จากนั้นตรวจสอบกฎการประทับเวลาและโค้ดการแยกวิเคราะห์ของโฮสต์เอง

หากคุณดูแลโฮสต์ WOPI แบบกำหนดเอง โปรดตรวจสอบโครงสร้างระดับไบต์ด้วย โทเค็นเป็น UTF-8 ความยาวเป็นจำนวนไบต์ URL เป็น URL แบบเต็มในรูปแบบตัวพิมพ์ใหญ่ และค่าเวลาต้องแสดงตรงตามที่ระบุไว้ทุกประการ คีย์สาธารณะต้องตรงกับคีย์ส่วนตัวที่ใช้โดยอินสแตนซ์ Collabora ที่ส่งคำขอ

6. แยกความล้มเหลวในการพิสูจน์ออกจากข้อผิดพลาดของรายการที่อนุญาตและข้อผิดพลาด TLS

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

สำหรับการติดตั้งใช้งาน Nextcloud คู่มือการแก้ไขปัญหาอย่างเป็นทางการแนะนำให้ตรวจสอบเส้นทาง HTTP(S) ที่จำเป็นทั้งสองทิศทาง ตรวจสอบบันทึกของ Nextcloud และ Collabora และยืนยันรายการอนุญาตโฮสต์ WOPI สำหรับคำเตือนเกี่ยวกับรายการอนุญาต การดำเนินการ: ปฏิบัติตามหมวดหมู่ข้อผิดพลาดในบันทึก ทดสอบจุดสิ้นสุดการค้นหาและการเข้าถึงเครือข่ายแยกต่างหากจากตัวตรวจสอบความถูกต้องของหลักฐาน อย่าขยายรายการอนุญาตเพื่อ*เป็นวิธีแก้ปัญหาชั่วคราว

ลำดับการกู้คืนที่ปลอดภัย

1. บันทึกเวลาที่คำขอไม่สำเร็จอย่างแม่นยำ และระบุว่าบริการใดบันทึกความล้มเหลวในการตรวจสอบหลักฐาน
2. ตรวจสอบบันทึกของ Collabora เพื่อหาคำเตือนเกี่ยวกับคีย์ที่หายไป ตรวจสอบ XML การค้นหาจากเส้นทางเครือข่ายของโฮสต์ WOPI
3. เปรียบเทียบกุญแจสาธารณะที่ได้จากการค้นหา กับกุญแจส่วนตัวและการกำหนดค่าโหนดที่ใช้ในการลงนามคำขอ
4. ตรวจสอบความสม่ำเสมอของโหลดบาลานเซอร์ การแคชการค้นหา และการเปลี่ยนแปลงคีย์ ชื่อโฮสต์ พร็อกซี หรือ TLS ล่าสุด
5. เปรียบเทียบ URL คำขอที่ลงชื่อแล้วและการจัดการเวลาโดยไม่เปิดเผยโทเค็นหรือส่วนหัวการพิสูจน์
6. ทดสอบซ้ำด้วยเอกสารหนึ่งฉบับและยืนยันว่าคำขอเดียวกันนั้นสำเร็จในบันทึกของโฮสต์ก่อนที่จะคืนค่าการรับส่งข้อมูลเป็นปกติ

หากยังคงเกิดความล้มเหลว ให้รวบรวมบันทึกที่ผ่านการกรองข้อมูลจากทั้งสองฝั่ง เวอร์ชันของ Collabora และพื้นที่จัดเก็บข้อมูล ประเภทการปรับใช้ จำนวนโหนดที่เกี่ยวข้อง (หนึ่งหรือหลายโหนด) XML การค้นหาที่ลบข้อมูลลับออกแล้ว และเส้นทางพร็อกซีสำหรับคำขอที่ล้มเหลว แบ่งปันข้อมูลนี้กับผู้จำหน่ายหรือผู้ดูแลระบบการผสานรวมที่เกี่ยวข้อง ข้อความแสดงข้อผิดพลาดเพียงอย่างเดียวไม่สามารถระบุได้ว่าสาเหตุเกิดจากการค้นหาที่ล้าสมัย การแปลง URL เป็นรูปแบบมาตรฐาน ปัญหาเรื่องเวลา หรือข้อบกพร่องของตัวตรวจสอบความถูกต้องแบบกำหนดเอง หลักฐานในระดับคำขอจะเป็นตัวกำหนดว่าควรดำเนินการแก้ไขในแนวทางใด