แก้ไขข้อผิดพลาดการเชื่อมต่อ “โอ้ นี่มันน่าอายจัง” ใน Collabora Online

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

คู่มือนี้ใช้เอกสารการดูแลระบบ Nextcloud 35 ฉบับปัจจุบันและคำแนะนำ SDK 25.04 ของ Collabora Online เป็นจุดอ้างอิง หลักการแก้ไขปัญหาเดียวกันนี้สามารถนำไปใช้กับการผสานรวม ownCloud และการผสานรวม WOPI แบบกำหนดเองได้หลายแบบ แต่ชื่อการตั้งค่าที่แน่นอนอาจแตกต่างกันไปตามแพลตฟอร์มและเวอร์ชัน

อะไรคือสาเหตุหลักที่ทำให้เกิดข้อผิดพลาดในการเชื่อมต่อ Collabora นี้?

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

นั่นหมายความว่าไม่มีวิธีแก้ไขที่ถูกต้องเพียงวิธีเดียวสำหรับทุกกรณี ให้เลือกวิธีการแก้ไขตามผลการทดสอบที่ล้มเหลวในครั้งแรก:

1. ตรวจสอบเอนด์พอยต์การค้นหาและความสามารถของ Collabora

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

https://office.example.com/hosting/discovery
https://office.example.com/hosting/capabilities

เอกสารการแก้ไขปัญหาปัจจุบันของ Nextcloud แนะนำให้ทำการทดสอบทั้งสองแบบ ปลายทางการค้นหาควรส่งคืนข้อมูล XML ในขณะที่ความสามารถจะส่งคืนข้อมูลความสามารถของ Collabora หากพบข้อความหมดเวลา คำเตือนเกี่ยวกับใบรับรอง ข้อผิดพลาด 404 หน้าข้อผิดพลาดที่มีตราสินค้าของพร็อกซี หรือการวนลูปการเปลี่ยนเส้นทาง แสดงว่าคุณควรแก้ไขปัญหาเครือข่ายหรือพร็อกซีแบบย้อนกลับก่อนที่จะแก้ไขการตั้งค่า WOPI

ตรวจสอบ URL การค้นหาและการใช้งานของ Collabora สาธารณะก่อน ทั้งสองต้องสามารถเข้าถึงได้ผ่านชื่อโฮสต์เดียวกันกับที่ใช้โดยการเชื่อมต่อ

สำหรับคำแนะนำที่ถูกต้องเกี่ยวกับอุปกรณ์ปลายทาง โปรดดูที่การแก้ไขปัญหา Nextcloud Officeและคู่มือ SDK ของ Collabora Online 25.04

2. ทดสอบการเชื่อมต่อเครือข่ายทั้งสี่ทิศทาง ไม่ใช่แค่ผ่านเบราว์เซอร์เท่านั้น

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

# From the Nextcloud/storage server
curl -fsS https://office.example.com/hosting/discovery >/dev/null && echo OK

# From the Collabora host/container
curl -fsS https://cloud.example.com/status.php

# Then inspect Collabora logs
docker logs --tail 100 collabora

หากชื่อโฮสต์สาธารณะแสดงผลแตกต่างกันภายใน Docker, Kubernetes หรือเครือข่ายส่วนตัว ให้ตัดสินใจว่าจะแก้ไข DNS ภายใน เพิ่มการแมปโฮสต์ที่เหมาะสม หรือกำหนดเส้นทางผ่านปลายทางสาธารณะ โดยทั่วไปแล้ว DNS ภายในจะมีความสะอาดกว่าเมื่อใช้งานในระดับใหญ่ การเพิ่มรายการในไฟล์ hosts ทำได้รวดเร็วสำหรับการติดตั้งแบบคงที่ขนาดเล็ก แต่จะดูแลรักษายากขึ้น

ทำการทดสอบการเชื่อมต่อจากเซิร์ฟเวอร์โดยตรง จากนั้นใช้บันทึกของ Collabora เพื่อแยกความล้มเหลวของเครือข่ายออกจากความล้มเหลวของความน่าเชื่อถือของ WOPI

3. แก้ไขปัญหา Reverse Proxy หากไม่มีเส้นทาง WebSockets หรือ Collabora

Collabora ไม่ใช่เว็บแอปพลิเคชันแบบคงที่ทั่วไป พร็อกซีแบบย้อนกลับของมันต้องการเส้นทางสำหรับสินทรัพย์ของเบราว์เซอร์ การค้นหา/ความสามารถ การรับส่งข้อมูลเอกสาร และ WebSockets ในคู่มือ SDK ของ Collabora ตัวอย่างของ Nginx จะส่งต่อ/browserเส้นทาง/hosting/discoveryWebSocket /hosting/capabilitiesและ/cool/.../wsการรับส่งข้อมูล/coolที่ เกี่ยวข้อง/lool

สำหรับเส้นทาง WebSocket นั้น พร็อกซีต้องรักษาโฮสต์ไว้และส่งต่อการอัปเกรด HTTP รูปแบบ Nginx ที่เรียบง่ายมีดังนี้:

location ~ ^/cool/(.*)/ws$ {
    proxy_pass http://127.0.0.1:9980;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "Upgrade";
    proxy_set_header Host $host;
    proxy_read_timeout 36000s;
}

อย่าคัดลอกส่วนนี้โดยไม่คิดไตร่ตรองหากคุณใช้การยุติ TLS ที่แตกต่างออกไป เอกสารของ Collabora มีรูปแบบที่แยกต่างหากสำหรับการยุติ TLS และ SSL แบบ end-to-end หาก TLS ยุติที่ Nginx และการเชื่อมต่อแบ็กเอนด์เป็น HTTP การตั้งค่า SSL ภายในของ Collabora ต้องตรงกับการออกแบบนั้น การใช้ HTTPS ทุกที่นั้นเข้าใจง่ายกว่า ในขณะที่การยุติ TLS ที่พร็อกซีช่วยลดการจัดการใบรับรองภายในคอนเทนเนอร์ แต่ก็ทำให้เกิดขอบเขตการกำหนดค่าเพิ่มเติมอีกอย่างหนึ่ง

รีเวิร์สพร็อกซีที่ถูกต้องจะต้องส่งต่อเส้นทาง HTTP ของ Collabora และรักษาการอัปเกรด WebSocket สำหรับเซสชันเอกสารไว้

4. ตรวจสอบความสอดคล้องของโปรโตคอล ใบรับรอง และชื่อโฮสต์

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

ตรวจสอบรายการเหล่านี้พร้อมกัน:

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

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

5. แก้ไขรายการอนุญาต WOPI ให้ถูกต้อง แทนที่จะปิดใช้งาน

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

ในส่วนของการจัดเก็บข้อมูล Nextcloud แนะนำให้จำกัดการร้องขอ WOPI เฉพาะที่อยู่ IP ของเซิร์ฟเวอร์ Collabora โดยใช้ การตั้ง ค่า "รายการอนุญาตสำหรับการร้องขอ WOPI " ในส่วนของ Collabora โฮสต์จัดเก็บข้อมูล WOPI ที่ได้รับอนุญาตจะต้องตรงกับ URL จัดเก็บข้อมูลที่ Collabora ได้รับจริง สำหรับโดเมนจัดเก็บข้อมูลหลายโดเมน เอกสาร SDK ปัจจุบันของ Collabora ได้ระบุกลุ่มนามแฝง WOPI ไว้แล้ว

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

ดูการตั้งค่า Nextcloud Officeสำหรับ URL เซิร์ฟเวอร์ปัจจุบันและคำแนะนำเกี่ยวกับรายการอนุญาต WOPI หากคุณใช้ ownCloud Infinite Scale บริการการทำงานร่วมกันจะใช้COLLABORATION_APP_ADDRURL แอป Office และCOLLABORATION_WOPI_SRCแหล่ง WOPI ที่เข้าถึงได้จากภายนอก โปรดดูเอกสารประกอบบริการการทำงานร่วมกันของ ownCloud

คุณควรใช้ CODE ที่มีมาให้ในตัวแทนการใช้เซิร์ฟเวอร์ Collabora แยกต่างหากเมื่อใด?

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

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

สิ่งที่ไม่ควรทำ

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

รายการตรวจสอบการยืนยันขั้นสุดท้าย

หลังจากทำการเปลี่ยนแปลงแล้ว ให้ตรวจสอบระบบตามลำดับนี้:

1. เปิด/hosting/discoveryใช้งาน/hosting/capabilitiesผ่านเว็บเบราว์เซอร์
2. ดึงข้อมูลปลายทางเดียวกันจากเซิร์ฟเวอร์จัดเก็บข้อมูล
3. จากเซิร์ฟเวอร์ Collabora ให้ดึง URL สถานะของเซิร์ฟเวอร์จัดเก็บข้อมูล
4. เปิดเอกสารพร้อมกับดูบันทึกการทำงานของทั้ง Collabora และพื้นที่จัดเก็บข้อมูลไปพร้อมกัน
5. ตรวจสอบให้แน่ใจว่าเบราว์เซอร์สามารถเชื่อมต่อกับ Collabora WebSocket ได้โดยไม่มีการตัดการเชื่อมต่อซ้ำๆ
6. ตรวจสอบให้แน่ใจว่าผู้ใช้คนที่สองสามารถเปิดและแก้ไขเอกสารทดสอบได้ หากจำเป็นต้องมีการแก้ไขร่วมกัน

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