PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Webserver ist von aussen nicht mehr erreichbar



hehehe
26.03.07, 20:30
Hallo,

Hier mein Problem:

Ich habe einen Jinzora Streaming Server eingerichtet, um meine Musik zu Hause auf dem Palm übers WLAN zu hören. Das hat auch geklappt, nun ist er aber nicht mehr erreichbar. Das ganze hat angefangen, als members.dyndns.org den DDOS Attacken erlag. Ich bin nun wieder vor Ort (also beim Server) aber irgendwie klappt es nun nicht mehr.

Über 192.168.0.175:80 komme ich zwar noch auf die Jinzora Seite, aber mit mein.dyndns.org klappt es nicht.

Hier ein paar Ausgaben:

/etc/apache2/apache.conf (der relevante Teil)


ServerName localhost

NameVirtualHost *:80

<VirtualHost *:80>
ServerName mein.dyndns.org
ServerAlias mein.dyndns.org
DocumentRoot /var/www/jinzora2
HostnameLookups On
UseCanonicalName On
</VirtualHost>

fish@fishbox:~$ ifconfig
eth0 Link encap:Ethernet HWaddr 00:00:E8:23:82:65
inet addr:192.168.0.175 Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: fe80::200:e8ff:fe23:8265/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:37771 errors:3 dropped:0 overruns:0 frame:0
TX packets:39956 errors:1 dropped:0 overruns:0 carrier:2
collisions:0 txqueuelen:1000
RX bytes:4523792 (4.3 MiB) TX bytes:43057323 (41.0 MiB)
Interrupt:12 Base address:0xa800

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:92671 errors:0 dropped:0 overruns:0 frame:0
TX packets:92671 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:9155266 (8.7 MiB) TX bytes:9155266 (8.7 MiB)
Die Ports 21, 22 und 80 sind im Router weitergeleitet - aber weder mein FTP, SSH noch Webserver sind erreichbar. Im lokalen Netzwerk funktioniert alles, aber nicht übers Netz. Ich muss dabei allerdings anmerken, dass ich es von einem PC innerhalb des Netzes versuche - also ein PC mit der gleichen externen IP wie der Server. Keine Ahnung, ob das einen Einfluss hat oder nicht. Gemäss verschiedenen Portscans/Porttests im Netz sind meine Ports 21, 22 und 80 offen, oder werden als stealth angezeigt. Das sollte also okay sein, oder?

Hier noch die ddclient.conf


GNU nano 1.3.10 File: /etc/ddclient.conf

# Configuration file for ddclient generated by debconf
#
# /etc/ddclient.conf

pid=/var/run/ddclient.pid
protocol=dyndns2
use=web, if=eth0
server=members.dyndns.org
wildcard=yes
login=xxx
password='xxx'
mein.dyndns.org
Wenn ich auf dyndns.org gehe und dort die IP angucke, scheint sie korrekt zu sein.

Auch ein einloggen über SSH direkt mit der externen/public Server-IP (anstatt der DynDNS) funktioniert nicht.

Die /etc/ssh/sshd_conf


# Package generated configuration file
# See the sshd(8) manpage for details

# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 768

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 120
PermitRootLogin no
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile %h/.ssh/authorized_keys

# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes

# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Change to no to disable tunnelled clear text passwords
PasswordAuthentication yes

# Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
KeepAlive yes
#UseLogin no

#MaxStartups 10:30:60
#Banner /etc/issue.net

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

Subsystem sftp /usr/lib/openssh/sftp-server

UsePAM no
Ich bin gerade etwas ratlos, wieso das alles nicht klappt.

Server System ist Ubuntu Dapper LTS Server Edition, der Client läuft auf Kubuntu Feisty 7.04 Beta.

Bin froh um jede Hilfe, vielen Dank!! :)

corresponder
27.03.07, 00:54
hi,

hast du mal probiert, dich auf der dyndns.org seite direkt einzuloggen?
mir scheint, die haben gerade massive probleme, zumindest wird meine ip seit ein paar tagen nicht mehr aktuallisiert.
per hand, direkt auf deren seite, geht es.
das stand auch vor kurzem mal auf heise.de.

gruss

c.

Pingu
27.03.07, 08:32
Hier ist Dein Problem:
Im lokalen Netzwerk funktioniert alles, aber nicht übers Netz. Ich muss dabei allerdings anmerken, dass ich es von einem PC innerhalb des Netzes versuche - also ein PC mit der gleichen externen IP wie der Server. Keine Ahnung, ob das einen Einfluss hat oder nicht.Das geht nicht (intern <-> extern <-> intern), wo extern auch noch die selbe IP ist. Du kannst solche Sachen immer nur von einem Rechner außerhalb ausprobieren.


mir scheint, die haben gerade massive probleme, zumindest wird meine ip seit ein paar tagen nicht mehr aktuallisiert.
Also bei mir ging es die letzten Tage. Ich war die letzten 2 Wochen in den Staaten und ich konnte von dort problemlos mein VPN mit zu Hause aufbauen.

Pingu

hehehe
27.03.07, 11:51
Hier ist Dein Problem: Das geht nicht (intern <-> extern <-> intern), wo extern auch noch die selbe IP ist. Du kannst solche Sachen immer nur von einem Rechner außerhalb ausprobieren.
Uhhmm...

Vor den Problemen bei DynDNS konnte ich mich aber z.B. vom Laptop (der die gleiche public IP hat wie der Server) in Firefox über mein.dyndns.org auf meine Jinzora Streaming Seite verbinden, das ging problemlos.

Nun klappt es nicht mehr und ich tappe im Dunkeln...

hehehe
31.03.07, 10:43
Kann niemand weiterhelfen?

bla!zilla
31.03.07, 11:33
Wird mal einen Packetsniffer an und schau was mit den Paketen passiert.

Die Aussage das intern -> extern -> intern nicht klappt ist nur bedingt richtig. Es gibt Router die das können, die tricksen aber eher. Normalerweise geht das bei NAT-Gateways nicht.

hehehe
01.04.07, 00:47
Hallo, Danke - das mit dem Paketsniffer würde ich ja gerne machen, aber muss der auf dem Server (ohne X) laufen oder geht es auch auf dem Laptop mit gleicher public IP? Ich kenne mich mit diesen Programmen überhaupt nicht aus. Ethereal?

Btw, auch hier suchen wir eine Lösung: http://serversupportforum.de/forum/webserver/15311-webserver-ist-von-aussen-nicht-mehr-erreichbar.html

Ich bin ratlos, allerdings auch ziemlicher Laie auf dem Gebiet...

rkauskh
01.04.07, 11:02
Hi

Such dir mal einen anonymisier-Proxy im Internet und ruf darüber deine externe IP auf. Dann sollte es auch wieder gehen aus dem internen Netz über die WAN-IP deines Routers den Streamserver zu erreichen.
Du kannst auf dem Client in /etc/hosts die Serveradresse auch direkt auf die lokale IP des Servers umleiten. Dann rufst du zwar die dyndns-Adresse auf, aber verläßt nie dein internes Netz, da dein Rechner die Adresse schon auf die interne IP des Servers auflöst. Nützt aber nix wenn du den Zugriff auch von außerhalb deines Netzes nutzt, da dann diese Auflösung fehlschlagen wird.
Ich hab mir eine Adresse bei nic.de.vu zugelegt. Wenn ich's richtig verstanden habe steht dort ein Proxy der die .de.vu-Adresse auf .dyndns.org umleitet. Damit gings bei mir.

bla!zilla
01.04.07, 11:03
Ethereal oder tcpdump, wobei tcpdump eher was für den Server ist, da es sehr klein und ohne grafische Oberfläche daherkommt. Wenn du aber überhaupt keine Ahnung von TCP/IP und Protokollen hast, dann lass es. Dann bringt sich das auch nicht weiter.