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