Bereiche
News
Rewind
Tipps & Berichte
Forum
Galerie
Journals
Events
Umfragen
Themenwoche
Kleinanzeigen
Interaktiv
Anmelden
Registrierung
Zu allen empfangenen Nachrichten
Suche...
Zur erweiterten Suche
Push-Nachrichten von MacTechNews.de
Würden Sie gerne aktuelle Nachrichten aus der Apple-Welt direkt über Push-Nachrichten erhalten?
Forum
>
Netzwerke
>
VPN unter OS X an Windows-Server extrem lahm
VPN unter OS X an Windows-Server extrem lahm
piik
26.02.14
18:03
Seit ich das mache ärgere ich mich darüber, dass VPN zu einem Windows-Server sehr, sehr schnarchig ist, verglichen mit dem VPN-Zugang auf einem PC (via VMware unter Win 7). Manchmal fast kaum zu verwenden.
Lahm ist nicht unbedingt die Datentransferrate, damit könnte ich leben, sondern das Listen von Verzeichnis-Inhalten auf dem Mac.
MaW.: mache ich ein Verzeichnis des Servers auf, in dem hunderte Ordner oder Dateien liegen, braucht das teilweise mehr als ein 1 Minute (auf dem PC Sekunden). Da wird es zur Qual, sich irgendwohin durchzuklicken. Im Internet gabs zwar hie und da Leute, die das auch beschäftigt, aber eben keine praktikable Lösung.
Vielleicht gibt es ja auch keine und es liegt schlicht daran, wie OS X mit X Zugriffen die Verzeichnisse ausliest.
Falls aber doch wäre das für mich (und andere betroffene Leute - nicht wenige) eine große Erleichterung.
Hilfreich?
0
Kommentare
Thomas Kaiser
26.02.14
18:21
Was sind denn die Versionsstände von Server und OS X? Tritt das Phänomen auch auf, wenn Du in Terminal.app zu dem fraglichen Verzeichnis navigierst und "ls" eingibst? Was gibt
sysctl net.inet.tcp.delayed_ack
in Terminal aus? Falls 3, würde ich mal das da im Terminal absetzen und direkt im Anschluß nochmal im Finder den Inhalt eines Verzeichnisses aktualisieren lassen und schauen, ob's einen Unterschied macht:
sudo sysctl -w net.inet.tcp.delayed_ack=2
Hilfreich?
0
piik
26.02.14
18:41
Das Phänomen tritt seit langem unter allen OS-X-Versionen mit allen Windows-versionen auf und liegt definitiv nicht an meinem Setup. Ich kenne viele, die da ächzen. Mit dem Terminal kann ich leider nicht crackmäßig, aber gepostete Zeilen kopieren geht
Das habe ich gemacht und ein Unterschied ist leider nicht wahrnehmbar.
Also wieder zurück auf 3 gesetzt.
Hilfreich?
0
Thomas Kaiser
26.02.14
18:55
piik
Also wieder zurück auf 3 gesetzt.
2 ist eigentlich besser. Aber egal, die Änderung überlebt eh keinen Neustart, wenn nicht auch was in /etc/sysctl.conf eingetragen wird). Was in dem Szenarium auch noch sein könnte, sind DNS-Probleme (reverse Lookup). Du könntest bspw. mal per
scutil --dns
mit angeknipstem VPN und ohne schauen/vergleichen, wer da gefragt wird.
Und dann wäre bei aktiviertem VPN spannend, wie (schnell) Name des Servers und dann andersrum die IP-Adresse des Servers auf den Namen (sog. PTR-Record) aufgelöst wird. Das geht bequem per Dienstprogramme
Netzwerkdienstprogramm
Lookup
Zumindest in älteren OS X Versionen gab's bzgl. reverse Lookup Probleme. Was ich auch noch nicht verstehe ist, ob Du den Test mit "ls" gemacht hast? Einfach "ls " (ohne Anführungszeichen aber mit abschl. Leerzeichen) im Terminal eingeben, dann aus dem Finder den Zielordner per Drag&Drop ins Terminal und dann auf
.
Hilfreich?
0
piik
26.02.14
19:14
Okay ich habe es mit ls gemacht.
Das geht ultrafix, unter eine Sekunde für über 100 Einträge statt >50 Sekunden.
Von daher dürfte es nicht mit DNS und Co zu tun haben, sondern eher eine Eigenheit des Finders sein, oder?
Hilfreich?
0
Thomas Kaiser
26.02.14
20:36
piik
Von daher dürfte es nicht mit DNS und Co zu tun haben, sondern eher eine Eigenheit des Finders sein, oder?
Warum? Also warum soll das eine unabhängig vom anderen sein? Du kannst doch so simpel nachschauen? Wenn (reverse) DNS-Auflösung bei etablierter VPN-Verbindung auch schnarchlahm ist, und genau deshalb der Finder herumlahmt, dann könnte eine Anpassung der DNS-Konfig die Lösung sein.
Ich hab in den letzten 10 Jahren so viele völlig absurde Gründe für lahme Directory Enumeration kennenlernen dürfen, dass ich erstmal gar nix mehr ausschließen würde
Hilfreich?
0
piik
27.02.14
11:00
Okay, ich habe die DNS-Abfrage duchgeführt und zweispaltig gegenüber gestellt.
Allein fehlt mir das Knowhow, um daraus etwas ableiten zu können.
Die Liste ist zwecks besserer Lesbarkeit hier
downloadbar.
Hilfreich?
0
Thomas Kaiser
27.02.14
11:25
piik
Okay, ich habe die DNS-Abfrage duchgeführt und zweispaltig gegenüber gestellt.
Allein fehlt mir das Knowhow, um daraus etwas ableiten zu können.
Im Normalfall ist die DNS-Reihenfolge: Google-DNS, spftor1.privacyfoundation.de, Deine Fritzbox (in genau der Reihenfolge werden die auch befragt mit schicken Timeouts von jeweils paar Sekunden, sollte einer der Server nicht erreichbar sein). Wenn Du das VPN anknipst, dann steht für die normale Auflösung 192.168.100.26 an erster Stelle (wohl ein DNS-Server am anderen Ende der VPN-Verbindung?) allerdings gibt es in 10.7 und 10.8 (IIRC) einen Bug, dass trotzdem lokale DNS-Server bevorzugt werden.
Das ist das, was die Screenshots hergaben (bitte pastebin.com nutzen in Zukunft, Copy&Paste funktioniert besser als Ablesen&Abtippen).
Die andere Frage war, was passiert, wenn Du bei aktiver VPN-Verbindung im Netzwerkdienstprogramm unter dem Punkt "Lookup" erst den Namen des SMB-Servers eingibst, mit dem Du Dich verbinden sollst (sollte dessen IP-Adresse als Antwort ausspucken) und dann im zweiten Schritt dessen IP-Adresse (sollte dann den Namen ausspucken, welcher ist dabei eigentlich egal, mir geht's an der Stelle nur darum, wie lange die Auflösung dieses sog. PTR-Records dauert -- denn ich kann mich an einen Fall erinnern, bei dem der Finder sich an derlei reverse-DNS-Chose verschluckt hat)
Hilfreich?
0
Kommentieren
Diese Diskussion ist bereits mehr als 3 Monate alt und kann daher nicht mehr kommentiert werden.
Tim Cook zu Trump-Besuch im Weißen Haus
Apple veröffentlicht macOS 15.3 (Aktualisierung...
Neues iPhone SE, MacBook Air und iPad Air vorau...
Sichere Exklave – neue Sicherheitsfunktion in m...
Bericht: iPad 11 erhält Apple Intelligence, App...
iPhone 17 "Air"
UltraFine 6K: LG möchte Apple mit neuem 32-Zoll...
Gefloppt: Humane AI Pin wird eingestellt, in we...