Projekt Wifidog: Unterschied zwischen den Versionen

Aus Opennet
Wechseln zu: Navigation, Suche
(konzeptentwürfe ergänzt)
(aktualisiert)
Zeile 149: Zeile 149:
 
* jeder AP ist ein Wifidog-Node, muss getrennt konfiguriert werden, hoher Verwaltungsaufwand
 
* jeder AP ist ein Wifidog-Node, muss getrennt konfiguriert werden, hoher Verwaltungsaufwand
 
* spezifische Firmware notwendig, Speicherbedarf größer
 
* spezifische Firmware notwendig, Speicherbedarf größer
 +
* kein Roaming zwischen Wifidog-Aps gleicher SSID möglich
 +
* Nutzerverwaltung (aussperren, freigeben) nicht für alle Nodes möglich
  
 
=== Konzeptvorschlag 2 ===
 
=== Konzeptvorschlag 2 ===
Zeile 156: Zeile 158:
 
* DNS-Forward zu AP 192.168.10.3 (inez.on.i.de), Netzmaske 172.17.0.0/24
 
* DNS-Forward zu AP 192.168.10.3 (inez.on.i.de), Netzmaske 172.17.0.0/24
 
* alias-Interface 172.17.0.1, da GW / DNS mit 172.17.0.1 übermittelt werden
 
* alias-Interface 172.17.0.1, da GW / DNS mit 172.17.0.1 übermittelt werden
 +
* Roaming zwischen Wifidog-Aps gleicher SSID
 +
* Nutzerverwaltung (aussperren, freigeben) für alle Nodes möglich
 
==== Vorteile ====
 
==== Vorteile ====
 
* alle APs haben einen Wifidog-Node (inez.on-i.de)
 
* alle APs haben einen Wifidog-Node (inez.on-i.de)

Version vom 1. Mai 2011, 17:28 Uhr

Team
Wifidog logo.png
Projekt Wifidog
Treffen: ??.03.2011
Weiterentwicklung und Integration des offenen WLAN Portals
Mitglieder:
MathiasMahnke
Christianw
Henning
Moh
Christoph
Kontakt:
Crew Mailingliste


Inhaltsverzeichnis

Einleitung

Um einen Gastzugang mit Anmeldung zum Opennet zu realisieren, haben wir nach einer vorhandenen Open Source Lösung gesucht. Wifidog bietet sich als sogenanntes Captive Portal an. Mehr unter http://dev.wifidog.org/

Aufbau

Wifidog besteht aus den Komponenten:

  • Gateway -- hier die Opennet Access Points
  • Portal (Auth-Server) -- ein zentraler Server für die Verwaltung

Installation

OpenWrt AP (Wifidog Gateway)

Zunächst müssen wir das Gateway-Plugin auf unserem AccessPoint installieren. Dazu wählen wir für unsere Firmware das passende Packet, in diesem Fall für WhiteRussianRC6:

ipkg install http://easynews.dl.sourceforge.net/sourceforge/wifidog/wifidog_1.1.3_beta6-1_mipsel_whiterussianRC6.ipk

Jetzt muss noch die Konfiguration angepasst werden:

vi /etc/wifidog.conf

Wir haben testweise gesetzt:

GatewayID oni1
ExternalInterface vlan1
GatewayInterface eth1
GatewayAddress 192.168.1.137
AuthServer {                                                                    
       Hostname        inez.on-i.de
       Path /
}
  • Die GatewayID hilft später bei der Verwaltung mehrerer Knoten auf dem auth server.
  • Als ExternalInterface muss das Interface konfiguriert werden, welches Verbindung zum Internet hat.
  • Das GatewayInterface ist die Schnittstelle über welche sich Clients verbinden können, in unserem Fall über WLAN.
  • Der Hostname gibt den Rechner an, auf dem der auth server läuft. Achtung: hier ist es wichtig keine Leerstelle hinter dem Namen zu haben!
  • Der Path gibt den Pfad zum wifidog auth server home-Verzeichnis an. Achtung: auch hier darf keine Leerstelle hinter dem letzten Zeichen sein!


Die Konfiguration auf dem AccessPoint wäre damit abgeschlossen. Wenn auch der auth server richtig konfiguriert ist, sollte wifidog auf dem AP nun ohne Fehlermeldungen durchstarten:

/etc/init.d/S*wifidog start

Debain/Ubuntu Server (Wifidog Portal)

Das Vorgehen ist sehr gut unter http://dev.wifidog.org/wiki/doc/install/ubuntu/auth-server beschrieben, hier die wichtigsten Schritte zusammengefasst:


Vorbereitungen

Installation Webserver, PHP sowie Datenbank:

sudo apt-get update
sudo apt-get install apache2 php5
sudo apt-get install postgresql
sudo apt-get install php5-cgi
sudo apt-get install php5-mhash php5-pgsql php-pear php5-xmlrpc php5-curl php5-mcrypt
sudo apt-get install language-pack-en-base
sudo apt-get install language-pack-de-base

Installation des Versionsmanagementsystems (wenn noch nicht vorhanden):

sudo apt-get install subversion

Installation einer zusätzlichen PHP-Bibliothek:

sudo pear install XML_RPC
cd /tmp
wget http://downloads.sourceforge.net/project/phlickr/Phlickr/0.2.7/Phlickr-0.2.7.tgz
sudo pear install Phlickr-0.2.7.tgz 
rm Phlickr-0.2.7.tgz

Hinweis: Es ist möglich, dass ein Mirror nicht mehr existiert - dann gegen einen funktionierenden austauschen.


Installation + Konfiguration (Shell)

Installation wifidog-AuthServer und Konfiguration im Webserver:

svn checkout https://dev.wifidog.org/svn/trunk/wifidog-auth
sudo mv wifidog-auth/ /var/www/
sudo nano /etc/apache2/sites-available/default
DocumentRoot /var/www/ -> DocumentRoot /var/www/wifidog-auth/wifidog
sudo /etc/init.d/apache2 restart

Spracheinstellungen:

sudo nano /var/www/wifidog-auth/wifidog/config.php
define('DEFAULT_LANG', 'en_US');

Mailserver installieren:

sudo apt-get install postfix

Datenbank anlegen:

sudo su - postgres
createuser wifidog --pwprompt 
createdb wifidog --encoding=UTF-8 --owner=wifidog

Alle Fragen mit 'n' beantworten.

Das initiale Passwort für die Installation erhält man mittels

cat /tmp/dog_cookie.txt

(benötigt für Installation + Konfiguration (Webinterface))


Installation + Konfiguration (Webinterface)

http://<server>/install.php (Login mit Username leer, Passwort siehe dog_coockie.txt)

Den Instruktionen folgen.

Hinweis: Es sollten alle rot markiertn Komponenten installiert werden, auch wenn die Beschreibung suggeriert dass diese optional sind. Wir hatten Probleme mit phpmailer - hier war der in den Quellen hinterlegte Link nicht mehr aktuell, wir haben manuell angepasst.

Aufräumen (Shell)

Entfernen des Installationsscipts:

cd /var/www/wifidog-auth/wifidog
mv install.php ../install.php


Nun ist der Portal-Server über http://<server>/ erreichbar.

Aktueller Projektstand

Die ursprüngliche Entwicklung von WifiDog ist leider eingeschlafen und seit nunmehr über einem Jahr wurde nichts mehr daran gemacht. Die Pakete sind teilweise noch aus 2007. Daher ist das WifiDogTeam im Moment am Überlegen, ob wir nicht auf ein anderes Captive Portal umsteigen. Angedacht war da z.B. CoovaChili. In den nächsten Wochen wollen wir uns Treffen und über solche Dinge entscheiden. Angestrebt wird eine einfache Lösung, die auch in unserer neuen Firmware integriert ist. Hier wäre es schön, wenn sich das Team Firmware darum kümmern könnte. Wir würden dann demnächst unsere gewünschten Anforderungen mitteilen. Wir möchten unseren ersten Portalknoten testweise am Doberaner Platz installieren. Bewährt er sich dort wäre es auch denkbar eine Pressemitteilung zu schalten, dass am Dobi unser Knoten für die Allgemeinheit nutzbar ist. Eventuell ließen sich so auch neue Interessenten für das Projekt oder Opennet im Allgemeinen gewinnen. Eventuell können wir das ja mit dem PR-Team koordinieren. :)


Firmware Implementierung und Netzwerk-Integration

Konzeptvorschlag 1

Wifidog 1.png

(aktuell in Firmware 3.0-2 NG implementiert)

  • Wifidog-Gateway läuft auf dem AccessPoint
  • DNS-Forward zu AP 192.168.10.3 (inez.on.i.de), Netzmaske 172.17.0.0/24
  • alias-Interface 172.17.0.1, da GW / DNS mit 172.17.0.1 übermittelt werden
  • normaler Tunnelaufbau

Vorteile

  • jeder AP ist ein Wifidog-Node, kann getrennt konfiguriert werden
  • gleichzeitiger Betrieb als normaler User-AP möglich
  • Zugang für Wifidog-Nutzer direkt über Gateway-VPN-tunnel

Nachteile

  • jeder AP ist ein Wifidog-Node, muss getrennt konfiguriert werden, hoher Verwaltungsaufwand
  • spezifische Firmware notwendig, Speicherbedarf größer
  • kein Roaming zwischen Wifidog-Aps gleicher SSID möglich
  • Nutzerverwaltung (aussperren, freigeben) nicht für alle Nodes möglich

Konzeptvorschlag 2

Wifidog 2.png
  • Wifidog-Gateway läuft auf inez.on-i.de, nur durch tunnel erreichbar
  • Weiterleitung von Tunnel auf Gateway anhand des CommenName (X.Y.wifidog.on) zu inez.on-i.de
  • DNS-Forward zu AP 192.168.10.3 (inez.on.i.de), Netzmaske 172.17.0.0/24
  • alias-Interface 172.17.0.1, da GW / DNS mit 172.17.0.1 übermittelt werden
  • Roaming zwischen Wifidog-Aps gleicher SSID
  • Nutzerverwaltung (aussperren, freigeben) für alle Nodes möglich

Vorteile

  • alle APs haben einen Wifidog-Node (inez.on-i.de)
  • keine extra Software (ausser DHCP-forwarder) auf AP nötig, geringer Speicherbedarf
  • kann auf APs mit alter Firmware problemlos nachgerüstet werden

Nachteile

  • es gibt nur einen Wifidog-Node, keine getrennte Konfiguration möglich (oder schwieriger)

Anmerkung: Wenn auf den Gateways mehrfache logins mit gleichem Zertifikat erlaubt werden, dann lassen sich unterschiedliche Nodes auf Basis unterschiedlicher Zertifikate verwalten. Alternativ könnten Zertifikatgruppen erstellt werden, dass macht aber alles etwas komplexer

Meine Werkzeuge
Namensräume

Varianten
Aktionen
Start
Opennet
Kommunikation
Karten
Werkzeuge