Tunnelserver

Tunnelserver
Starttermin	20 Sep. 17
Status	Aktiv
Der Tunnelserver dient der Anbindung von sogenannten Funkinseln der Community an das FunkFeuer-Netz über eine nicht zu FunkFeuer gehörende Breitbandverbindung unter Nutzung von unterschiedlichen Techniken der Paketverkapselung.
Projekt

Beschreibung

Der Tunnelserver dient der Anbindung von sogenannten Funkinseln der Community an das FunkFeuer-Netz über eine nicht zu FunkFeuer gehörende Breitbandverbindung unter Nutzung von unterschiedlichen Techniken der Paketverkapselung.

Funkinseln sind entweder solche Knoten, deren einzige Verbindung zum FunkFeuer-Netz über eine nicht zum FunkFeuer-Netz gehörende Breitbandverbindung hergestellt wird, oder solche Knoten, die über eine externe Breitbandverbindung und ihre jeweilige Funkschnittstelle oder jeweiligen Funkschnittstellen entlegene Knoten, die sonst nicht mit dem restlichen FunkFeuer-Netz verbunden sind, verbinden, sowie jene Knoten, die aus Gründen der höheren Redundanz eine externe Breitbandverbindung als Backupverbindung nützen, um zwischen Nachbarknoten und dem FunkFeuer-Housing über eine Breitbandverbindung Daten weiterzuleiten, Routinginformationen auszutauschen oder selbst Daten zu übertragen.

Maintainer

Erich N. Pekarek,Christoph Lösch,Christian Pock,Bernhard Marker

Abhängigkeiten

Das Tunnelserverprojekt ist von folgenden Projektgruppen abhängig:

• Core-Team/Roofnode-Team
• v642-Projekt
• Housing/VM

Um die wechselseitigen Abhängigkeiten zu reduzieren, lautet der aktuelle Projektfahrplan wie folgt: Den gegenwärtigen Tunnelserver, der leider auch andere, systemrelevante Aufgaben erledigt, in mehreren Schritten zu migrieren.

• Vorbereitungen:
  • Sämtliche Tunnelfunktionen von Tunnel6 und Tunnel auf der „VM-Tunnel6“ zu vereinen.
  • Tests neuer Funktionen.
• Hauptphase: Die vereinte VM wird auf eine physische Hardware migriert. Diese Maschine wird wie ein Roofnode mit erhöhter Redundanz eingebunden werden.
• Nacharbeiten:
  • Anschließend die VM „Tunnel 6“ stilllegen.
  • Die Routing-Funktionen der „VM Tunnel” auf die neuen Roofnodes oder andere Router so verteilen, wie es sinnvoll ist.
  • Die VM „Tunnel“ anschließend stilllegen.

• Dauerarbeiten: Wartung und Betreuung.

Ziel ist es, einen redundant angebundenen Tunnelserver zu haben, der einerseits „echte Funkinseln“ mit mehreren Protokollen versorgen kann, andererseits auch versprengte IPv6-Maschinen durch das IPv4-Netz anbinden kann. Eine weitere Aufgabe kann die Anbindung der vereinzelt existenten OLSRv1-IPv6 Knoten sein. Letzteres ist durch Migrationsvorhaben an den davon betroffenen Knoten jedoch nur noch bedingt relevant.

Details

Gegenwärtiger Status: * Tunnel VM hat Aufgaben von Tunnel6 vorübergehend übernommen. * Tunnel6 wurde aktualisiert und wird nun um neue Features erweitert. Hier sind wir in der Testphase. Nach deren Abschluss steht die Migration sämtlicher Tunneldienste auf diese VM unmittelbar bevor. * Die physische Maschine ist bereits rudimentär eingerichtet.

• Tunnelbetreiber wurden angeschrieben, um den Bedarf zu erheben und Dokumentationsmängel zu beheben. Nicht mehr benötigte Tunnel wurden gelöscht, ebenso wie unbenutzte Tunnel ohne jedwede oder selbst nach Nachfrage nicht nachvollziehbare Kontaktinformation. Die Nichtangabe von Kontaktinformationen verstösst nämlich auch gegen das PicoPeeringAgreement.
• Migration abgeschlossen, Regelbetrieb.

Verwendung

OpenVPN-Tunnel_zu_FunkFeuer