Standorte/AFE: Unterschied zwischen den Versionen

Version vom 8. November 2017, 10:01 Uhr

ACHTUNG: Diese Seite befindet sich im Aufbau. Aus Sicherheitsgesichtspunkten ist das beschriebene Setup nicht empfehlenswert!

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/30 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

BB-Client

VLAN Konfiguration des BB-Clients (Nanostation). VLAN65/2 bzw. Viprinet Config siehe unten.

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)
- VLAN id: 11 (statt 100/114, wegen 841er, s.u.)

Gluon Router

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'

Internet Uplink

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.

Die VLAN Konfiguration in LuCi: Ein neues VLAN mit der id 9 wird erstellt und die CPU und der erste LAN Port, an dem sich das LAN befindet, zugeordnet. Tagged bedeutet, dass die Pakete beim Verlassen des Routers ihren VLAN tag behalten.

Die Interface Konfiguration in LuCi: Ein neues Interface auf dem VLAN 9 wird erstellt und ein DHCP Server (nicht im Bild) darauf gestartet.

Die Firewall Konfiguration in LuCi: Traffic aus dem VLAN 9 wird ins WAN geNATed.

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
Aussenkabel durch UV festes ersetzen
Firewall regeln: Zugriffe auf FF server whitelisten