วิธีตั้งค่าการยุติ SSL สำหรับคอนเทนเนอร์ Collabora CODE

การยุติการเชื่อมต่อ SSL เหมาะอย่างยิ่งสำหรับคอนเทนเนอร์ Collabora Online Development Edition (CODE) เมื่อคุณต้องการปลายทาง HTTPS สาธารณะหนึ่งจุด ในขณะที่ยังคงจัดการใบรับรองไว้ที่พร็อกซีแบบย้อนกลับ เช่น Nginx ในการออกแบบนี้ เบราว์เซอร์จะเชื่อมต่อกับ Nginx ผ่าน HTTPS, Nginx จะถอดรหัสการรับส่งข้อมูล และ Collabora จะรับ HTTP ธรรมดาบนพอร์ตภายในของตนเอง เป้าหมายด้านคุณภาพไม่ได้อยู่ที่เพียงแค่ “หน้าเว็บโหลดได้” การใช้งานที่ประสบความสำเร็จควรมีใบรับรองสาธารณะที่ถูกต้อง ปลายทางค้นหา WOPI ที่เข้าถึงได้ การอัปเกรด WebSocket ที่ใช้งานได้ และเซสชันการแก้ไขเอกสารจริงที่เชื่อมต่ออยู่เสมอ

เอกสารเกี่ยวกับพร็อกซีของ Collabora เองอธิบายรูปแบบการยกเลิกการเข้ารหัส SSL นี้ว่าเป็นการเชื่อมต่อแบบ HTTP เท่านั้นระหว่างพร็อกซีและ Collabora โดยมีssl.enable=falseและssl.termination=trueบนฝั่ง Collabora ดูการตั้งค่าพร็อกซีแบบย้อนกลับของ Collabora Onlineตัวอย่างด้านล่างใช้ Nginx และ Docker Compose แต่สามารถได้ผลลัพธ์เดียวกันด้วยพร็อกซีแบบย้อนกลับอื่นๆ หากยังคงรักษาพฤติกรรมของโฮสต์และ WebSocket ที่จำเป็นไว้

การตั้งค่า SSL Termination ที่ดีควรบรรลุผลลัพธ์อะไรบ้าง

ขั้นตอนที่ 1: ยืนยันขอบเขตเครือข่ายก่อนทำการเปลี่ยนแปลง Collabora

กำหนดจุดสิ้นสุดของ TLS และโฮสต์ใดบ้างที่สามารถเข้าถึงพอร์ต 9980 ได้ หาก Nginx ทำงานบนเครื่องเดียวกับ Docker การผูกพอร์ตที่เผยแพร่ไว้กับพอร์ต 9980 127.0.0.1เป็นวิธีง่ายๆ ในการป้องกันการเข้าถึงโดยตรงจากอินเทอร์เน็ต เอกสารของ Docker ระบุว่าการเผยแพร่พอร์ตไปยังพอร์ต 9980 จะ127.0.0.1ทำให้พอร์ตนั้นอยู่ภายในเครื่องโฮสต์นั้นๆ โปรดดูเอกสารเกี่ยวกับการเผยแพร่พอร์ตของ Docker

หาก Nginx ทำงานอยู่ในคอนเทนเนอร์อื่น เครือข่าย Docker ส่วนตัวที่ใช้ร่วมกันมักจะสะอาดกว่าการเผยแพร่พอร์ต 9980 สู่สาธารณะ หลักการก็เหมือนกันคือ ลูกค้าควรใช้ชื่อโฮสต์ของ HTTPS reverse-proxy ไม่ใช่ชื่อโฮสต์ของคอนเทนเนอร์ Collabora โดยตรง

ขั้นตอนที่ 2: รันโค้ดในโหมด SSL-Termination

สำหรับการยุติการเชื่อมต่อ TLS ฝั่งพร็อกซี Collabora ควรทราบว่ารูปแบบการเชื่อมต่อที่ลูกค้าใช้งานในตอนแรกคือ HTTPS แม้ว่าการเชื่อมต่อต้นทางโดยตรงจะเป็น HTTP ก็ตาม การตั้งค่าที่ระบุไว้มีดังนี้:

--o:ssl.enable=false --o:ssl.termination=true

ตัวอย่างการใช้งาน Compose แบบง่ายๆ จะมีลักษณะดังนี้:

services:
  collabora:
    image: collabora/code:YOUR_TESTED_TAG
    restart: unless-stopped
    ports:
      - "127.0.0.1:9980:9980"
    environment:
      - "extra_params=--o:ssl.enable=false --o:ssl.termination=true"
      - "server_name=office.example.com"

ควรเปลี่ยนYOUR_TESTED_TAGไปใช้เวอร์ชันที่คุณตรวจสอบแล้วแทนที่จะสันนิษฐานโดยอัตโนมัติว่าlatestปลอดภัยสำหรับการใช้งานจริง นอกจากนี้ ให้กำหนดค่าโฮสต์ WOPI หรือชื่อแทนที่เหมาะสมสำหรับการผสานรวมของคุณ ค่าเหล่านั้นจะขึ้นอยู่กับว่าคุณกำลังเชื่อมต่อกับ Nextcloud, ownCloud, โฮสต์ WOPI อื่น หรือการผสานรวมแบบกำหนดเอง

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

docker compose up -d
docker compose ps
docker logs --tail=100 collabora

หมายเหตุเกี่ยวกับเวอร์ชันสำหรับการใช้งานเวอร์ชัน 26.04

อย่ามองว่าแฟล็ก SSL สองตัวเป็นตัวแปรเดียวเมื่อแก้ไขปัญหาภาพเวอร์ชัน 26.04 ปัจจุบัน ในช่วงกลางปี ​​2026 Collabora ได้ติดตามปัญหาที่เกิดขึ้นกับภาพ Docker แบบไร้ดิสโทรและคอนฟิกที่ปิดใช้งาน SSL เอกสารปัญหาอย่างเป็นทางการบน GitHub ได้บันทึกปัญหาการเริ่มต้นใช้งานเวอร์ชัน 26.04 และการติดตามผลของชุมชน Collabora รายงานว่าพฤติกรรมการยุติ SSL ที่ได้รับผลกระทบกลับมาใช้งานได้อีกครั้งในภาพเวอร์ชัน 26.04.2.4.1 ในภายหลัง โปรดตรวจสอบปัญหาหมายเลข #16019 ใน CollaboraOnline/onlineหากคอนฟิกการยุติที่เคยใช้งานได้ก่อนหน้านี้ใช้งานไม่ได้ทันทีหลังจากอัปเกรดภาพ

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

ขั้นตอนที่ 3: กำหนดค่า Nginx เพื่อยุติการเชื่อมต่อ TLS และพร็อกซีเส้นทาง Collabora

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

server {
    listen 443 ssl;
    server_name office.example.com;

    ssl_certificate     /etc/letsencrypt/live/office.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/office.example.com/privkey.pem;

    location ^~ /browser {
        proxy_pass http://127.0.0.1:9980;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Proto https;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }

    location ^~ /hosting/discovery {
        proxy_pass http://127.0.0.1:9980;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Proto https;
    }

    location ^~ /hosting/capabilities {
        proxy_pass http://127.0.0.1:9980;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Proto https;
    }

    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_set_header X-Forwarded-Proto https;
        proxy_read_timeout 36000s;
    }

    location ~ ^/(c|l)ool {
        proxy_pass http://127.0.0.1:9980;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Proto https;
    }

    location ^~ /cool/adminws {
        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_set_header X-Forwarded-Proto https;
        proxy_read_timeout 36000s;
    }
}

ส่วนหัวของ WebSocket ไม่ใช่แค่ส่วนตกแต่ง เอกสารอย่างเป็นทางการของ Nginx อธิบายว่าUpgradeส่วน หัวเหล่านี้ Connectionเป็นส่วนหัวแบบ hop-by-hop และต้องส่งผ่านอย่างชัดเจนสำหรับ WebSocket ที่ใช้ reverse-proxy ดูที่Nginx WebSocket proxyingเอกสารโมดูล proxy มาตรฐานยังครอบคลุมถึงส่วนหัวproxy_set_headerเหล่านี้proxy_passด้วยproxy_read_timeout: ngx_http_proxy_module

ขั้นตอนที่ 4: ตรวจสอบความถูกต้องของ Nginx ก่อนทำการรีโหลด

ทดสอบการตั้งค่า Nginx ก่อนที่จะแทนที่การตั้งค่าที่ใช้งานได้ดีอยู่แล้ว:

sudo nginx -t

โหลดหน้าเว็บใหม่เฉพาะเมื่อตรวจสอบไวยากรณ์ผ่านแล้วเท่านั้น:

sudo systemctl reload nginx

จากนั้นตรวจสอบว่า Nginx สามารถเข้าถึงแบ็กเอนด์ Collabora ในเครื่องเดียวกันได้หรือไม่ สำหรับการตั้งค่าแบบเดียวกันบนโฮสต์เดียวกัน การตรวจสอบที่มีประโยชน์คือ:

curl -I http://127.0.0.1:9980/hosting/discovery

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

ขั้นตอนที่ 5: ตรวจสอบความถูกต้องของจุดเชื่อมต่อ HTTPS สาธารณะ

จากไคลเอ็นต์ที่สามารถระบุชื่อโฮสต์สาธารณะได้ ให้ร้องขอเอนด์พอยต์การค้นหาผ่าน Nginx:

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

การร้องขอจากเบราว์เซอร์https://office.example.com/hosting/discoveryควรส่งคืนข้อมูล XML นี่เป็นวิธีตรวจสอบการทำงานที่ดีกว่าการพึ่งพา URL หลัก เนื่องจากพฤติกรรมของหน้าหลักไม่ใช่ข้อกำหนดหลักของ WOPI และอาจแตกต่างกันไปในแต่ละเวอร์ชัน

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

ขั้นตอนที่ 6: ทดสอบเอกสารจริงและ WebSocket

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

หากหน้าต่างแก้ไขเอกสารโหลดได้ แต่เอกสารล้มเหลวในเวลาไม่นานหลังจากนั้น ให้ตรวจสอบเส้นทาง WebSocket, เวลาหมดอายุของพร็อกซี, รายการอนุญาต WOPI และพฤติกรรมของส่วนหัวโฮสต์ก่อน หากบันทึกของ Nginx แสดงข้อผิดพลาดในการเชื่อมต่อกับเซิร์ฟเวอร์ก่อนที่จะมีการสร้าง WebSocket ใดๆ ให้ตรวจสอบตัวรับฟังและเวอร์ชันรูปภาพของ CODE ก่อน

วิธีวินิจฉัยสาเหตุความล้มเหลวที่พบบ่อย

502 Bad Gateway

โดยปกติแล้ว รหัสข้อผิดพลาด 502 หมายความว่า Nginx ไม่สามารถรับการตอบสนองที่ถูกต้องจากอัปสตรีมที่กำหนดค่าไว้ได้ ตรวจสอบว่า CODE กำลังรับฟังอยู่ที่พอร์ต 9980 หรือไม่ และคุณกำลังใช้โปรโตคอลอัปสตรีมที่ถูกต้องหรือไม่ ในการออกแบบการยุติ SSL ที่ตั้งใจไว้ การเชื่อมต่อจากพร็อกซีไปยัง CODE จะเป็น HTTP หากความผิดพลาดของอิมเมจทำให้ CODE ยังคงให้บริการ HTTPS ภายในแม้ว่าคุณจะตั้งค่าแฟล็กแล้วก็ตาม บันทึกและcurlการทดสอบโดยตรงจะเปิดเผยความไม่ตรงกัน อย่าเปลี่ยนไปใช้อัปสตรีม HTTPS อย่างถาวรเพียงเพื่อซ่อนความผิดพลาดในการกำหนดค่าที่ไม่สามารถอธิบายได้ ตรวจสอบพฤติกรรมของอิมเมจ CODE ที่คุณกำลังใช้งานอยู่ก่อน

ฟังก์ชันการค้นหาใช้งานได้ แต่เอกสารเปิดไม่ได้

ปัญหานี้มักเกิดจากการส่งต่อ WebSocket หรือการอนุญาต WOPI มากกว่าตัว TLS เอง ตรวจสอบ/cool/.../wsเส้นทาง ส่วนหัวการอัปเกรด และโฮสต์ที่คุณอนุญาตให้เป็นแหล่งที่มาของ WOPI Collabora อาจสามารถเข้าถึงได้อย่างสมบูรณ์ผ่าน HTTPS ในขณะที่เซสชันการแก้ไขอาจยังคงถูกปฏิเสธหรือล้มเหลว

เนื้อหาผสมหรือ URL ที่มีรูปแบบไม่ถูกต้อง

หากเบราว์เซอร์เห็นหน้าเว็บ HTTPS ที่อ้างอิงถึงทรัพยากร HTTP ให้ตรวจสอบssl.termination=trueส่วนหัวของรูปแบบที่ส่งต่อและชื่อเซิร์ฟเวอร์ ฝั่งสาธารณะของการใช้งานจะต้องระบุตัวเองว่าเป็น HTTPS อย่างสม่ำเสมอ แม้ว่าการเชื่อมต่อส่วนตัวจะเป็น HTTP ก็ตาม

รายงานคอนเทนเนอร์แสดงสถานะผิดปกติ แม้ว่าการแก้ไขจะใช้งานได้ก็ตาม

การอัปเดตเวอร์ชัน 26.04 ล่าสุดได้เพิ่มพฤติกรรมการตรวจสอบสถานะสุขภาพที่เปลี่ยนแปลงไปในระหว่างการเปลี่ยนไปใช้ภาพดิสก์แบบไร้ดิสโทร Collabora ได้ติดตามกรณีที่การตรวจสอบไม่เคารพการกำหนดค่าแบ็กเอนด์ HTTP ที่อยู่เบื้องหลังการยุติ TLS หากการทดสอบการทำงานผ่าน แต่สถานะสุขภาพของ Docker เป็นสีแดงโดยไม่คาดคิด ให้ตรวจสอบประวัติปัญหาเฉพาะเวอร์ชันก่อนที่จะออกแบบพร็อกซีที่ใช้งานได้ใหม่ ดู ปัญหาหมายเลข # 16032 ใน CollaboraOnline/online

ควรใช้ดีไซน์ที่แตกต่างออกไปเมื่อใด

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

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

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

• ชื่อโฮสต์ของ Collabora จะแปลงเป็นพร็อกซีแบบย้อนกลับ
• พอร์ต 443 แสดงใบรับรองที่เชื่อถือได้สำหรับชื่อโฮสต์นั้น
• CODE ไม่ได้ถูกเปิดเผยสู่สาธารณะทางอินเทอร์เน็ตโดยไม่จำเป็นผ่านพอร์ต 9980
• ssl.enable=falseและssl.termination=trueนำไปใช้ในการออกแบบแบ็กเอนด์ HTTP
• Nginx สามารถเข้าถึง CODE ผ่านทางแอดเดรสส่วนตัวได้
• /hosting/discoveryตอบกลับผ่าน URL HTTPS สาธารณะ
• การอัปเกรด WebSocket /cool/.../wsสำเร็จแล้ว
• เอกสารจริงสามารถเปิด แก้ไข บันทึก และเปิดใหม่ได้
• คุณได้เลือกและทดสอบเวอร์ชันอิมเมจ CODE ที่ตรงกับที่คุณวางแผนจะใช้งานแล้ว

หากการตรวจสอบทั้งหมดผ่าน การยุติการเชื่อมต่อ SSL ก็ทำงานได้ตามปกติ: การรับส่งข้อมูลภายนอกได้รับการปกป้องด้วย HTTPS, Collabora เข้าใจว่าการเชื่อมต่อสาธารณะมีความปลอดภัย และเส้นทางการแก้ไขยังคงใช้งานได้ หากการตรวจสอบข้อใดข้อหนึ่งล้มเหลว ให้แก้ไขปัญหาที่ระดับนั้นแทนที่จะเปลี่ยนแปลงหลายส่วนของระบบพร้อมกัน