[Problem] Alle Anfragen über offenes WLAN auf internen Webserver umleiten

gisbert

Neuer User
Mitglied seit
5 Feb 2008
Beiträge
24
Punkte für Reaktionen
0
Punkte
1
Hallo,

ich will aus einer 7270 ein "Infoterminal" mit einer statischen Webseite ohne Internetzugang machen:
- Offenes WLAN
- Kein Internet
- Webserver mit einfacher statischer HTML-Seite

Erfahrungen mit Freetz habe ich, aber mir ist nicht klar, wie ich sämtliche Anfragen umgeleitet bekomme. Muss ich dazu einen eigenen DNS-Server betreiben, der stets auf meine interne Webseite auflöst? Oder werden mit iptables sämtliche Anfragen umgeleitet? Oder kann privoxy helfen, um stets mit meiner internen HTML-Seite zu "antworten"?

Ich gebe zu, um das Routing-Thema immer einen Bogen gemacht zu haben und hoffe, mit eurer Hilfe eine Abkürzung zu nehmen. :)

Danke,
GS
 
Zuletzt bearbeitet:
Du kannst das mittlerweile vergessen, wenn es für öffentlich gedacht ist, es ist vieles im Web verschlüsselt und da kannst du nicht eingreifen
 
Die Frage ist wie durchdacht das sein soll.

Ein DNS Server, der für alle Anfragen die lokale IP ausgibt ist einfach zu realisieren und genauso einfach zu umgehen.

Ein transparenter Proxy ist deutlich komplexer aber nicht so leicht auszuhebeln.

Ersteres dürfte ausreichen wenn keine Internetverbindung besteht. Beim Aufruf von HTTPS Seiten bekommt der Client aber einen Hinweis wg des Zertifikats.
 
Du kannst das mittlerweile vergessen, wenn es für öffentlich gedacht ist, es ist vieles im Web verschlüsselt und da kannst du nicht eingreifen

"Kein Internet"

Mit iptables wäre das leicht umzusetzen, aber i h weiß nicht ob das bei den Boxen vorhanden ist.
 
Auch ohne Internet gehen die meisten Browser auf HTTPS Google und dann gibt es mindestens eine Zertifikats-Warnung
 
Nicht wenn du keine Zertifikate verwendest.
Per iptables alles von Port 443 nach Port 80 oder da hin wo dein HTTP-Server steht. Der muss ja nicht zwingend SSL machen.
 
Per iptables alles von Port 443 nach Port 80 oder da hin wo dein HTTP-Server steht. Der muss ja nicht zwingend SSL machen.
Das wäre allerdings ein toller Trick, wenn sich ein Browser so einfach per iptables von (s)einem Vorhaben abbringen ließe, eine verschlüsselte Verbindung aufzubauen. Das wäre dann schon ein eklatanter Fehler des Browser ...
 
Ja, wird so sein. Hab nur kurz getestet auf https://heise.de wo man auf http:// landet und gedacht das wäre überall so.

Ansonsten, ja mei gibt es halt eine Zertifikatswarnung.
 
Nur auf die Gefahr hin, falsch verstanden worden zu sein:

Ich will genau den gleichen Effekt erreichen, wie man ihn von T-Online Hotspots kennt. Verbindung per WLAN und egal welche Adresse eingegeben wird, man landet auf der T-Online Seite zur Authentifizierung. Der Webserver soll ja auch auf der Fritzbox liegen, da es sich in diesem Fall nur um eine Infoseite mit statischen Inhalten handelt.

Wenn der Client jetzt nach https:irgendwas.de fragt, dann sollte der lokale DNS "irgendwas.de" als 127.0.0.1 übersetzen, das (s) von http: ignorieren und die statische HTML-Seite via lokalen Webserver anzeigen.

Zu naiv gedacht?
 
und noch eine Ergänzung: Es muss überhaupt nicht durchdacht/sicher sein, denn die Fritzbox wird gar nicht am Internet angeschlossen sein. Die soll nur während einer Veranstaltung diese eine Seite ausliefern, ein Surfen der Gäste ist genau nicht gewünscht :)
 
und noch eine Ergänzung: Es muss überhaupt nicht durchdacht/sicher sein, denn die Fritzbox wird gar nicht am Internet angeschlossen sein. Die soll nur während einer Veranstaltung diese eine Seite ausliefern, ein Surfen der Gäste ist genau nicht gewünscht
Einfach alle Zugriffe auf HTML-Seiten in der Box für das Gastprofil sperren (leere Whitelist), das offene WLAN als Gastnetz benutzen und die Sperrseite (irgendwas unter /usr/www/$OEM/html/errors, wenn ich mich richtig erinnere) entsprechend abändern, damit dort entweder der Inhalt direkt ausgeliefert wird oder zumindest ein "redirect" auf eine andere (lokale) URL (die sollte nicht durch die Whitelist müssen) ... denn wenn da weitere HTML-Links im gewünschten Inhalt vorhanden sind (auch für imgs usw.), dann könnten die sich an der Umleitung auf fritz.box:8181 (oder so ähnlich, auch das muß man noch einmal prüfen, das ist nur aus der Erinnerung) stören, wenn es um das Nachladen geht.

EDIT: Über einen DNS-Server ist da praktisch wenig bis nichts zu machen, denn der entscheidet nicht darüber, ob da HTTP oder HTTPS zum Einsatz kommt und auf welchem Port ... der löst nur den Domainnamen in eine Adresse auf (und die darf natürlich nicht 127.0.0.1 sein, denn das ist nicht die Box, sondern der Client selbst).
 
Moins

Whitelist ist nur notwendig, wenn die Geräte noch Internetzeit haben. ;)
...oder nicht gesperrt sind.

Gastprofil
Im Gastnetz kann kaum auf einen lokalen Server weitergeleitet werden, außer die Kommunikation der WLAN Klienten untereinander ist erlaubt und der Server befindet sich auch im Gastnetz.
Ansonsten muss die Sperrseite alles was gebraucht wird liefern können/müssen.

Die Sperrseitenmanipulation halte ich auch für am Praktikabelsten.
1. "http://fritz.box:8181/"
2. "http://fritz.box:8182/"
Code:
ls /usr/www/$OEM/errors/
ERR_NOT_FOUND* kids/
ls /usr/www/$OEM/errors/kids
ERR_NOT_ALLOWED* ERR_NOT_FOUND* [COLOR=#ff0000][B]### Das sind die für Port 8181 und 8182[/B][/COLOR]
Nach Manipulation muss der AVM Webserver neugestartet werden.
...damit die Änderungen wirksam werden.
Code:
ctlmgr-s;sleep 2;ctlmgr
 
Zuletzt bearbeitet:
Danke für die Vorschläge, alles erfolgreich umgesetzt und siehe da: Wenn die 7170 nicht via DSL verbunden ist, dann ist die Kindersicherung nicht verfügbar...
 
Wenn die 7170 nicht via DSL verbunden ist, dann ist die Kindersicherung nicht verfügbar...
Ok, jetzt wird es aber obskur ... am Beginn war es noch eine (allerdings nicht näher spezifizierte) 7270. Die KiSi der 7170 würde noch ziemlich anders funktionieren (04.8x vs. 05.5x bzw. sogar 06.ß5 bei v2/v3).

Auch werde ich nicht so richtig schlau, ob das nun heißt, daß es erfolgreich umgesetzt wurde oder ob der zweite Teil des Satzes dann doch aussagen soll, daß es ein Schuß in den Ofen war.

Wenn das letztere der Fall ist, stellt sich natürlich die Frage, warum Du überhaupt auf "ohne DSL" konfiguriert hast und was das am Ende für die Frage "to route or not to route" heißt, was Du da ansonsten noch an Konfigurationseinstellungen gewählt hast. Daß bei einer Box im IP-Client-Modus die KiSi nicht funktionieren kann, wäre ja nun nicht wirklich überraschend.
 
Sorry, ich war da zu ungenau:

Als Hardware liegen vor: Speedport W701V und W920V, also Derivate der 7170 und 7570.

Ich habe im Freetz-Image für die 7170 die ERR_NOT_FOUND Datei angepasst und dann bei der Inbetriebnahme festgestellt, dass ich die Kindersicherung ohne aktives DSL nicht in Betrieb nehmen kann. Der Menüpunkt erscheint schlichtweg nicht.

Auf der 7570 ist es das gleiche Spiel - dort kommt die Kindersicherung ohne DSL-Zugang auch nicht zum Einsatz. Natürlich kann ich überall den DSL-Zugang einstellen, aber das ändert nichts an der Situation. Ich habe auch versucht, in der Box via Client-Modus in meinem Netz die Zeit zu aktualisieren, aber das hat nicht funktioniert.

Kann ich denn die Kindersicherungsfunktion unabhängig des Internetzugangs erzwingen?

Nochmal zur Erinnerung: Die Box soll später keinen Internetzugang haben. Es soll nur eine einzige Seite angezeigt werden.
 
Da das beides nur Geräte mit Firmware-Versionen < 05.xx sind (das wäre bei der 7270 aus #1 eben anders gewesen), bin ich mir nicht sicher, wie die KiSi dort arbeitet.

Allerdings sollte es möglich sein, die 7170 auf "Router-Modus" umzustellen; als IP-Client gibt es eben nur ein einziges Netz und die Box arbeitet nicht als Gateway in ein anderes (das WAN, was sich i.d.R. hinter "dev dsl" im FRITZ!OS verbirgt, unabhängig von der Zugangstechnologie, die tatsächlich verwendet wird).

Nur wenn die Box als Gateway arbeitet, werden alle Pakete von ihr geroutet und auch nur dann leitet sie blockierte HTTP-Anfragen per Redirect auf die Sperrseite um.

Im Router-Modus (egal ob DSL oder LAN1) sollte die KiSi also funktionieren (soweit man das für 04.xx noch sagen kann) und ob da am Ende eine DSL-Verbindung besteht oder nicht, sollte der Box für die Auslieferung der Sperrseite auch fast egal sein - Hauptsache sie ist entsprechend konfiguriert, wobei eben LAN1-Modus (aber eben "Verbindung selbst aufbauen") auch funktionieren sollte.
 
Hier die Lösung:

Freetz mit iptables, dnsmasq und lighttpd erstellen.

lighttpd mit index.html versorgen, sollte unter 192.168.178.1:8008 erreichbar sein.

Per Telnet auf der Box folgendes eingeben:

echo "1" > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A PREROUTING -s 192.168.1.0/24 -p tcp --dport 80 -j DNAT --to-destination 192.168.178.1:8008
iptables -t nat -A POSTROUTING -j MASQUERADE

In der Freetz Webgui unter dnsmasq/extra folgenden Befehl eingeben:

address=/#/192.168.178.1


Jetzt werden alle IP-Adressen auf 192.168.178.1 umgeleitet, ebenso alle Adressen als 192.168.178.1 aufgelöst.

Danach noch die Weboberflächen deaktivieren und fertig ist das Infoterminal :)

Wie setze ich das jetzt auf [gelöst]? Schon wieder so eine Herausforderung :)
 
Der Thread-Titel kann über Editieren des ersten Beitrags geändert werden.

Nur noch der Hinweis für spätere Leser, daß diese Lösung recht spezifisch für Firmware-Versionen "vor AVM-PA" ist (also bis 04.irgendwas, danach ist iptables nur noch unter bestimmten Rahmenbedingungen wirksam, wobei die Chancen bei SYN-Paketen nicht so schlecht sind) und es sich - anders als es in #1 immer noch steht - um eine 7170 handelt (oder auch um eine 7570 bzw. die Telekom-Pendants, was aber an der höchsten verfügbaren Firmware-Version m.W. nichts ändert - Version 05.xx gab es wohl nur noch ab 7270 aufwärts).
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.