Howto`s

Einrichtung der Toolchain und compilieren des Source-Tree unter Debian basierten Linux-Systemen ([K]Ubuntu, Kanotix, Sidux etc.).

benötigte Pakete:

Vorbereiten der Toolchain:

Um den aktuellen Stand des BS-Source-Tree herzustellen, den entsprechenden Patch downloaden folgendermaßen anwenden:

Sollte alles geklappt haben, liegt das fertige Image unter dev_tree/images.

Howto für das Einbinden eigener Konfigurationen und Skripte in das Bitswitcher-Image.

Das Image enthält im Verzeichnis /etc/start_scripts das Skript custom.sh. Dieses wird nach dem Starten als letztes aufgerufen und prüft im NVRAM den Parameter custom_start. Ist dieser =1 gesetzt, wird das im NVRAM hinterlegte custom_script nach /var geschrieben und ausgeführt. Der default-Wert für custom_start ist =0, weshalb also nach dem Aufspielen des BS-Image kein custom_script ausgeführt wird.

Zunächst mit telnet oder ssh auf den Router und dann folgende Befehle ausführen:

Beim nächsten Neustart wird das Skript aus dem NVRAM nach /var/custom_script.sh geschrieben und ausgeführt. Sollten weitere Änderungen notwendig sein, dann einfach das aktuelle /var/custom_script.sh editieren und anschließend wieder im NVRAM sichern.

Das obige Bild zeigt eine Beispielkonfiguration, in welcher der Router als Wireless-Bridge fungiert. Im Beispiel ist bereits ein WLAN konfiguriert, welches durch den DSL-Router verwaltet wird. Das Ziel ist es nun, den vorhandenen Kabel-/Sat-Receiver, welcher nur über eine Ethernet-Schnittstelle verfügt, in das WLAN einzubinden um auf diesen per WLAN zugreifen zu können oder dem Receiver den Internetzugriff zu ermöglichen.

Die Konfiguration erfolgt in folgenden Teilschritten:

Zunächst mit telnet oder ssh auf den Router und dann in die Datei /var/custom_script.sh folgende Zeilen einfügen:

Der Block Verschluesselung muss je nach gewünschter Verschlüsselungsvariante angepasst werden. Im Falle von WEP-64 sind als Schlüssel ($WEP_KEY) 5 Ascii-Zeichen bzw. 10 Hexadezimalwerte ohne Trennzeichen anzugeben. Bei WEP-128 entsprechend 13 Ascii-Zeichen oder 26 Hexadezimalwerte. Im obigen Beispiel ist ein WEP-128 Schlüssel dezimal angegeben.

Die ebtables-Befehle müssen zwingend mit ausgeführt werden, da sonst die bei WPA gesendeten EAPOL-Pakete nicht vom nas-Programm behandelt werden können. Dies hat zur Folge das sich der Router nicht am gewünschten Access-Point anmelden kann.

Die Regeln sorgen dafür, dass nur ARP- und IPv4-Pakete (also normaler Traffic) gebridged werden. Die Anweisung ebtables -t broute -A BROUTING -p 0x888e -j DROP, welche die obigen Regeln ersetzen könnte, funktioniert leider aus unerfindlichen Gründen nicht.

Informationen zu nas sind hier zu finden.

Im BS-Image wird nicht der udhcpd als DHCP-Server verwendet. Stattdessen wird dnsmasq genutzt, der ein sehr flexibel und leicht zu konfigurierender DHCP- und zugleich auch ein DNS-Server ist.

Für den normalen Gebrauch ist der DHCP- und DNS-Server mit der Konfiguration über das Web-Interface völlig ausreichend. Aber wenn sehr spezielle oder exotische Optionen benötigt werden, kann die Konfiguration an die jeweiligen Bedürfnisse angepasst werden.

Die Konfigurationsdateien sind /var/dhcp.dnsmasq für DHCP und /var/dns.dnsmasq für DNS. Die Optionen können einfach in den Dateien angefügt werden:

Danach muss der dnsmasq nur noch neu gestartet werden:

Die Konfiguration für den DNS-Server ist äquivalent.

Diese manuelle Konfiguration bleibt natürlich nur solange bestehen, bis der Router neu gestartet oder durch eine Konfiguration per Web-Interface überschreiben wird.

Um die Änderungen persistent, über einen Reboot hinweg, zu sichern, müssen diese im NVRAM gespeichert werden. Diese sind am besten im custom_script aufgehoben.

Mit der Version 0.1.1 wurde die individuelle DHCP- und DNS-Konfiguration vereinfacht und verbessert. Für zusätzliche DHCP- und DNS-Optionen sind die NVRAM-Variablen dhcp_custom für DHCP und dns_custom für DNS vorgesehen, um sie persistent zu speichern. Diese werden nun beim Erstellen der Konfiguationsdateien für dnsmasq berücksichtig.

Beispiel:

Ebenso einfach können DNS-Optionen gesetzt werden. Es ist dann jeweils nur dns_custom statt dhcp_custom und dns_custom_start statt dhcp_custom_start zu verwenden!

Einige DHCP-Optionen die evtl. gesetzt werden müssen.

dnsmasq Homepage

RFC 2132, DHCP Options and BOOTP Vendor Extensions

Möchte man ein PPPoE-Verbindung nicht nur über das WAN-Interface (DSL) sondern auch über Ethernet oder WLAN etablieren, kann man wie folgt vorgehen:

Hat sich das ADSL-Modem noch nicht synchronisiert oder besteht keine DSL-Verbindung, wartet der pppd bis eine DSL-Verbindung aufgebaut ist. Dabei ist es egal welches Interface, in diesem Beispiel die Ethernet-Schnittstelle, der pppd verwenden soll.

Mit dem folgenden Befehl kann dem pppd eine DSL-Verbindung vorgetäuscht werden:

Wenn der pppd daraufhin seine Arbeit nicht aufnimmt, muss der echo-Befehl wiederholt werden, bis er beginnt eine PPP-Session zu starten:

Hier einige Parameter für den pppd

WPAD ist ein Protokoll mit dem Web-Browser eigenständig ermitteln welche Web-Proxys für unterschiedliche Ziele zu verwenden sind. Dies benötigt man vorallem wenn mehrere Proxys für verschiedene Ziele gleichzeitig benutzt werden müssen. Denn üblicherweise ist es nur möglich einen einzigen Proxy in der Web-Browser Konfiguration anzugeben. Aber auch wenn nur ein Proxy genutzt werden muss, kann WPAD nützlich sein. Nämlich dann, wenn man sich zum Beispiel mit einem Laptop öfter in verschieden Netzen befindet.

Die Proxy-Autokonfiguration wird üblicherweise in der Datei wpad.dat gespeichert. Diese könnte beispielsweise so aussehen:

Mit dieser wpad.dat werden die privaten 192-er Netze direkt erreicht, für Web-Server im 10-er Netz ist der interne Proxy zu nutzen und für die restlichen ist der externe Proxy zu verwenden.

Die wpad.dat kann mit folgendem Befehl im NVRAM persistent gespeichert werden:

Die Datei wpad.dat wird von den Web-Browsern vom WPAD-Server per HTTP-Protokoll heruntergeladen (http://wpad/wpad.dat). Die Datei wpad.dat muss nun in das Web-Verzeichnis des Web-Servers geladen werden. Dazu muss zuerst ein beschreibbarer Bereich im ansonsten schreibgeschützten Web-Root geschaffen werden, anschließend kann die wpad.dat dort abgelegt werden:

Der beschreibbare Bereich wird mit 5 kByte Speicher dimensioniert. Dies sollte für die wpad.dat ausreichen, kann aber je nach Bedarf angepasst werden.

Jetzt kann die wpad.dat bereits vom Web-Server des Routers heruntergeladen werden (http://Adresse-des-Router/wpad.dat).

Web-Browser finden die wpad.dat auf zwei Arten, entweder per DHCP oder per DNS. Bei der DNS-Variante löst der Web-Browser den Hostnamen wpad auf und versucht anschließend die Datei wpad.dat von http://wpad/wpad.dat zu beziehen. Deshalb muss der Hostname wpad beim DNS-Server registriert werden. Am einfachsten ist dies über das Web-Frontend unter BS-Extras→Network settings→DNS im Bereich Known Hosts.

Dort ist die IP-Adresse des Routers, in der Standardkonfiguration 192.168.2.1, und als Name wpad einzugeben.

Jetzt sollte die wpad.dat unter http://wpad/wpad.dat zur Verfügung stehen und Browser wie Firefox die die DNS-Konfiguration nutzen sollten jetzt funktionieren.

Für WPAD ist nur eine DHCP-Option nötig. Wenn der Hostname wpad beim DNS-Server registriert ist, sieht die Option wie folgt aus:

Diese Option sollte wie im Abschnitt Individuelle DHCP- und DNS-Optionen beschrieben dem DHCP-Server übergeben werden.

Die Routerkonfiguration wird im NVRAM als XML-Datei gespeichert. An diese Datei kommt man im Normalfall nur heran, wenn sie per Web-Interface (Laden & Sichern→Konfiguration sichern) heruntergeladen wird. Allerdings ist die Konfiguration Verschlüsselt und es ist nur mit relativ hohem Aufwand, wenn überhaupt, möglich die Konfiguration zu ändern.

Das BS-Image schafft hier Abhilfe und bietet eine einfache Möglichkeit die Konfiguration zu editieren.

Nachdem der Login per Telnet oder SSH erfolgt ist, kann die Routerkonfiguration folgendermaßen aus dem NVRAM ausgelesen werden:

Mit diesem Befehl wird die Routerkonfiguration in die Datei /var/config.xml geschrieben. Anschließend kann die XML-Datei mit dem Editor vi bearbeitet werden:

Wurden alle Änderungen vorgenommen und gespeichert, kann die Konfiguration wieder in den NVRAM geschrieben werden:

Das war es auch schon! Nach dem Neustart werden alle Änderungen aktiv.

Bei manchen Providern tritt das Problem auf, das die voreingestellten ATM-Parameter (Virtual Path Identifier (VPI), Virtual Channel Identifer (VCI)) nicht funktionieren. Die Standard-Settings hierfür sind VPI/VCI gleich 1/32. Dieses Problem ist z.B. bei NetCologne-, Alice- und bei älteren Arcor-Anschlüssen sowie in Österreich aufgetreten. Dieses Howto zeigt, wie ATM-Parameter geändert werden können.

Zur Demonstartion werden in diesem Beispiel die VPI/VCI-Parameter von 1/32 auf 8/35 geändert. Um dies zu tun, muss die Routerkonfiguration, wie im Abschnitt "Router-Konfiguration manuell anpassen" beschrieben, verändert werden.

Zuerst muss die Konfiguration aus dem NVRAM geladen werden, danach kann sie bearbeitet werden. Dazu wird hier der Editor vi verwendet.

Im folgenden Listing sind die relevanten Teile der Konfiguration zu sehen:

Die rot eingefärbten Textstellen müssen an die neuen Parameter angepasst werden, es reicht nicht nur die Attribute vpi und vci zu Ändern:

Nachdem die Änderungen an der Konfiguration vorgenommen und gespeichert wurden, kann diese in den NVRAM geschrieben werden:

Nach dem Ausschalten und Neustarten des Routers werden die Änderungen wirksam.

Für den Betrieb hinter einem Kabelmodem ist dieser Routertyp eigentlich nicht so gut geeignet, aber es sollte mit einigen Einschränkungen trotzdem funktionieren. Zunächst ist zu beachten, dass der DSL-Port in diesem Szenario keine Anwendung findet, da mit diesem keine Verwendung als normaler Ethernet-Port möglich ist (zumindest soweit wir wissen). Aus diesem Grunde, verwende ich für dieses Howto den normalen LAN-Port für die Verbindung mit dem Kabelmodem und alle anderen PCs im LAN sollten über WLAN dann auf das Internet zugreifen.

Da die Konfiguration sehr individuell ist, nehme ich alle Einstellungen manuell über das custom_script vor. Also folgende Teilschritte durchführen:

Zunächst mit telnet oder ssh auf den Router und dann in die Datei /var/custom_script.sh folgende Zeilen einfügen:

Ab Version 0.3 kann der Router über das Web-Interface konfiguriert werden, so dass er hinter einem Kabelmodem betrieben werden kann.

Das LAN-Interface ist beim Betrieb hinter dem Kabelmodem gleichzeitig WAN-Interface. Dies wird in Firewall→General Settings beim Punkt WAN interface mit LAN/BRIDGE eingestellt.

In der LAN-Konfiguration LAN muss die Option Get settings via DHCP aktiviert werden. Danach ist der Router bereit für den Einsatzt hinter einem Kabelmodem.

Für bestimmte Nutzer kann es sinnvoll sein, eine zeitgesteuerte Trennung der Online-Verbindung durchzuführen. Da die meisten Provider selbst in bestimmten Abständen die Verbindung trennen, kann dies zum kurzzeitigen Ausfall der Verbindung im normalen Tagesbetrieb führen. Aus diesem Grunde folgendes Howto um mittels Cron-Job die Trennung zum gewünschten Zeitpunkt regelmässig durchzuführen.

Die Konfiguration erfolgt in folgenden Teilschritten:

Zunächst mit telnet oder ssh auf den Router und dann in die Datei /var/custom_script.sh folgende Zeilen einfügen:

Ab BS Version 0.2.1 kann der Router auch per Telefon gesteuert und konfiguriert werden. Es sind einige Standardfunktionen vorgeben (siehe Doku), aber es ist natürlich auch möglich individuelle Funktionen/Aktionen via Telefon zu starten.

Das Programm vodsl_monitor überwacht das Telefon und startet bei jedem Ereignis das eintritt ein Skript (/usr/bin/call_mon_event.sh), das die Ereignisse auswertet und ggf. eine der vorgegebenen Standardfunktionen ausführt. Ist für ein Ereignis keine Standardfunktion vorgegeben wird stattdessen ein Custom-Skript gestartet falls ein solches vorhanden ist.

Es können drei Ereignisse auftreten:

Das Ereignis CALL ist auszuwerten, wenn Aktionen via Telefoncodes gestartet werden sollen.

Das Event-Skript als auch das Custom-Skript erhalten neben dem Ereignis noch zusätzliche Informationen über das Ereignis bzw. den Ruf. Folgende Parameter werden den Skripten übergeben:

Diese Parameter werden dem Event- sowie dem Custom-Skript als Umgebungsvariable als auch als Übergabeparameter, in der hier angegebenen Reihenfolge, zugänglich gemacht.

Für individuelle Funktionen ist nur ein NVRAM Parameter notwendig - das Custom-Skript selbst, welches im NVRAM unter custom_call_event abgelegt sein muss.

Das folgende Listing zeigt das Standard-Event-Skript (/usr/bin/call_mon_event.sh), es kann als Vorlage für eigene Skripte dienen:

#!/bin/sh

[ "$#" -lt "5" ] && exit 1

export PATH=/bin:/etc/start_scripts:$PATH
CUSTOM="/var/custom_call_event.sh"

load_custom_script ()
{
 if [ ! -e $CUSTOM ]
 then
   RET=`nvram getfile custom_call_event=$CUSTOM`
   [ "$RET" == "Failed" ] && exit 0
 fi
 chmod +x $CUSTOM
 #$CUSTOM $@
 /bin/sh $CUSTOM $@
}

echo "Call event..."
ledtool 1 3

if [ "$EVENT" == "CALL" ]
then
 case "$CALLER" in
  "77*0*")
        echo "SSH start"
        start=`nvram get ssh_start`
        [ "$start" != "1" ] || nvram set ssh_start=1 >/dev/null 2>/dev/null
        ssh.sh restart
        ;;
  "77*1*")
        echo "SSH stop"
        ssh.sh stop
        ;;
  "77*2*"*)
        echo "set IP to br0"
        IP=`echo "$CALLER"|sed -e 's/^77\*2\*//'|sed -e 's/[*]/./g'`
        IP=`/webs/cgi-bin/isip.sh $IP`
        echo $IP
        [ "$IP" != "ERROR" ] && ifconfig br0 $IP up
        ;;
  "77*3*12345")
        echo "flush firewall"
        iptables -F
        iptables -P INPUT ACCEPT
        iptables -P OUTPUT ACCEPT
        iptables -P FORWARD ACCEPT
        #iptables -t nat -F
        #iptables -t mangle -F
        ;;
  "77*4*12345")
        echo "flush ebtables"
        ebtables -F
        ebtables -P INPUT ACCEPT
        ebtables -P OUTPUT ACCEPT
        ebtables -P FORWARD ACCEPT
        ebtables -t nat -F
        #ebtables -t broute -F
        ;;
  "77*5*")
        echo "flash LEDs"
        ledtool X 7
        ledtool X 10
        sleep 1
        ledtool 0 1
        ;;
  "96*0*")
        echo "WLAN start"
        wlctl up
        ;;
  "96*1*")
        echo "WLAN stop"
        wlctl down
        ;;
  "96*4*")
        echo "Call monitor server start"
        nvram set call_mon_start=1
        call_mon.sh restart
        ;;
  "96*5*")
        echo "Call monitor server stop"
        nvram set call_mon_start=0
        call_mon.sh restart
        ;;
  "96*7*")
        echo "telnet start"
        start=`nvram get telnet_start`
        [ "$start" != "1" ] && nvram set telnet_start=1 >/dev/null 2>/dev/null
        telnet.sh restart
        ;;
  "96*8*")
        echo "telnet stop"
        telnet.sh stop
        ;;
  "990*15901590*")
        echo "reboot"
        nvram reboot
        ;;
  "991*15901590*")
        echo "nvram reset and reboot"
        nvram reset
        nvram reboot
        ;;
  *)
     load_custom_script $@
     ;;
 esac

 exit 0
fi

if [ "$EVENT" == "RING" ]
then
 case "$CALLER" in
   *)
      load_custom_script $@
      ;;
 esac
 exit 0
fi

if [ "$EVENT" == "DISCONNECT" ]
then
 case "$CALLER" in
   *)
      load_custom_script $@
      ;;
 esac
 exit 0
fi

Zur Demonstration soll ein einfaches Custom-Skript dienen, das nur zwei Aktionen auslöst. Zum Einen wird nach der Eingabe des Tastencodes \#55*0*\# der Rechner mit der MAC-Adresse "00:00:FB:25:DA:4C" per Wake-On-LAN aufgeweckt. Zum Anderen wird bei einem eingehenden Ruf von "0162123456" eine Firewallregel gesetzt oder gelöscht, die den Zugriff auf den Web-Server des Rechners mit der privaten IP-Adresse "192.168.1.1" ermöglicht.

Zunächst mit telnet oder ssh auf den Router und dann in die Datei /var/custom_call_script.sh folgende Zeilen einfügen:

Anschließend kann das Skript im NVRAM abgelegt und persistent gespeichert werden:

Portknocking ist eine Technik mit der man einem Host, der mit einer Firewall geschützt ist und dadurch eigentlich keine Information erhalten kann, Signale geben kann. Dazu werden in der Regel TCP- und/oder UDP-Datagramme an den Host gesendet. Mit diesen wird gewissermaßen "angeklopft". Aber auch diese Datagramme werden von der Firewall verworfen. Nur wenn in einer festgelegten Zeitspanne eine bestimmte Sequenz von Datagrammen empfangen wird, löst dies eine Reaktion aus. Die Sequenz besteht aus mehreren Datagrammen die an unterschiedliche Ports gesendet werden, im Fall von TCP können auch noch die TCP-Flags variiert werden.

Mit Hilfe des Portknocking können so z.B. Ports in der Firewall geöffnet oder Programme gestartet werden. Der Fantasie sind da keine Grenzen gesetzt.

Ab BS Version 0.3 ist für das Portknocking das Programm tportknockd im Image integriert. Die folgenden Abschnitte beschreiben wie der tportknockd konfiguriert und betrieben wird.

Die Konfiguration der knock-Sequenzen wird in einer Konfigurationsdatei festgehalten. Die Konfiguration kann mehrere knock-Sequenzen enthalten, die unterschiedliche Aktionen auslösen.

Für jedes Ereignis gibt es einen eigenen Konfigurationsblock. Dieser wird mit <EVENT_NAME> eingeleitet und mit </EVENT_NAME> abgeschlossen. Jedes Ereignis erhält einen eindeutigen Namen.

Für jedes Ereignis muss die knock-Sequenz, eine Zeitspanne (timeout) in der die Sequenz beendet werden muss und ein Kommando (start_command) enthalten, das ausgeführt wird, nachdem das knock-Ereignis ausgelöst wurde. Optional kann noch ein zweites Kommando (stop_command) angegeben werden, das nach einer angegeben Verzögerung (command_delay) ausgeführt wird.

Die knock-Sequenz besteht aus einer mit Leerzeichen separierten Liste mit Frames, mit der die Sequenz beschrieben wird. Für jedes Frame der Sequenz muss das verwendet Protokoll (TCP oder UDP) und der Port angegeben werden. Für TCP können auch Flags bzw. Flag-Kombinationen angegeben werden. Protokoll, Port und Flags werden mit einem Doppelpunkt (:) voneinander getrennt.

Für die TCP-Flags sind folgende Angaben möglich:

diese können auch kombiniert werden. Werden keine Flags angegeben, wird (n - None) impliziert.

Ist im start_command oder stop_command ein "%IP%" enthalten, wird dies durch die IP-Adresse des Hosts ersetzt, der das knock-Ereignis ausgelöst hat.

Aus Gründen der Performance sollten alle knock-Sequenzen mit Ports und Flag Kombinationen beginnen, die nicht durch die "normale" Kommuniaktion aufgelöst werden.

Das folgende knock-Ereignis wird ausgelöst, wenn die Sequenz aus UDP- und TCP-Frames innerhalb von 10 Sekunden durchlaufen wird. Danach können TCP-Frames die an den Port 22 (typischerweise SSH) gerichtet sind, vom Host der das knock-Ereignis auslöste, die Firewall passieren. Die Firewall wird nach 30 Sekunden wieder geschlossen. Bei einer statefull Firewall bleiben aber Verbindung, die zuvor etabliert wurden, bestehen.

Das folgende Beispiel zeigt, dass nach dem knock-Ereignis der OpenVPN Client gestartet wird und zum OpenVPN Server mit der IP %IP% (also dem Host der das knock-Ereignis auslöste) eine Verbindung aufbaut.

Ist der Datenverkehr zum Beispiel durch eine (Firmen-)Firewall auf wenige Ports beschränkt, kann das "anklopfen" auch mit verschiedenen TCP-Flag Kombinationen realisiert werden.

Die Parameter die dem tportknockd übergeben werden können und müssen, sind in der Folgenden Tabelle aufgelistet:

Ist die Konfigurationsdatei mit den knock-Sequenzen "/opt/knock.conf" und soll das PPP-Device überwacht werden, kann der tportknockd mit folgendem Aufruf, beispielsweise mit dem Custom script, gestartet werden:

Wenn das Device das der tportknockd überwachen soll (noch) nicht verfügbar ist, beendet sich der tportknockd mit einer entsprechenden Fehlermeldung. Beispielsweise kann dies passieren, wenn der tportknockd das PPP-Device überwachen soll und direkt nach dem Booten gestartet wird, aber die PPP-Verbindung noch nicht etabliert wurde.

Um dieses Problem zu umgehen, ist es Sinnvoll, zuerst zu prüfen ob das Device verfügbar ist und erst dann, wenn z.B. die PPP-Verbindung aufgebaut wurde, den tportknockd zu starten. Das folgende Skript zeigt, wie dies umgesetzt werden kann.

Wenn der tportknockd einmal läuft, dann kann er auch mit dem zeitweisen "verschwinden" (z.B. bei der DSL Zwangstrennung) des Device umgehen, wenn die Option -r angegeben wurde.

Ab BS Version 0.3.0 sind Imagevarianten verfügbar, welche den RADIUS-Server haprad enthalten. Dieser basiert auf dem sehr bekannten HostAP, welcher um die meisten Codeteile erleichtert wurde, um einen schlanken RADIUS-Server zur Authentifizierung von WLAN-Zugängen zu erhalten.

Der haprad ist für die Verwendung als Authentifizierungsserver für WLAN’s bestimmt. In den meisten Fällen wird ein WLAN meist mit einem shared key gesichert, d.h. alle Nutzer erhalten ein und denselben Schlüssel um sich am WLAN anzumelden (z.B. WEP oder WPA-/WPA2-PSK). Es kann jedoch sinnvoll sein, jedem Nutzer ein eigenes Zugangspasswort oder ein eigenes Zertifikat zu vergeben. Dies erlaubt dem Administrator einzelne Nutzer zu kontrollieren und ggf. zu sperren. Bei einem shared key hingegegen, muss dieser nach einer Änderung wieder an alle Nutzer verteilt werden.

Die nutzerbezogene Authentifizierung von WLAN-Zugängen stellt das sicherste Verfahren zur Verschlüsselung von WLAN-Verbindungen dar, da der für die Verschlüsselung verwendete PMK (Pairwise Master Key) bei jedem Authentifizierungsvorgang neu erzeugt wird. Dadurch ist jede WLAN-Verbindung jedes Nutzers mit einem anderen Schlüssel gesichert und ändert sich auch nach dem Neuanmelden wieder. Aus diesem Grunde sind Angriffe auf die eigentliche Verschlüsselung praktisch undenkbar.

Im folgenden soll der haprad-Server für die Authentifizierung von Nutzern mittels Nutzername/Passwort unter Verwendung der EAP-Methode PEAP-MSCHAPv2 konfiguriert werden. Dies hat den Vorteil, dass sowohl Windows-Clients (ab Windows XP SP2) als auch Linux-Clients (z.B. mittels WPA-Supplicant) dieses Verfahren beherrschen.

Die Konfiguration erfolgt in folgenden Teilschritten:

Wir legen die Konfiguration zunächst auf dem lokalen Rechner an und kopieren dann das gesamte Verzeichnis auf den Router:

Das Erzeugen der Zertifikate kann auf verschiedene Weise erfolgen. An dieser Stelle werden die EasyRSA-Skripte aus dem OpenVPN-Paket genommen.

Da das haprad-Konfigurationsverzeichnis später auf dem Router unter /opt liegt, werden alle Pfade bereits so angegeben:

Im nächsten Schritt geben wir dem haprad mit der Datei haprad.radius_clients bekannt, welche Clients mit welchen Passwörten (genannt shared secret) ihn kontaktieren dürfen. Wir konfigurieren hier den localhost und das shared secret secret:

Die folgende Datei haprad.eap_user enthält alle Nutzer, welche sich später mit dem WLAN verbinden dürfen. Wir konfigurieren hier zwei Beispielnutzer:

Nun kopieren wir das temporäre Verzeichnis vom lokalen Rechner auf den Router:

Jetzt wird die WLAN-Konfiguration auf dem Router angepasst, um den haprad als Authentifizierungsserver zu nutzen:

auf dem Webinterface folgende Einstellungen tätigen:

Network Settings→Wireless LAN→Security Settings

Jetzt testen wir ob die Konfiguration funktioniert indem wir mit telnet oder ssh auf den Router gehen und den haprad manuell starten. Anschließend verbinden wir uns mit einem WindowsXP-Rechner per WLAN mit dem Router:

Jetzt zum WindowsXP-Rechner:

Doppelklick WLAN-Symbol unten rechts→Eigenschaften→Drahtlosnetzwerke→Hinzufügen

Jetzt überall "OK" drücken und Einstellungen damit speichern. Jetzt in der Liste der Drahtlosnetzwerke dass eben Konfigurierte auswählen, dann sollte unten eine Meldung erscheinen: "Klicken Sie hier um Anmeldeinformationen einzugeben". Darauf klicken und im folgenden Fenster:

eingeben und die Authentifizierung sollte erfolgreich ablaufen.

Zu guter Letzt veranlassen wir nach einem erfolgreichen Test in Schritt 7, noch den automatischen Start des RADIUS-Servers. Hierzu im Web-Interface unter System Settings→Administration→Custom script folgende Zeilen ins custom_script einfügen und natürlich auch Start custom script auf On setzen:

Zunächst muss man sich per Telnet oder SSH auf den Router begeben und Platz für das Image schaffen:

Jetzt das Image per scp (oder winscp) in das temporäre Verzeichnis kopieren:

Danach kann das manuelle Firmwareupdate durchgeführt werden:

Wake-on-LAN (WoL) ist eine Technik mit der man einen abgeschalteten Computer mithilfe der eingebauten Netzwerkkarte einschalten kann. Es gibt verschiedene Varianten des WoL. Die verbreitetste Variante basiert auf dem Magic Packet. Das Magic Packet ist ein Datenpaket, das sechs mal den Hexadezimalwert FF und anschließend 16-mal die MAC-Adresse der Netzwerkkarte enthält. Empfängt die Netzwerkkarte ein Magic Packet mit der eigenen MAC-Adresse, löst sie den Start des Computers aus. Das Magic Packet kann mit beliebigen Protokollen (z.B. Ethernet, IP, IPX, UDP) transportiert werden. Üblicherweise werden Magic Packets direkt in Ethernet- oder UDP/IP-Datagrammen übertragen.

Computer können über das BS Web-Interface mit WoL gestartet werden (sieh Bild). Dazu wird das Programm etherwake verwendet. Dieses generiert und sendet Magic Packets die direkt in Ethernet Frames "verpackt" sind (für alle die es interessiert: für Magic Packets wird der Protokoll-Typ 0x0842 verwendet). Deshalb können so "nur" Computer innerhalb des LAN-Segments gestartet werden.

Um einen Computer zu starten, muss nur dessen MAC-Adresse in das Feld "MAC-Address" eingetragen werden. Mit einem klick auf "Run" werden drei Magic Packets gesendet.

Mit einem ARP-Ping kann geprüft werden, ob der/ein Computer an oder aus ist. Hier hätte mach auch einen "normalen" Ping (ICMP Echo Request) nutzen können, aber Mancheiner glaubt durch ICMP Echo Requests irgendeiner Gefahr ausgesetzt zu sein und lässt diese Pakete verwerfen. Um aber dennoch mit Sicherheit feststellen zu können, ob der/ein Computer im LAN-Segment an ist, wird stattdessen ein ARP-Request verwendet. Diesem kann man sich nicht entziehen.

Für einen ARP-Ping muss man nur die IP-Adresse des Computers in das Feld "IP-Address" eintragen und auf "ARP-Ping" klicken.

Die Drop-Down-Liste "known Hosts" und deren Inhalt haben per se nichts mit WoL zu tun. Diese entstammt aus der DHCP-Konfiguration und dient nur als Hilfe, um sich etwas Schreibarbeit zu ersparen. Diese Liste enthält alle Hosts die in der DHCP-Konfiguration separat konfiguriert wurden. Ein klick auf einen Eintrag in der Liste füllt automatisch die Felder "MAC-Address" und "IP-Address" aus.

Mit der BS Firmware ist es auch möglich einen Computer per Telefon zu wecken. Dafür können Custom Call Events definiert werden. Mit dem folgenden Custom Call Event-Skript kann ein Magic Packet versendet werden, indem man am Telefon, das am Router angeschlossen ist, die Tasten \#55*0\# drückt. Ein Magic Packet wird ebenfalls bei einem eingehenden Anruf mit der Rufnummer "0162123456" gesendet.

Dieses Skript muss noch im NVRAM (custom_call_event) gespeichert werden. Näheres dazu ist im Abschnitt Router steuern per Telefon - Eigene Funktionen beschrieben.

Portknocking ist eine Technik, mit der man einen Computer trotz Firewall "Signale" senden und Ereignisse auf dem Computer starten kann. Auf diese Weise ist es auch möglich einen Computer im lokalen LAN aus dem Internet zu starten.

Mit der folgenden Konfiguration ist es möglich, zwei Computer im LAN zu starten, wenn man dem Router innerhalb von 10 Sekunden jeweils ein TCP-Frame mit gesetztem SYN-Flag an Port 2000, 3000 und 4000 bzw. 2001, 3001 und 4001 sendet. Was die Konfiguration genau bedeutet und wie man das Portknocking auf dem Router startet, kann im Abschnitt Portknocking nachgelesen werden.

Die drei TCP-Frames mit gesetztem SYN-Flag können ganz einfach mit telnet erzeugt werden.

Mit Hilfe von http://stephan.mestrona.net/wol kann man UDP/IP-basierte Magic Packets versenden. Diese Pakete erreichen den Router zwangläufig auf dem externen Interface. Damit diese nicht verworfen werden und ins lokale Netz weitergeleitet werden, muss für diese Pakete Portforwarding aktiviert werden. Die Pakete sind UDP Datagramme die an Port 9 gesendet werden.

Um nur einen bestimmten Computer im LAN per WoL zu starten, sind folgende Einstellungen zu tätigen:

Um verschiedene Computer im LAN per WoL zu starten, sind folgende Einstellungen zu tätigen:

Die statischen ARP-Einträge sind nötig, da der Router sonst nicht weiß an welche MAC-Adresse das Frame zu senden ist, wenn der Computer aus ist. Desweiteren ist es mit IPtables nicht möglich, Frames an die Broadcastadresse (z.B. 192.168.1.255) weiterzuleiten. Deshalb ist der Umweg über eine nicht genutzte IP-Adresse in Kombination mit der Ethernet-Broadcastadresse nötig.

Damit der Computer über die Netzwerkkarte gestartet werden kann, wenn er abgeschaltet ist, sind am Computer selbst auch noch einige Einstellungen zu tätigen. Die Netzwerkkarte muss natürlich WoL-fähig und mit dem Standby-Stromzweig des Netzteils mit Spannung versorgt werden. Dies und auch WoL muss im BIOS aktiviert werden. Informationen darüber sind dem Handbuch des Mainboards zu entnehmen.

Die Netzwerkkarte muss während des herunterfahrens (z.B. beim "ausschalten", "Suspend to Ram" oder "Suspend to Disk") vom Betriebssystem in den WoL-Modus versetzt werden. In Windows wird dies über die "Eigenschaften der Netzwerkkarte" (erreichbar über den Geräte-Manager) konfiguriert. Unter Linux kann dies mit ethtool getan werden. Für eine detaillierte Beschreibung sind die entsprechenden Hilfs- und/oder Dokumentationsquellen zu konsultieren.

Ab BS Version 0.3.0 sind Imagevarianten verfügbar, welche OpenVPN enthalten.

OpenVPN ist eine VPN-Client/-Server Software, welche TCP- oder UDP-Verbindungen nutzt um verschlüsselt IP- oder Ethernetverbindungen zu tunneln. OpenVPN legt dazu im Userspace eine virtuelle Netzwerkkarte an, die eine IP-Adresse aus dem Adressbereich des VPN’s erhält. Alle an diese IP-Adresse gesendeten Daten, werden dann von OpenVPN entgegen genommen, verschlüsselt, in den Datenteil von TCP oder UDP eingepackt und meist über das Internet zum entsprechenden OpenVPN-Server oder -Client geschickt. Wenn die VPN-Verbindung als gerouteter IP-Tunnel konfiguriert ist, nennt man die virtuelle Schnittstelle tun-Device. Werden Ethernet-Pakete übertragen heisst diese tap-Device. OpenVPN ist im Vergleich zu den häufig verwendeten IPSec-basierten VPN-Lösungen leichter zu konfigurieren und vor allem wesentlich flexibler in der Handhabung.

Im folgenden HowTo soll der Router, wie im obigen Bild gezeigt, als OpenVPN-Server konfiguriert werden. Dies soll es ermöglichen mit mobilen Clients (z.B. Laptop) von unterwegs oder vom Arbeitsplatz aus etc. auf das heimische Netzwerk (Home-LAN) zugreifen zu können, um z.B. Netzwerkfreigaben zu nutzen oder interne Geräte zu erreichen.

Die Konfiguration erfolgt in folgenden Teilschritten:

Wir legen die Konfiguration zunächst auf dem lokalen Rechner an und kopieren dann das gesamte Verzeichnis auf den Router:

Das Erzeugen der Zertifikate kann auf verschiedene Weise erfolgen. An dieser Stelle werden die EasyRSA-Skripte aus dem OpenVPN-Paket genommen.

Da das OpenVPN-Konfigurationsverzeichnis später auf dem Router unter /opt liegt, werden alle Pfade bereits so angegeben:

Nun kopieren wir das temporäre Verzeichnis, welches die komplette Serverkonfiguration enthält, vom lokalen Rechner auf den Router:

Jetzt widmen wir uns der Konfiguration des Clients. Als Beispiel wird hier ein Laptop mit Windows XP genommen.

Auf dem Windows-XP Rechner:

Zuerst laden wir natürlich den OpenVPN-Installer hier herunter (z.B. openvpn-2.1_rc13-installer.exe) und führen ihn aus. Es wird OpenVPN standardmässig nach C:\Programme\OpenVPN\ installiert und gleichzeitig ein tap-Device als neue Netzwerkkarte angelegt. Diese bekommt später vom DHCP-Server des Routers eine IP aus dem internen LAN zugewiesen, deshalb brauchen wir dort auch nichts einzustellen.

Jetzt benötigen wir die in Schritt 1 erzeugten Dateien namens laptop.crt, laptop.key und evtl. tls_auth_shared.key und führen folgende Schritte durch:

Jetzt mit dem Editor die Datei C:\Programme\OpenVPN\config\client.ovpn öffnen und folgende Konfiguration einfügen:

Der Parameter remote ist natürlich auf die lokale IP vom Router einzustellen, da wir im nächsten Schritt die Konfiguration zunächst testen.

Wir kümmern uns beim Testen zunächst um den Start des Servers. Hierzu legen wir vorher ein tap-Device an und fügen dieses zur Bridge hinzu. Damit sollte dann der VPN-Client vom DHCP-Server auf dem Router eine IP bekommen und auch mit anderen Rechnern im LAN kommunizieren können.

Dann mittels telnet oder ssh auf den Router:

Nachdem der Server gestartet wurde, können wir uns dem Client widmen.

Hierzu auf dem Windows-XP Rechner:

Wenn alles klappt, sollte das tap-Device auf dem Windows-XP Rechner eine IP-Adresse vom Router bekommen.

Im letzten Schritt wollen wir noch dafür sorgen, dass der OpenVPN-Server auf dem Router immer gestartet wird und dieser auch über das WAN-Device erreichbar ist.

per telnet oder WebShell-Plugin folgendes Kommando auf dem Router ausführen, um den OpenVPN-Port (hier im Beispiel TCP-Port 1194) beim nächsten Start am WAN-Interface zu öffnen:

Über das Web-Interface unter System Settings→Administration→Custom script fügen wir noch folgende Zeilen ins custom_script ein um den Server nach einem Reboot zu starten:

Jetzt den Router neu starten und am Client den Parameter remote in der client.ovpn auf den öffentlichen DNS-Namen des Routers stellen (z.B. remote myrouter.dyndns.org). Damit sollte der Router per OpenVPN aus dem Internet erreichbar sein.

Der Router verfügt über eine serielle Schnittstelle. Über diese kann mit einem Terminalprogramm wie kermit, minicom (UNIX/Linux), oder Hyperterminal (Windows) auf dem Router zugegriffen werden. Der Router kann dann über das Terminal (Shell - ash) konfiguriert werden, ein Passwort ist dafür nicht nötig! Die serielle Schnittstelle ist vorallem beim Entwickeln, Portieren von Software oder bei Änderungen am Kernel sinnvoll. Sie ist aber auch hilfreich, wenn man durch eine fehlerhafte Netzwerk- oder Firewall-Konfiguration keinen Zugriff auf den Router hat.