Layer3Firmware: Unterschied zwischen den Versionen

Version vom 27. Mai 2019, 13:44 Uhr

Allgemeine Informationen

Wichtige Dateien

Hood file
/etc/hoodfile (Fabian, Adrian ab 2019)
/www/hood/keyxchangev2data (Adrian bis 2018)

Gatewaykonfiguration
/etc/config/gateway

Script configuregateway

Die Gatewayfirmware kann sehr einfach mithilfe des Skripts configuregateway auf Basis von Hood file und der Gatewaykonfiguration konfiguriert werden.

Das Script configuregateway wird nie automatisch ausgeführt. Entsprechend muss es nach Änderungen erneut ausgeführt werden, sowie nach Updates. (Es werden zwar die o. g. Dateien beim Upgrade kopiert, jedoch muss eben manuell configuregateway ausgeführt werden, um sie anzuwenden …)

Achtung: Unbekannte Einstellungen werden möglicherweise entfernt!

ULA und Wifi bezieht das Script aus der Hood file, den Rest aus der Gatewaykonfiguration.

Firmwarezweige

Die Gatewayfirmware wird aktuell größtenteils hier entwickelt:

https://github.com/fblaese/firmware/tree/l3-fbl
- Rebase auf aktuelle Firmware und aktuelle Entwicklung im l3-fbl Branch!
https://github.com/adrianschmutzler/fff-firmware/tree/mainline

Die beiden Firmwarezweige unterscheiden sich funktional wenig voneinander. Am besten immer den aktuellen Stand abfragen, was gerade wie zu installieren ist.

Download

Fertige Builds gibt es entsprechend den Tags aus dem o. g. Repository hier:

http://fw.sgstbr.de/gateway/

https://freifunk.jubt.org/fff-firmware.php (Variante gw_* wählen!)

Achtung: Die Imagedatei *.bin darf nicht länger als 64 Zeichen sein, sonst wird sie beim flashen nicht erkannt!

Typischer Ablauf einer Installation

Router flashen
Als Client mit dem Router per SSH verbinden oder aus dem Heimnetzwerk über die WAN-IP des Routers per SSH verbinden
WireGuard-Keypair generieren falls WireGuard verwendet wird (Schlüssel sichern!) oder sich für eine Richtfunkstrecke absprechen
Peering-Partner für WireGuard suchen, persönlich treffen und Schlüssel austauschen
Die Gatewaykonfiguration auf das Gerät kopieren (/etc/config/gateway)
Das Hoodfile auf das Gerät kopieren (/etc/hoodfile oder /www/hood/keyxchangev2data, siehe oben!)
Mit „configuregateway -c“ die Einstellungen aus der Gatewayconfig in die Openwrt Configs übernehmen.
Mit „configuregateway -t“ die Einstellungen testen, falls das Script nicht manuell abgebrochen wird, werden nach 200 Sekunden die Einstellungen zurück gesetzt
Falls der Router noch erreichbar ist, das Script beenden (STRG + C) falls man von der SSH Session heruntergeflogen ist, innerhalb 200 Sekunden erneut verbinden und das configuregateway-Script killen (z. B. mit „killall configuregateway“). Sollte man auf den Router nicht mehr drauf kommen, werden nach 200 Sekunden alle Einstellungen zurück gesetzt und man ist wieder im Ursprungszustand
Alle Einstellungen prüfen
Mit „configuregateway -a“ werden alle Einstellungen fest gespeichert, erst hiermit wird alles rebootfest geschrieben. Davor kann durch einen „reboot“ jederzeit der Urzustand wieder erreicht werden.

Peering-Partner

https://wiki.freifunk-franken.de/w/Portal:Layer3Peering

Für Redundanz sollten (mindestens) zwei Peerings eingestellt werden(zum Testen reicht eines aber völlig aus). Sinnvoll ist es auch, wenn nicht beide Peerings einfach per VPN-Tunnel laufen, sondern z. B. ein weiteres per Richtfunk; somit läuft das Netz auch weiter wenn der Internetanschluss ausfällt!

VPN-Tunnel via WireGuard

Wenn du über das Internet peeren willst, muss die Gegenseite WireGuard sprechen.

Es ist aktuell in der Firmware nicht möglich, aber man kann theoretisch auch andere Tunneltechnologien (z. B. GRE eignet sich sehr gut) für Babel verwenden.

Für WireGuard musst du dir einen Peering-Partner suchen – mit einem Menschen reden, ob er mit dir ein Peering eingehen will – und mit ihm deinen Public-Key austauschen. Mit diesem könnt ihr die VPN-Verbindung aufbauen.

Generieren der Keys für WireGuard

Ausführliche Anleitung: https://www.wireguard.com/quickstart/

Für WireGuard muss ein Keypair generiert werden. Am einfachsten macht man dies per SSH direkt am Gateway-Router:

wg genkey | tee privatekey | wg pubkey > publickey

Den privatekey in der gleichnamigen Datei trägst du in deine gatewayconfig ein. Den publickey teilst du deinem Peering-Partner mit.

Prinzipiell ist es möglich, pro Router jeweils ein Keypair zu generieren oder immer das gleiche Keypair für alle Gateways zu verwenden (mit größerem Risiko bei „Verlust“).

Es empfiehlt sich, den privatekey zu sichern, da man sonst vom Peering-Partner gehauen wird, wenn deswegen der Tunnel neu eingerichtet werden muss.

Per LAN Kabel/Richtfunk/Glasfaser

Es kann am Gateway Babel auch auf einen Ethernetport (wenn nötig auch VLAN-getagget) gelegt werden. Somit kann auch über Kabel gepeered werden. Natürlich kann das Peering auch über Richtfunk, Glasfaser oder sonstige Technologien (z. B. Internet-Exchange) realisiert werden.

Hood file

Das Hood File ist konzeptionell identisch zu der unter V2 verwendeten Datei.

Details zum Hood-File unter: Hood file

Benutzte IP-Adressbereiche eintragen!

IPv4: Portal:Netz

IPv6: Portal:Netz/IPv6

Babel Metrik

Siehe hier: Richtlinien für Babel Penalty bei dezentralen Hoods

configuregateway

Folgende Parameter können übergeben werden:

-c: Konfiguriert das Gateway mit uci. Kein commit, kein Anwenden der Einstellungen!
-t: Startet alle Dienste neu, damit werden die Einstellungen aus -c angewendet. Script wartet bis zu 200 Sekunden darauf, dass es beendet wird (Strg + C, wenn SSH nicht verloren geht, ansonsten „kill(all)“). Wird das Script in dieser Zeit nicht beendet, werden die Einstellungen zurückgesetzt und die Dienste erneut neu gestartet.
-a: Übernimmt die Änderungen (uci commit), startet Dienste neu.
-r: Macht die Änderungen rückgängig.

/etc/config/gateway

Benutzte IP-Adressbereiche eintragen:

IPv4: Portal:Netz

IPv6: Portal:Netz/IPv6

Beispielkonfiguration

Eine Bespielkonfiguration mit einem direkten Peer und einem WireGuardpeer gibt’s hier: https://gist.github.com/fblaese/ca4d903b20b4d7033553f48625b93ca6

Erklärung:

Port	VLAN	Ziel
P1	2	Intern
P2	3	BATMAN
P3	3	BATMAN
P4	1	Client
P5	1t, 101t	Client, Babel-Peeringnachbar

VLAN	Name	Ziel
1	Client	Geräte als Client anbinden
2	WAN	Internetverbindung, Babel zu FFF-GW via Wireguard
3	BATMAN	Versorgung von v2 Knoten
101	babel-neigh	VLAN zu Nachbargateway, Babel z.B. über Richtfunk

Achtung: Die VLAN-Einstellungen hier sind für den TL-WDR4900, für andere Geräte muss z. B. geprüft werden auf welchen Port der WAN liegt. Eine Liste ist ganz unten zu finden oder in der offiziellen Firmware: https://github.com/FreifunkFranken/firmware/tree/master/src/packages/fff/fff-network/ar71xx

VLAN-Konfiguration Firmware Adrian

In der obigen Beispieldatei müssen alle zu konfigurierenden VLANs mittels "config vlan" angegeben werden. Alle vorigen Einstellungen werden überschrieben.

In Adrians gw_* Firmware ab gw_20190525 wird die VLAN-Konfiguration abgewandelt:

Die bisherige Konfiguration bleibt erhalten, neue VLANs können mit folgenden Blöcke angelegt werden:

config add_vlan 
        option vlan '11' 
        option ports '0t 4'

Achtung: Meine Firmware erfordert die Angabe des CPU-Ports (hier 0t).

Soll ein VLAN geändert werden, sodass die alte VLAN-ID entfernt werden muss, kann folgender Block verwendet werden:

config del_vlan 
        option vlan '2'

Die bisherigen Blöcke 'config vlan' werden ignoriert. Möchte man die Standardkonfiguration verwenden, muss man demnach keine add_vlan/vlan-Blöcke verwenden.

Notwendig ist weiterhin die Verknüpfung eines VLAN oder Interfaces mit client bzw. batman; Beispiel client:

config client
        option vlan '1'

oder

config client
        option iface 'eth0'

Diese Blöcke sind für batman und client Pflicht. Für wan ist eine entsprechende Angabe nur notwendig, wenn die Verknüpfung geändert werden soll (z.B. VLAN 12 statt VLAN 2).

Achtung: Die Angabe der VLAN-ID als Verknüpfung (option vlan) ist nur möglich, wenn nur eines der beiden Interfaces mit tagged Ports konfiguriert ist. Ansonsten muss die option iface gewählt werden, z.B. Archer C7 v2:

config client
        option iface 'eth1.1' 

config batman
        option iface 'eth1.3'

# Diese Angabe erfolgt nur zur Erklärung.
# Da es sich um die Standardkonfiguration handelt,
# kann diese am Gerät entfallen
config wan
        option iface 'eth0.2'

Zur Zeit benutzen folgende Geräte per default tagged-Ports an mehreren ethX-Devices: Archer C7 v2, TL-WR1043ND v2/v3

gateway

Name	Typ	Pflicht	Variante	Beschreibung
name	string	nein	F
peer_ip	IPv4-Adresse	nein	F	IPv4-Adresse für Peerings
peer_ip6	IPv6-Adresse	nein	F	IPv6-Adresse für Peerings

vlan

Name	Typ	Pflicht	Variante	Beschreibung
comment	string	nein	F
port	list	nein	F	Ports auf dem Standard-Switch

add_vlan

Name	Typ	Pflicht	Variante	Beschreibung
vlan	int	ja	A	VLAN-ID
ports	list	ja	A	Ports inkl. CPU-Ports

del_vlan

Name	Typ	Pflicht	Variante	Beschreibung
vlan	int	ja	A	VLAN-ID

client

Name	Typ	Pflicht	Variante	Beschreibung
iface	interface	nein	F/A	Clientnetz auf Interface legen (z.B. eth0, eth0.1)
vlan	int	nein	F/A	Clientnetz auf VLAN mit angegebener IP auf dem Standard-Switch* legen *(alternativ zu iface!)*
ipaddr	IPv4-Adresse	nein	F/A	Router-IP im Client-Netz (CIDR Notation)
ip6addr	IPv6-Adresse	nein	F/A	Router-IP im Client-Netz (CIDR Notation)**
dhcp_start	IPv4-Adresse	nein	F/A	DHCP-Startadresse
dhcp_limit	int	nein	F/A	Maximale Anzahl an DHCP-Leases (default 150)

* Bei Adrian: Nur verwenden, wenn maximal EIN ethX mit tagged VLANs vorhanden ist!

** Zum Beispiel 2001:DB8:aaaa:bbbb::1/64, wobei 2001:DB8: und aaaa den du beim reservieren erhältst und bbbb der selbst festgelegte Teil (damit es zu einen /64 wird), mit dem Du die jeweiligen Netze der dezentralen Gateways unterscheidest. Im Monitoring wird die Adresse dann unter 2001:DB8:ffff:ffff:ffff:ffff:ffff:ff01 versteckt.

dns

Name	Typ	Pflicht	Variante	Beschreibung
server	list	nein	F/A	DNS-Server, auf den geforwarded wird*

* Hinweis: Hier sollten auch IPv6-DNS-Server aufgelistet werden.

batman

Name	Typ	Pflicht	Variante	Beschreibung
iface	interface	nein	F/A	B.A.T.M.A.N. auf physikalisches auf Interface legen
vlan	int	nein	F/A	B.A.T.M.A.N. auf VLAN mit angegebener IP auf dem Standard-Switch* legen *(alternativ zu iface!)*

* Bei Adrian: Nur verwenden, wenn maximal EIN ethX mit tagged VLANs vorhanden ist!

wan

Name	Typ	Pflicht	Variante	Beschreibung
iface	interface	nein	A	WAN auf physikalisches auf Interface legen
vlan	int	nein	A	WAN auf VLAN mit angegebener IP auf dem Standard-Switch* legen *(alternativ zu iface!)*

* Bei Adrian: Nur verwenden, wenn maximal EIN ethX mit tagged VLANs vorhanden ist!

babelpeer

Name	Type	Required	Beschreibung
iface	interface	no	Babel auf physikalisches Interface legen
vlan	number	no	Babel auf VLAN mit angegebener IP auf dem Standard-Switch legen *(alternativ zu iface!)*
type	babel-type	no	Babel-Verbindungstyp (z. B. wired, wireless, tunnel …)
rxcost	number	no	Babel rxcost

wireguardpeer

Name	Type	Required	Beschreibung
endpoint_host	host oder ip	yes
endpoint_port	port	yes
persistent_keepalive	seconds	no
public_key	wireguard pubkey	yes
private_key	wireguard privkey	no	automatically generated if unspecified
rxcost	number	no	Babel rxcost

Hardware-Port-Belegungen

Die Switch-Port-Belegung für die gängigen und genutzten Router für die VLAN-Konfiguration.

TP-Link WDR4900 v1

Port	Switch Port
WAN	1
LAN 1	2
LAN 2	3
LAN 3	4
LAN 4	5

TP-Link WR1043ND v1

Port	Switch Port
WAN	0
LAN 1	1
LAN 2	2
LAN 3	3
LAN 4	4

TP-Link WR1043ND v2, v3, v4

Port	Switch Port
WAN	5
LAN 1	4
LAN 2	3
LAN 3	2
LAN 4	1
CPU	0

Leistungstests

Gerät	System-on-a-Chip (SoC)	CPU [MHz]	WireGuard [Mbit/s]	Routing [Mbit/s]
TP-Link Archer C2600	Qualcomm Atheros IPQ8064	2 × 1400	140–170	unbekannt
TP-Link Archer C7 v2	Qualcomm Atheros QCA9558	720	ca. 50	unbekannt
TP-Link TL-WDR4300 v1	Atheros AR9344	560	ca. 55	unbekannt
TP-Link TL-WDR4900 v1	Freescale MPC85xx	800	95–110	650–700
TP-Link TL-WR1043N/ND v1	Atheros AR9132	400	40–46	150–200
TP-Link TL-WR1043N/ND v2&3	Qualcomm Atheros QCA9558	720	ca. 50	unbekannt
TP-Link TL-WR1043N/ND v4	Qualcomm Atheros QCA9563	750	ca. 80	unbekannt
Ubiquiti EdgeRouter X			~200	800–930

Version vom 27. Mai 2019, 13:44 Uhr (Quelltext anzeigen) Adrian Schmutzler (Diskussion \| Beiträge) (→‎batman) ← Zum vorherigen Versionsunterschied		Version vom 27. Mai 2019, 13:44 Uhr (Quelltext anzeigen) Adrian Schmutzler (Diskussion \| Beiträge) (→‎batman) Zum nächsten Versionsunterschied →
Zeile 331:		Zeile 331:

	<nowiki>*</nowiki> Bei Adrian: Nur verwenden, wenn maximal EIN ethX mit tagged VLANs vorhanden ist!		<nowiki>*</nowiki> Bei Adrian: Nur verwenden, wenn maximal EIN ethX mit tagged VLANs vorhanden ist!


	==== wan ====		==== wan ====