WAN-Zugriff auf Webserver (thttpd) - unmöglich?

[Schnoerkel]

Hallo allerseits,

nach zig erfolglosen Versuchen meinerseits auf meinem WL500gx einen funktionsfähigen Webserver einzurichten, wende ich mich nun an euch, in der Hoffnung das mir jemand helfen kann.

Als Linux-Newbie habe ich mittels der beiden Tutorials "ipkg package system Tutorial" und "thttpd Web Server" (www.macsat.com) auf meinem Router (Oleg-Firmware 1.9.2.7-4) alle notwendigen Sachen eingerichtet, um laut Anleitung einen funktionsfähigen Webserver zu erhalten. Dieses Unterfangen sah auf dem ersten Blick auch recht erfolgreich aus, bis ich feststellen musste, dass die auf dem Router (bzw. dem angeschlossenen USB-Stick) hinlegte Seite nicht über das WAN abrufbar ist und über LAN nur innerhalb der ersten 10 Minuten.

Das Forum habe ich, vorzugsweise im englischen Bereich, schon durchforstet. Wie es scheint, bin ich nicht allein mit meinem Problem. Lösungen sind aber keine dabei, da sich die Threads alle in Nebensächlichkeiten verlaufen.

Auch wenn meine Einträge denen aus dem Tutorial entsprechen, möchte ich sie dennoch einmal auflisten.



post-boot aus /usr/local/sbin/
~~~~~~~~~~~~~~~~~~~
#!/bin/sh
# wait for /opt to mount
mount /dev/discs/disc0/part1 /opt
i=0
while [ $i -le 30 ]
do
if [ -d /opt/etc ]
then
break
fi
sleep 1
i=`expr $i + 1`
done

# Activate swap
swapon /dev/discs/disc0/part2

# Run all active services - active means starts with S
/opt/etc/init.d/rc.unslung




post-firewall aus /usr/local/sbin/
~~~~~~~~~~~~~~~~~~~~
#!/bin/sh
iptables -D INPUT -j DROP
iptables -A INPUT -p tcp --dport 81 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -t nat -A PREROUTING -i $1 -p tcp --dport 80 -j DNAT --to-destination $4:81

iptables -A INPUT -j DROP




thttpd.conf aus /opt/etc/
~~~~~~~~~~~~~~~~~
dir=/opt/share/www
port=81
user=nobody
nochroot
nosymlink
novhost
logfile=/opt/var/log/thttpd.log
# Please do not edit pidfile path at it is use to kill thttpd process during init
pidfile=/opt/var/run/thttpd.pid


Ich würde mich freuen, wenn sich der Sache jemand annehmen könnte. Ich bin mit meinem Latein (trotz großem Latinum ;) ) am Ende *schnüff*

Grüße
Schnoerkel

[Schnoerkel]

Mir drängt sich so langsam aber sicher der Verdacht auf, dass ich im deutschsprachigen Forenbereich der einzige mit Zugriffsproblemen auf den Webserverdienst bin. Benutzt denn hier wirklich niemand dieses Feature? Lief es bei allen auf Anhieb? Hat keiner irgendwelche Tipps, was man noch überprüfen könnte?

Grüße
Schnoerkel

[schnickschnack0]

Hi Schnoerkel,

wie versuchst Du von aussen auf den Router zuzugreifen. Direkt über die momentane öffenliche IP oder über einen DYNDNS Dienst?

Du solltest so http://deineÖffenlicheIP:81 auf deine Seite zugreifen.

Da du den port 80 auf den port 81 umgeleitet hast.

iptables -t nat -A PREROUTING -i $1 -p tcp --dport 80 -j DNAT --to-destination $4:81

Mittels des Tutorials von macsat funktioniert die Sache eigentlich auf Anhieb.:)

[Schnoerkel]

Hallo schnickschnack0,

der WAN-Zugriff funktioniert sowohl über die öffentliche IP als auch über den DynDNS-Alias nicht (beide IPs werden korrekt aufgelöst und sind identisch). Der Zugriffsversuch auf den Webserver erfolgte jeweils über den Internetanschluss eines Freundes oder Bekannten, also nicht über den gleichen DSL-Anschluss an dem auch der Webserver angeschlossen ist (da soll es angeblich zu Problemen kommen). Ping bzw. Tracerts können erfolgreich auf die IP abgesetzt werden. Unter dem Standard-Port (80) wird aber keine Seite angezeigt.

Deinen Vorschlag:


Du solltest so http://deineÖffenlicheIP:81 auf deine Seite zugreifen.
Da du den port 80 auf den port 81 umgeleitet hast.

kann ich nicht ganz nachvollziehen. Laut der Regel sollte der Webserver doch über den Standardport (80) von außen erreichbar sein. Die interne Weiterleitung von Port 80 (extern) auf Port 81 (intern) erreiche ich doch mit


iptables -t nat -A PREROUTING -i $1 -p tcp --dport 80 -j DNAT --to-destination $4:81

Demnach muss der Aufruf also: "http://meineÖffenlicheIP:80" oder einfach "http://meineÖffenlicheIP" heißen.

Greife ich innerhalb des LANs auf den Webserver zu (über Port 81) klappt es anstandslos. Die in meinem ersten Post erwähnten Zugriffsprobleme:


... und über LAN nur innerhalb der ersten 10 Minuten.

konnte ich mittlerweile beheben. Scheinbar neigt thttpd dazu sich hin und wieder aufzuhängen bzw. aus der Prozessliste zu verschwinden ;)

Was mich vorallem wundert ist die Tatsache, dass die Einträge innerhalb der post-firewall überhaupt keinen Einfluss auf iptables -L zu haben scheinen (dort sollten doch dann auch die Einträge gelistet sein, oder nicht?). Auch das Asus-eigene Webinterface listet die von mir vorgenommenen Firewalleinstellungen über post-firewall in der Übersicht nicht auf. Deaktiviere ich z.B. die Firewall komplett über das Webinterface kommt ebenfalls kein Webserver-Zugriff zustande, obwohl ein entsprechendes Portforwarding dort noch eingestellt ist.

Gibt es denn keine Checkliste anhand dessen man kontrollieren kann, ob alle notwendigen Einstellungen richtig gesetzt sind? Ich habe mich ja, wie gesagt, schon strickt an das Tutorial auf macsat.com gehalten. Bei der Syntax "--to-destination" meine ich mich beispielsweise zu erinnern, das sich dies nur auf Bereiche innerhalb einer DMZ-bezieht, oder sehe ich das falsch? Aber dann müsste es ja auch bei anderen nicht laufen, die den Webserver ebenfalls nicht in einer DMZ stehen haben.

Mein Problem ist, das ich nicht mehr weiß, wo ich noch nach einem Fehler suchen könnte.

Grüße
Schnoerkel

[schnickschnack0]

Natürlich musst Du das über einen externen DSL Anschluss machen.

Auf Port 80 Internetport sollte, wenn Du das nicht umgesellt hast das Webinterface des Routers antworten und angezeigt werden.

Da Du von aussen automatisch über port 80 auf deinen Router zugreifst, musst über :81 auf das Webverzeichnis zugreifen, da sonst das Webinterface des Router antwortet und nicht das www - Verzeichnis.

So ist es zumindest bei mir.

Ich habe festgestellt, daß dies unterschiedlich ist, je nachdem was für eine Version der Firmware installiert ist.

Das Abschmieren des thttpd kannst Du über den Cron beheben, indem du von Zeit zu Zeit den thttpd neu startest.

Ich schätze mal, wenn Du eine alternative Firmware installiert hast, solltest Du die Finger vom Webinterface lassen.

[Schnoerkel]

Auf Port 80 Internetport sollte, wenn Du das nicht umgesellt hast das Webinterface des Routers antworten und angezeigt werden.

Da Du von aussen automatisch über port 80 auf deinen Router zugreifst, musst über :81 auf das Webverzeichnis zugreifen, da sonst das Webinterface des Router antwortet und nicht das www - Verzeichnis.

*nickt* ... Zu Anfang wurde tatsächlich das Webinterface des Routers angezeigt. Da war ich auch noch guter Dinge. Dachte mir also: "Stell ich mal den Port für das Interface um." Das Webinterface erreiche ich nun über den geänderten Port (den externen Zugriff darauf habe ich deaktiviert). Rufe ich aber die externe Ip über Port 80 auf kommt die bekannte Fehlermeldung, dass die Seite (also die Selbsterstellte für thttpd) nicht angezeigt werden kann *grmpf*.



Ich schätze mal, wenn Du eine alternative Firmware installiert hast, solltest Du die Finger vom Webinterface lassen.

Habe zur Zeit die Firmware version 1.9.2.7-4 von Oleg drauf. Dachte eigentlich, dass gerade die Weiternutzung des orginalen Webinterfaces dabei von Vorteil ist. Bei OpenWRT fällt dies ja beispielsweise vollständig weg.

Grüße
Schnoerkel

[schnickschnack0]

Hast Du es jetzt mal mit http://deineDYNDNS-Adresse:81 versucht.
Ich bekomme, trotz daß ich den Port für das Webinterface umgestellt habe, das Webinterface, wenn ich ohne :81 auf den Router von aussen zugreife.

[Schnoerkel]

Hast Du es jetzt mal mit http://deineDYNDNS-Adresse:81 versucht.
Ich bekomme, trotz daß ich den Port für das Webinterface umgestellt habe, das Webinterface, wenn ich ohne :81 auf den Router von aussen zugreife.
nope ... bekomme bei beiden "Möglichkeiten", also sowohl über Port 80 als auch über 81 von WAN-Seite aus nichts angezeigt. Wenn ich meine IP-Adresse mit dem geänderten Port für das Webinterface angebe, dann ebenfalls nicht, aber dies ist ja auch so gewollt und im Konfigurationsmenü entsprechend eingestellt (bzw. deaktiviert).

Wenn der Webserver bei dir ohne Probleme von außerhalb erreichbar ist, könntest du dann bitte einmal deine Ausgabe von iptables -L posten. Vielleicht kann man im Vergleich schon daran erkennen ob und was bei mir noch fehlt.

Edit: beim nochmaligen Durchlesen deines letzten Postings wurde ich etwas stutzig ... reden wir wirklich beide davon über den Router eigene hinterlegte html-Seiten (z.B. auf dem USB-Stick) nach außen hin verfügbar zu machen? Ich möchte die Konfigurationsseite _nicht_ von außenhalb zugänglich machen, sondern lediglich eigene Seiten mithilfe von thttpd anbieten.

Grüße
Schnörkel

[schnickschnack0]

Ich habe schon kappiert, daß Du von aussen auf deinen Webserver zugreifen willst.

das ist meine post-firewall.

#!/bin/sh
iptables -D INPUT -j DROP
iptables -A INPUT -p tcp --dport 81 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -t nat -A PREROUTING -i $1 -p tcp --dport 80 -j DNAT --to-destination $4:81

Ich kann keinen Unterschied zu deiner finden.

[Schnoerkel]

das ist meine post-firewall.

... entspricht wie du schon gesagt hast der meinigen. Wie sieht es mit der Ausgabe mittels "iptables -L" bei dir aus? Meiner einer bekommt folgendes:



[admin@(none) /]$ iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
DROP all -- anywhere anywhere state INVALID
ACCEPT all -- anywhere anywhere state RELATED,ESTABL ISHED
ACCEPT all -- anywhere anywhere state NEW
ACCEPT all -- anywhere anywhere state NEW
SECURITY all -- anywhere anywhere state NEW
ACCEPT tcp -- anywhere my.router tcp dpt:www
ACCEPT tcp -- anywhere anywhere tcp dpt:ftp
ACCEPT tcp -- anywhere anywhere tcp dpt:81
ACCEPT tcp -- anywhere anywhere tcp dpt:www
DROP all -- anywhere anywhere

Chain FORWARD (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere
DROP all -- anywhere anywhere state INVALID
TCPMSS tcp -- anywhere anywhere tcp flags:SYN,RST/SY N tcpmss match 1453:65535TCPMSS set 1452
ACCEPT all -- anywhere anywhere state RELATED,ESTABL ISHED
SECURITY all -- anywhere anywhere state NEW
ACCEPT all -- anywhere anywhere ctstate DNAT

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Chain MACS (0 references)
target prot opt source destination

Chain SECURITY (2 references)
target prot opt source destination
RETURN tcp -- anywhere anywhere tcp flags:SYN,RST,AC K/SYN limit: avg 1/sec burst 5
RETURN tcp -- anywhere anywhere tcp flags:FIN,SYN,RS T,ACK/RST limit: avg 1/sec burst 5
RETURN udp -- anywhere anywhere limit: avg 5/sec bur st 5
RETURN icmp -- anywhere anywhere limit: avg 5/sec bur st 5
DROP all -- anywhere anywhere

Chain logaccept (0 references)
target prot opt source destination
LOG all -- anywhere anywhere state NEW LOG level warning tcp-sequence tcp-options ip-options prefix `ACCEPT '
ACCEPT all -- anywhere anywhere

Chain logdrop (0 references)
target prot opt source destination
LOG all -- anywhere anywhere state NEW LOG level warning tcp-sequence tcp-options ip-options prefix `DROP '
DROP all -- anywhere anywhere

... ist hier vielleicht schon der/die Fehler sichtbar?

in der INPUT-Chain wundert mich vorallem der Bereich


ACCEPT tcp -- anywhere my.router tcp dpt:www
ACCEPT tcp -- anywhere anywhere tcp dpt:ftp
ACCEPT tcp -- anywhere anywhere tcp dpt:81
ACCEPT tcp -- anywhere anywhere tcp dpt:www

... warum wird www zweimal aufgelistet. Oder liegt das noch an der zusätzlichen Eintragung im Webinterface im Menüpunt Portforwarding? Wenn ja, müsste das dann nicht in der FORWARD-Chain drinstehen? Fragen über Fragen, wer weiß die Antworten?

Grüße
Schnoerkel

[Schnoerkel]

*gähn* ... man kommt sich hier fast vor wie im Altenheim. Alle sitzen in diversen Ecken und keiner traut sich ein Wort zu sagen. Alle sprachlos ob dieses Problems geworden? Wo sind sie denn, die sich Linux-Experten schimpfen?

Grüße
Schnoerkel

[martin72]

Excuse me, my english is better than my german.

Try this:

In a telnet session:
nvram set http_lanport=8008
nvram commit

In thttpd.conf, use port 80 instead of 81.
The post-firewall file can be left empty, no special routering is required.

The great change here is that now you get to your router setup at a different port (http://192.168.1.1:8008), so your default port 80 is free to use for a web server or anything else you may like.
Don't know where I found this, perhaps on Macsat site. Anyway, this works really fine for me!!

Best regards,

Martin.

[Schnoerkel]

Hi martin72,

I already changed the port for the webinterface and it's reachable on the new port only. This works fine.

I erased the content of post-firewall, altered the setting in thttpd.conf as you told and rebooted the router. The two lines from my old setting above:


ACCEPT tcp -- anywhere anywhere tcp dpt:81
ACCEPT tcp -- anywhere anywhere tcp dpt:www

... disapeared in iptables


[admin@(none) /]$ iptables -L

Chain INPUT (policy ACCEPT)
target prot opt source destination
DROP all -- anywhere anywhere state INVALID
ACCEPT all -- anywhere anywhere state RELATED,ESTABL ISHED
ACCEPT all -- anywhere anywhere state NEW
ACCEPT all -- anywhere anywhere state NEW
SECURITY all -- anywhere anywhere state NEW
ACCEPT tcp -- anywhere my.router tcp dpt:www
ACCEPT tcp -- anywhere anywhere tcp dpt:ftp
DROP all -- anywhere anywhere

Chain FORWARD (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere
DROP all -- anywhere anywhere state INVALID
TCPMSS tcp -- anywhere anywhere tcp flags:SYN,RST/SY N tcpmss match 1453:65535TCPMSS set 1452
ACCEPT all -- anywhere anywhere state RELATED,ESTABL ISHED
SECURITY all -- anywhere anywhere state NEW
ACCEPT all -- anywhere anywhere ctstate DNAT

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Chain MACS (0 references)
target prot opt source destination

Chain SECURITY (2 references)
target prot opt source destination
RETURN tcp -- anywhere anywhere tcp flags:SYN,RST,AC K/SYN limit: avg 1/sec burst 5
RETURN tcp -- anywhere anywhere tcp flags:FIN,SYN,RS T,ACK/RST limit: avg 1/sec burst 5
RETURN udp -- anywhere anywhere limit: avg 5/sec bur st 5
RETURN icmp -- anywhere anywhere limit: avg 5/sec bur st 5
DROP all -- anywhere anywhere

Chain logaccept (0 references)
target prot opt source destination
LOG all -- anywhere anywhere state NEW LOG level warning tcp-sequence tcp-options ip-options prefix `ACCEPT '
ACCEPT all -- anywhere anywhere

Chain logdrop (0 references)
target prot opt source destination
LOG all -- anywhere anywhere state NEW LOG level warning tcp-sequence tcp-options ip-options prefix `DROP '
DROP all -- anywhere anywhere


The webserver is now available on LAN-site with 192.168.1.1:80 but again not from the external adress (e.g. http://myexternalIP:80) :(

Regards,
Schnoerkel

[martin72]

Hi martin72,

I already changed the port for the webinterface and it's reachable on the new port only. This works fine.

I erased the content of post-firewall, altered the setting in thttpd.conf as you told and rebooted the router. The two lines from my old setting above:

... disapeared in iptables


The webserver is now available on LAN-site with 192.168.1.1:80 but again not from the external adress (e.g. http://myexternalIP:80) :(

Regards,
Schnoerkel


Hi,

I few options:
- I set up my router itself as a virtual server (NAT settings, only port 80), but I do not really know if this is needed. I cannot test this right now.
- On my Speedtouch modem, I also made a port forwarding, directing all traffic to the static WAN IP adress of mij router.
- A question: here do you check your external IP adress? I myself cannot reach my website from my LAN using my external IP. It only works from outside. Perhaps you tested this already, but just to be sure...

Hope this helps,

Martin

[Datafreak]

Also ich hab mir nicht alles durchgelesen, aber der Zugriff erfolgt wie folgt:

Extern (Wan) über deine IP oder dyndns Adresse (Port 80).

Intern Lan über die interne IP-Adresse des Routers und Port 81, da auf Port 80 dein Webinterface läuft.

Fall man von außen nicht Zugreifen kann, muss du ggf. den PING zulassen.
Kannst du testen, in dem du dich mal von außen anpingen lässt!

Ich bin der gleichen Anleitung von "macsat" gefolgt und bei funktioniert es!

MFG
Datafreak

[Schnoerkel]

I set up my router itself as a virtual server (NAT settings, only port 80), but ...

I changed the virtual server setting to port 80, too. Without any effect.



A question: here do you check your external IP adress? I myself cannot reach my website from my LAN using my external IP. It only works from outside. Perhaps you tested this already, but just to be sure...

I tested the external access via another internet-connection. As I said before the internal access (router webinterface & webserver) works fine.



Intern Lan über die interne IP-Adresse des Routers und Port 81, da auf Port 80 dein Webinterface läuft.

Wie in Post13 beschrieben habe ich nun auf Vorschlag von martin72 den Zugangsport für den Webserver auf Port 80 abgeändert (stand ja vorher auf 81). Den Zugangsport des Webinterface (zur Routerkonfiguration) hatte ich damals schon umgestellt (Macht der Gewohnheit von meinem alten Router).



Fall man von außen nicht Zugreifen kann, muss du ggf. den PING zulassen.
Kannst du testen, in dem du dich mal von außen anpingen lässt!

Ich habe tatsächlich die Ping-Anfragen im Webinterface ausgestellt. Abgesetzte Pings werden also nicht beantwortet. Jedoch frage ich mich, was die Verweigerung von jenen ICMP-Paketen mit dem Zugriff auf einen http-Server zu tun haben soll *wunder*.



Ich bin der gleichen Anleitung von "macsat" gefolgt und bei funktioniert es!

... und genau das bringt mich zur Verzweiflung. Das Tutorial von macsat sieht nach meinem Verständnis in sich recht schlüssig aus. Und scheinbar läuft es ja auch bei einigen auf Anhieb. Das meinereiner zu der Minderheit zu zählen scheint, bei der eben dies nicht der Fall ist, beschäftigt mich nun schon seit knapp vier Wochen und so langsam aber sicher habe ich keine Einfälle mehr wo ich noch suchen könnte. In den englischsprachigen Foren existiert dieses Phänomän scheinbar auch, nur verlaufen sich dort die Lösungsvorschläge auch im Sande.

Grüße
Schnoerkel

[SuperB]

Maybe you should take a look in your PREROUTING table.


iptables --list -t nat

I have an external website and use these commands:


[admin@asus sbin]$ cat post-firewall
#!/bin/sh
/usr/sbin/iptables -t nat -D PREROUTING -i "$1" -p tcp --dport 80 -j DROP
/usr/sbin/iptables -t nat -I PREROUTING 1 -p tcp -d "$2" --dport 80 -j DNAT --to "$2":8080
/usr/sbin/iptables -t nat -I PREROUTING 2 -i "$1" -p tcp --dport 8080 -j DROP
/usr/sbin/iptables -t nat -I PREROUTING 3 -i "$1" -p tcp --dport 443 -j DNAT --to "$4":22
/usr/sbin/iptables -I INPUT 1 -i "$1" -d "$2" -p tcp --syn --dport 8080 -j ACCEPT
/usr/sbin/iptables -I INPUT 1 -p tcp --dport 22 -j ACCEPT


The (external) webserver listens on port 8080. Port 443 (external) and 22 (internal) are used for SSH.

Look here (http://wl500g.info/showthread.php?t=5092) for something I wrote on this subject.

[gegy]

So....damit Du nicht alleine bist mit deinem Problem:

Ich habe aus so ein Problem:

Der Webserver ist über meine domain (oder meine statische IP) intern über port 81 erreichbar, aber nicht vom WAN aus. ich habe es koplett gleich gemacht wie im tutorial. Ich finde den fehler leider auch nicht.
Hat da schon wer ne lösung?

Gruß

Gegy