Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Nächste Überarbeitung | Vorhergehende Überarbeitung | ||
technik:gateways:routing [20.09.2015 - 14:40] – angelegt lamdo | technik:gateways:routing [28.04.2019 - 11:38] (aktuell) – Externe Bearbeitung 127.0.0.1 | ||
---|---|---|---|
Zeile 3: | Zeile 3: | ||
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. | 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. | ||
+ | https:// | ||
===== Konfiguration ===== | ===== Konfiguration ===== | ||
- | ==== Einrichtung Tinc ==== | + | ==== Vorbereitung: |
- | Tinc, VLAN-Support | + | Tinc und bridge-utils installieren: |
< | < | ||
- | apt-get install tinc vlan bridge-utils | + | apt-get install tinc bridge-utils |
</ | </ | ||
Zeile 15: | Zeile 16: | ||
< | < | ||
cd /etc/tinc | cd /etc/tinc | ||
- | mkdir ffsVPN | + | mkdir ffsbb |
- | mkdir ffsVPN/hosts/ | + | mkdir ffsbb/hosts/ |
</ | </ | ||
- | Tinc-Konfigurationsdatei / | + | Tinc-Konfigurationsdatei |
< | < | ||
# IPv6 + IPv4 | # IPv6 + IPv4 | ||
Zeile 32: | Zeile 33: | ||
Mode = switch | Mode = switch | ||
- | name = gw10 | + | name = $HOST |
- | + | ||
- | # Kommentare ARE: | + | |
- | #Mode = switch | + | |
- | #Forwarding = off | + | |
- | # | + | |
- | #DirectOnly = yes | + | |
</ | </ | ||
- | In /etc/tinc/ffsVPN/hosts/ liegen die Schlüsseldateien der Tinc-GWs, z.B. /etc/tinc/ffsVPN/ | + | In '' |
+ | |||
+ | Die Schlüsseldatei generieren | ||
+ | < | ||
+ | tincd -n ffsbb -K 4096 | ||
+ | </ | ||
+ | und die Addresse ergänzen, z.B. '' | ||
< | < | ||
Cipher = blowfish | Cipher = blowfish | ||
Address = gw10.freifunk-stuttgart.de | Address = gw10.freifunk-stuttgart.de | ||
+ | Port = 11100 | ||
+ | PMTUDiscovery = yes | ||
+ | Digest = sha256 | ||
+ | ClampMSS = yes | ||
-----BEGIN RSA PUBLIC KEY----- | -----BEGIN RSA PUBLIC KEY----- | ||
MIICCgKCAgEA4G/ | MIICCgKCAgEA4G/ | ||
Zeile 61: | Zeile 65: | ||
</ | </ | ||
+ | Das tinc-Interface konfigurieren (''/ | ||
+ | < | ||
+ | allow-hotplug ffsbb | ||
+ | auto ffsbb | ||
+ | iface ffsbb inet static | ||
+ | tinc-net ffsbb | ||
+ | tinc-mlock yes | ||
+ | tinc-pidfile / | ||
+ | address 10.191.255.< | ||
+ | netmask 255.255.255.0 | ||
+ | broadcast 10.191.255.255 | ||
+ | post-up | ||
+ | pre-down | ||
+ | |||
+ | </ | ||
+ | |||
+ | Routing-Tabellen anlegen, dazu zwei Zeilen zu ''/ | ||
+ | < | ||
+ | 70 stuttgart | ||
+ | 71 nodefault | ||
+ | 42 icvpn | ||
+ | </ | ||
+ | |||
+ | ==== Einrichtung OSPF ==== | ||
+ | |||
+ | Quagga propagiert Routen grundsätzlich zwischen den Routing-Protokollen und der Kernel-Table '' | ||
+ | |||
+ | Installation: | ||
+ | < | ||
+ | apt-get install bird | ||
+ | </ | ||
+ | |||
+ | Die Konfiguration von bird erfolgt über den Generator https:// | ||
+ | < | ||
+ | router id 10.191.255.< | ||
+ | |||
+ | # Define a route filter... | ||
+ | filter ffs_filter { | ||
+ | if net ~ 172.21.0.0/ | ||
+ | if net ~ 10.190.0.0/ | ||
+ | else reject; | ||
+ | } | ||
+ | |||
+ | protocol kernel { | ||
+ | learn; | ||
+ | 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, | ||
+ | # Uplinks aus dem Weg zu gehen | ||
+ | import filter ffs_filter; | ||
+ | export filter ffs_filter; | ||
+ | |||
+ | area 0.0.0.0 { # Backbone-Area | ||
+ | external{ | ||
+ | 0.0.0.0/0; | ||
+ | }; | ||
+ | |||
+ | | ||
+ | cost 100; | ||
+ | hello 10; | ||
+ | poll 20; | ||
+ | retransmit | ||
+ | priority | ||
+ | wait 40; | ||
+ | type bcast; | ||
+ | authentication | ||
+ | password | ||
+ | }; | ||
+ | |||
+ | # | ||
+ | # cost 1000; | ||
+ | # stub yes; | ||
+ | # }; | ||
+ | # | ||
+ | # cost 1000; | ||
+ | # stub yes; | ||
+ | # }; | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | }; | ||
+ | }; | ||
+ | |||
+ | </ | ||
+ | |||
+ | ==== 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, | ||
+ | - 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, | ||
+ | Die von bird berechnete Route zum entfernten Netz wird mit Metric 100 in die Routing-Tabelle übernommen. |