PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : DynDNS macht Probleme



Dj-SPm
21.01.07, 16:51
Hallo,

hab in der Firma einen neuen Server aufgebaut (diesmal mit SuSE 10.1 statt 9.3). Habe dabei die Einstellungen nicht großartig verändert. Nun ist es aber so, dass ich auf adresse.dyndns.org nicht mehr innerhalb des Netzwerkes zugreifen kann. Das ist mein größtest Problem.

Wenn ich außerhalb des Netzwerkes bin, funktioniert der Zugriff und alles andere wunderbar.

Bitte um Hilfe - ist wichtig. Wenn Ihr noch mehr Infos braucht, fragt einfach nach.

Danke im Voraus

tschloss
21.01.07, 17:19
Ich kenne das als normal: in einem genatteten LAN kann ich nicht per externer IP auf geforwardede Server zugreifen. Ich weiss nicht so recht, woran das liegt, aber ich hebae es mit den Home-Routern, die ich schon hatte, nie anders erlebt.

Ist dein Server = Router? Wenn nein, welchen Router hast Du? Und das ging schonmal?

Dj-SPm
21.01.07, 17:23
Mein Server ist kein Router. Hab in der Firma einen DLink-Router und es ging schonmal. Ich vermute sogar, es liegt irgendwie an der neuen Linux-Version, denn:

Ich habe privat auch die gleiche Version, die ich vorher in der Firma hatte (9.3), einen SMC-Router und eine DynDNS-Adresse und das geht auch immernoch.

Wenn ich einen Ping absetze, geht er raus zu DynDNS und dann wieder ins Netzwerk rein mit der richtigen IP...

Das Problem ist äußerst seltsam!

bla!zilla
21.01.07, 17:26
Poste doch mal die Ausgabe von dem ping. Und was heißt das du nicht auf die Adresse zugreifen kannst? Bitte eine genaue Fehlerbeschreibung.

Dj-SPm
21.01.07, 17:30
PING [adresse] (ip) 56(84) bytes of data.
64 bytes from [adresse] (ip): icmp_seq=1 ttl=250 time=0.000ms
64 bytes from [adresse] (ip): icmp_seq=1 ttl=250 time=0.280ms
64 bytes from [adresse] (ip): icmp_seq=1 ttl=250 time=0.290ms
64 bytes from [adresse] (ip): icmp_seq=1 ttl=250 time=0.310ms

Dabei ist die IP (ip) nie die lokale IP des Servers.

Die Fehlermeldung, von wegen nicht erreichbar, lautet: 404 Die Seite kann nicht angezeigt werden.

bla!zilla
21.01.07, 19:00
Ist ja auch klar, bei einem ping auf den dynamischen DNS Namen deines Servers, antwortet der Router und nicht dein Server. Überprüfe mal lieber deine Portforwardings bzw. deinen Apache.

Dj-SPm
21.01.07, 20:03
Habe keinen Apache laufen. Portforwarding läuft auf port 22 und 10000 auf die IP des Servers (192.168.2.1) Router hat die IP 192.168.2.2

bla!zilla
21.01.07, 20:51
Habe keinen Apache laufen.

Dann lass dich doch mal endlich aus was du da laufen hast.


Die Fehlermeldung, von wegen nicht erreichbar, lautet: 404 Die Seite kann nicht angezeigt werden.

Was soll mir diese Fehlermeldung sagen? Klingt für mich nach "Browser geöffnet, DNS Name in der Adressleiste eingegeben und 404 bekommen". Wenn das nicht so ist ERKLÄRE bitte mal DETAILLIERT was du machst und was nicht geht. Wir sind hier keine lustige Fragerunde.


Portforwarding läuft auf port 22 und 10000 auf die IP des Servers (192.168.2.1) Router hat die IP 192.168.2.2

Portforwardings prüfen, Logs prüfen, Datenverkehr mittels Ethereal auswerten. Punkt.

Dj-SPm
21.01.07, 21:58
Also ok,

ich habe auf Port 10000 den Webmin laufen. Port 22 habe ich für PuttY geöffnet. Logs etc geben keine Fehler aus. Ich gebe in der Adressleiste (InternetExplorer) [server].homeftp.net ein und bekomme einfach nur die Seite 404 ... angezeigt.

Ich muss allerdings auf diese Adresse vom Netzwerk aus zugreifen können, da wir Programme verwenden, die (noch) hard-gecodet mit dieser Adresse laufen. Dass soll sich jetzt auch schnell ändern.

Die Client-Konfig:

IP 192.168.2.5
SubNet: 255.255.255.0
Gateway: 192.168.2.1 (Server)
DNS: 194.25.2.129 (T-Online)

Apache-Server läuft nicht, allerdings die Tobit WebBox. Diese zeigt gleiches Verhalten. Sprich: Extern kommte ich drauf, intern nicht.

Als Lösung hatte ich in der windows-hosts-datei jedes Clients den Server-DNS-Namen und dessen IP hinzugefügt. Das ging dann auch, doch da trat das nächste Problem auf:

Der eine Client ist ein Notebook und wird demnach auch zu Hause verwendet und der findet jetzt logischerweiser den Server unter der internen IP nicht, da er ja nicht mehr im Netzwerk ist, aber die Host-Datei diesen Hostname auf die interne IP routet.

so...

Wene
21.01.07, 22:10
Also ok,

ich habe auf Port 10000 den Webmin laufen. Port 22 habe ich für PuttY geöffnet. Logs etc geben keine Fehler aus. Ich gebe in der Adressleiste (InternetExplorer) [server].homeftp.net ein und bekomme einfach nur die Seite 404 ... angezeigt.

Solange du via Browser (in deinem Fall IE) auf eine IP oder URI zurgeiffen willst ohne einen Prot anzugeben verbindet er automatisch mit dem HTTP Port 80. Wenn dieser nicht weitergeleitet wird, liegt da das Problem.

Das wiederspricht allerdings deiner Aussage, von aussen währe ein Zugriff möglich. :ugly:

Läuft auf dem Server zufällig eine Firewall? Wenn ja: Wie ist die konfiguriert?

Dj-SPm
21.01.07, 22:12
Ja, Port 80 ist auch freigegeben und momentan offen wie ein Scheunentor (ergo: keine Firewall).

Ich komm auch wie gesagt auf die Tobit Webbox (deren Apache-Server, wenn man's so nimmt)

tschloss
21.01.07, 22:38
Also ich habe es gerade nochmal mit meinem WRT-54GL versucht:

Wenn ich aus meinem -genatteten- LAN auf die externe IP auf einen Port (22) zugreife, der auf einen im gleichen LAN stehenden Server geforwarded ist, passiert einfach nichts. Es kommt keine Verbindung zustande.

An dem Router kann man beim Forwarding nicht viel falsch machen.
Der selbe Server, der selbe Serverprozess (sshd in diesem Fall) funktioniert von Außen aber ohne Probleme. Ich wüßte also nicht, was ich am Server noch verändern sollte.

Mein Fazit: Das geht halt -zumindest mit dem Natting der üblichen Home-Router- nicht.
Hat denn jemand eine solche Situation, bei der es definitv geht?

Dj-SPm
21.01.07, 22:42
Ich HATTE sie. Habe den Router und dessen Einstellungen und die Clients nicht verändert. Habe nur neues Linux (10.1, vorheer 9.3). Und bei meinem 9.3 zu Hause geht es genauso. Auch NAT-Router und Port Forwarding. Weiß nicht, wieso es nicht geht...

Wene
22.01.07, 12:05
Bei mir geht das auch auf Port 80 (Apache) mit einem Netopia NAT Router.

tschloss
22.01.07, 12:22
Bei mir geht das auch auf Port 80 (Apache) mit einem Netopia NAT Router.
Ich hatte hier schon D-Link, Draytek Vigor und Linksys - niemals ging das. Egal.

RichieX
22.01.07, 12:33
Ich hatte hier schon D-Link, Draytek Vigor und Linksys - niemals ging das. Egal.

Haut mich tot, aber das sollte doch auch NICHT funktionieren. Sonst könnte doch jeder mit einer gefälschten IP ins genNATete LAN vordringen können. Ich würde sagen, das ist eine Feature und zwar eine Sicherheitsfeature und kein Bug.

RichieX

Dj-SPm
22.01.07, 15:37
Naja, so egal ist das nicht... Jedenfalls nicht in meiner Situation... Also, wir wissen, dass es nicht am Router liegt und auch nicht an den Clients.

Es muss also irgendwie an der Konfig des Suse-Linux-10.1 liegen. Nur leider kenne ich mich in diesem Punkt (DNS) nicht so aus. Was kann also Auslöser für so ein Problem sein?

bla!zilla
22.01.07, 16:05
Wird doch mal Ethereal oder tcpdump an. Dann siehst du anhand des Verkehrs wo es hakt. Wenn am Server schon nichts ankommt, dann muss es am Router liegen. Außerdem solltest du mal prüfen ob überhaupt etwas auf port *:80 lauscht.

Dj-SPm
22.01.07, 16:56
wie muss ich tcpdump anwenden? Wenn ich vom Linux-Rechner einen Ping auf seine DynDNS-Adresse abgebe, kommt der Ping an. Muss ich das nicht von den Client-Rechnern aus probieren? Die kommen ja nicht auf den Server.

netstat-a:

tcp 0 0 *:www-http *:* LISTEN

bla!zilla
22.01.07, 21:10
Wenn du einen Ping auf die Dyndns Adresse machst, so beantwortet der Router diesen ICMP Echo Request, nicht der Server. Bezüglich tcpdump: man tcpdump.

Wene
22.01.07, 21:49
Haut mich tot, aber das sollte doch auch NICHT funktionieren. Sonst könnte doch jeder mit einer gefälschten IP ins genNATete LAN vordringen können. Ich würde sagen, das ist eine Feature und zwar eine Sicherheitsfeature und kein Bug.

RichieX
Wie meinst du das jetzt? Wenn ich den Port 80 explizit auf meinen Server hinter der NAT weiterleite dann möchte ich ja damit (genau wie Dj-SPm auch) erreichen dass dieser Rechner von Aussen (und in seinem Fall auch von Innen) erreichbar ist.

Und bei mir ist er das ohne was besonderes eingestellt zu haben. :cool:
Aus dem internen Netz ist der Server natürlich auch über seinen internen Namen und die interne IP erreichbar.

Sehe auch keinen Grund warum das nicht so sein sollte, schliesslich brauche ich ja keinen Server ins Netz stellen wenn ich nicht will das darauf zugegriffen wird. :ugly:

@Dj-SPm:
Hast du zwischen NAT und Server noch eine Firewall, Router oder sonst was?

Dj-SPm
23.01.07, 00:13
Nö, die NATFirewall ist im Router drin und der Server selbst ist komplett offen. Ich weiß auch nicht, warum es nicht mehr geht...

Bin am Verzweifeln

tschloss
23.01.07, 00:28
Naja, so egal ist das nicht... Jedenfalls nicht in meiner Situation... Also, wir wissen, dass es nicht am Router liegt und auch nicht an den Clients.

Es muss also irgendwie an der Konfig des Suse-Linux-10.1 liegen. Nur leider kenne ich mich in diesem Punkt (DNS) nicht so aus. Was kann also Auslöser für so ein Problem sein?
Mit DNS hat das übrigens nix zu tun, oder geht es, wenn du die Übung mit deiner externen IP durchführst?

(Ein Firmwareupdate bei deinem Router hast du nicht zufällig noch mitgemacht?)

bla!zilla
23.01.07, 05:53
Bezüglich der Thematik: Aus dem internen Netz über eine dyndns Adresse auf einen internen Server zugreifen: Also bei mir geht das auch ohne besondere Tricks. Interessant sind die Logeinträge vom Apache - da steht nämlich der DNS Name meines Routers drin, nicht der des Clients. IMHO sollte das problemlos bei anderen Routern gehen, fraglich ist nur wie der Router Zugriffe von internen Clients über die externe Schnittstelle verarbeitet. Man müsste sich den Verkehr mal genau ansehen um zu sehen warum es bei mir klappt und bei anderen nicht.

RichieX
23.01.07, 08:41
Erstmal, versteh ich das richtig:

LANClient -> NATRouter -> Internet -> NATRouter -> LANServer
:confused:

Also vom internen Netz raus ins Internet und wieder zurück in LAN über den NATRouter.

RichieX

Dj-SPm
24.01.07, 18:58
Das siehst du richtig.

Hab jetzt hier privat auch einen neuen Server, auch wieder SuSE 10.1 und da klappt es auch einwandtfrei.

Das macht mich jetzt wirklich nachdenklich...

Nein, ein FirmwareUpdate etc habe ich nicht gemacht. Im Prinzip nur folgendes:

Alten Server abgebaut
Neuen drangehängt, IP eingerichtet etc
Daten kopiert

Mehr nicht...

Also liegt es an der Standart-Installtion von SuSE auch nicht.

bla!zilla
24.01.07, 19:07
Es hätte mich auch gewundert wenn es an der Standardinstallation gelegen hätte. Bitte endlich mal den Packetsniffer auspacken und den Verkehr beobachten.