Napraw błąd połączenia Collabora Online „Cóż, to jest żenujące”

Komunikat Collabora Online „No cóż, to kłopotliwe, nie możemy połączyć się z Twoim dokumentem” to objaw, a nie diagnoza. Pojawia się po załadowaniu powłoki edytora, ale sesja dokumentu nie może się zakończyć. W obecnych wdrożeniach najszybszym sposobem rozwiązania tego problemu jest zidentyfikowanie, które połączenie w ścieżce WOPI powoduje awarię, zamiast zmiany losowych ustawień Collabora.

W tym przewodniku wykorzystano aktualną dokumentację administracyjną NextCloud 35 oraz wskazówki dotyczące pakietu SDK Collabora Online 25.04 jako punkty odniesienia. Ta sama logika rozwiązywania problemów ma zastosowanie do wielu integracji ownCloud i niestandardowych WOPI, ale dokładne nazwy ustawień mogą się różnić w zależności od platformy i wersji.

Co zazwyczaj powoduje błąd połączenia Collabora?

Działająca sesja przeglądarki zależy od kilku oddzielnych ścieżek. Przeglądarka użytkownika musi dotrzeć zarówno do serwera pamięci masowej, jak i do Collabora; serwer pamięci masowej musi dotrzeć do Collabora; Collabora musi dotrzeć do serwera pamięci masowej; protokoły i certyfikaty muszą być zgodne; a odwrotny serwer proxy musi poprawnie przekazywać trasy HTTP i WebSocket Collabora. Oficjalna strona rozwiązywania problemów Nextcloud wyraźnie wymienia te wymagania dotyczące dwukierunkowej dostępności.

Oznacza to, że nie ma jednego, uniwersalnego rozwiązania. Wybierz ścieżkę naprawy na podstawie pierwszego nieudanego testu:

1. Zweryfikuj punkty końcowe wykrywania i możliwości Collabora

Zacznij od publicznego adresu URL Collabora, z którego faktycznie korzysta Twoja integracja. Otwórz te punkty końcowe w przeglądarce i na serwerze pamięci masowej:

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

Aktualna dokumentacja rozwiązywania problemów Nextcloud zaleca oba testy. Punkt końcowy wykrywania powinien zwrócić XML, a funkcja capabilities (opcje) zwraca dane o możliwościach Collabora. Przekroczenie limitu czasu, ostrzeżenie o certyfikacie, błąd 404, strona błędu oznaczona jako proxy lub pętla przekierowania oznaczają, że przed zmianą ustawień WOPI należy naprawić sieć lub odwrotny serwer proxy.

Najpierw sprawdź publiczne adresy URL funkcji odkrywania i możliwości Collabora; oba muszą być dostępne za pośrednictwem tej samej nazwy hosta, której używa integracja.

Aby uzyskać wiarygodne wskazówki dotyczące punktów końcowych, zapoznaj się z dokumentem Rozwiązywanie problemów z pakietem Nextcloud Office oraz podręcznikiem zestawu SDK Collabora Online 25.04 .

2. Przetestuj wszystkie cztery kierunki sieci, nie tylko przeglądarkę

Częstym błędem jest założenie, że skoro office.example.comCollabora otwiera się w przeglądarce na komputerze, może również pobierać pliki z serwera pamięci masowej. Nie ma takiej gwarancji. Przetestuj na rzeczywistych hostach lub kontenerach:

# 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

Jeśli publiczna nazwa hosta jest inaczej rozwiązywana w Dockerze, Kubernetesie lub sieci prywatnej, zdecyduj, czy naprawić wewnętrzny DNS, dodać odpowiednie mapowanie hosta, czy też przekierować przez publiczny punkt końcowy. Wewnętrzny DNS jest zazwyczaj bardziej przejrzysty w dużej skali; wpis w pliku hosts jest szybki w przypadku małej instalacji statycznej, ale trudniejszy w utrzymaniu.

Uruchom testy dostępności z poziomu samych serwerów, a następnie użyj dziennika Collabora, aby oddzielić awarię sieci od błędu zaufania WOPI.

3. Napraw odwrotny serwer proxy, jeśli brakuje tras WebSockets lub Collabora

Collabora nie jest zwykłą statyczną aplikacją internetową. Jej odwrotny serwer proxy wymaga tras dla zasobów przeglądarki, funkcji wykrywania/funkcji, ruchu dokumentów i WebSocketów. W podręczniku SDK Collabora przykład Nginx przekazuje /browser, /hosting/discovery, /hosting/capabilities, /cool/.../wsścieżkę WebSocket oraz powiązany /coolruch /lool.

W przypadku trasy WebSocket serwer proxy musi zachować hosta i przekazać uaktualnienie HTTP. Uproszczony wzorzec Nginx wygląda następująco:

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;
}

Nie kopiuj tego bezmyślnie, jeśli kończysz TLS w inny sposób. Collabora dokumentuje oddzielne wzorce dla zakończenia TLS i SSL w trybie end-to-end. Jeśli TLS kończy się na Nginx, a połączenie z zapleczem jest HTTP, wewnętrzne ustawienia SSL Collabora muszą być zgodne z tym projektem. Korzystanie z HTTPS wszędzie jest prostsze do zrozumienia, podczas gdy zakończenie TLS na serwerze proxy ogranicza obsługę certyfikatów w kontenerach, ale wprowadza kolejną granicę konfiguracji.

Prawidłowy odwrotny serwer proxy musi przekazywać trasy HTTP Collabora i zachowywać uaktualnienie WebSocket dla sesji dokumentu.

4. Sprawdź spójność protokołu, certyfikatu i nazwy hosta

Aktualna dokumentacja konfiguracji pakietu Office w Nextcloud stwierdza, że ​​serwer Collabora Online powinien używać tego samego protokołu, co instalacja Nextcloud, z zalecanym protokołem HTTPS. W praktyce mieszane publiczne konfiguracje HTTP/HTTPS mogą powodować blokowanie treści, błędne przekierowania lub błędy walidacji certyfikatu zaplecza.

Sprawdź te elementy razem:

• Adres URL Collabora zapisany na platformie pamięci masowej to dokładny publiczny adres URL, do którego docierają użytkownicy.
• Certyfikat przedstawiony przez daną nazwę hosta jest ważny dla tej nazwy hosta i jest zaufany przez serwer pamięci masowej.
• Collabora może zweryfikować certyfikat HTTPS serwera pamięci masowej.
• Twój odwrotny serwer proxy poprawnie przekazuje oryginalnego hosta i schemat.
• Nie ma przekierowania ze skonfigurowanej nazwy hosta Collabora na inną nazwę hosta, której WOPI nie oczekuje.

Certyfikat podpisany samodzielnie może być akceptowalny w laboratorium, jeśli każdy komponent jest jawnie skonfigurowany tak, aby mu ufać, ale ta wygoda oznacza mniejszą przenośność i często powoduje późniejsze niepowodzenia aktualizacji lub przebudowy kontenerów. W środowisku produkcyjnym bezpieczniejszym wyborem jest łańcuch certyfikatów zaufanych publicznie lub przez organizację.

5. Popraw listy dozwolonych funkcji WOPI zamiast je wyłączać

Jeśli wyszukiwanie działa, a logi Collabora wyświetlają komunikaty takie jak „ Unauthorized WOPI hostbrak akceptowalnego hosta WOPI pasującego do celu” lub „brak akceptowalnego hosta WOPI”, problem przeniósł się z podstawowej łączności na konfigurację zaufania. Oficjalna dokumentacja rozwiązywania problemów Nextcloud wyraźnie wskazuje administratorom logi kontenerów w tym przypadku.

W kwestii pamięci masowej, Nextcloud zaleca ograniczenie żądań WOPI do adresów IP serwerów Collabora za pomocą ustawienia „Lista dozwolonych żądań WOPI” . W przypadku Collabora, dozwolone hosty pamięci masowej WOPI muszą być zgodne z adresami URL pamięci masowej faktycznie odbieranymi przez Collabora. W przypadku wielu domen pamięci masowej, obecny pakiet SDK Collabora dokumentuje grupy aliasów WOPI.

Zadbaj o to, aby adres URL serwera Collabora oraz lista dozwolonych adresów WOPI odpowiadały rzeczywistemu wdrożeniu; zamiast wyłączać sprawdzanie poprawności, użyj wąskich, zaufanych wpisów.

Aktualny adres URL serwera i listę dozwolonych WOPI można znaleźć w konfiguracji NextCloud OfficeCOLLABORATION_APP_ADDR . Jeśli korzystasz z ownCloud Infinite Scale, usługa współpracy używa adresu URL aplikacji biurowej i COLLABORATION_WOPI_SRCzewnętrznie dostępnego źródła WOPI; patrz dokumentacja usługi współpracy ownCloud .

Kiedy należy używać wbudowanego KODU zamiast oddzielnego serwera Collabora?

W przypadku małej instalacji Nextcloud, wbudowany serwer CODE redukuje liczbę zewnętrznie zarządzanych komponentów. Wadą jest to, że nadal zależy to od możliwości połączenia się instancji Nextcloud z samą sobą poprzez nazwę hosta używaną w przeglądarce. Dokumentacja rozwiązywania problemów Nextcloud bezpośrednio to podkreśla i sugeruje poprawne rozwiązanie tej nazwy hosta, gdy wbudowany serwer CODE nie może się połączyć.

Oddzielny serwer Collabora jest zazwyczaj lepszym rozwiązaniem, gdy potrzebujesz niezależnego skalowania, scentralizowanej obsługi wielu instancji pamięci masowej lub architektury produkcyjnej z wyraźniejszymi granicami zasobów. Dodaje on konfigurację DNS, proxy, certyfikatów, zapory sieciowej i zaufania WOPI, co zwiększa obciążenie operacyjne.

Czego nie robić

• Nie wyłączaj walidacji WOPI jako pierwszej poprawki. Może to ukryć faktyczną niezgodność nazw hostów i osłabić granicę bezpieczeństwa.
• Nie udostępniaj portu 9980 bezpośrednio tylko dlatego, że serwer proxy nie działa. Napraw serwer proxy, chyba że bezpośrednie udostępnianie jest celowym, bezpiecznym rozwiązaniem.
• Nie zakładaj, że odpowiedź 200 ze strony głównej Collabora dowodzi, że edycja dokumentów działa. Odkrywanie, możliwości, dostęp do plików WOPI i WebSockets to oddzielne ścieżki.
• Nie zmieniaj wielu warstw jednocześnie. Testuj po każdej zmianie, aby upewnić się, czy przyczyną był DNS, TLS, proxy czy zaufanie WOPI.

Ostateczna lista kontrolna weryfikacji

Po wprowadzeniu zmian należy zweryfikować system w następującej kolejności:

1. Otwórz /hosting/discoveryz /hosting/capabilitiespoziomu przeglądarki.
2. Pobierz te same punkty końcowe z serwera pamięci masowej.
3. Z serwera Collabora pobierz adres URL stanu serwera pamięci masowej.
4. Otwórz dokument, obserwując jednocześnie dzienniki Collabora i pamięci masowej.
5. Sprawdź, czy przeglądarka nawiązała połączenie WebSocket Collabora bez wielokrotnego rozłączania.
6. Sprawdź, czy drugi użytkownik może otworzyć i edytować dokument testowy, jeśli wymagana jest wspólna edycja.

Jeśli wszystkie sześć sprawdzeń zakończy się powodzeniem, ogólny komunikat „No cóż, to żenujące” nie powinien już maskować błędu połączenia. Jeśli komunikat nadal się pojawia, należy zapisać dokładne wiersze dziennika Collabora i błąd sieciowy przeglądarki dla jednej próby otwarcia dokumentu; te dwa dowody są bardziej przydatne niż sam ogólny komunikat interfejsu użytkownika.