1. Internet-Zugang
Das ist erstmal ganz einfach.
Die FBF ist im Auslieferungszustand so eingestellt.
Sie nutzt nur eine IP-Adresse nach aussen und das DSL-Modem ist im Bridge-Modus aktiv.
Einfach IPCop/RED an LAN-A(!) anschliessen, Zugangsdaten im IPCop eintragen und lossurfen.
2. WLAN-AP
Ist im Auslieferungszustand auch schon an, funktioniert aber noch nicht richtig.
Das WLAN-Interface ist im Bridge-Modus, also als reiner AP und nicht als Router aktiv und die FBF weiss nicht, wohin mit den ganzen IP-Paketen.
Also muss unter Einstellungen -> System -> Netzwerkeinstellungen -> IP-Routen eine Default-Route eingetragen werden, also Netzwerk und -maske 0.0.0.0 und Gateway bei mir die blaue IPCop-IP 192.168.178.2.
Wenn man das gemacht hat, wird die Default-Route an eth0 gebunden und alle IP-Pakete werden brav über LAN-B ausgeliefert.
Da muss also ein Kabel zum IPCop/BLUE dran.
Und schon holen sich die Clients per DHCP ihre Einstellungen vom IPCop ab und können auch lossurfen und alles machen, was ihnen der IPCop erlaubt.
Was ich noch testen muss: Es gibt eine Einstellung, die den WLAN-Clients den Traffic untereinander verbietet. Wenn das bedeutet, dass über das WLAN-Interface nur Pakete für fremde Netze akzeptiert werden, dann hätte das den angenehmen Nebeneffekt, dass man vom WLAN auch nicht auf die FBF selbst kommt, diese mithin von dort nicht angreifbar ist.
[
2006-08-29] Ergebnis: Zugriff auf die FBF ist vom WLAN aus möglich - schade eigentlich.
[
2006-09-01] Die FBF schickt merkwürdigerweise auch IP-Pakete über LAN-B an RED. Ich habe deshalb alle Pakete geblockt, die über RED von der FBF selbst kommen.
[
2006-09-04] Die merkwürdigen Pakete haben sich erledigt. eth0 ist LAN-B und eth1 ist LAN-A. Kabel getauscht und keine Probleme mehr.
3. VoIP: Nameserver
Das wird etwas komplizierter.
AVM hat es nämlich unterlassen, in der Weboberfläche die Modifikation des Nameservers zuzulassen.
Das bedeutet, dass der in der FBF aktive voipd bei 192.168.180.1 (und .2) - also bei sich selbst - nachsieht, welche IP der VoIP-Provider hat.
Die FBF weiss es natürlich nicht und damit hat der voipd ein Problem.
Aber das lässt sich zum Glück umbiegen.
Mit einem angeschlossenen Telefon per #96*7* den telnetd aktivieren, sich mit der Box verbinden und (bei mir) 'echo "nameserver 192.168.178.2" > /var/tmp/resolv.conf' eingeben und schon weiss die Box, wen sie fragen muss.
Das lässt sich sicher noch optimieren - einmal durch Ermitteln der IP aus der Default-Route - oder noch besser dadurch, dass AVM das bei Verwendung der Box als ATA selbst macht: bitte immer die Standard-Route auch als Nameserver vorsehen.
Diese Zeile sollte man/frau natürlich tunlichst fest in der debug.cfg eintragen.
Wie das geht, steht in vielen anderen Threads, hier deshalb nicht nochmal.
[
2006-08-29] Der Nameservereintrag wird bei jedem Start des multid auf die in der ar7.cfg stehenden Werte zurückgesetzt, muss dann also immer wieder umgebogen werden. Inzwischen habe ich die Zeile wie folgt auf der Box:
/sbin/route | grep "^default" | grep "lan$" && echo "nameserver 192.168.178.2" > /var/tmp/resolv.conf
Wenn jemand weiss, wie ich mit den Mitteln der Busybox ohne große Verrenkungen das zweite Feld der Default-Route isoliert bekomme, immer her damit. Also ähnlich wie cut 2, nicht mit einer extra Funktion und $2 auswerten...
[
2006-08-31] Wenn man den multid mit "-s Pfad-zum-Skript" startet, kann man dort eigene Erweiterungen einhängen. Das lässt sich für einen Watchdog verwenden, der (leider) erforderlich ist, um den Nameserver-Eintrag und nebenbei die regelmäßige VoIP-Registrierung sicher zu stellen.
Auszug aus der debug.cfg:
Code:
# Lokales Verzeichnis (muss beschreibbar sein) in dem die Dateien liegen sollen
LOCALDIR="/var/usr"
DEBUGLOG="$LOCALDIR/debug.log"
# Adresse des Servers von dem die Dateien nachgeladen werden
SERVER="Name-eines-erreichbaren-Servers"
# Herunterladen von Dateien
f_wget() {
# Abholen vom Webserver
CMD="wget http://$SERVER/$1"
echo "$(date '+%F %T') $CMD" >> $DEBUGLOG
$CMD
# Test auf Erfolg
[ -e ./$1 ] || return 1
# Anpassen der Dateirechte
chmod +x ./$1
# Test auf Erfolg
[ -x ./$1 ] || return 1
}
# multid fuer Status online/offline und Nameserver
f_wget multid.cfg || exit
f_wget multid.sh || exit
CMD="$LOCALDIR/multid.cfg"
echo "$(date '+%F %T') $CMD" >> $DEBUGLOG
$CMD &
Auszug aus multid.cfg:
Code:
#!/bin/sh
PGM="multid"
LOCALDIR="/var/usr"
# Tests
[ -x $LOCALDIR/$PGM.sh ] || exit
# Neustart
if [ $(ps fax | grep -c "$PGM.sh") -lt 2 ]; then
$PGM -s
$PGM -S $LOCALDIR/$PGM.sh
sleep 10
fi
# Neu registrieren
voipd -R
# Sonntags zwischen 3 und 4 reboot vorsehen, sonst sich selbst aufrufen
CMD="$LOCALDIR/$(basename $0)"
if [ "$(date +%w)" = "0" ]; then
if [ "$(date +%H)" = "03" ]; then
CMD="$(which reboot)"
fi
fi
# Im Hintergrund eine halbe Stunde warten, dann Kommando ausführen
(sleep 1800 ; $CMD) &
# EOF
multid.sh:
Code:
#!/bin/sh
/sbin/route | grep "^default" | grep "lan$" && echo "nameserver 192.168.178.2" > /var/tmp/resolv.conf
# EOF
Einfacher gehts leider nicht.
4. VoIP: UDP-Routing
Wenn der IPCop einfach alle Pakete von BLUE nach RED durchlässt, sollten jetzt ausgehende Gespräche möglich sein.
Aber ich habe ja den IPCop gerade, um den Traffic zu filtern, insbesondere den vom WLAN in BLUE.
Deshalb müssen eine ganze Reihe UDP-Ports freigegeben werden.
Wer das einzeln machen möchte, installiert BOT auf dem IPCop, gibt "voipd -R" an der FBF-Telnet-Konsole ein, sieht der Firewall bei der Arbeit zu und gibt nach und nach alle benötigten Ports für die VoIP-Registrierung frei. Und dann zum eingentlichen Telefonieren das Ganze noch einmal für die Sprachpakete.
Wer dazu keine Lust hat, lässt einfach alle UDP-Pakete durch, die von der FBF kommen.
Damit funktionieren noch keine kommenden Gespräche.
Wer das realisieren möchte, macht analog das Gleiche - sprich benötigte Ports einzeln freigeben und an die FBF weiterleiten - ist aber mühsam, weil man dazu ja von aussen anrufen muss und jeder Port in eine eigene Regel verfrachtet werden muss.
Oder hat jemand eine fertige Portliste?
Wer auch dazu keine Lust hat, verzichtet auf eingehende VoIP-Gespräche und lässt sich übers Festnetz anrufen.
[
2006-08-29] So wie es aussieht, müssen die vom RTP genutzten Ports eingehend freigegeben werden, sonst klappt zwar die Signalisierung, sprich es klingelt am anderen Ende, und der Ton geht zum/zur Angerufenen, aber es kommen keine Sprachpakete zurück.
Bei mir siehts jetzt so aus:
1&1 ausgehende Gespräche: raus src(!) UDP 5060, 7078-7081, rein dst 7078-7081
1&1 eingehende Gespräche: muss ich noch testen
[
2006-08-31] Das mit der ganzen Reihe Ports hat sich erledigt. Die FBF benutzt für SIP nur den UDP-Port 5060 sowie für RTP für das erste Gespräch die Ports 7078 und 7079, für ein zweites Gespräch 7082 und 7083. Also reicht es, die UDP-Ports 5060 sowie 7078 -7079 und 7082-7083 freizugeben, und zwar ausgehend als Source- und eingehend als Destination-Ports mit Forwarding auf die FBF.
5. VoIP: Registrierung
Ein weiteres Problem ist nach anderen Forumsberichten das schnelle Verfallen der VoIP-Registrierung, wenn die FBF als ATA arbeitet.
Dazu könnte man regelmäßig ein "voipd -R" auf der FBF machen, aber das geht wiederum nur mit cron (FW-Mod) oder einer Skript-Schleife, die in der debug.cfg verankert wird.
[
2006-08-31] Die Registrierung läuft nach etwas über einer halben Stunde aus. Deshalb muss sie regelmäßig erneuert werden. Das lässt sich mit dem unter 3. eingerichteten Watchdog gleich mit erledigen.
6. VoIP: QoS
Jetzt hängt die FBF also am IPCop, ich kann sicher surfen und telefonieren.
Startet die beste Ehefrau/-freundin von allen jetzt mal wieder einen grossen Upload, um z.B. Abzüge von mit der Digitalkamera gemachten Fotos zu bestellen, ist das ganz schlecht fürs Telefonieren.
Da muss der IPCop dafür sorgen, dass VoIP-Pakete eine höhere Priorität bekommen.
Wie das geht, weiss ich bis jetzt nur theoretisch.
Aber vielleicht kann da ja mal jemand was zu posten, bei dem es rennt.
Ich nehm das dann hier mit rein.
[
2006-09-03] QoS läuft jetzt auch und war gar nicht sooo schwierig. Ich habe auf dem IPCop z.Zt. die FW 1.4.11 und QoS_ng 1.4.2. Installation und Konfiguration sind in dem Addon-Paket sehr gut beschrieben. Bei mir bekommen die UDP-Ports 5060, 7078-7079 und 7082-7083 aus- und eingehend eine Bandbreite von 140kBit reserviert. Die reinen Gesprächsdaten laufen dabei über 7078 bzw. 7082.
Das wars...
7. Änderungen
[
2006-08-29] erste Überarbeitung zu 3. und 4.
[
2006-08-31] zweite Überarbeitung zu 3. und 4., 5. eingefügt
[
2006-09-01] Blocken FBF-Pakete über RED
[
2006-09-03] QoS
[
2006-09-04] LAN-A und -B getauscht
