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.
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.
