HOWTO: 7050 als DSL-Modem+WLAN-AP+ATA ohne FW-Mod

thc

Neuer User
Mitglied seit
15 Sep 2005
Beiträge
112
Punkte für Reaktionen
0
Punkte
16
Hallo zusammen,
ich tüftele schon seit einiger Zeit an einer Lösung, meine FBF mit einem Router (IPCop) so zu kombinieren, dass ich kein drittes Gerät benötige und auch nichts an der FBF-Firmware ändern muss.
Bisher habe ich als Aussage immer gefunden, dass es zwei Szenarien gibt:
1. IPCop hinter FBF
Vorteil: FBF macht die volle Unterstützung für VoIP
Nachteil: Extra WLAN-AP erforderlich, da ohne FW-Mod keine Filterung des Traffic zwischen WLAN und Internet möglich ist (Stichwort iptables)
2. FBF hinter IPCop
Vorteil: Filterung jeglichen Traffics durch den IPCop möglich
Nachteil: Extra DSL-Modem erforderlich, Extra Aufwand für VoIP
Im folgenden Beitrag stelle ich eine Möglichkeit vor, wie es bei mir jetzt ohne zusätzliche Geräte funktioniert.
Architektur:
FBF mit derzeit FW 14.04.15 und IP 192.168.178.1
IPCOP mit derzeit FW 1.4.11 und IP 192.168.178.2
Verbindung der beiden LAN-A - RED und LAN-B - BLUE
Gruß
Claus
 
Zuletzt bearbeitet:
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
 
Zuletzt bearbeitet:
thc schrieb:
"nameserver 192.168.178.2 > /var/tmp/resolv.conf"

Müsste es nicht "echo nameserver 192.168.178.2 > /var/tmp/resolv.conf" heißen?

Darf ich diese Anleitung gleich in die Wiki-HowTos übernehmen?

Gruß,
Kay.
 
Müsste es nicht "echo nameserver 192.168.178.2 > /var/tmp/resolv.conf" heißen?
Natürlich - ändere ich - das Ganze ist aus dem Gedächtnis geschrieben.

Darf ich diese Anleitung gleich in die Wiki-HowTos übernehmen?
Lieber noch nicht.
Ich würde erstmal warten, bis ein paar andere das verifiziert haben und es vollständig ist (eingehende UDP-Ports und QoS).

Gruß
Claus
 
@thc: Ich habe soeben 5(!) Deiner Postings zusammengefasst. Bitte nutze die "Ändern"-Funktion, um Ergänzungen nachzureichen. Neue Beiträge erst nach 24 Std.
 
@Novize: Wenns denn so sein soll, von mir aus.
Bei meinem letzten Howto wars noch kein Problem, den Komplex in einzelne Teile zu zerlegen und diese zwecks besserer Gliederung in einzelnen Posts/Postings abzuhandeln.
Aber Hauptsache, die Forenmitglieder haben was davon.
Gruß
Claus
 
Kurze Ergänzung :

Ich habe den fast gleichen Construct:

IPCOP FW und am LAN A die FBF mit einem Switch verbunden. Habe auf der IPCOP einfach die UDP Ports 5060 und 8000-8005 auf die interne IP der FBF weitergeleitet. Da die IPCOP auch QOS kann, einfach den UDP Ports eine höhere Prio eingeräumt und die Viop gespräche sind so klar, als ob ich vom Festnetz telefoniere. ;)
 
witz schrieb:
Habe auf der IPCOP einfach die UDP Ports 5060 und 8000-8005 auf die interne IP der FBF weitergeleitet. Da die IPCOP auch QOS kann, einfach den UDP Ports eine höhere Prio eingeräumt und die Viop gespräche sind so klar, als ob ich vom Festnetz telefoniere. ;)
zu UDP: Wenn ich das richtig sehe, ist das mit den freizugebenden Ports nicht ganz trivial. Es gibt ein paar festgelegte Ports, z.B. 5060 für die Rufsignalisierung, und einige vom Provider und der Hardware abhängige. Wenn man das richtig machen will, muss man eine Tabelle aufmachen.
zu QoS: Da wäre es ja ganz toll von Dir, nicht nur zu schreiben, dass es funktioniert, sondern wie. Ich bemühe mich z.B. immer, in meinem Text soviel Informationen zu geben, dass es für eine Umsetzung ausreicht. Das kann dann je nach Komplexität ein kleiner Hinweis sein oder ganze Coding-Passagen. Und für QoS wäre m.E. Coding angesagt.
Gruß
Claus
 

Statistik des Forums

Themen
246,540
Beiträge
2,253,808
Mitglieder
374,394
Neuestes Mitglied
hansipeterson
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.