Netzwerk/Super-Node Backbone Anbindung: Unterschied zwischen den Versionen
Takt (Diskussion | Beiträge) |
|||
| (50 dazwischenliegende Versionen von 4 Benutzern werden nicht angezeigt) | |||
| Zeile 1: | Zeile 1: | ||
Dieser Artikel erläutert, wie eine [[Super-Node]] an den [[Backbone]] des Freifunk Rheinland angeschlossen werden kann. | |||
Dieser Artikel | |||
== | == Netzwerkdiagram == | ||
[https://forum.freifunk-rheinland.net/uploads/default/170/326136dea60dc3de.png Im Forum, Stand 4.10.2014] | |||
== tinc == | |||
Die Super-Nodes und die Router bilden ein vermaschtes VPN (Layer 2) per tinc. | |||
Zuerst das Paket tinc installieren. | |||
# pacman -S tinc | |||
Das Verzeichnis für die Backbone-Konfiguration und die Schlüssel anlegen. Der Name dieser Instanz lautet: ''rheinland''. | |||
# mkdir -p /etc/tinc/rheinland/hosts | |||
Die tinc-Konfiguration für tinc ablegen. Hier das externe Interface des Servers unter $INTERFACE und den Hostnamen unter $HOSTNAME eintragen. | |||
# > /etc/tinc/rheinland/tinc.conf | |||
AddressFamily ipv4 | |||
BindToInterface $INTERFACE | |||
Broadcast direct | |||
DeviceType tap | |||
DirectOnly yes | |||
Forwarding off | |||
HostNames no | |||
Interface bb0 | |||
Mode switch | |||
Name $HOSTNAME | |||
PingInterval 15 | |||
PingTimeout 5 | |||
PrivateKeyFile /etc/tinc/rsa_key.priv | |||
ConnectTo = rheinland0 | |||
ConnectTo = rheinland1 | |||
Debug 3 | |||
Dann eine Datei mit Adresse und Schlüssel des einen Routers anlegen. | |||
# > /etc/tinc/rheinland/hosts/rheinland0 | |||
Address=78.47.35.139 | |||
-----BEGIN RSA PUBLIC KEY----- | |||
MIIBCgKCAQEA2xz9NGY9XUkrsciIZ5AucrtGnlXcD257/jYDyyCVLDNuS16cA3vF | |||
bsH5Br3zjYRsN+AZjvgUbfCyrM4qxWBoSTmcFOH5uQLt0RD+p8dpq/p/9B0vRMI2 | |||
eGLK6C+2EylLEui9lrwpXF27530uIlXxORsjEgGjgJMegkTQoU/yFpt8kXr0N+Zg | |||
sCdLyVByzS6FqmZOuFJiNTC/IggkRHqqKLoj9Kp4L/qqdTCeszWVtkNQpljXhiEq | |||
4OR9nreH+icns+GrvWAqhMUyVTJrOr1nPDgFT5FytGjmudN/tSpp7PE4OZbvpIg/ | |||
ZxMfmKM7Qs/+xPLry7SB7NJzJSJVOR6fDQIDAQAB | |||
-----END RSA PUBLIC KEY----- | |||
Und noch eine Datei mit Adresse und Schlüssel des anderen Routers. | |||
# > /etc/tinc/rheinland/hosts/rheinland1 | |||
Address=78.47.35.141 | |||
-----BEGIN RSA PUBLIC KEY----- | |||
MIIBCgKCAQEAxaewx1cZPPjeRLomoO2z0GN/Lioc0bwEoM9cB++lzqfhfEbNLDbU | |||
hMkn2Q/2uR51h2ZJ5tgUcU1wCa2lrPXVO8e8oZo7RTJi+rYJyDtosC2W693GtLxK | |||
GYDQOyPmrcc55X4j0UeyFNP2dKH8qmRH2cs2VM1sJslKOGheJVSXxo2xBQy2EiQw | |||
AMITubAW6NaG/tB5hwehyvcp11B/EXuWl1UByEi3R8TCQPPyyuyhmVswnSUZzbsU | |||
UMkazbrbaK322DmuHT8txn4DK6/DLSz0MzPwe0AGB8ReQA5wKS2JgnRmZ0HKLJ9K | |||
awnBNLV2ate25FZuvjHkD6yyjQcCsoryMwIDAQAB | |||
-----END RSA PUBLIC KEY----- | |||
Ein Skript zum Setzen der Adressen beim Start des VPN anlegen.. Bitte $SUFFIX durch das Suffix der Super-Node ersetzen (z.B. ''13'' für Rheinufer). | |||
# > /etc/tinc/rheinland/tinc-up | |||
#/bin/sh | |||
ip link set up dev $INTERFACE | |||
ip -4 addr add 10.78.0.$SUFFIX/22 dev $INTERFACE | |||
ip -6 addr add 2001:470:72da:$SUFFIX::1/64 dev $INTERFACE | |||
ip -6 addr add 2001:470:7861:$SUFFIX::1/64 dev $INTERFACE | |||
Das Skript ausführbar machen | |||
# chmod +x /etc/tinc/rheinland/tinc-up | |||
Ein Paar aus öffentlichem und privaten Schlüssel erzeugen. Wir nehmen die Standardlänge von 2048 bit und den vorgeschlagenen Pfad zu den Dateien (/etc/tinc/rsa_key.priv und /etc/tinc/rsa_key.pub). | |||
# tincd -K | |||
Den public keys des Hosts linken (hier wieder $HOSTNAME durch den Hostnamen ersetzen). | |||
# ln -s /etc/tinc/rsa_key.pub /etc/tinc/rheinland/hosts/$HOSTNAME | |||
Der öffentliche Schlüssel soll auf der Wiki-Seite der Super-Node dokumentiert und den Admins der Router mitgeteilt werden. Wenn die Admins den Schlüssel eingetragen haben, tincd aktivieren und starten. | |||
# systemctl enable tincd@rheinland | |||
# systemctl start tincd@rheinland | |||
== Adressierung der Supernodes im Backbone == | == Adressierung der Supernodes im Backbone == | ||
== Konfiguration von | === IPv6 === | ||
[http://en.wikipedia.org/wiki/IPv6_stateless_address_autoconfiguration SLAAC] ist zu verwenden. | |||
=== Legacy IP (IPv4) === | |||
Der Adressbereich 10.78.0.0/22 ist für den Backbone reserviert. | |||
Adressen sind [[Netzwerk/Backbone Adressierung | hier]] zu verwalten. | |||
== Routing == | |||
Innerhalb des Backbones wird das Routing-Protokoll [http://en.wikipedia.org/wiki/Open_Shortest_Path_First OSPF] verwendet. So werden die Subnetze automatisch verteilt. | |||
Als Routing-Dienst kommt derzeit Quagga zum Einsatz. Die Konfigurationen für IPv4 und IPv6 finden getrennt statt. Quagga ist in den Paketsammlungen der üblichen Linux Distributionen bereits enthalten. | |||
# pacman -S quagga | |||
=== zebra === | |||
zebra synchronisiert die Routing-Tabellen des Kernels. Dazu benötigen wir nur eine minimale Konfiguration. Hier $HOSTNAME durch den Hostname ersetzen: | |||
# > /etc/quagga/zebra.conf | |||
hostname $HOSTNAME-zebra | |||
password zebra | |||
ip forwarding | |||
ipv6 forwarding | |||
line vty | |||
Es wird lediglich ein Hostname sowie ein Passwort für die Zebra Shell gesetzt und IP Forwarding aktiviert. Mittels <tt>telnet 127.0.0.1 2601</tt> kann zebra auch interaktiv konfiguriert werden. Die Konfiguration ähnelt der von Routern mit Cisco IOS. | |||
Den Dienst aktivieren und starten | |||
# systemctl enable zebra | |||
# systemctl start zebra | |||
=== ospf6d === | |||
ospf6d teilt zebra die Routing-Tabellen für IPv6 mit. Folgende Konfiguration verwendet für die Routing-Map das Interface br0, auf dem das Freifunk-Netzwerk liegt. Bei $HOSTNAME kommt wieder der hostname hinein: | |||
# > /etc/quagga/ospf6d.conf | |||
hostname $HOSTNAME-ospf6d | |||
password ospf6d | |||
interface bb0 | |||
ipv6 ospf6 hello-interval 1 | |||
ipv6 ospf6 dead-interval 4 | |||
router ospf6 | |||
redistribute connected | |||
interface bb0 area 0.0.0.0 | |||
interface br0 area 1.0.0.0 | |||
line vty | |||
log syslog | |||
Den Dienst aktivieren und starten | |||
# systemctl enable ospf6d | |||
# systemctl start ospf6d | |||
=== ospfd === | |||
IPv4-Routing wird per ospfd (analog zum ospf6d) konfiguriert. Hier $NETWORK durch das IP-Netz der Domäne (und wieder $HOSTNAME durch den Hostnamen) ersetzen. | |||
# > /etc/quagga/ospfd.conf | |||
hostname $HOSTNAME-ospf | |||
password ospfd | |||
interface bb0 | |||
ip ospf hello-interval 1 | |||
ip ospf dead-interval 4 | |||
router ospf | |||
auto-cost reference-bandwidth 100000 | |||
passive-interface default | |||
no passive-interface bb0 | |||
network 10.78.0.0/22 area 0.0.0.0 | |||
network $NETWORK area 0.0.0.0 | |||
line vty | |||
Den Dienst aktivieren und starten | |||
# systemctl enable ospfd | |||
# systemctl start ospfd | |||
So werden beide Tunnel-Interfaces zu unseren Netzwerken für OSPF verwendet. Ankündigungen für Routen werden jedoch nur ins Backbone-Netz geschickt, nicht über ein anderes Interface. | |||
Aktuelle Version vom 5. Oktober 2014, 16:26 Uhr
Dieser Artikel erläutert, wie eine Super-Node an den Backbone des Freifunk Rheinland angeschlossen werden kann.
Netzwerkdiagram
tinc
Die Super-Nodes und die Router bilden ein vermaschtes VPN (Layer 2) per tinc.
Zuerst das Paket tinc installieren.
# pacman -S tinc
Das Verzeichnis für die Backbone-Konfiguration und die Schlüssel anlegen. Der Name dieser Instanz lautet: rheinland.
# mkdir -p /etc/tinc/rheinland/hosts
Die tinc-Konfiguration für tinc ablegen. Hier das externe Interface des Servers unter $INTERFACE und den Hostnamen unter $HOSTNAME eintragen.
# > /etc/tinc/rheinland/tinc.conf AddressFamily ipv4 BindToInterface $INTERFACE Broadcast direct DeviceType tap DirectOnly yes Forwarding off HostNames no Interface bb0 Mode switch Name $HOSTNAME PingInterval 15 PingTimeout 5 PrivateKeyFile /etc/tinc/rsa_key.priv ConnectTo = rheinland0 ConnectTo = rheinland1 Debug 3
Dann eine Datei mit Adresse und Schlüssel des einen Routers anlegen.
# > /etc/tinc/rheinland/hosts/rheinland0 Address=78.47.35.139 -----BEGIN RSA PUBLIC KEY----- MIIBCgKCAQEA2xz9NGY9XUkrsciIZ5AucrtGnlXcD257/jYDyyCVLDNuS16cA3vF bsH5Br3zjYRsN+AZjvgUbfCyrM4qxWBoSTmcFOH5uQLt0RD+p8dpq/p/9B0vRMI2 eGLK6C+2EylLEui9lrwpXF27530uIlXxORsjEgGjgJMegkTQoU/yFpt8kXr0N+Zg sCdLyVByzS6FqmZOuFJiNTC/IggkRHqqKLoj9Kp4L/qqdTCeszWVtkNQpljXhiEq 4OR9nreH+icns+GrvWAqhMUyVTJrOr1nPDgFT5FytGjmudN/tSpp7PE4OZbvpIg/ ZxMfmKM7Qs/+xPLry7SB7NJzJSJVOR6fDQIDAQAB -----END RSA PUBLIC KEY-----
Und noch eine Datei mit Adresse und Schlüssel des anderen Routers.
# > /etc/tinc/rheinland/hosts/rheinland1 Address=78.47.35.141 -----BEGIN RSA PUBLIC KEY----- MIIBCgKCAQEAxaewx1cZPPjeRLomoO2z0GN/Lioc0bwEoM9cB++lzqfhfEbNLDbU hMkn2Q/2uR51h2ZJ5tgUcU1wCa2lrPXVO8e8oZo7RTJi+rYJyDtosC2W693GtLxK GYDQOyPmrcc55X4j0UeyFNP2dKH8qmRH2cs2VM1sJslKOGheJVSXxo2xBQy2EiQw AMITubAW6NaG/tB5hwehyvcp11B/EXuWl1UByEi3R8TCQPPyyuyhmVswnSUZzbsU UMkazbrbaK322DmuHT8txn4DK6/DLSz0MzPwe0AGB8ReQA5wKS2JgnRmZ0HKLJ9K awnBNLV2ate25FZuvjHkD6yyjQcCsoryMwIDAQAB -----END RSA PUBLIC KEY-----
Ein Skript zum Setzen der Adressen beim Start des VPN anlegen.. Bitte $SUFFIX durch das Suffix der Super-Node ersetzen (z.B. 13 für Rheinufer).
# > /etc/tinc/rheinland/tinc-up #/bin/sh ip link set up dev $INTERFACE ip -4 addr add 10.78.0.$SUFFIX/22 dev $INTERFACE ip -6 addr add 2001:470:72da:$SUFFIX::1/64 dev $INTERFACE ip -6 addr add 2001:470:7861:$SUFFIX::1/64 dev $INTERFACE
Das Skript ausführbar machen
# chmod +x /etc/tinc/rheinland/tinc-up
Ein Paar aus öffentlichem und privaten Schlüssel erzeugen. Wir nehmen die Standardlänge von 2048 bit und den vorgeschlagenen Pfad zu den Dateien (/etc/tinc/rsa_key.priv und /etc/tinc/rsa_key.pub).
# tincd -K
Den public keys des Hosts linken (hier wieder $HOSTNAME durch den Hostnamen ersetzen).
# ln -s /etc/tinc/rsa_key.pub /etc/tinc/rheinland/hosts/$HOSTNAME
Der öffentliche Schlüssel soll auf der Wiki-Seite der Super-Node dokumentiert und den Admins der Router mitgeteilt werden. Wenn die Admins den Schlüssel eingetragen haben, tincd aktivieren und starten.
# systemctl enable tincd@rheinland # systemctl start tincd@rheinland
Adressierung der Supernodes im Backbone
IPv6
SLAAC ist zu verwenden.
Legacy IP (IPv4)
Der Adressbereich 10.78.0.0/22 ist für den Backbone reserviert. Adressen sind hier zu verwalten.
Routing
Innerhalb des Backbones wird das Routing-Protokoll OSPF verwendet. So werden die Subnetze automatisch verteilt.
Als Routing-Dienst kommt derzeit Quagga zum Einsatz. Die Konfigurationen für IPv4 und IPv6 finden getrennt statt. Quagga ist in den Paketsammlungen der üblichen Linux Distributionen bereits enthalten.
# pacman -S quagga
zebra
zebra synchronisiert die Routing-Tabellen des Kernels. Dazu benötigen wir nur eine minimale Konfiguration. Hier $HOSTNAME durch den Hostname ersetzen:
# > /etc/quagga/zebra.conf hostname $HOSTNAME-zebra password zebra ip forwarding ipv6 forwarding line vty
Es wird lediglich ein Hostname sowie ein Passwort für die Zebra Shell gesetzt und IP Forwarding aktiviert. Mittels telnet 127.0.0.1 2601 kann zebra auch interaktiv konfiguriert werden. Die Konfiguration ähnelt der von Routern mit Cisco IOS.
Den Dienst aktivieren und starten
# systemctl enable zebra # systemctl start zebra
ospf6d
ospf6d teilt zebra die Routing-Tabellen für IPv6 mit. Folgende Konfiguration verwendet für die Routing-Map das Interface br0, auf dem das Freifunk-Netzwerk liegt. Bei $HOSTNAME kommt wieder der hostname hinein:
# > /etc/quagga/ospf6d.conf hostname $HOSTNAME-ospf6d password ospf6d interface bb0 ipv6 ospf6 hello-interval 1 ipv6 ospf6 dead-interval 4 router ospf6 redistribute connected interface bb0 area 0.0.0.0 interface br0 area 1.0.0.0 line vty log syslog
Den Dienst aktivieren und starten
# systemctl enable ospf6d # systemctl start ospf6d
ospfd
IPv4-Routing wird per ospfd (analog zum ospf6d) konfiguriert. Hier $NETWORK durch das IP-Netz der Domäne (und wieder $HOSTNAME durch den Hostnamen) ersetzen.
# > /etc/quagga/ospfd.conf hostname $HOSTNAME-ospf password ospfd interface bb0 ip ospf hello-interval 1 ip ospf dead-interval 4 router ospf auto-cost reference-bandwidth 100000 passive-interface default no passive-interface bb0 network 10.78.0.0/22 area 0.0.0.0 network $NETWORK area 0.0.0.0 line vty
Den Dienst aktivieren und starten
# systemctl enable ospfd # systemctl start ospfd
So werden beide Tunnel-Interfaces zu unseren Netzwerken für OSPF verwendet. Ankündigungen für Routen werden jedoch nur ins Backbone-Netz geschickt, nicht über ein anderes Interface.