Große Probleme mit Team-Client über VPN

1. ich würde die Probleme dann doch im VPN selbst suchen, denn wenn dieses passend für den David Client eingerichtet ist funktioniert darüber sowohl die Suche in allen 3 aktuell verfügbaren David Clients, als auch der stabile Betrieb aller 3 Varianten.
Beim Team Client habe ich allerdings die Erfahrung gemacht das er sehr zickig reagiert wenn Der David Server mal nicht erreichbar ist.
Aus unerfindlichen Gründen verwirft er dann jeweils seine Login Daten, samt Server Adresse.
Daher macht es dort für uns am meisten Sinn die Leute die Anmeldung über Chayns nutzen zu lassen, da sie sich dann neben ihrer eMail Adresse nur noch das Kennwort merken müssen.

2. wenn man im DNS des internen Netzes einen Eintrag für den externen Namen eines sowohl intern, als auch extern verfügbaren David Servers mit der internen IP einrichtet müssen sich die Leute generell nur noch einen Servernamen merken.
(Randnotitz dazu: Wer den postlagernden Versand nutzt kommt da übrigens auch gar nicht drum herum, zumindest nicht wenn er den Nutzern ermöglichen möchte im Zweifel auch mal einen postlagernd versandten Anhang selbst kontrollieren zu können.)

3. sowohl Modern, als auch Team Client arbeiten in der Tat deutlich flüssiger über schlechte Leitungen als der classic Client.
Neue Kollegen bekommen daher auf Ihren mobilen Geräten seit geraumer Zeit auch nur noch den jeweils aktuellsten Client.
Zuerst gab es also den Modern und inzwischen den Team Client für neue Kollegen.
Bekommen Nutzer des Modern Client neue Geräte erhalten sie inzwischen dort dann auch den Team Client.
Altnutzer bekommen nur bei Klagen über die mobile Performance den Team Client, da es doch eine sehr große Umgewöhnung vom Classic Client ist und es dazu viele Beschwerden von Altnutzern gab. Wenn sie allerdings mal merken das die moderneren Clients unterwegs flüssiger arbeiten, mögen sich die meisten dann doch lieber umgewöhnen.

Quote from nordtech

Nochmal im Detail: Ich beende den Team-Client, der mit Verbindung zu SERVERNAME brav funktionierte, starte ihn dann neu (OHNE dass sich an der VPN-Verbindung irgendwas ändert) und plötzlich mag Team SERVERNAME nicht mehr, obwohl er bis eben über diese Verbindung kommuniziert hat.

Leider doch, denn wenn es auf der Verbindung zu Paketverlusten oder lag kommt und der Client ab und an schlicht keine rechtzeitige korrekte Antwort vom Server bekommt, verwirft er die Verbindung samt Login Daten. Ja, ist nicht schön, aber leider Tatsache.
Andere Programme / Protokolle sind da toleranter, weswegen sie auch über richtig grottige VPN Verbindungen noch sauber laufen. Deine Beispiele SQL und SMB sind perfekte Beispiele dafür selbst mit richtig grottigen VPNs noch gut klar zu kommen.
Der Grund warum Du das siehst wenn der Client geschlossen wurde und man ihn neu startet ist schlicht das es nur bei der Authentifizierung auftritt. Steht die Verbindung erst mal nehmen die David Clients für die Dauer der Sitzung - völlig zu recht - an das sie mit den richtigen Daten am Server verbunden sind und es nichts weiter als akute Netzwerkstörungen sind, versuchen es als einfach beliebig häufig nach mal.
Klappt allerdings das anmelden nicht muss man die Daten - völlig absurder Weise - jedes mal wieder neu eingeben, weil die modernen Clients sie schlicht jedes mal bei einem Fehlschlag der Verbindung verwerfen.
Man kann übrigens auch schlicht immer wieder die gleiche Server Adresse eingeben, irgendwann klappt es dann halt, unabhängig davon ob man die Adresse ändert, oder nicht.
Das ist am Ende eine reine Timing Frage.

Meine Erfahrung ist das die David Clients über die gleich schlechte Internet Verbindung besser ohne VPN, als mit VPN klar kommen.
Dabei ist der classic Client Fehlertoleranter, dafür aber weniger flüssig über schlechte Leitungen, die beiden modernen Clients sind dafür weniger Fehlertolerant, im Gegenzug aber flüssiger.

Hier sollte Tobit meiner Meinung nach noch mal deutlich am Login Verhalten der modernen Clients nachbessern und einmal eigegebene Zugangsdaten schlicht wenigstens so lange unverändert im Speicher behalten wie man keine anderen eingibt.
Ich habe das allerdings bislang nicht als Supportanfrage bei Tobit aufgemacht weil es für uns unterm Strich ein exotisches Problem ist, was sich durch Stabilisierung der Anbindung fast völlig beseitigen ließ und seither nur noch sehr selten auftritt.

Hat man ein taugliches VPN läuft das alles einfach insgesamt sauber, ganz gleich mit welchem Client.
Gleiches gilt auch ohne VPN bei direkt exponiertem David Server, passiert da halt nur meist seltener, weil eben der Overhead vom VPN das Problem der nicht optimalen Anbindung nicht noch zusätzlich belastet.

Quote from nordtech

Bei dieser Konstellation haben wir bei mehreren Kunden reprouzierbar das Phänomen, dass sich der Client nach längerem Nicht-Benutzen weghängt. Das Fenster wird "blass", der Mauszeiger zum Kringel, und man muss 30 Sekunden warten, bis sich wieder etwas tut. Dieses Problem wurde hier im Forum immer wieder mal in Einzelfällen berichtet, und Tobit hat es nie in den Griff bekommen. Ebenfalls so eine "Kleinigkeit", die in der Praxis tödlich nerven kann. Man hat jemanden am Telefon, sagt: "Warte, ich schau schnell im Kalender nach" - und dann kommt der Kringel.

Das klingt danach als würde der Client zwischendurch über die externe Verbindung versuchen den Server zu erreichen.
Da das bei den meisten Routern nicht funktioniert, bzw. selbst wenn es vom Router unterstützt wird und auch freigegeben ist halt dann zu einer Limitierung der Verbindungsgeschwindigkeit kommt kann man damit genau die von Dir - und gelegentlich hier im Forum - beschriebenen Effekte sehen, unterschiedlich ausgeprägt, je nach dem ob der Router Loopback erlaubt, oder ob er es nicht tut.

Im Grunde ist das genau der Grund warum man sein DNS für solche konstellationen als sogenanntes split DNS aufsetzt, damit eben interne Nutzer beim Zugriff auf den intern stehenden Server nicht über die externe IP Adresse und damit durch den externen Router / Firewall hindurch - möglichst noch samt port forwarding - auf den Server zugreifen, sondern direkt.
Das funktioniert aber halt nur dann wirklich sauber, wenn sichergestellt ist das die internen Clients garantiert immer die interne IP des Servers vom DNS geliefert bekommen.
Tja und da sind wir bei der eigentlichen Problemquelle angelangt.
Oft haben interne Clients doch Zugriff auf externe DNS Server und bekommen so dann von dort - in der Situation - unpassende DNS Antworten, was sie dazu bringt über das externe Interface des Routers / der Firewall auf den eigentlich internen Server zugreifen zu wollen.

Bis zur Einführung von DNS over HTTPS gab es da eigentlich eine wirklich simple Lösung: sperren von jeglichen Client seitigen Traffic zu externen DNS Servern bzw. eben der entsprechenden Ports. Seit DNS over HTTPS ist das halt nicht mehr durch einfache Sperren zu erzwingen und es kommt schlicht drauf an die Clients korrekt zu konfigurieren.