Standorte/AFE
Allgemeines
AFE ist ein Backbone-Client Standort Am Fort Elisabeth 27 (FF Map) betrieben von rfelten. Der Standort ging Anfang November 2017 testweise Betrieb und verbindet sich zum Backbone am Standort Uniklink-Hochhaus. Erklärtes Hauptziel neben der Freude am Experimentieren ist die Bereitstellung von Uplink Kapazität eines vorhandenen 400/10 MBit/s Internetanschluss an den Backbone des Freifunk Mainz. Als Bonus könnte das Setup ggf. als fail-over Internetzugang fungieren, falls der lokale Zugang ausfällt.
Diese Seite soll das Setup dokumentieren (und im Idealfall zu eigenen Standorten inspirieren ;)
Konfiguration
Für das Verständnis der nachfolgenden Abschnitte ist die Lektüre des Backbone-Client Howto, insbesondere für die Rollen des BB-Clients und des Gluon-Routers sehr sinnvoll.
BB-Client
Aufgabe: Verbindung zum Backbone, "Ubiquiti Airmax" Technologie erforderlich (Proprietäres TDMA)
- Hardware: Ubiquiti NanoStation loco M5
- Config: 1:1 vom Backbone-Client Howto übernommen, jedoch
- IP: 10.37.3.106 (vgl.Backbone Netzplan). Verwaltung via ff-mwu.
- VLAN id: 11 (statt 100/114, wegen 841er, s.u.). Willkürlich gewählt, sollte jedoch nicht im eigenen Netz vorkommen.
Gluon Router
In der Laufe der Zeit wurde mit verschiedenen Hardwareplatformen für den Gluon-Router experimentiert. Ein initiales Setup mit einem WR841v9 wurde testweise eingesetzt war aber nicht leistungsfähig genug vom Durchsatz her. Es ist ziemlich ausführlich weiter unten beschrieben. Danach war ein paar Monate ein Futro im Einsatz. (Dessen Setup müsste noch dokumentiert werden *hust).
Im Sommer 2018 wurde ein Lenovo Laptop mit einem defekten Display gespendet, dieser dient jetzt als Host für Virtualbox welche u.A. einen Gluon-Router bereitstellt.
Setup 3: VirtualBox (aktiv)
Installation
tba
Konfiguration
Zunächst sollte man sicherstellen, das am Switch auch Port die VLANs 11 getaggt ("tagged") rauskommt:
Check auf dem VirtualBox host:
(VirtualBox) $ sudo tcpdump -n -i enp0s25 vlan -e 11:28:31.053517 5a:2e:17:06:ef:54 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 486: vlan 11, p 0, ethertype 0x4305, ^^ Batman traffic auf VLAN 11
Check in der VM, also auf dem Gluon-Router: Wir schauen auf unserem WAN Interface, also jenes welches in unser lokales Netzwerk führt, ob der Traffic aus VLAN 11 ankommt.
root@FFMZ-AFE-GWVM:~# # tcpdump -n -i eth1 vlan -e | grep "vlan 11" 11:28:31.636997 5a:2e:17:06:ef:54 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 118: vlan 11, p 0, ethertype 0x4305, ^^ Batman traffic auf VLAN 11
Laut der Dokumentation Chapter 6 kann es bei einigen NICs zu Problemen kommen, hier jedoch nicht ;)
Wir editieren auf dem Gluon-Router die Datei /etc/config/network und erzeugen auf unserem WAN Interface ein neues VLAN Interface mit Id 11 für den Batman Traffic:
root@FFMZ-AFE-GWVM:~# vi /etc/config/network
config interface 'mesh_vlan11' option auto '1' option ifname 'eth1.11' option macaddr '86:a0:d4:44:06:51' option proto 'gluon_mesh' option fixed_mtu '1' option transitive '1'
Danach starten wir das Netzwerk neu um die geänderte Konfiguration zu übernehmen:
root@FFMZ-AFE-GWVM:~# /etc/init.d/network restart
Wir verifizieren die direkten Nachbarn im BATMAN Netzwerk:
root@FFMZ-AFE-GWVM:/etc/config# cat /sys/kernel/debug/batman_adv/bat0/neighbors
[B.A.T.M.A.N. adv 2017.2, MainIF/MAC: primary0/4a:0c:3d:f3:61:43 (bat0 BATMAN_IV)]
IF Neighbor last-seen
mesh-vpn 02:00:0a:25:00:07 4.690s
eth1.11 5a:2e:17:06:ef:54 4.430s
Und schon meshen wir mit dem Backbone über das Interface eth1.11
Internet Uplink (aktiv)
Aufgabe: Backbone Traffic aus dem Backbone ableiten.
Ablauf: Mit der bisherigen Konfiguration können wir via den Backbone das Freifunk Netzwerk nutzen, wir wollen jedoch auch einen Uplink zum Internet bereitstellen.
Auf dem Hochhaus der Uniklink läuft ein Viprinet Multichannel Router, vgl. Uniklinik-Hochhaus Konfiguration. Um einen lokalen Internetzugang nutzen zu können, muss ein Interface des Multichannel Router eine lokale IP (z.b. 192.168.178.100) und die lokale Gateway IP (z.b. 192.168.178.1) per DHCP beziehen können. Die verschiedenen Uplinks auf der Uniklink per VLAN getrennt, diesem Standort wurde die id 65 zugeteilt. Aufgabe ist es nun, den Inhalt aus diesem VLAN 65 (d.h. die DHCP Requests des Viprinet Routers) auf das WAN-Port Interface des Gluon-Routers zu legen (d.h. die DHCP Requests tauchen im lokalen LAN auf).
Weil die VLAN id 65 jedoch zu hoch für unseren 841er ist, packen wir auf dem BB-Client (d.h. auf der Nanostation) um und zwar in das VLAN id 2, siehe Screenshot oben.
Zusätzliche Konfiguration auf dem 841: Neues VLAN mit der id 2 erzeugen (an allen Ports akzeptieren) ...
config switch_vlan
option device 'switch0'
option vlan '2'
option ports '0t 1t 2t 3t 4t'
... und das neue VLAN Interface (eth0.2) ins Interface wan bridgen:
config interface 'wan'
#option ifname 'eth1' # das hier auskommentieren
list ifname 'eth1' # stattdessen "list ifname ..." verwenden
list ifname 'eth0.2' # neues vlan interface
option multicast_querier '0'
option peerdns '0'
option auto '1'
option type 'bridge'
option proto 'dhcp'
option macaddr '0e:53:a1:94:26:60'
In dieser Konfiguration sollte der VipriNet Router bereits eine IP aus dem lokalen LAN erhalten haben. Um das zu prüfen pingen wir alle Kisten im LAN an und lassen uns dann die MAC Adressen geben:
$ nmap -sP 192.168.16.0/24 $ arp -a ... $? (192.168.16.153) at 00:18:ca:80:11:7c [ether] on enp0s25 ...
Dank der OUI Suche wissen wir, dass 00:18:CA zur 'Viprinet GmbH gehört.
Es läuft zwar, aber dieses Setup hat einen gravierenden Nachteil: Unser lokales LAN ist vollständig im VLAN 65 auf der Uniklinik sichtbar. Um Abhilfe zu erschaffen, sperren wir den Traffic des Multichannels Routers in ein eigenes VLAN und spendieren ihm einen seperaten DHCP Server. Es wird angenommen, dass das lokale LAN mit einem OpenWRT/Lede Router betrieben wird. (FritzBox User würden vermutlich einfach die WAN-Buchse des Gluon-Routers mit dem Gastnetzwerk der FritzBox.)
In LuCi lässt sich ein neue VLAN recht komfortabel zusammen klicken. Drei Dinge müssen neu angelegt werden:
- Neues VLAN: Wir verwenden die willkürlich eine VLAN id < 15 die lokal noch nicht verwendet wird: VLAN id 9. Diese machen wir tagged an CPU und LAN1 (an diesem Port hängt unser lokales LAN).
- Neues Interface: Wir erzeugen ein neues Interface mit den Namen ff_uplink auf eth0.9 und vergeben eine willkürlich vergebene IP Range z.B. 192.168.9.0/24 an dem unten auf der Seite aktivierten DHCP Server.
- Neues Forwarding: Im Tab Firewall erstellen wir eine neues Zone => Fowardings von ff_uplink auf wan, wählen 3x die Policy ACCEPT und setzen die checkbox bei Masquerading.
Test auf lokalem Rechner: (enp0s25 ist das lokale Interface, verbinden mit dem OpenWRT Router)
# ip link add link enp0s25 name enp0s25.9 type vlan id 9 # ip link set dev enp0s25.9 up # dhclient enp0s25.9
Das Interface enp0s25.9 sollte nun eine IP bekommen haben:
# ip addr show dev enp0s25.9
7: enp0s25.9@enp0s25: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether b8:ae:ed:79:1f:27 brd ff:ff:ff:ff:ff:ff
inet 192.168.9.186/24 brd 192.168.9.255 scope global enp0s25.9
...
und Wireshark sollte auch ne Menge Traffic anzeigen, da sich das neue Interface als default route eingeschummelt hat.
Wir beenden den Test mit:
# ip link set dev enp0s25.9 up
Auf der Seite des Gluon-Routers müssen wir nun den Traffic aus VLAN 2 (vormals VLAN 65 auf der Uniklinik), in das neue VLAN 9 packen und ins lokale LAN Richtung OpenWRT Router blasen. Konkreter: Wir erzeugen auf dem dem Gluon-Router ein neues Interface mit VLAN 9, jedoch auf dem WAN Port (eth1.9), bridgen es mit dem bestehenden Interface von VLAN 2 (eth0.2). Somit sollten die Pakete aus dem VLAN 2 ins VLAN 9 "umgepackt" werden. Im letzten Schritt holen wir eth0.2 aus dem wan Interface wieder raus:
1) Wir erstellen ein neues VLAN auf eth1 mit der id 9, eine IP Adresse ist nicht erforderlich (proto 'none'):
config interface 'vipri_local'
option ifname 'eth1.9'
option proto 'none'
2) Wir bridgen den Traffic aus VLAN 2 an den LAN Buchsen (eth0.2) ins das neue Interface und vice-versa:
confih interface 'vlan_repack'
list ifname 'eth0.2'
list ifname 'eth1.9'
option auto '1'
option type 'bridge'
3) Die Konfiguration von wan wird wieder zurückgebaut:
config interface 'wan'
option ifname 'eth1' # wieder "option ifname", ist na nur noch ein interface
#list ifname 'eth1' # auskommentieren / löschen
#list ifname 'eth0.2' # auskommentieren / löschen
option multicast_querier '0'
option peerdns '0'
option auto '1'
option type 'bridge'
option proto 'dhcp'
option macaddr '0e:53:a1:94:26:60'
Das wars. Sobald der VipriNet Multichannel Router sich eine neue IP aus unserer geänderten Range geholt hat, sollte der Traffic wieder fließen. Wir können uns das auf unserem OpenWRT Router mit tcpdump anschauen:
root@LEDE:~# tcpdump -e | grep "vlan 9" ...
Bewertung / Ausblick
841 zu lahm (gemessener durchsatz zu Uni ca 30MBit/s (Link kapazität ca. 104MBit/s) -> Futro Offloader -> Energieverbrauch ->VM- Aussenkabel durch UV-festes Kabel ersetzen
- Firewall regeln: Zugriffe auf FF Server whitelisten
Alte Konfigurationen
Setup 2: FUJITSU SIEMENS FUTRO S550 (Veraltet, nicht mehr aktiv)
todo: Setup + Config postmortem beschreiben
Setup 1: TP-Link WR841v9 (Veraltet, nicht mehr aktiv)
- Aufgabe: BATMAN Pakete verarbeiten
- Hardware: WR841v9
- Config: Siehe Backbone-Client Howto, jedoch leicht unterschiedliche Switch + VLAN Config, da der 841er nur VLAN IDs bis 15 unterstützt. Infos zur Nummerierung der LAN Ports (Gelbe Buchsen) siehe OpenWRT Wiki.
Alle LAN Ports raus aus dem VLAN 1 (=kein VLAN), nur die CPU an Port 0 bleibt drin:
config switch_vlan option device 'switch0' option vlan '1' option ports '0t'
Neues VLAN mit id 2 fürs FF Management LAN, akzeptieren an allen LAN Ports
#Freifunk Client MNGMT VLAN
config switch_vlan
option device 'switch0'
option vlan '3'
option ports '0t 1t 2t 3t 4t'
Neues VLAN mit id 11 für den Batman traffic ...
#Freifunk Batman Traffic von UM
config switch_vlan
option device 'switch0'
option vlan '11'
option ports '0t 1t 2t 3t 4t'
... und neues VLAN interface (eth0.11) ans Batman hängen:
config interface 'mesh_vlan11'
option auto '1'
option ifname 'eth0.11'
option mesh 'bat0'
option macaddr '86:a0:d4:44:06:58'
option mesh_no_rebroadcast '1' # !!! Nur bei Point-to-Point und Mesh-on-[LAN|WAN] aktivieren !!!
option proto 'batadv'
Client interface auf FF Management (aus VLAN id 3) beschränken (war vorher 'eth0'):
config interface 'client' option type 'bridge' option macaddr 'c4:e9:84:f3:14:6c' list ifname 'eth0.3' list ifname 'bat0' option proto 'dhcpv6' option reqprefix 'no' option robustness '3' option query_interval '2000' option query_response_interval '500' option peerdns '1' option sourcefilter '0'