Nextcloud Talk sehr langsam, Server hinter Reverse Proxy

[Spike S.]

Ich habe einen öffentlich erreichbaren VPS mit Proxmox. Der öffentliche Traffic wird direkt durch eine OPNsense Firewall (in einer VM) geleitet, in dieser Firewall ist das nginx Proxy Plugin aktiv, welchen ich als Reverse Proxy verwende. In einem Container steckt dann Nextcloud.

Bisher funktioniert eigentlich alles wie ich es mir vorstelle (in weiteren Containern laufen noch andere Dienste), bis auf Nextcloud Talk auf Android. Startet man die App aus der Kalten, dauert es meist 20, zuletzt eher 30 bis 60 Sekunden bist die Chatübersicht geladen ist. Läuft die App im Vorder- oder Hintergrund weiter (Cache?), reagiert sie in erwartbarem Zeitrahmen. Dies tritt konsequent bei allen Androiden auf, egal welche Android Version oder ob die App aus dem Play Store oder von Github installiert wurde. Auch aus unterschiedlichen Netzwerken heraus (LANs und Mobil). Im Browser tritt das Problem nicht auf.

Ich habe schon die diversen Issues auf Github zum Thema "lange Ladezeit" durch und den Server entsprechend geprüft/eingerichtet. coturn läuft auch mittlerweile. Jedoch kein Erfolg bisher.
Warum ich mich jetzt hier melde, ist eine Beobachtung beim Versuch den Traffic der App mitzuschneiden. Mit PCAPdroid wollte ich schauen, ob die Talk App ins Nirvana funkt oder wirklich solange keine Antwort bekommt. Allerdings tritt mit aktiver Protokollierung der Fehler gar nicht auf. Bei etlichen Versuchen, hat die Talk App die Chatübersicht immer in etwa einer Sekunde geladen, also nix zu meckern. PCAPdroid überwacht den Traffic einer App über einen VPN Zugang, "verbiegt" also den Weg zwischen Client und Server.

An der Stelle komm ich mit meinem Wissen nicht mehr weiter. Wo suche ich weiter nach einer Problemlösung? Beim Reverse Proxy? Der Firewall? Bei den DNS Einstellungen auf dem Handy? Bei der Talk App? Oder doch auf dem Nextcloud Server?

Mein Verdacht ist seit einiger Zeit der Reverse Proxy, dass er "Fragen" von der Talk App nicht richtig beantwortet und damit die Begrüßung nicht richtig funktioniert. Mir fehlt aber eine Ahnung, wie man das untersuchen könnte.

 

[Mojo1987]

Hast du mal ein anderes Handy versucht?
Das es mit der PCAPdroid nicht passiert ist halt schon seltsam, nicht dass dein Android komische Netzwerksachen macht.

 

[tdbr]

Wie stark ist die Hardware?
Fedora Server 39, i5-7500T, 8G RAM, docker, traefik. Zuhause gehostet (100/30mbit), erreichbar über Domain.
Sony Xperia 10 III, SailfishOS mit Android App support - Ladezeit 3-5s.

Wie sieht das Ganze aus über den Browser am Handy?

 

[Spike S.]

Wie gesagt, mit verschiedenen Androidgeräten (Android 7 bis 14, Samsung, Google, GrapheneOS) besteht das Problem. Die Beobachtung mit dem Trafficlogger hat mich auch überfordert...

Das ist ein gehosteter KVM Rootserver:
4x AMD EPYC 7443P Cores 4.0GHz
12 GB DDR4 RAM
100 GB NVME Speicherplatz
1,5 Gbit/s (Shared)

Sollte also reichen. Tut es ja auch. Steht die NC Talk Verbindung irgendwann mal, kann man darin ganz normal agieren. Nur die App öffnen dauert so lange, das man vergisst was man machen wollte...

Über den DDG Browser (Chrome Abkömmling), der regelmäßig seinen Cache leert, auf einem betroffenen Gerät, lief der Aufruf ohne Komplikationen. Also: Anmeldung Nextcloud, Talk App öffnen, Chat antippen.
Nur die Android App macht Probleme.

 

[tdbr]

Wie schaut es aus mit Konfigurationen? Wenn du container sagst wovon reden wir? Podman, Kubernetes, Docker, LXC. Ich kann mich schwach an meine Probleme erinnern. Ich hab in meiner nextcloud config noch trusted_domains und trusted_proxies reingesetzt. Ich glaub ich hatte allerdings Anmeldeprobleme und nicht trägheit.

## nextcloud config.php

[...]

  'trusted_domains' =>
  array (
    0 => 'nextcloud-nginx',
    1 => 'sub.domain.tld',
    2 => 'sub.domain.tld',
  ),
  'trusted_proxies' =>
  array (
    0 => '172.19.0.0/24',
  ),
 
[...]

 

[Spike S.]

Da ich Proxmox sagte, dachte ich es sei klar in welcher Art Container Nextcloud sitzt
Es ist ein LXC und das Nextcloud ist "bare metal" sozusagen, also nicht die AIO oder Docker Variante.

Jupp, die Config ist bei mir vorhanden. Wie du sagst, würde man ja sonst geblockt werden.
Deine Frage brachte mich aber auf einen Gedanken, mir die SSL Config nochmal anzusehen. Eingehende Verbindungen nutzen zwei SSL Verbindungen, von außen bis zum Proxy und intern vom Proxy zu Nextcloud noch mit einem "internen" Zertifikat. Probleme beim Handshake könnten mein Fehlerbild ergeben 🤔

 

[tdbr]

Meine internen Verbindungen sind alle ohne SSL. Das gibt immer nur Probleme und macht kaum Sinn mit reverse Proxy.

 

[Spike S.]

Ich habe mal das interne Zertifikat deaktiviert und den Proxy die Anfragen an Port 80 vom Nextcloud Server weiterleiten lassen. Keinerlei Änderung am Verhalten.

Dann habe ich mal alle Netzwerkpakete die über OPNsense laufen aufgezeichnet. Mir fehlt da einiges an Wissen und Erfahrung, aber was direkt auffällt:
1) dass es fast 18 Sekunden dauert, bis das erste Mal der Nextcloud Server (10.73.1.13) kontaktiert wird und
2) das hier IPv4 und IPv6 vermischt sind, kann aber nicht einschätzen ob das bei meinem Fehler eine Rolle spielt.

Hier die Aufzeichnung der LAN Schnittstelle von OPNsense (10.73.1.1). "Source" ist meine Public IP, "Destination" die IP vom Handy.

 

[Spike S.]

Hat noch jemand eine Idee? Ist das eine Spur, was ich zuletzt "entdeckt" habe?

Was ich mich frage, muss ich denn die Upstream Server immer mit IPv4 und IPv6 konfigurieren? Der Reverse Proxy und die Server untereinander arbeiten im Wesentlichen nur mit IPv4, aber eingehend scheint es ja IPv6 zu sein 🤔

 

[R00kie]

Ich bin gerade nur zufällig über diesen Thread gestolpert und sehe deine letzte Frage, zu der ich zumindest etwas sagen kann.

Was ich mich frage, muss ich denn die Upstream Server immer mit IPv4 und IPv6 konfigurieren? Der Reverse Proxy und die Server untereinander arbeiten im Wesentlichen nur mit IPv4, aber eingehend scheint es ja IPv6 zu sein

Wenn du den/ dem DNS-Eintrag bzw. -Einträgen zu deiner Domäne eine IPv6-Adresse hinterlegst, dann muss bis zum Server (Nextcloud) eine IPv6-Verbindung durchkonfiguriert sein (wenn man keine IPv6-zu-IPv4-Konvertierung durchführt).

Android bevorzugt IPv6-Verbindungen ggü. IPv4-Verbindungen und daher stürzt sich das Handy auf IPv6-Adressen bei DNS-Anfragen und versucht darüber den Verbindungsaufbau. Besteht z.B. vom Router bzw. Reverse-Proxy keine IPv6-Verbindung zum Nextcloud-Server schlägt die Verbindung fehl.

Wenn das bei dir der Fall ist, dass IPv6 nur halb umgesetzt ist, dann hast du zwei Optionen:
1. IPv6 intern vom Router/ Reverse-Proxy zum NC-Server konfigurieren
2. den IPv6-Eintrag vom DNS-Server entfernen

Ich hoffe das hilft.

 

[Spike S.]

@R00kie
Danke für den Tipp, habe mich dadurch nochmal damit auseinandergesetzt. Ich bin mir nur unsicher, ob der Weg passt. Habe in der Upstream-Gruppe den Nextcloud-Server mit der v4 und der v6 Adresse drin, also selber Server nur mit verschiedenen Adressen. Sollte zweckmäßig sein.

Nach anfänglichen Schwierigkeiten (musste an den Einstellungen "herumprobieren"), sehe ich jetzt in der Paketverfolgung, dass intern die v6 Adresse angesprochen wird. Allerdings mit dem gleichen Verhalten, erst nach etwa 40 Sekunden ist plötzlich eine Kommunikation durch Talk zu sehen, nur jetzt eben über die v6 Adresse.
Was ich nicht verstehe, während der 40 Sekunden Wartezeit funkte der Nextcloud Client vom PC über webDav (Dateisync) mit dem Server, auch über die v6 Adresse.
Ich kapiere es nicht....

Und auf den HA Proxy wechseln ist ja auch keine Garantie zur Problemlösung 🤷‍♂️

 

[konkretor]

https://stuff.21zoo.com/posts/nginx-disable-dns-caching-proxy-pass/

Das könnte noch ne Idee sein

 

[Spike S.]

@konkretor In den Einstellungen vom nginx Plugin für OPNsense sehe ich keine derartigen Einstellungen....ich werde die FW aber vermutlich eh neu aufsetzen, ohne OPNsense, mal schauen. Das kommt aber später.

Ich habe aber noch eine neue Erkenntnis gewonnen... beim Check über https://check-your-website.server-daten.de/ aller meiner verschiedenen Subdomains (die auf die selben IPs zielen), kommt bei allen IPv6 Anfragen ein Timeout. Die IPv4 Varianten der URLs die der Checker durchspielt funktionieren alle. Und wenn ich CURL Ausgabe von curl -v -s -I -X -6 POST https://example.com richtig lese, kommt ein Fehler 400.

Das bedeutet, der Fehler ist beim DNS bzw. der grundlegenden Netzwerkkonfiguration des Servers zu suchen?

Wie ist das eigentlich mit den IPv6 die einem der Hoster bereitstellt. Ich habe abab:1212:c:3::/64 (Beispiel) bereitgestellt bekommen. Diese ist doch direkt auch die erste reguläre IP und kann direkt so verwendet werden, in der DNS Zone beispielsweise, oder?
(ausgeschrieben abab:1212:000c:0003:0000:0000:0000:0000)

 

[konkretor]

https://wiki.archlinux.org/title/systemd-resolved


Schau mal mit resolvectl status was da raus kommt.

Vermutlich fehlt dem Container der richtige dns Server. Dann läuft deine Anfrage in einen dns timeout und daher ist es langsam

 

[Spike S.]

Dem Gedanken, warum DNS auf dem Servercontainer ein Problem sein sollte, kann ich nicht ganz folgen....

Allerdings bringt das etwas zu Tage:

Edit:
Das gibt mir auch zu denken, Ping vom Servercontainer aus. fc00:10::1 ist die interne IP vom Proxmox Host, worüber der öffentliche Verkehr zur Firewall geleitet wird (iptables DNATing).