Freifunk Köln, Bonn und Umgebung - Benutzerbeiträge [de]

FF-Router einsperren im VLAN

2015-05-18T17:33:40Z

Krugar: Guide: Freifunk-Router am heimischen WLAN-Router in einem VLAN einsperren

=Freifunk-Router am heimischen WLAN-Router in einem VLAN einsperren=
Das folgend beschrieben Vorgehen funktioniert bei WLAN-Routern unter OpenWrt mit konfigurierbarem Switch, hier am Beispiel eines TP-Link Archer C5 als Internet-Gateway, bei der der Freifunk-Router in einem der gelben LAN-Ports steckt, in direkter Nachbarschaft zu Desktoprechnern und ähnlichem.

'''Achtung''': die [http://wiki.openwrt.org/toh/tp-link/tl-wdr7500#port_map Switch-Belegung] beim Archer C5 ist etwas eigen, bitte nicht unbedacht für andere Modelle kopieren.

Die Idee hier ist, dem physikalischen Steckplatz im Switch ein VLAN zuzuweisen, in dem der Freifunk-Router alleine ist, und dann alles weitere so einzustellen, dass er Verbindungen ins WAN herstellen kann.

Hierbei gibt es drei logische Einheiten innerhalb des "WLAN-Router"-Kastens zu bedenken:
* Switch
* Router
* Firewall
Wenn im Folgenden das Wort "Router" verwendet wird, ist damit die logische Einheit innerhalb des Kastens gemeint, und nicht der ganze Kasten. Das Wort "Freifunk-Router" meint hingegen den anderen Kasten, der via Kabel angeschlossen werden soll, als Ganzes.

==Switch konfigurieren==
Sicherheitshalber sollte man ein Gerät zur Hand haben, mit dem man via WLAN auf den Router zugreifen kann, entweder via ssh oder die Webschnittstelle. Falls man sich bei der Switchkonfiguration vertut, bleibt der Router nämlich über WLAN erreichbar.

Switch und Router werden unter OpenWrt in der gleichen Datei konfiguriert, nämlich /etc/config/network
der Switch in unserem Beispielgerät hat 7 ports wie folgt:
<pre>
0 eth1
1 WAN
2 LAN1
3 LAN2
4 LAN3
5 LAN4
6 eth0
</pre>
Quelle: http://wiki.openwrt.org/toh/tp-link/tl-wdr7500#port_map

Dabei sind 0 und 6 Router-Interfaces, die in festen internen Ports im Switch stecken, und 1-5 sind die blauen (1) und gelben (2-5) Buchsen auf der Rückseite des Geräts.

Per Voreinstellung finden sich in /etc/config/network folgende Einträge zum Switch:
<pre>
config switch
option name 'switch0'
option reset '1'
option enable_vlan '1'

config switch_vlan
option device 'switch0'
option vlan '1'
option vid '1'
option ports '0 2 3 4 5'

config switch_vlan
option device 'switch0'
option vlan '2'
option vid '2'
option ports '1 6'
</pre>
Hier werden also die gelben physischen LAN-Ports (2-5) mit dem Router-Interface eth1 zusammen in VLAN 1 gesteckt,
und der blaue "WAN"-Port (1) zusammen mit eth0 in VLAN 2. Hierbei handelt es sich um untagged VLANs,
was nur so lange funktioniert, wie jeder Port in nur einem VLAN steckt.
In unserem Fall wollen wir aber einen der gelben Ports in ein eigenes VLAN stecken, und damit er mit dem Router reden kann, muss auch das Router-Interface eth1 in diesem VLAN liegen (eth1 ist das "LAN"-Interface des Routers). An dieser Stelle kommen tagged VLANs ins Spiel, und die Regeln sind in etwa wie folgt:
* ein Port darf in einem untagged und in mehreren tagged VLANS sein
* innerhalb des gleichen VLANS dürfen tagged und untagged Ports gemischt sein
* die Nummer des VLANs wird als Tag verwendet, mit dem Pakete in bestimmten Fällen markiert werden
* wenn Pakete mit Tag von aussen über einen untagged Port beim Switch ankommen, werden sie ignoriert
* wenn Pakete ohne Tag von aussen über einen tagged Port beim Switch ankommen, werden sie ignoriert
* wenn Pakete ohne Tag über einen untagged Port am Switch in ein VLAN kommen, liefert der Switch sie mit passendem Tag an tagged Ports im gleichen VLAN aus
* wenn Pakete mit Tag über einen tagged Port am Switch in ein VLAN kommen, entfernt der Switch das Tag, bevor er die Pakete an untagged Ports im gleichen VLAN ausliefert
* wer oder was auch immer aussen an einem tagged Port des Switches hängt, muss das wissen und in der Lage sein, getaggte Pakete zu senden und zu empfangen

Was wir jetzt machen müssen ist folgendes:
Im Switch ein weiters VLAN einrichten, und da einen der gelben Ports reintun. Dieser gelbe Port muss entsprechend aus dem VLAN, in dem er gerade drin ist (VLAN 1) herausgenommen werden, damit er nur in einem VLAN ist (wir wollen den Freifunk-Router ja isolieren). Wie schon erwähnt, muss eth1 (Switchport 0) auch in dieses VLAN, aber es muss auch im VLAN 1 bleiben, weil wir sonst ja die anderen 3 gelben Ports effektiv abklemmen. Deswegen nehmen wir eth1 als tagged Port in unser neues VLAN und lassen es als untagged Port im alten. Beispielconfig:
<pre>
config switch_vlan
option device 'switch0'
option vlan '3'
option vid '3'
option ports '0t 5'
</pre>
Hier ist die gelbe Buchse mit der Nummer 4 auf der Rückseite des Routerkastens (LAN4 in der Liste oben, Switchport 5) als Anschluss für den Freifunk-Router gewählt, das neue VLAN heisst "3", und es beinhaltet Port 0 als tagged Port (das kleine "t" regelt das) und Port 5 als untagged. Nicht vergessen: Port 5 aus VLAN 1 entfernen!
<pre>
config switch_vlan
option device 'switch0'
option vlan '1'
option vid '1'
option ports '0 2 3 4' #keine 5 mehr in dieser Liste
</pre>

Damit ist der Switch konfiguriert, aber die Datenpakete des Freifunk-Routers kommen jetzt mit dem Tag "3" bei der Routerkomponente an, die sie geflissentlich ignorieren wird.

==Router konfigurieren==
Die voreingestellte Routerkonfiguration beinhaltet drei Interfaces: loopback, lan, wan. loopback interessiert uns nicht:
<pre>
config interface 'lan'
option force_link '1'
option type 'bridge'
option proto 'static'
option ipaddr '?.?.?.1'
option netmask '255.255.255.0'
option ip6assign '60'
option _orig_ifname 'eth1 wlan0 wlan1'
option _orig_bridge 'true'
option ifname 'eth1 wlan0 wlan1'

config interface 'wan'
option ifname 'eth0'
option _orig_ifname 'eth0'
option _orig_bridge 'false'
option proto 'static'
option ipaddr '?.?.?.?'
option netmask '?.?.?.?'
option gateway '?.?.?.?'
</pre>

Wir fügen jetzt ein weiters Interface hinzu, welches das VLAN 3 auf dem physikalischen interface eth1 entgegennehmen soll:
<pre>
config interface 'KBU'
option proto 'static'
option ifname 'eth1.3'
option ipaddr '192.168.200.1' #beispielwert
option netmask '255.255.255.0'
option ip6assign '64'
</pre>
die wichtige Stelle ist das "ifname 'eth1.3'". hiermit wird dem Router gesagt, dass er Daten, die an seinem Interface eth1 als VLAN 3 getaggt ankommen, auf dem neuen Interface "KBU" annehmen soll.

Wenn man sich bisher über die LUCI-Weboberfläche durchgeklickt hat, wird einem VLAN 3 nur als "eth0.3" angeboten, was aber zumindest logisch der falsche Port ist (eth0 = WAN, eth1 = LAN). Ich habe nicht ausprobiert, ob man sich das VLAN auch mit "5 6t" klicken kann und dann den Rest via LUCI regeln kann. Ich gehe im Weiteren davon aus, dass das VLAN 3 aus "0t 5" besteht und "KBU" auf "eth1.3" lauscht. Falls jemand Erfolg mit "5 6t" und "eth0.3" hat, bitte diesen Artikel entsprechend anpassen.

Eine Sache bleibt noch: auf dem automatisch definierten Interface "lan" hängen im Moment die physischen interfaces 'eth1, wlan0, wlan1' gemeinsam. Nach meinem Verständnis ist das VLAN 1 das "default VLAN", weswegen "eth1" gleichbedeutend mit "eth1.1" sein dürfte, aber zumindest bei meiner Installation hat es nicht geschadet, das explizit zu ändern:
<pre>
config interface 'lan'
option force_link '1'
option type 'bridge'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
option ip6assign '60'
option _orig_ifname 'eth1 wlan0 wlan1'
option _orig_bridge 'true'
option ifname 'eth1.1 wlan0 wlan1'
</pre>

==Firewall==
Jetzt wo unsere Datem vom Freifunk-Router über den Switch beim Router an einem Interface ankommen, müssen wir sie noch ins Internet rausreichen, und das machen wir über eine Firewall-Zone, die wir in /etc/config/firewall anlegen (oder sehr bequem in LUCI klicken können). Hier kopieren wir im Grunde einfach die Einstellungen der LAN-Zone:
<pre>
config zone
option name 'KBU'
option input 'ACCEPT'
option output 'ACCEPT'
option network 'KBU'
option forward 'ACCEPT'

config forwarding
option dest 'wan'
option src 'KBU'
</pre>

solange die Default-Einstellungen der Firewall beibehalten wurden und für nicht definiertes Forwarding gilt, dass es verboten ist, sind jetzt 'lan' und 'KBU' von einander getrennt, können aber beide jeweils dank Forwarding mit der WAN-Seite (dem Internet) reden.

<pre>
config defaults
option syn_flood '1'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'REJECT' # <- das ist entscheidend
option drop_invalid '1'
</pre>

==Danksagung==
nomaster vom Freifunk Rheinland e.V. hat sich auf dem 1C2 sehr viel Zeit genommen, um mir den Unterschied zwischen Router und Switch zu vermitteln. Ohne seine Geduld wäre dieser Artikel nicht möglich gewesen.

Pimp my Node

2015-05-18T16:43:53Z

Krugar: /* Einsperren des Freifunk-Routers in eine DMZ */

[[Kategorie:Mitmachen]]
== Netztheorie/Technik und Entwicklung ==
Vertiefung

*[[FSM-Dynamisches-Bridging]]
*[[Batman_adv]]
*[[Entwicklung]]
*[[Firmware|Firmware/Betriebssystem]]

== Arbeiten auf der Shell ==
Vorraussetzung für folgende Befehle sind eine Verbindung mit dem KBU Freifunk Netz sowie ein Terminal / Shell.
Vergesst nicht eth0 gegen die Bezeichnung eures Netzwerkinterfaces, welches am Freifunk hängt zu tauschen.
Bei Macbooks via Wlan z.B. "en1" statt "eth0"! Die link local Adresse der jeweiligen node findet ihr auf der [http://register.kbu.freifunk.net KBU Register] Seite. Um Dateien auf dem Node ändern zu können, steht als einziger Editor ''vi'' bzw. ''vim'' zur Verfügung.

=== IPv6 ping ===
<pre>
ping6 <link local Adresse des Nodes>%eth0
</pre>

=== IPv6 ssh ===
Hinter der link local Adresse "%" + "Netzwerk Interface an eurer Kiste" (Hier im Beispiel eth0)
<pre>
ssh root@<link local Adresse des Nodes>%eth0
</pre>

=== Hostnamen des Nodes ändern ===
Standardmäßig ist der Hostname des Nodes gleich der MAC-Adresse des Routers. Möchte man den Hostnamen ändern, so kann man dies in der Datei ''/etc/config/system''. Hier gibt es gleich als ersten Punkt ''config system'' und dort findet man den Eintrag
<pre>option hostname 'aa:bb:cc:dd:ee:ff'</pre>
Hier kann man jetzt aa:bb:cc:dd:ee:ff (diese Adresse sieht bei jedem Node anders aus!) zu dem gewünschten Hostnamen ändern. Eine Änderung wird erst nach dem Kommando ''reboot'' (danach startet der Node neu) wirksam.

=== Node überträgt keine Statistiken ===
Auf der [https://kbu.freifunk.net/cserv Cserv Seite] könnt ihr prüfen, ob eurer Node bereits Statistiken übermittelt.
==== ntp-Bug in Firmware 1.2.1b beseitigen ====
Falls sich ein Node-Betreiber wundert, warum sein Node keine Statistiken liefert und es ein Mesh-Only-Node ist (d. h. ohne eigenen Uplink zum Internet), so liegt das an einem Bug in der Firmware. Diesen kann man jedoch mit einfachen Mitteln beheben:
Editiert wird die Datei ''/etc/config/system''. Dort findet man einen Eintrag ''config timeserver 'ntp'''. Defaultmäßig stehen hier 4 Zeitserver von openwrt (in der Form x.openwrt.pool.ntp.org). Diese müssen bei Mesh-Only-Nodes in IPv6-Adressen geändert werden, und zwar, dass der komplette Konfigurationspunkt wie folgt aussieht:
<pre>config timeserver 'ntp'
list server '2a03:4000:2:494::2'
list server '2a01:4f8:161:2461:e4::1'
list server '2a02:180:1:1::551f:bb4b'
option enabled '1'
option enable_server '0'</pre>
Auch hier werden die Änderungen erst nach einem Neustart des Nodes mittels ''reboot'' wirksam.
Dieser Bug soll mit dem nächsten Firmware-Release behoben sein. Man kann die Eintragungen auch in den Nodes mit Internet-Uplink ändern ohne die Funktion zu beeinträchtigen.

==== Collectd prüfen ====
Falls es durch das beheben des ntp-Bug noch immer nicht zum übertragen der Statistiken kommt, überprüft mal die Einstellungen eures Collectd. Es kann sein das beim Firmware Update diese Config nicht geupdatet wurde und eine veraltet IPV6 Adresse noch vorhanden ist, so sollte es sein:
<pre>
vim /etc/collectd.conf // Config Datei für Collectd zum bearbeiten öffnen

Zeile 39-44:
<Plugin ping>
TTL 127
Interval 30
Host "fdd3:5d16:b5dd:3::6" // Diesen Eintrag auf Übereinstimmmung prüfen
</Plugin>

Zeile 46-50:
<Plugin network>
Server "fdd3:5d16:b5dd:3::6" "25827" // Diesen Eintrag auf Übereinstimmmung prüfen
Forward false
</Plugin>
</pre>

=== SSH public key auf Node aufspielen ===
Möchte man sich nicht immer per Paßwort auf den eigenen Node verbinden, so kann man das auch mit einem Schlüsselpaar realisieren. Falls man danach noch die Authentifizierung per Paßwort abschaltet (s. nächster Punkt), dann hat man einen sicheren Zugriff auf seinen Node realisiert.
Voraussetzung ist natürlich, dass man schon ein gültiges Schlüsselpaar besitzt. Falls dem so ist, so genügt es, den öffentlichen Schlüssel (public key) auf den Node zu übertragen. Das kann mit Hilfe von scp (secure copy) passieren:
<pre>
scp -6 id_rsa4096.pub root@[<link local Adresse des Nodes>%eth0]:/etc/dropbear/authorized_keys
</pre>
Hierbei steht id_rsa.pub für die Datei, die den public key enthält. '''ACHTUNG:''' Obiger Befehl ersetzt die eventuell schon vorhandene Datei authorized_keys auf dem Node. Das ist ok für den ersten Key. Sollen mehrere Keys eingetragen werden (z. B. weil man außer vom Laptop auch vom Tablet auf seinen Node verbinden möchte), kann man das so machen:
<pre>
cat ~/.ssh/id_rsa4096.pub | ssh root@[<link local Adresse des Nodes>%eth0] 'umask 077; cat >>.ssh/authorized_keys'
</pre>

Sollte beim Kopierversuch die Meldung
<pre>ssh: Could not resolve hostname fe80:</pre>
erscheinen, hat man höchstwahrscheinlich die eckigen Klammern um die IP-Adresse inklusive Interface vergessen. Dann wird der erste Doppelpunkt schon als Ende des Hostnamens interpretiert! Auch hier werden die Änderungen nach einem Neustart des Routers mittels ''reboot'' übernommen.

=== Paßwort-Authentifizierung abstellen ===
'''Wichtig:''' Als erstes prüfen, ob man sich mit seinem Schlüsselpaar auf den Router einloggen kann. Man sollte jetzt nicht mehr nach dem Paßwort gefragt werden (allerhöchstens nach dem Paßwort, welches den privaten Schlüssel schützt).
Falls das erfolgreich funktioniert, kann man die Datei ''/etc/config/dropbear'' wie folgt ändern:
<pre>config dropbear
option PasswordAuth 'off'
option RootPasswordAuth 'off'
option Port '22'
# option BannerFile '/etc/banner'</pre>
Nach einem Neustart des Routers mittels ''reboot'' sollte es jetzt nur noch möglich sein, sich mit seinem Schlüsselpaar auf den Rotuer einzuloggen.

=== Firmware aktualisieren ===
==== Node mit uplink ====

<pre>
ssh root@<link local Adresse des Nodes>%eth0 // SSH Verbindung zum Node aufbauen
cd ../tmp/ // in das Verzeichnis "tmp" wechseln
free // Freien Speicher prüfen
wget http://pfad/zur/firmware.bin // Firmware herunterladen oder
sysupgrade -v firmware.bin // Firmwareupgrade durchführen
</pre>

'''Achtung''': Beim Download der Firmware via wget kann auf dem Router die Integrität der Firmware nicht geprüft werden, da gpg i.d.R. auf den Routern nicht verfügbar ist. Deshalb ist es sicherer, den oben beschriebenen Weg zu wählen, oder die geprüfte Firmware per scp (s.u.) auf den Router zu kopieren.

==== Node ohne uplink (mesh node) ====
<pre>
scp -6 -v -r firmware.bin root@\[<link local Adresse des Nodes>%eth0\]:../tmp/ // Firmware auf den node schieben (md5 checken!)
ssh root@<link local Adresse des Nodes>%eth0
cd ../tmp/
sysupgrade -v firmware.bin
</pre>

=== LAN Kopplung ===
Eine LAN Kopplung kann in manchen Fällen sinnvoll sein, besonders wenn man einen VLAN fähigen Switch und eine bestehende Ntzwerkverkabelung hat. Hier werden die Switchports angwiesen auch über LAN zu meshen.

==== TL-WR841ND ====
03/2014: Hier wird über die alle 4 LAN Ports gemeshed, Mesh über WLAN kann man optional noch ausschalten! Folgende Config stammt von rampone/FF-KBU und wurde an 2 TL-WR841N v.8 getestet mit KBU-FF-Firmware 1.1.

05/2015: Verifiziert (und ergänzt) für TL-WR841N v.9 und KBU-FF-Firmware 1.2.2rc3 .

''vim /etc/config/network'' - Folgende Änderungen wurden an der FF-Firmware vorgenommen:
#config interface 'freifunk' -> Hier haben wir das ethX-Interface aus "ifname" rausgenommen, damit kein ff aus dem ethX (switch) rauskommt (X=1 für Hardware bis einschließlich v8, sonst X=0).
#config interface 'mesh_lan' -> kompl. codeblock hinzugefügt, dieser bewirkt das über ethX (switch) gemeshed wird.

<pre>
config interface 'loopback'
option ifname 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'

config interface 'wan'
option ifname 'eth0'
option proto 'dhcp'
option type 'bridge'
option accept_ra '0'
option auto '1'

config switch
option name 'switch0'
option reset '1'
option enable_vlan '1'

config switch_vlan
option device 'switch0'
option vlan '1'
option ports '0 1 2 3 4'

config interface 'freifunk'
option ifname 'bat0' #LAN-Kopplung: ifname eth1 (bzw. eth0, s.o.) entfernt
option type 'bridge'
option proto 'none'
option auto '1'
option accept_ra '1'
option macaddr '10:fe:ed:f1:53:84'

config interface 'mesh'
option proto 'batadv'
option mtu '1528'
option mesh 'bat0'

config interface 'mesh_vpn'
option ifname 'mesh-vpn'
option proto 'batadv'
option mesh 'bat0'
option macaddr '12:fe:ed:f2:53:84'

config interface 'mesh_lan' #LAN-Kopplung: Codeblock mesh-lan hinzugefuegt
option ifname 'eth0' # ab TL-841N(D) v9: eth0, bis v8: eth1 . Bei falschem Interface läuft das mesh-lan über den blauen Port. Wer's mag...
option proto 'batadv'
option mesh 'bat0'
</pre>

''vim /etc/config/wireless'' - Hier wird der Codeblock, der für das Mesh über WLAN verantwortlich ist auskommentiert (optional)
<pre>
#config wifi-iface 'wifi_mesh'
# option device 'radio0'
# option network 'mesh'
# option mode 'adhoc'
# option ssid '02:d1:11:37:fc:39'
# option bssid '02:d1:11:37:fc:39
</pre>

==== TL-WDR4300 ====
Das gleiche nochmal für den 4300er

''vim /etc/config/network''
<pre>
config interface 'loopback'
option ifname 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'

config interface 'wan'
option ifname 'eth0.2'
option proto 'dhcp'
option type 'bridge'
option accept_ra '0'
option auto '1'
option macaddr 'a2:f3:c1:65:81:cd'

config switch
option name 'eth0'
option reset '1'
option enable_vlan '1'

config switch_vlan
option device 'eth0'
option vlan '1'
option ports '0t 2 3 4 5'

config switch_vlan
option device 'eth0'
option vlan '2'
option ports '0t 1'

config interface 'freifunk'
option ifname 'bat0' #LAN-Kopplung: ifname eth0.1 entfernt
option type 'bridge'
option proto 'none'
option auto '1'
option accept_ra '1'
option macaddr 'a0:f3:c1:64:81:cc'

config interface 'mesh'
option proto 'batadv'
option mtu '1528'
option mesh 'bat0'

config interface 'mesh_vpn'
option ifname 'mesh-vpn'
option proto 'batadv'
option mesh 'bat0'
option macaddr 'a2:f3:c1:65:81:cc'

config interface 'mesh_lan' #LAN-Kopplung: Codeblock mesh-lan hinzugefuegt
option ifname 'eth0.1'
option proto 'batadv'
option mesh 'bat0'

</pre>

== Einsperren des Freifunk-Routers in eine DMZ ==

Wer seinen Freifunk-Router einsperren und/oder die Bandbreite begrenzen möchte, kann dies am einfachsten tun, indem er ihn an seiner Firewall an einen eigenen Netzwerkport klemmt und diesen dann als DMZ konfiguriert. Ein KBU-Freifunk-Router muß zur Zeit im LAN DHCP, DNS, im Internet NTP sowie mit den [[fastd]]-Knoten reden können. Folgendes Bespiel für eine iptables-Firewall nimmt an, dass der Freifunk-Router über eth2 angeschlossen ist:

# eth2 darf nur dns, ntp, dhcp und ansonsten mit den fastdX reden
iptables -i eth2 -A INPUT -p udp --dport 67:68 --sport 67:68 -j ACCEPT
iptables -i eth2 -A FORWARD -p udp --dport 67:68 --sport 67:68 -j ACCEPT
iptables -i eth2 -A INPUT -p udp --dport 53 -j ACCEPT
iptables -i eth2 -A INPUT -p tcp --dport 53 -j ACCEPT
iptables -i eth2 -A INPUT -p tcp --dport 123 -j ACCEPT
iptables -i eth2 -A FORWARD -p udp --dport 53 -j ACCEPT
iptables -i eth2 -A FORWARD -p tcp --dport 53 -j ACCEPT
iptables -i eth2 -A FORWARD -p tcp --dport 123 -j ACCEPT
iptables -i eth2 -A FORWARD --dst 176.9.41.253 -j ACCEPT
iptables -i eth2 -A FORWARD --src 176.9.41.253 -j ACCEPT
iptables -i eth2 -A FORWARD --dst 178.63.59.41 -j ACCEPT
iptables -i eth2 -A FORWARD --src 178.63.59.41 -j ACCEPT
iptables -i eth2 -A FORWARD --dst 37.120.169.214 -j ACCEPT
iptables -i eth2 -A FORWARD --src 37.120.169.214 -j ACCEPT
iptables -i eth2 -A FORWARD --dst 37.221.195.47 -j ACCEPT
iptables -i eth2 -A FORWARD --src 37.221.195.47 -j ACCEPT
iptables -i eth2 -A FORWARD --dst 78.46.68.75 -j ACCEPT
iptables -i eth2 -A FORWARD --src 78.46.68.75 -j ACCEPT
iptables -i eth2 -A FORWARD --dst 84.201.35.206 -j ACCEPT
iptables -i eth2 -A FORWARD --src 84.201.35.206 -j ACCEPT
iptables -i eth2 -A INPUT -j DROP
iptables -i eth2 -A FORWARD -j DROP
# eth2 darf maximal 2000 kbit/s ein- und ausgehenden traffic machen
wondershaper eth2 2000 2000

Prinzipiell könnte man den Traffic noch weiter einschränken. DHCP und DNS müssen nur zum DHCP- bzw. DNS-Server funktionieren und der Traffic zu den fastd-Servern ließe sich auf TCP Port 80 und UDP Port 10000 begrenzen.

===Alternative: Einsperren im VLAN===
siehe: [[FF-Router einsperren im VLAN]]

== Uplink mit Android-Tethering/USB Netzwerkkarte ==
(ssh Zugang Erfahrung nötig)

Das ganze sei von Anfang an als "sportlich" zu betrachten. Leider sind mobile 3g/LTE Tarife fast ausnahmslos nach einem bestimmten Volumen gedrosselt (üblicherweise auf 64 bis 56 kbit/s (neuere NetzclubSim sogar auf 32 kbit/s), Ausnahme bilden hier nur LTE Zuhause "DSL" Ersatz Tarife -> 386kbit/s).
Da Freifunk auch bei Nichtbenutzung Daten überträgt, ist nur bei LTE Zuhause Tarifen interessant dies als Dauerlösung zu nutzen. Dort ist aber wiederum meist ein LTE-Router vor Ort und man den Router auch "traditionell" via LAN Kabel anbinden.
Bei Benutzung als uplink bei Strassenfesten/Festivals etc. ist wahrscheinlich, dass erstens das Datenvolumen schnell aufgebraucht sein wird und zweitens ab einer bestimmten Größe auch das 3g Netz vor Ort überlastet ist. Wenn man es dennoch machen will (mehrere Sim Karten/spezieller hochvolumiger Tarif/Netzbetreiber gesponserter Uplink (träum)), sollte man die Benutzung von LTE erwägen. Auch dort könnten aber durch zukünftige Adapation Überlasterscheinungen auftreten. Desweitern nutzen 2g/3g/4g auch dasselbe Backbone, welcher dann auch für LTE ein Flaschenhals darstellt.
Muss nochmal nachprüfen, aber wenn, dann nicht uninteressant: Der Wlan Zugang des Telefons (CM7) wurde per tethering weitergeleitet und bei Abschalten gab es fallback auf 3g -> nicht schöne, aber einfache "Immer"netzlösung? Mein Tablet zeigt nicht dieses Verhalten.)

Blablabla, jetzt geht es los:
Das ganze habe ich mit einem 1043ND und einem droid 2.3CM7 Telefon und einem droid 2.2 Tablet ausprobiert, sollte aber auf jeglichen OpenWrt Router mit USB, Android USB tethering fähigem Gerät und einfachen USB ethernet Adaptern (nachprüfen!!!) funktionieren:

- Per ssh in den router einloggen
- Installieren der notwendigen Treiber

<pre>
opkg update
opkg install kmod-usb-uhci kmod-usb-net-rndis
</pre>

Dies sollte, falls ihr noch keine USB Unterstützung in der Firmware hat auch diese über dependencies nachinstallieren. (nachprüfen!!!)

- Ihr müsst den Netzwerkzugang für da neue Interface "usb0" noch konfigurieren. Unter /etc/config/network fügt ihr z.B. folgendes hinzu:

<pre>
config interface 'wan2'
option ifname 'usb0'
option proto 'dhcp'
option type 'bridge'
</pre>

Auch unter Luci sollte dies konfigurierbar sein.

- Nach einem Neustart und einem angeschlossenen Gerät sollte nun der Uplink via dem USB Netzwerk Gerät/Android tethering funktionieren.
- Sollte das Gerät erst später angeschlossen werden, so könnt ihr mit folgendem Befehl das Netzwerkgerät starten.

<pre>
ifup wan2
</pre>
(Dies ist noch nicht ein perfektes Tutorial, werde es nochmal durchprobieren. Einen UMTS Stick hatte ich auf Anhieb noch nicht zum laufen gebracht. Auch scheint Multiwan in OpenWRT eine interessante Sache)

== Zusätzlich zum Freifunk auch privates WLAN einrichten ==

Es ist möglich ein privates WLAN anzulegen, das mit dem WAN Port gebridged und separat zum Mesh Netzwerk ist. (Bitte beachten, dass Mesh on Wan nicht zeitgleich mit aktiviert werden sollte.)
Effekt: Das private WLAN wird erweitert, zeitgleich fungiert der Router als Freifunk-Router. Die Netze sind voneinander abgekoppelt.
Das private WLAN kann per SSH in der Konsole aktiviert werden:
<pre>
uci set wireless.wan_radio0=wifi-iface
uci set wireless.wan_radio0.device=radio0
uci set wireless.wan_radio0.network=wan
uci set wireless.wan_radio0.mode=ap
uci set wireless.wan_radio0.encryption=psk2
uci set wireless.wan_radio0.ssid="$SSID"
uci set wireless.wan_radio0.key="$KEY"
uci set wireless.wan_radio0.disabled=0
uci commit
wifi
</pre>
Bitte ersetze $SSID mit dem Namen deines Heimnetzwerks und $KEY mit deinem bisher üblichen Key (der vom privaten Router). Falls dein Router beide Frequenzbänder unterstützt(2.4 und 5 Ghz) und du in beiden auch privates WLAN aktivieren möchtest, muss dies für radio0 und radio1 mit übernommen werden.
Zum deaktivieren des Ganzen wie folgt vorgehen:
<pre>
uci set wireless.wan_radio0.disabled=1
uci commit
wifi
</pre>