Hallo Amauris,

zum ersten verwechselst Du DNS mit Netbios/WINS. Nur da funktionieren reine Hostnamen ;-)
Zum Zweiten sind die Speedports verdammt unlogisch gestrickt in der Hinsicht.

Mal davon abgesehen das die Kisten (zumindest bei meinem 921er) als DNS-Namen speedport.ip nutzen und eine logische Konsequenz eine Fortführung dessen wäre (z.B. diskstation.ip) - benutzt die 921er Serie den eigenen Namen mit Firmwareversion als Domainendung. Bei mir ist das z.B. jetzt "diskstation.Speedport_W_921V_1_22_000" (ohne "").
Geh in deinen Router, such dir den Namen und benutze den als TLD. Vielleicht handhabt der das genau wie die 921er-Serie. Viel Erfolg.

zum ersten verwechselst Du DNS mit Netbios/WINS. Nur da funktionieren reine Hostnamen ;-)

Nö, das verwechselt er nicht.

Bei der Fritzbox können Rechner ihren Hostnamen beim Router registrieren,
und der im Router eingebaute DNS Server kann diese Rechner dann unter der
Domain "fritz.box" mit ihrem Namen finden:

$ nslookup iPad-von-XXX.fritz.box. fritz.box
Server: fritz.box
Address: fd00::XXXX:XXXX:XXXX:XXXX#53

Name: iPad-von-XXX.fritz.box
Address: 192.168.178.115


Und da "fritz.box" die Standard-Domain ist (das wird per
DHCP so an die Rechner im Netzwerk verteilt), kann man nun
die Rechner einfach über ihren Hostnamen ansprechen:

$ ping iPad-von-XXX
PING ipad-von-XXX.fritz.box (192.168.178.115): 56 data bytes
...


Speedports können so etwas nicht. Jedenfalls konnte es mein
W303v Typ B nicht, und der W724v kann es offenbar ja auch nicht.

Mal davon abgesehen, dass dieses nicht unbedingt zur Lösung beiträgt:

Doch.. verwechselt er.
Es wird ein Hostname benutzt. Hostname ungleich DNS-Name.
Wenn irgendein Gerät ein DNS-Suffix dran hängt, dann wird es zu einem FQDN und damit ist es DNS.
Hängt ein Gerät nichts dran, bleibt es ein Hostname und kann via DNS nicht aufgelöst werden.
Die Fritzbox ist hier halt nur anscheinend etwas benutzerfreundlicher, intelligenter und sagt den Geräten das sie doch bitte ein DNS-Suffix nutzen sollen

Mal davon abgesehen, dass dieses nicht unbedingt zur Lösung beiträgt: Doch.. verwechselt er.

Hallo, und vielen Dank für Eure Antworten!

Um es schon mal vorweg zu nehmen: Nein, ich verwechsle nicht DNS mit NetBIOS!
Aber ich muss zugeben, dass ich durch den Beitrag auch das recherchiert und überprüft habe. Und selbst wenn man zunächst davon ausgegangen, dass die von mir angesprochene Hostnamens-Auflösung bisher über NetBIOS stattgefunden hätte, die einzige Änderung war der Austausch des Routers (Speedport ersetzt Fritzbox).

Also gibt es nun zwei Möglichkeiten:
1. Der Speedport leitet keine NetBIOS-Anfragen weiter, während die FritzBox das anscheinend sehr wohl macht (was ja auch so sein sollte).
Das wäre äußerst merkwürdig und daher IMHO auch unwahrscheinlich. Gänzlich ausschließen möchte ich das aber natürlich nicht, dafür habe ich schon zu viel Seltsames mit Telekom-Hardware erlebt. ;)

2. Oder aber die Namensauflösung findet doch über DNS statt.
Und dies ist auch tatsächlich der Fall: Denn der DNS-Resolver des Clients ganz sehr wohl auch Hostnamen auflösen, zumindest sofern eine Domänensuchliste bekannt ist (natürlich findet die eigentliche Namensauflösugn dann wieder mit einem FQDN statt, aber aus Sicht des Nutzers, also aus meiner Sicht, ist es eine "Hostname-Namensauflösung"). Dies ist bei DHCP-Adressvergabe durch das DNS-Suffix möglich. (siehe auch RFC 3397: http://tools.ietf.org/html/rfc3397#page-2 )

Wie auch Dein W921V vergibt mein W724V einen DNS-Suffix, der auf Modell-Namen und Firmware-Version abgeleitet ist, nämlich: Speedport_W_724V_01011601_00_009

Allerdings wird dieser Suffix ja allen Geräten per DHCP mitgeteilt und im Rahmen einer DNS-Anfrage automatisch bei der Namensauflösung als Domänensuchliste verwendet. Daher müsste der W724V die Hostnamen der angeschlossenen bzw. per DHCP-verwalteten Geräte eigentlich auch ohne expliziter Angabe der Domäne auflösen können. Unabhängig davon was laut korrekter DNS-Implementierung funktionieren müsste: auch mit Angabe des Domänen-Suffix funktioniert die Namensauflösung nicht!

Und mal abgesehen davon: DNS soll doch eine Vereinfachung sein, damit man sich nicht die IP merken muss bzw. den Gerätenamen bequem und schnell über die Tastatur eingeben kann. Wer bei der Telekom hat sich denn bitteschön diesen Monster-DNS-Suffix einfallen lassen?
Der Speedport selbst ist doch bereits über die Domäne "ip" erreichbar (nämlich: "speedport.ip"). Das wäre doch auch ein hervorragender DNS-Suffix für die DHCP-Clients gewesen, oder etwa nicht? ;)

Interessanterweise kann man ja eine Namensliste aller dem Speedport bekannten Geräte einsehen und sogar anpassen. Da kann ich mir eigentlich nur vorstellen, dass es sich hier um eine fehlerhafte Implementierung handelt. Davon hat der W724V ja leider mehrere (z.B. auch das nervige Fehler: "DNSv6-Fehler: Der angegebene Domainname kann nicht von < > aufgelöst werden. Fehler: DNSv6 Address Unreachable. (P008)" ).

Es wird ein Hostname benutzt. Hostname ungleich DNS-Name. Wenn irgendein Gerät ein DNS-Suffix dran hängt, dann wird es zu einem FQDN und damit ist es DNS. Hängt ein Gerät nichts dran, bleibt es ein Hostname und kann via DNS nicht aufgelöst werden.

Das ist aber Standard für einen DNS Client: Endet der Name nicht mit einem
Punkt, dann wird vom DNS Client der eigene Domainname ergänzt, bzw. es wird
versucht den Namen durch anhängen aller Search-Domains zu einem FQDN zu ergänzen
und die werden dann alle durchprobiert. Es kann höchstens noch sein, dass
Namen die innerhalb der Zeichenkette Punkte enthalten erst mal so als FQDN
probiert werden, bevor mit dem ergänzen von Domainnamen begonnen wird.


Und genau über den FQDN kann der Fritzbox DNS Server ja die IP Adressen zu den
Rechnern im lokalen Netz liefern.

Zuallererst Asche auf mein Haupt.. ich habe den Eintrag mit der Suchliste übersehen.. ist doch etwas zu warm heute gewesen... sorry dafür.. das rückt alles in ein anderes Licht.

Ok, grenzen wir das ganze ein:
Die Suchliste verteilt der Speedport per DHCP.
Ein Suffix allerdings nicht.
In Summe SOLLTE das ganze funktionieren, da eine Suchliste im Normalfall ausreicht.
Der Speedport scheint also den Host nicht identifizieren zu können oder hat per default nicht die Funktion auf so etwas zu antworten - was allerdings die Vergabe der Suchliste sinnfrei machen würde.

Ich würde darauf tippen, das hier bei der Programmierung nicht zu Ende gedacht wurde oder es tatsächlich ein Bug ist.

Von daher kann man eigentlich nur sagen:

Bitte liebes TelekomTeam.. sagt den Firmwareschreibern die sollen Suffixe per DHCP verteilen und/oder die Suchlistenfunktion fixen (und nicht mit der Firmware im Suffix - gerne die *.ip Variante).
Und wenn ich mir noch etwas wünschen darf.. nicht nur bei der 700er-Serie ;-)

p.s. ich habe allerdings einen kleinen Unterschied zu Dir Amauris: Gerät+Suffix wird bei mir aufgelöst - anscheinend ein kleiner Unterschied im 921er

Zuallererst Asche auf mein Haupt.. ich habe den Eintrag mit der Suchliste übersehen.. ist doch etwas zu warm heute gewesen... sorry dafür.. das rückt alles in ein anderes Licht. Ok, grenzen wir das ganze ein: Die Suchliste verteilt der Speedport per DHCP. Ein Suffix allerdings nicht.

Kein Problem. Ich habe mir ja auch in dem Beitrag viel Mühe gegeben, in langen Schachtel-Sätzen möglichst viel Information unterzubringen. ;)

Noch eine weitere kleine Erläuterung:
Das unter Windows sog. "DNS-Suffix" (bzw. "verbindungsspezifische DNS-Suffix") ist mit der Domänen-Suchliste gleichzusetzen. Bei Unix-basierten Systemen wird es daher sinnvollerweise direkt "Such-Domänen" bzw. "Search Domains" genannt.
Darüberhinaus gibt es eigentlich nur noch den systemweiten Domänen-Namen, der dem Host mitgeteilt werden kann. Dieser Domänen-Name (sog. "Primary Domain Name") wird auf allen Verbindungen in der Such-Liste verwendet. Die DNS-Suffixe jedoch nur auf dem jeweiligen Netzwerk-Adapter bzw. der jeweiligen Netzwerkverbindung (darum hat sich Microsoft wohl auch zu diesem Namen "verbindungsspezifischer DNS-Suffix" entschieden).

Fazit: Der Speedport verteilt per DHCP zwar einen DNS-Suffix (sog. Domänen-Suchliste), kann aber innerhalb dieses Namensraums trotzdem die Namen der ihm bekannten Geräte nicht auflösen. In meinen Augen ein klarer Firmware-Fehler!

Ich gehe mal davon aus, dass Du auch als gelernter Admin im heimischen LAN keinen Active Directory Server hast, sondern dass Du "normale" Windows PCs hast, die sich untereinander sozusagen organisieren.

Das ist ein RIESEN-MIST. Schreibe ich aus eigener Erfahrung.
Alles lief superschön, ich konnte hin und her auf die jeweils freigegebenen Ordner zugreifen. Hierzu hatte ich (weil Windows da immer mal ein bisschen braucht, bis es weiß, wo es ist und wer um es herum ist) in der Synology den "Local Master Browser" aktiviert.
Dann gab es eine "Störung" durch ein neues Gerät im Netz. Und ab da geriet alles durcheinander und ward seither nicht mehr wie es war.

Ich bin zwar kein Fan des W724V, aber ich würde ihn zumindest im Windows-Netz (und insbesondere, falls ein Win 8 da drin unterwegs ist) nicht alleinig unter Generalverdacht stellen.

Von manchen PCs geht nur noch der Zugriff über die IP-Adresse und die anderen PCs werden in der Netzwerkumgebung nicht mehr gesehen (außer, sie sind über die IP-Adresse als Netzlaufwerk verbunden).

Ich gehe mal davon aus, dass Du auch als gelernter Admin im heimischen LAN keinen Active Directory Server hast, sondern dass Du "normale" Windows PCs hast, die sich untereinander sozusagen organisieren.

Bei mir laufen zwar auch diverse Server-Systeme (u.a. auch WS2K8R2), allerdings in einem separaten VLAN und somit völlig unabhängig von meinem "privaten Netz".
Und in diesem privaten LAN gibt es auch ein paar Windows-Maschinen, jedoch lediglich aus nostalgischen Gründen. Die primär genutzten Geräte sind allesamt auf UNIX-Basis (Linux und Mac OS ). Der Windows Dateidienst ist daher zwar in der Synology aktiviert, jedoch ohne keinerlei Zusatzfunktion eingeschaltet (also auch ohne aktiviertem "Local Master Browser").
Diese ganze NetBIOS- und WINS-Geschichte war schon damals während meiner Dozenten-Tätigkeit für Microsoft (für die MCSA-/MCSE- bzw. später MCITP-Zertifizierungen) nicht wirklich vermittelbar. Anstatt die alten Zöpfe mal endlich sauber abzuschneiden, hat Microsoft sich da echt selbst nen Kuckucks-Ei ins Nest gelegt.

In Bezug auf das von mir geschilderte Problem bleibe ich daher dabei:
Der Fehler liegt im Speedport! Ich habe inzwischen alle Komponenten ausgeschaltet und nacheinander wieder in Betrieb genommen und neu konfiguriert (Lehrbuch-mäßig in Reihenfolge der ISO-OSI-Schichten ). Doch selbst im komplett neu eingerichteten Netzwerk sind die gleichen Probleme.
Aber: Sobald ich den Speedport gegen einen anderen Router austausche (egal ob FritzBox, Linksys, Cisco oder Netgear) funktioniert die Namensauflösung tadellos.
Und um die fehlerhafte DNS-Implementierung noch deutlicher herauszustellen:
Sobald ich im Speedport den DHCP-Dienst deaktiviere und einen dedizierten DHCP- und DNS-Server aufsetze und verwende, funktioniert auch wieder alles tadellos.

Fazit: Der DNS-Dienst im Speedport ist buggy!
Beim Durchstöbern dieses Forums habe ich eben gelesen, dass das Telekom-Support-Team ja in einem anderen Thread bzgl. der tausendfachen "DNSv6-Fehler"-Einträge im System-Log des W724V bereits mitgeteilt hat, dass es Probleme mit der DNS-Implementierung gibt und demnächst ein Firmware-Update herauskommen soll.

Nimm einfach den DNS des Synology, richte DHCP auf dem Synology ein und lass das NAS das Netzwerk organisieren, wenns sowieso den ganzen Tag läuft. Den Speedport würde ich dann nur noch als Gateway nutzen. Einziger Nachteil, Du musst dann die Konfigurationsoberfläche des Routers per IP-Adresse öffnen.

Hallo bb123!

Danke für Deinen Tipp. Allerdings hat dieses Vorgehen noch einen weiteren Nachteil:
Selbst wenn die Diskstation 24/7 eingeschaltet ist, so verbringt sie die meiste Zeit im Standby-Modus, denn im Regelfall schlafe ich nachts und tagsüber bin ich gar nicht zu Hause und greife daher dann auch nur vereinzelt von extern auf die NAS zu.
Ferner gehe ich davon aus, dass die Aktivierung von DHCP und DNS auf der Diskstation automatisch den Ruhezustand bzw. Stand-By-Modus ausschaltet oder verhindert. Andernfalls müsste die NAS zuerst "aufwachen" (sofern sie im Ruhezustand/Stand-by ist), sobald sich ein Gerät per DHCP anmelden oder eine DNS-Anfrage stellen will.

Unabhängig davon wie es nun konkret ist: das ist nicht die von mir bevorzugte Lösung!
Es gibt schließlich ein Gerät bei mir (und in den meisten anderen Haushalten auch), welches tatsächlich 24/7 eingeschaltet und aktiv (und nicht im Stand-By-Modus) ist, nämlich der Router! Für Client-Client Kommunikation sollte es nicht notwendig sein zuerst das NAS "aufzuwecken", wenn es ohnehin ein Gerät gibt, welches normalerweise genau dafür da ist.

Ich bin Dir trotzdem sehr dankbar für die Hilfestellung, jedoch beseitigt sie nicht die Ursache des Problems, sondern lediglich das Symptom.
Vielleicht kann sich ja auch mal jemand von offizieller Seite hierzu äußern. Es wäre schon interessant zu wissen, ob an diesem Problem bereits im Rahmen des ohnehin geplanten Firmware-Updates wg. der DNSv6-Probleme gearbeitet wird. Und darüber hinaus natürlich auch, wann mit der Lösung (sprich: Update-Veröffentlichung) zu rechnen ist.

Moin,

kleine Zwischenfrage, hast Du mal versucht die Diskstaion über diesen "vergurkten" FQDN anzusprechen? Selbst bei der von Dir als Vorbild genannten Fritzbox musste ich manchmal Geräte über ansprechen, allein ging auch manchmal nicht. Oder hast Du es alternativ mal mit versucht?

hast Du mal versucht die Diskstaion über diesen "vergurkten" FQDN anzusprechen? Selbst bei der von Dir als Vorbild genannten Fritzbox musste ich manchmal Geräte über ansprechen, allein ging auch manchmal nicht. Oder hast Du es alternativ mal mit versucht?

Na klar, funktioniert aber auch nicht. Hatte ich auch schon mal geschrieben, ist aber in der Masse an Informationen wohl untergegangen. ;)

Weder mit dem FQDN "diskstation.Speedport_W_724V_01011601_00_009" noch mit "diskstation.speedport.ip" oder "diskstation.ip" funktioniert es.
Bei der FritzBox hatte ich die von Dir angesprochenen Probleme nicht: da wurde immer entsprechend der DNS-Suffixe / Domänensuchliste korrekt aufgelöst.

Hatte ich auch schon mal geschrieben, ist aber in der Masse an Informationen wohl untergegangen.

Hmm, ja sorry, hab mir Deinen "Schachtelsatzbeitrag" oben noch mal sinnentnehmend durchgelesen. Du schreibst da von http://host und die Diskussionen dahinter schweifen dann zu Netbios ab. Irgendwann war ich dann auch nicht mehr im Bilde ;-)
Bei http://host hatte ich aber auch schon mal Unterschiede feststellen können. Das war sowohl browser als auch betriebssystemabhängig. Safari z.B. versuchte eine Seite im Internet zu öffnen, während Firefox die lokale url ansteuerte.

Browser- und Betriebssystemabhängigkeit kann weitestgehend ausgeschlossen werden, denn das Problem besteht mit Firefox, Chrome und Safari sowohl unter MacOS, als auch Ubuntu und Windows 7.

Mir ist gerade aufgefallen, dass den Clients per DHCP neben der IPv4-DNS-Server-Adresse (192.168.2.1) auch eine IPv6-DNS-Server-Adresse (fe80::1) mitgeteilt wird, also eine Link Local Adresse. Seltsamerweise ist die weder per "ping" noch als Namensserver per "nslookup" erreichbar.

Gibt es denn gar nichts, was von offizieller Seite hierzu gesagt werden kann???

Mir würde ja schon eine Info aufmuntern, dass im Rahmen der DNSv6-Problembehebung beim W724v auch dieses (durchaus verwandte) Problem angegangen wird.

Neben dieser Hostnamen-Problematik konnte ich am Wochenende noch ein weiteres Phänomen beobachten:
DynDNS URLs, die auf die eigene öffentliche IPs verweisen, können aus dem internen Netz nicht aufgerufen werden!
Offenbar hat der W724v einen üblen Bug in der Namensauflösung oder aber die Routing-Tabelle ist fehlerhaft bzw. unvollständig.

Wie dem auch sei:

Liebes Telekom-Team!

Ich bitte nun zum dritten Mal um eine Antwort von Euch, da ich gerne wissen möchte, ob zumindest das Hostnamen-Problem bereits angegangen wird oder ob ich den Router austauschen lassen soll.

DynDNS URLs, die auf die eigene öffentliche IPs verweisen, können aus dem internen Netz nicht aufgerufen werden!

It´s not a bug, it´s a feature. Die Suchfunktion hilft in diesem Fall

Danke für den Hinweis. Die Suche hatte ich zwar auch schon bemüht, allerdings sucht die nur in dem Forum, in dem man sich gerade befindet. Und das wird recht unübersichtlich oberhalb des "Willkommen im Service-Forum"-Banners angezeigt. ;)


Ich muss zugeben, dass ich leicht entsetzt über das Fehlen der Hairpin-NAT Funktion bin. Der Speedport W 724v ist immerhin das neueste Gerät in der Speedport-Familie. Vermutlich hast Du aber recht, dass das Fehlen dieser Funktion womöglich von der Telekom sogar noch als Security-Feature angepriesen wird. Dabei sollten doch die Zeiten mittlerweile vorbei sein, als NAT von paranoiden Halbwissenden als "Sicherheitsfunktion" angesehen wurde. Aber das scheint wohl noch nicht zu den sog. Sicherheitsexperten der Telekom durchgedrungen zu sein. Mehr dazu in folgendem Thread:
http://forum.telekom.de/foren/read/service/dsl-festnetz/speedports/speedport-dsl-vdsl-modems/implementierung-von-hairpin-nat-aka-nat-loopback,843,11154971.html


Daher ziehe ich diesen Punkt aus meinem vorherigen Beitrag zurück. (Editieren ist in diesem Forum ja leider nicht möglich...)

Grundsätzlich bleibt ich aber dabei:

Liebe Telekom,
wann kommt endlich ein Firmware-Update, das die DNS-Probleme behebt? Wird da überhaupt schon dran gearbeitet?

Scheint ja wirklich schwer zu sein, sich zu diesem Thema zu äußern... O.o

Hallo Amauris,
hallo in die Runde,

herzlichen Dank zunächst an alle User hier im Thread für den engagierten und fachkundigen Austausch über das Symptom - und Dank insbesondere an Amauris nicht zuletzt für seine Geduld!

Wir haben die Hinweise und Wünsche intern weitergeleitet und melden uns hier im Thread zurück, sobald die Antwort eingetroffen ist.

Bereits jetzt eine Anmerkung aus eigener Erfahrung zu einer Frage von Amauris:

DNS soll doch eine Vereinfachung sein, damit man sich nicht die IP merken muss bzw. den Gerätenamen bequem und schnell über die Tastatur eingeben kann. Wer bei der Telekom hat sich denn bitteschön diesen Monster-DNS-Suffix einfallen lassen? Der Speedport selbst ist doch bereits über die Domäne "ip" erreichbar (nämlich: "speedport.ip"). Das wäre doch auch ein hervorragender DNS-Suffix für die DHCP-Clients gewesen, oder etwa nicht?

Das Gute an dieser Lösung ist, dass der aktuell als DHCP-Server bzw. als Gateway aktive Routertyp samt momentanem Firmware-Stand z. B. unter Windows an der Kommandozeile über
ipconfig /all
direkt erkundbar ist.

Das ist zumal bei telefonischer Unterstützung unserer Kunden oft effizienter als der Weg des Kunden hin zum Router (im Keller  -  hinterm Schrank  -  "weiß nicht, wo er ist" . . . *wolke ), um aufs Etikett zu schauen, und bietet zudem mehr Informationen zum Heimnetz als der direkte Zugriff auf die Startseite der Routerkonfiguration.

Wir haben die Hinweise und Wünsche intern weitergeleitet und melden uns hier im Thread zurück, sobald die Antwort eingetroffen ist.

Danke für die Rückmeldung und fürs Weitergeben an die Technik! Hoffentlich gibt es da in absehbarer Zeit Verbesserungen, denn ansonsten werde ich nach dem Markstart der neuen FritzBox 7490 im Herbst wohl das Speedport-Abo wieder kündigen müssen.

Das Gute an dieser Lösung ist, dass der aktuell als DHCP-Server bzw. als Gateway aktive Routertyp samt momentanem Firmware-Stand z. B. unter Windows an der Kommandozeile über ipconfig /all direkt erkundbar ist.

Das Schlechte an dieser Lösung ist, dass die eigentlichen Merkmale dieser Funktion nicht mehr sichergestellt sind. Es findet also quasi eine missbräuchliche bzw. falsche Nutzung der DNS-Funktionen für Support-Zwecke statt. Dabei lassen sich die genannten Informationen doch viel einfacher über die Router-Webseite herausfinden. Selbst bei vergessenem Passwort muss man nicht in den Keller gehen und auf der Rückseite vom Router nachschauen, denn die allgemeinen System-Informationen bekommt man auch ohne Login: http://imgur.com/Q1YbD3T

Das funktioniert übrigens bei allen Kunden (mit Speedport W724V), sogar bei denen, die den Router NICHT als DHCP-Server einsetzen und folglich auch dieses "Monster-DNS-Suffix" nicht mitgeteilt bekommen.

Hallo Amauris,
 
auch wenn der Anschein enstehen könnte: „Nein“, wir haben Sie nicht vergessen – Sie sind uns lediglich ein wenig durchgerutscht… unser Fauxpas ;)
 

Danke für die Rückmeldung und fürs Weitergeben an die Technik! Hoffentlich gibt es da in absehbarer Zeit Verbesserungen…

Gerne, allerdings haben wir auf das „wann“ nicht so den Einfluss. Eine Antwort liegt bisher ebenfalls noch nicht vor, so dass wir aktuell nicht mit Infos glänzen können.

Hallo Amauris,

danke für Ihre Stellungnahme zur Gateway-"Kennung" - inzwischen haben unsere Kollegen sich bei uns zurückgemeldet, und es zeichnen sich eine denkbare Ursache und eine effiziente Lösung ab, die mit *diesem* Thema nix zu tun hat:

Laut Handbuch Ihres Synology-Modells DS213+ unter
http://ukdl.synology.com/download/ds/userguide/DSM4.2/Syno_UsersGuide_NAServer_deu.pdf
 - dort auf Seite 19 im Screenshot ersichtlich - lautet die werksseitig festgelegte URL Ihres NAS konkret
DiskStation
und nicht
diskstation
. . . bitte testen Sie den lokalen Zugriff auf das NAS mit der "offiziellen" groß- und kleingeschriebenen Variante.

Klappt es dann?

Laut Handbuch Ihres Synology-Modells DS213+ unter http://ukdl.synology.com/download/ds/userguide/DSM4.2/Syno_UsersGuide_NAServer_deu.pdf  - dort auf Seite 19 im Screenshot ersichtlich - lautet die werksseitig festgelegte URL Ihres NAS konkret DiskStation und nicht diskstation . . . bitte testen Sie den lokalen Zugriff auf das NAS mit der "offiziellen" groß- und kleingeschriebenen Variante. Klappt es dann?

Vielen Dank für die Rückmeldung!
Ich hatte natürlich vorher auch schon den exakten Hostnamen (laut der Diskstation Konfigurations-Webseite) ausprobiert. Allerdings hat dies erwartungsgemäß weder damals noch jetzt gerade (bei einem erneuten Versuch) zum Erfolg geführt, denn schließlich sind sowohl DNS als auch WINS "case insensitive". Sprich: die Groß-/Kleinschreibung ist irrelevant.
Siehe auch:
http://www.ietf.org/rfc/rfc4343.txt
http://technet.microsoft.com/en-us/library/cc728457(v=ws.10).aspx

Ich habe auch schon den Hostnamen sowohl in der Diskstation-Konfiguration als auch der Speedport-Geräteliste auf "diskstation" (kleingeschrieben) gesetzt, jedoch auch ohne Erfolg. Selbst die Foren-Beiträge mit dem Hinweis, dass das "Hairpin-NAT"-Problem (siehe anderer Thread) durch das Konfigurieren des Gerätenamens in der Speedport-Geräteliste auf den DynDNS-Namen umgangen werden könne, haben nicht funktioniert.

Der einzig funktionierende Weg ist derzeit die Verwendung der IP, was jedoch aus sicherlich nachvollziehbaren Gründen keine dauerhafte Alternative geschweige denn eine echte Lösung darstellt.

Hallo Amauris,

Der einzig funktionierende Weg ist derzeit die Verwendung der IP, was jedoch aus sicherlich nachvollziehbaren Gründen keine dauerhafte Alternative geschweige denn eine echte Lösung darstellt.

Als Umgehungslösung bietet es sich an einen entsprechenden Eintrag in die Hosts-Datei der verwendeten Clients vorzunehmen. Das sollte funktionieren.

Wir vermuten mal, Sie wissen wie das funktioniert....

Wir vermuten mal, Sie wissen wie das funktioniert....

Danke für die Info. Ja, das habe ich natürlich als Provisorium an meinem privaten Geräte bereits so eingerichtet. ;)

Mehr als ein Übergangslösung kann das jedoch nicht sein, denn auf Dauer möchte ich auch mit meinem dienstlichen Notebook auch wieder problemlos im Home Office arbeiten können. Mangels Administrationsrechten ist da nämlich das Editieren von System-Dateien (nachvollziehbarer Weise) unterbunden.

Dieses Vorgehen ist daher als Behelfslösung durchaus für eine überschaubare Zeit praktikabel, sie behebt jedoch nicht das eigentliche Problem! 😛

Danke für die Info. Ja, das habe ich natürlich als Provisorium an meinem privaten Geräte bereits so eingerichtet

Das hatten wir uns fast schon gedacht, dass Sie als Fachmensch, das so gelöst haben. Ist aber schon ein bisschen gemein, dass Sie das der Forengemeinde nicht verraten haben

Gibt ja bestimmt auch noch den einen oder anderen User, dem mit diesem Workaround geholfen werden kann.

Mehr als ein Übergangslösung kann das jedoch nicht sein, denn auf Dauer möchte ich auch mit meinem dienstlichen Notebook auch wieder problemlos im Home Office arbeiten können. Mangels Administrationsrechten ist da nämlich das Editieren von System-Dateien (nachvollziehbarer Weise) unterbunden.

Sie werden sicher für diesen Rechner auf die IP zurückgreifen, was ja erst mal auch funktioniert.

Wir haben das Verhalten des Speedports ja bereits an die zuständigen Menschen weitergeleitet. Ob sich in dieser Hinsicht was ändern wird und wann können wir leider nicht sagen.

Ich habe übrigens das gleiche Problem. Bisher nutzte ich einen Netgear Router und musste jetzt wegen Entertain/VoIP auf einen alten Speedport 723V zurückgreifen.

Ich habe mehrer Endgeräte über Portweiterleitungen von aussen verfügbar gemacht. Als URL in den Browsern habe ich aber immer den DynDNS Namen verwendet. Denn ich möchte sowohl intern als auch von extern auf die Geräte mit meinem iPad, MAC, etc zugreifen können.

Beispiel: http://xxx.homeip.net:8080

Bisher hat das auch vom lokalen Netz mit meinem Netgear Router immer gut funktioniert. Seitdem ich nun den 723v als Router benutze geht das nicht mehr und ich muss zu Hause das xxx.homeip.net durch die täsächliche IP Adresse ersetzen.

Bin ich unterwegs brauche ich wieder den DynDNS Namen. Das ist aüßerst unkomfortabel.
Gibt es denn keine Lösung liebe Telekom?

Vielen Dank!