Dynamisches Routing zwischen den Segmenten (Work in progress!)
Um nicht auf jedem Gateway zwingend alle Segmente als L2 vorhalten zu müssen, ist ein L3-Routing zwischen den Segmenten erforderlich. Da statische Routen schlecht skalieren, kommt OSPF als Routing-Protokoll zum Einsatz. Die L3-Verbindung erfolgt über ein Tinc-VPN.
Konfiguration
Vorbereitung: Einrichtung Tinc
Tinc und bridge-utils installieren:
apt-get install tinc bridge-utils
Tinc konfigurieren:
cd /etc/tinc mkdir ffsbb mkdir ffsbb/hosts/
Tinc-Konfigurationsdatei /etc/tinc/ffsVPN/tinc.conf anlegen:
# IPv6 + IPv4 AddressFamily = any # Tinc nur über das öffentliche Netz laufen lassen BindToInterface = eth0 Broadcast = mst ConnectTo = gw02 # Hier sollten alle aktuell verfügbaren GWs stehen Mode = switch name = $HOST
In /etc/tinc/ffsbb/hosts/ liegen die Schlüsseldateien der Tinc-GWs.
Die Schlüsseldatei generieren
tincd -n ffsbb -K 4096
und die Addresse ergänzen, z.B. /etc/tinc/ffsbb/hosts/gw10:
Cipher = blowfish Address = gw10.freifunk-stuttgart.de Port = 11100 PMTUDiscovery = yes Digest = sha256 ClampMSS = yes -----BEGIN RSA PUBLIC KEY----- MIICCgKCAgEA4G/ek8KZuHFZPVuNK5HsQvCPAe/lhzYp2ERqVUWa1jHnnG/5fk1E IgicXfVdJV/2j8OGrrKhpZRMfzgXCZtq639fJb7XmB9ZF3OF9I8pceIWGt8E1M5j TUYfyQKrQBj1itz2sn4RqJJJDaXpMFIu3swSJ6stLMumq2MYRxS4BciLwGBrkSaH vVP5Xufd5GG6ZnTBN+8eqnLV4chw2yTsf+Wk1rSA9wZnI0tDH6nkHrKg5H6HRzWB 1/fb/Rt38waSuc+7Kx0eH2CJX8dzMeiB64kR38dKMiwkb84rdtkGthY8oWG3057o EZPzdMOUs2Qnvw1Bol/SWsXU0Qg/fntcbKdgi6PZjdTbHvjoZE+l1OMGGAkf9Ost 7GzM4pC2Pu1mLUHFXlZ7RW6SBLaKX5/tAfTPkLbYsVFPgygpGRSRpGkMZJqgMWMA Lch+imiegXg2TewUrSqauxTxGaN32y+3XdmX914RDx7IlCr/fpmknljcAaAYgy+g w0TWrgxhq8nXoJJ68FL8aPDvPpK6mPnS3YtCRkuaf0AsZonaUBGiQFIT1jtgv8Fv YpY1ve/xyyPj57RepkDAFHa6aUmpR5IcOQ6MXnG+j+CNlwiY9WCWHxmtYUaL7dxR Fdqgnmax0IyY00/IHgMjOq0PS7rfz1ANmg6ubVEZbjIwZmziIbg8cXkCAwEAAQ== -----END RSA PUBLIC KEY-----
Das tinc-Interface konfigurieren (/etc/network/interfaces.d/ffsbb):
allow-hotplug ffsbb
auto ffsbb
iface ffsbb inet static
tinc-net ffsbb
tinc-mlock yes
tinc-pidfile /var/run/tinc.ffsbb.pid
address 10.191.255.<gwnum>/24 # Z.B. 10.191.255.10
netmask 255.255.255.0
broadcast 10.191.255.255
post-up /sbin/ip rule add iif $IFACE table stuttgart priority 7000 || true
pre-down /sbin/ip rule del iif $IFACE table stuttgart priority 7000 || true
Routing-Tabellen anlegen, dazu zwei Zeilen zu /etc/iproute2/rt_tables hinzufügen:
70 stuttgart 71 nodefault 42 icvpn
Einrichtung OSPF
Quagga propagiert Routen grundsätzlich zwischen den Routing-Protokollen und der Kernel-Table main, was für ffs ungeeignet ist. BIRD spricht ebenfalls die relevanten Routing-Protokolle OSPFv[23] und BGP, läßt aber eine Konfiguration der Ziel-Routing-Tabelle zu.
Installation:
apt-get install bird
Die Konfiguration von bird erfolgt über den Generator https://github.com/freifunk-stuttgart/FfsConfigGenerator, hier nur exemplarisch:
router id 10.191.255.<gw>; # z.B. 10.191.255.10
# Define a route filter...
filter ffs_filter {
if net ~ 172.21.0.0/16 then accept;
if net ~ 10.190.0.0/15 then accept;
else reject;
}
protocol kernel {
learn; # Learn all alien routes from the kernel
persist no;
scan time 20; # Scan kernel routing table every 20 seconds
export all; # Default is export none
import all;
kernel table 70; # Kernel table to synchronize with (default: main)
export filter { # Propagate routes with low metric into kernel table
krt_metric = 100;
accept;
};
}
# This pseudo-protocol watches all interface up/down events.
protocol device {
scan time 10; # Scan interfaces every 10 seconds
}
protocol ospf ffsBackbone {
preference 100;
rfc1583compat no; # Metrik gem. OSPFv2, RFC 2328
stub router no; # Box macht ggf. auch Transit-Traffic
tick 1; # Topologie-Berechnungen nur alle 1s
ecmp no; # Kein Equal-Cost-Multipath, um Problemen mit unterschiedlichen
# Uplinks aus dem Weg zu gehen
import filter ffs_filter; # filtert alle andern IPs
export filter ffs_filter; # filtert alle andern IPs
area 0.0.0.0 { # Backbone-Area
external{
0.0.0.0/0;
};
interface "ffsbb" { # Run OSPF over VPN
cost 100;
hello 10;
poll 20;
retransmit 5;
priority 10;
wait 40;
type bcast;
authentication cryptographic;
password "ffsVPN00";
};
# interface "br*" { # Don't run OSPF over interface, but propagate networks
# cost 1000;
# stub yes;
# };
# interface "ffs-br" { # Don't run OSPF over interface, but propagate networks
# cost 1000;
# stub yes;
# };
stubnet 172.21.28.0/22; # eigener DHCP Range Segment 0
stubnet 10.190.48.0/21; # eigener DHCP Range Segment 1
stubnet 10.190.112.0/21; # eigener DHCP Range Segment 2
stubnet 10.190.176.0/21; # eigener DHCP Range Segment 3
stubnet 10.190.240.0/21; # eigener DHCP Range Segment 4
};
};
Wie funktioniert das ganze?
Über das VPN bauen die bird-Instanzen OSPF-Adjacencies auf und tauschen darüber Informationen über die bekannten Netze aus. Jede OSPF-Instanz berechnet dann für sich, wie dieses Netz am besten erreicht werden kann. Da OSPF ein Link-State-Protokoll ist und alle Instanzen die gleichen Informationen haben und den gleichen Algorithmus verwenden, kommt es dabei auch nicht zu Loops.
Bird ist so konfiguriert, dass es zwei Arten von Routen propagiert:
- Statische Kernel-Routen in der stuttgart-Tabelle. Hierüber können andere Gateways den lokalen Uplink (egal, ob per VPN oder über lokale Ausleitung realisiert) nutzen, ohne dass das auf den anderen GWs konfiguriert werden muss.
- Lokal auf den Interfaces br* konfigurierte Netze. Hierüber werden die am lokalen GW vorhandenen Segmente netzweit propagiert
OSPF unterstützt prinzipiell Equal-Cost-Multipath, d.h. wenn ein Netz über mehrere Wege zu gleichen Kosten erreicht werden kann, kann ein Load-Balancing über diese Pfade erfolgen. Das ist hier aber deaktiviert, da am Uplink NAT erfolgt und daher keine echte Ende-zu-Ende-Verbindung zwischen FFS-Client und einem Ziel im Internet besteht. Würden hier unterschiedliche Pfade über unterschiedliche NAT-Boxen zum Einsatz kommen, kann es zu Problemen kommen.
Die von bird berechnete Route zum entfernten Netz wird mit Metric 100 in die Routing-Tabelle übernommen.