https://wiki.funkfeuer.at/api.php?action=feedcontributions&user=Erich&feedformat=atomFunkFeuer Wiki - Benutzerbeiträge [de]2024-03-28T19:49:08ZBenutzerbeiträgeMediaWiki 1.36.3https://wiki.funkfeuer.at/index.php?title=Services/Organisation/Tunnelserver&diff=3587Services/Organisation/Tunnelserver2023-12-25T22:57:30Z<p>Erich: /* Maintainer */</p>
<hr />
<div>{{Projekt<br />
|name=tunnel.funkfeuer.at<br />
|startdate=2017/09/20<br />
|state=Aktiv<br />
|desc=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.<br />
}}<br />
<br />
== Beschreibung ==<br />
<br />
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. <br />
<br />
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.<br />
<br />
== Maintainer ==<br />
* [[Benutzer:erich|Erich N. Pekarek]]<br />
* [[Benutzer:vchrizz|Christoph Lösch]]<br />
* [[Benutzer:Pocki|Christian Pock]]<br />
* [[Stefan Schultheis]]<br />
* [[Simon Schwendemann]]<br />
<br />
== Abhängigkeiten ==<br />
<br />
Das Tunnelserverprojekt ist von folgenden Projektgruppen abhängig:<br />
<br />
* Core-Team/Roofnode-Team<br />
* v642-Projekt<br />
* Housing/VM<br />
<br />
<s>Um die wechselseitigen Abhängigkeiten zu reduzieren, lautet der aktuelle Projektfahrplan wie folgt:<br />
Den gegenwärtigen Tunnelserver, der leider auch andere, systemrelevante Aufgaben erledigt, in mehreren Schritten zu migrieren.<br />
* Vorbereitungen:<br />
** Sämtliche Tunnelfunktionen von Tunnel6 und Tunnel auf der „VM-Tunnel6“ zu vereinen.<br />
** Tests neuer Funktionen.<br />
* Hauptphase: Die vereinte VM wird auf eine physische Hardware migriert. Diese Maschine wird wie ein Roofnode mit erhöhter Redundanz eingebunden werden.<br />
* Nacharbeiten:<br />
** Anschließend die VM „Tunnel 6“ stilllegen.<br />
** Die Routing-Funktionen der „VM Tunnel” auf die neuen Roofnodes oder andere Router so verteilen, wie es sinnvoll ist.<br />
** Die VM „Tunnel“ anschließend stilllegen.<br />
</s><br />
* Dauerarbeiten: Wartung und Betreuung.<br />
<br />
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. <s>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.</s> Gegenwärtig nützt nur noch Knoten OZW OLSRv1 mit IPv6 aus dem Prefix 2a02:60:100::/40.<br />
<br />
== Details ==<br />
Gegenwärtiger Status:<br />
<s>* Tunnel VM hat Aufgaben von Tunnel6 vorübergehend übernommen.</s><br />
<s>* 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.</s><br />
<s>* Die physische Maschine ist bereits rudimentär eingerichtet.</s><br />
* 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.<br />
* Migration abgeschlossen, Regelbetrieb.<br />
* Bedarf an einem neuen Tunnel oder Änderungswünsche können u.a. unter https://forum.funkfeuer.at/t/tunnelserver-fuer-funkinseln-und-backuplinks/261 eingemeldet werden. Das Maintainer-Team kümmert sich darum.<br />
<br />
== Verwendung ==<br />
[[OpenVPN-Tunnel_zu_FunkFeuer]]</div>Erichhttps://wiki.funkfeuer.at/index.php?title=Services/Organisation/Tunnelserver&diff=3586Services/Organisation/Tunnelserver2023-12-25T22:27:59Z<p>Erich: </p>
<hr />
<div>{{Projekt<br />
|name=tunnel.funkfeuer.at<br />
|startdate=2017/09/20<br />
|state=Aktiv<br />
|desc=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.<br />
}}<br />
<br />
== Beschreibung ==<br />
<br />
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. <br />
<br />
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.<br />
<br />
== Maintainer ==<br />
* [[Benutzer:erich|Erich N. Pekarek]]<br />
* [[Benutzer:vchrizz|Christoph Lösch]]<br />
* [[Benutzer:Pocki|Christian Pock]]<br />
* [[Benutzer:damadmai|Daniel A. Maierhofer]]<br />
* [[Simon Schwendemann]]<br />
== Abhängigkeiten ==<br />
<br />
Das Tunnelserverprojekt ist von folgenden Projektgruppen abhängig:<br />
<br />
* Core-Team/Roofnode-Team<br />
* v642-Projekt<br />
* Housing/VM<br />
<br />
<s>Um die wechselseitigen Abhängigkeiten zu reduzieren, lautet der aktuelle Projektfahrplan wie folgt:<br />
Den gegenwärtigen Tunnelserver, der leider auch andere, systemrelevante Aufgaben erledigt, in mehreren Schritten zu migrieren.<br />
* Vorbereitungen:<br />
** Sämtliche Tunnelfunktionen von Tunnel6 und Tunnel auf der „VM-Tunnel6“ zu vereinen.<br />
** Tests neuer Funktionen.<br />
* Hauptphase: Die vereinte VM wird auf eine physische Hardware migriert. Diese Maschine wird wie ein Roofnode mit erhöhter Redundanz eingebunden werden.<br />
* Nacharbeiten:<br />
** Anschließend die VM „Tunnel 6“ stilllegen.<br />
** Die Routing-Funktionen der „VM Tunnel” auf die neuen Roofnodes oder andere Router so verteilen, wie es sinnvoll ist.<br />
** Die VM „Tunnel“ anschließend stilllegen.<br />
</s><br />
* Dauerarbeiten: Wartung und Betreuung.<br />
<br />
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. <s>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.</s> Gegenwärtig nützt nur noch Knoten OZW OLSRv1 mit IPv6 aus dem Prefix 2a02:60:100::/40.<br />
<br />
== Details ==<br />
Gegenwärtiger Status:<br />
<s>* Tunnel VM hat Aufgaben von Tunnel6 vorübergehend übernommen.</s><br />
<s>* 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.</s><br />
<s>* Die physische Maschine ist bereits rudimentär eingerichtet.</s><br />
* 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.<br />
* Migration abgeschlossen, Regelbetrieb.<br />
* Bedarf an einem neuen Tunnel oder Änderungswünsche können u.a. unter https://forum.funkfeuer.at/t/tunnelserver-fuer-funkinseln-und-backuplinks/261 eingemeldet werden. Das Maintainer-Team kümmert sich darum.<br />
<br />
== Verwendung ==<br />
[[OpenVPN-Tunnel_zu_FunkFeuer]]</div>Erichhttps://wiki.funkfeuer.at/index.php?title=Services/Organisation/Gallery&diff=3283Services/Organisation/Gallery2021-06-03T17:05:10Z<p>Erich: </p>
<hr />
<div>== Beschreibung ==<br />
Photo Gallery zur Ablage von Bildern von Knoten, Events, Workshops, Konferenzen,...<br />
<br />
== Abhängigkeiten ==<br />
<br />
Anregung:<br />
Für Inklusion in der nodeDB wäre es sehr gut, wenn jedes Photo und uach jeder node (== standort) einen statischen permalink hat, der sich auch bei Versions-upgrades nicht mehr ändert.<br />
Bitte das in die Entscheidung bei der Auswahl der gallery berücksichtigen.<br />
<br />
<br />
== Verwendung ==<br />
Die Gallery soll grundsätzlich offen für alle Funkfeuer-User sein.<br />
<br />
--> Frage: IP range Funkfeuer oder Funkfeuer login (nodeDB/redeemer)?<br />
<br />
Gesonderte Zugriffsrechte für manche Bereiche wären wünschenswert - etwa für einzelne Bilder oder Standorte (Alben).<br />
<br />
== Maintainer ==<br />
Erich Pekarek<br />
Daniel Maierhofer<br />
<br />
== Brainstorming ==<br />
<br />
=== Anforderungen ===<br />
<br />
Die bisherige Gallery basiert auf G2. Gallery2 und Gallery3 werden nicht mehr weiterentwickelt. Die Migration auf ein anderes System ist erforderlich.<br />
<br />
* möglichst kein externes Cloud Service<br />
* möglichst keine PHP Software (auch für andere Projekte - warum eigentlich? -> Diskussionsseite)<br />
* möglichst statische Seiten<br />
* ev. (shell-)Scripts die die Bilder darstellen<br />
und Bilder-Upload getrennt davon (möglichst userfreundlich)<br />
* Upload soll für 'Neue' möglich sein (selfregistration -> entspricht das dem Workflow? -> Diskussionsseite)<br />
* künftige Erfassung der Fotorechte<br />
<br />
weiterführende Informationen zu Alternativen:<br />
https://www.it-pulse.eu/webanwendungen/menalto-gallery/gallery-team-verkuendet-aus-fotogalerie-software-1809.html<br />
<br />
<br />
<small>'''UPDATE''' (2021-05-31): => publicweb admins wollen php5 zeitnah abdrehen</small><br />
<br />
There is a "stable version of Gallery 3 that is PHP 7+ compatible [..] download it from http://galleryrevival.com/"<small>--[http://galleryproject.org/gallery-development-continues.html '''Gallery development is continuing!''' (2019-11-13)]<br /><br /><small>''Gallery 3 is actually a completely different application from Gallery 2, so there isn't an upgrade process as such.<br />Start by installing Gallery 3, then import your Gallery 2 items using the Gallery 2 Import Module which is included in the standard installation.''<br />--http://codex.galleryproject.org/Gallery3:FAQ.html#Upgrading_from_Gallery_2_to_Gallery_3 </small></small><br />
<br />
=== Mögliche Lösungen ===<br />
<br />
* Neuer Lösungsansatz: Keine Gallery mehr benützen, sondern die Bilder in Forenbeiträgen im neuen [https://forum.funkfeuer.at Forum] ablegen. Spart Maintership, ist kein PHP, Forum ist per se eine Form von Social-Media mit Kommentarfunktion, User können entscheiden, ob sie Daten sichtbar machen oder nicht.<br />
<br />
Die nachfolgenden Projekte sind in alphabetischer Reihenfolge sortiert.<br />
<br />
==== Coppermine ====<br />
<br />
<br />
* Website: http://coppermine-gallery.net/<br />
* Programmiersprache: PHP<br />
* Lizenz: GPL v3.0 [http://documentation.coppermine-gallery.net/en/copyrights.htm]<br />
<br />
* Demo: http://coppermine-gallery.net/demo/cpg15x/<br />
* Plugins: http://coppermine-gallery.net/plugins.php?cpg_version=both<br />
<br />
(+)zahlreiche Plugins verfügbar (Backup, Massimport, Panoramaviewer, Timeline, ...)<br />
(+)individuell konfigurierbare Userprofil-Einträge<br />
(+)Passwortgeschützte Alben möglich<br />
<br />
===== Migration von G2 zu Coppermine 1.5.x =====<br />
http://forum.coppermine-gallery.net/index.php?topic=76143.0<br />
<br />
==== DAlbum ====<br />
<br />
* Website: http://www.dalbum.org<br />
* Programmiersprache: PHP<br />
* Lizenz: GPL v2+ [http://www.dalbum.org/index.php?go=Copyrights]<br />
<br />
(+) baut auf lokaler Ordnerstruktur auf, welche indiziert wird<br />
(-)kein integrierter Bilder Upload (ist via FTP [http://www.dalbum.org/index.php?go=Upload gedacht])<br />
(·)[http://dalbum.org/index.php?go=Access User Verwaltung]<br />
(·)beim Indizieren werden auch Thumbnails erstellt<br />
(+)Pic-Infos werden ausgelesen und lassen sich ein/ausblenden<br />
<br />
==== Drupal + Node Gallery ====<br />
<br />
* Website: https://www.drupal.org<br />
* Website Modul: https://www.drupal.org/project/node_gallery<br />
* Programmiersprache: PHP 5.6 oder 7.x<br />
* Lizenz: GPL 2<br />
<br />
(+) Flexibilität: Es handelt sich um ein stark DB-orientiertes CMS mit zahlreichen Modulen<br />
(+) Erweiterbar<br />
(+) Code-Updates über Cronjob mittels "drush -y up"<br />
(+) Darstellung der Nodes über Views anpassbar - ermöglicht Filter, Sortierung, Gruppierung.<br />
(-) Bedarf des Einlernens<br />
(-) Bedarf der Anpassung<br />
<br />
==== Hugo + Hugo-gallery oder Hugo + HugoPhotoswipe + PhotoSwipe ====<br />
<br />
* Hugo Website: https://gohugo.io/tools/<br />
* Programmiersprache: Go<br />
<br />
* Hugo-Gallery<br />
** Repository: https://github.com/icecreammatt/hugo-gallery/blob/master/README.md<br />
** Lizenz: MIT [https://github.com/icecreammatt/hugo-gallery/blob/master/LICENSE]<br />
<br />
* HugoPhotoSwipe<br />
** Repository: https://github.com/GjjvdBurg/HugoPhotoSwipe/blob/master/README.rst<br />
** Lizenz: GPL v3.0 [https://github.com/GjjvdBurg/HugoPhotoSwipe/blob/master/LICENSE]<br />
<br />
* PhotoSwipe<br />
** Website: http://photoswipe.com/<br />
** Lizenz: MIT 'with Wordpress exception'<br />
<br />
(·) Hugo ist ein statischer Websitegenerator auf Basis von Go; die beiden Erweiterungen können scriptbasiert Galerien erstellen.<br />
(·) PhotoSwipe ist rein auf Javascript aufgebaut und nutzt vordefinierte Bildgrößen. Dokumentation [http://photoswipe.com/documentation/getting-started.html]<br />
<br />
Meinungen: <br />
sieht auch nach einem guten statischen Generator aus.<br />
<br />
==== Media Goblin ====<br />
<br />
* Website: http://www.mediagoblin.org/<br />
* Lizenz: GNU AGPLv3 [http://mediagoblin.readthedocs.io/en/stable/siteadmin/about.html#how-is-gnu-mediagoblin-licensed]<br />
<br />
(+) War schon mal Projekt bei Google Summer of Code, und reicht regelmäßig dort ein.<br />
(-) Es ist riesig, sowohl bezüglich Funktionalität (Video-Transkodierung etc.) als auch Sourcen.<br />
(·) Medien landen in einer (lokalen) Datenbank, nicht Verzeichnisbaum.<br />
(·) Bringt sein eigenes Django-artiges (?) Framework, aber eben nicht Django.<br />
(+) Debian/Ubuntu-Pakete, Fedora/Redhat vorhanden; Abhängigkeiten:<br />
Python 2.7 or Python 3.4+<br />
python-lxml<br />
git<br />
SQLite/PostgreSQL<br />
Python Imaging Library (PIL)<br />
virtualenv<br />
nodejs<br />
http://mediagoblin.readthedocs.io/en/stable/siteadmin/deploying.html<br />
<br />
Meinungen:<br />
"This project is part of the GNU Project." Supporttechnisch sicher nicht übel.<br />
<br />
==== nextcloud ====<br />
(getestet)<br />
<br />
* Website: http://nextcloud.com/<br />
* Demo: https://demo.nextcloud.com/<br />
* Programmiersprache: PHP<br />
* Lizenz: GNU AGPL 3.0 [https://github.com/nextcloud/nextcloud.com/blob/master/LICENSE]<br />
<br />
(-) keine Baum-Darstellung der Gallery<br />
(-) kein Resizing der Bilder<br />
(-) keine Pic-Infos,... in der Gallery-Darstellung<br />
<br />
Meinung: mbmn als Gallery ungeeignet [+/-] (2/0)<br />
<br />
==== PhotoFloat ====<br />
<br />
* Website: https://git.zx2c4.com/PhotoFloat/about/<br />
* Programmiersprache: Python2<br />
* Lizenz: GPL v2.0+ [https://git.zx2c4.com/PhotoFloat/about/]<br />
<br />
Eindrücke:<br />
PhotoFloat hat eine serverseitige Authentifizierung basierend auf flask-login, sodass man Alben etc. mit Login "schützen" kann. https://flask-login.readthedocs.io/en/latest/<br />
<br />
Allerdings sehe ich da weder ein Web-Interface für Selbstregistrierung, noch Unterstützung für mehr als zwei (!?) User.<br />
<br />
Es dürfte auch keinen Web-Bilder-Upload geben, und von PEP-8 [5] hat der Autor wohl noch nichts gehört :-) https://www.python.org/dev/peps/pep-0008/#tabs-or-spaces<br />
<br />
Fazit: (Auch) PhotoFloat bräuchte einige Anpassungen und Umbauten für den Gallery-Anwendungsfall.<br />
<br />
==== Piwigo ====<br />
(getestet)<br />
<br />
* Website: http://piwigo.org<br />
* Programmiersprache: PHP<br />
* Lizenz: GNU GPLv2 [http://piwigo.org/basics/license]<br />
<br />
(·) wird oft als Ersatz für G2 und G3 Projekte verwendet.<br />
<br />
Meinungen:<br />
* schaut interessant aus<br />
<br />
===== Migration von G2 nach Piwigo =====<br />
Migration von G2 mittels Scripts möglich etwa: <br />
https://github.com/dschwen/g2piwigo<br />
<br />
==== Sigal ====<br />
<br />
* Website: http://sigal.saimon.org/<br />
* Programmiersprache: Python<br />
* Lizenz: MIT [http://sigal.saimon.org/en/latest/]<br />
<br />
(·) album metadaten via markdown files.<br />
(+) generiert wenn gewünscht auch eine nette Karte basierend auf den Koordinaten in den Photo-Metadaten via leaflet / openstreetmap.<br />
(+) einfach zu installieren und konfigurieren.<br />
(+) könnte als cronjob, git post-receive hook oder dergleichen laufen.<br />
(?) die offene frage wäre dann wie man sicher fotos von selbst registrierten users in einen lokalen ordner am server bekommt.<br />
<br />
Meinungen: <br />
sieht nach einem guten statischen Generator aus.<br />
<br />
==== WordPress ====<br />
<br />
* Website:<br />
* Programmiersprache: PHP<br />
* Lizenz: GPL v2 + [https://wordpress.org/about/license/]<br />
<br />
(·) via Plugin: Gallery Manager<br />
<br />
Meinungen:<br />
* ganz allgemein... Hände weg von wordpress; Gegenfrage: warum?<br />
* Sicherheitslücken...; Gegenargument: die werden aber üblicherweise flott gestopft...;<br />
<br />
==== Zenphoto ====<br />
(getestet)<br />
<br />
* Website: http://www.zenphoto.org/<br />
* Programmiersprache: PHP<br />
* Lizenz: GPL v2+ [http://www.zenphoto.org/pages/licenses/]<br />
<br />
(·) eher als Foto-CMS gedacht<br />
(?) Userrechte für verschiedene Fotogrößen?<br />
<br />
===== Migration von G2 zu Zenphoto =====<br />
http://www.zenphoto.org/news/gallery2-to-zenphoto-migration/<br />
<br />
==== GoGallery ====<br />
<br />
* Website: https://github.com/smancke/gogallery<br />
* Programmiersprache: Go<br />
* Lizenz: MIT License [https://github.com/smancke/gogallery/blob/master/LICENSE]<br />
<br />
==== Chevereto Free ====<br />
<br />
* Website: https://chevereto.com/free<br />
* Programmiersprache: PHP<br />
* Lizenz: GNU Affero General Public License v3.0 [https://github.com/Chevereto/Chevereto-Free/blob/master/LICENSE]<br />
* Demo: https://demo.chevereto.com/<br />
<br />
=== Zeitplan ===<br />
<br />
* Brainstormingphase ... bis Herbst 2017<br />
* Sept. 2017 Entscheidung über System.<br />
* Umsetzung bis Anfang 2018.<br />
<br />
=== Diverse Links ===<br />
<br />
https://en.wikipedia.org/wiki/Comparison_of_photo_gallery_software<br />
<br />
wiki deutsch listet teilweise andere auf<br />
https://de.wikipedia.org/wiki/Webgalerie<br />
<br />
https://www.heise.de/download/products/foto/web-galerien</div>Erichhttps://wiki.funkfeuer.at/index.php?title=Hardware/PoE&diff=3183Hardware/PoE2020-12-13T15:49:35Z<p>Erich: </p>
<hr />
<div>== Allgemeines ==<br />
[https://de.wikipedia.org/wiki/Power_over_Ethernet Power over Ethernet auf Wikipedia]<br />
<br />
== passive PoE ==<br />
Bei z.B. Ubiquiti Antennen wird passives PoE mit 24V über zwei Adernpaare mit + an Pin 4 & 5 und - an Pin 7 & 8 verwendet. (Mode B/Midspan)<br />
<br />
Bei 100 Mbit/s-Ports reichen somit simple [https://geizhals.at/digitus-dn-95001-a1214858.html PoE Injectoren] für die zwei zur Datenübertragung ungenutzten Adernpaare. (45+ 78-)<br />
<br />
Bei 1 GBit/s-Ports wird Phantomspeisung verwendet, da alle vier Adernpaare für Datenübertragung genutzt werden. Dafür sind Übertrager(kleine Trafos) notwendig.<br />
<br />
Grundsätzlich gilt, dass die Daten mit Strömen zwischen den Adern eines Adernpaares und die Stromversorgung zwischen den Adernpaaren selbst übertragen wird.<br />
<br />
Dies kann über PoE-Injector-Netzteile von Ubiquiti [https://geizhals.at/ubiquiti-desktop-gigabit-poe-injektor-poe-15-12w-a949862.html POE-15-12W] oder [https://www.amazon.de/WS-GPOE-1-WM-Port-Gigabit-Injektor-Montage-Wandmontage/dp/B00ENNUWO4 WS-GPOE-1-WM] mit eingebauten Trafos erfolgen, in letzterem befindet sich eine selbstrückstellende Sicherung, die bei 650mA anschlägt: [http://www.pttc.com.tw/DataSheets/DataSheetforRLD72VXFSeries.pdf D72 XF065]<br />
<br />
Erstere haben eine Reset-Taste, welche das Resetten eines Gerätes von der Ferne ermöglicht, siehe auch https://dren.dk/mreset.html<br />
<br />
== passive PoE über alle Adernpaare ==<br />
Beim [[Hardware/EdgePoint_R6|EdgePoint R6]] werden alle vier(wie 802.3bt-2018, aber Polarität der zusätzlichen Paare vertauscht! - 4PPoE) Adernpaare für PoE als auch Daten verwenden. (1245+ 3678-)<br />
<br />
Durch Crimpen mit spezieller Belegung können herkömmliche PoE-Injectoren so umgebaut werden, der Strom von allen Adernpaaren auf einen DC-Hohlstecker geführt werden kann.<br />
<br />
Siehe dazu [https://community.ui.com/questions/Ubiquiti-EdgeRouter-6P-powered-by-MikroTik-RBGPOE-with-4-Pair-PoE-Injector/05400bad-0bf7-4ea6-b423-0b937f1490cf Ubiquiti EdgeRouter 6P powered by MikroTik RBGPOE with 4 Pair PoE-Injector].<br />
<br />
== Fertige Lösung ==<br />
[https://www.amazon.de/dp/B07K2Z6CFK 9V/12 + 24V PoE, USB, Rundstecker-Powerbank/USV]<br />
<br />
[[Datei:PoE_Injector_USB_DCDC.JPG|miniatur|WS-GPOE-1-WM mit USB-StepUp-Wandler auf 24V]]<br />
[[Datei:PoE_Injector_USB_DCDC_UBNT.jpg|miniatur|Netzteil entfernt, USB-StepUp-Wandler eingebaut, mit Schiebeschalter für Reset]]<br />
[[Datei:PoE_Injector.jpg|miniatur|Innenleben von POE-15-12W]]<br />
[[Datei:PoE_Injector_WS-GPOE-1-WM_oben.jpg|miniatur|Innenleben von WS-GPOE-1-WM oben]]<br />
[[Datei:PoE_Injector_WS-GPOE-1-WM_unten.jpg|miniatur|Innenleben von WS-GPOE-1-WM unten]]</div>Erichhttps://wiki.funkfeuer.at/index.php?title=Kanalwahl&diff=3180Kanalwahl2020-12-06T20:09:54Z<p>Erich: </p>
<hr />
<div>Es ist darauf zu achten, dass die Frequenzwahl im gesetzlich erlaubten Bereich liegt, als Region/Country Code ist AT bzw. Austria einzustellen.<br />
<br />
Generell wollen wir auf die Betriebsart Ad-hoc weitgehend verzichten und auf eine durchgängige Access Point(AP) <-> Client/Station (STA) Konfiguration setzen, bei der immer das räumlich höhere Gerät als AP konfiguriert wird.<br />
<br />
In diesem Fall ist es nicht notwendig eine BSSID einzutragen, da diese aus der MAC-Adresse des WLAN-Interfaces abgeleitet wird.<br />
Sollten dennoch Ad-hoc-Verbindungen verwendet werden, sind die BSSIDs in aus den Tabellen zu verwenden.<br />
<br />
Als SSID (ESSID) verwenden wir [[Policies/Namenskonvention|'''[node][direction].funkfeuer.at''']], um den Ort der Gegenstelle besser erkennbar zu machen.<br />
<br />
==5GHz 802.11n/ac==<br />
Da sich unsere Geräte das [https://www.rtr.at/de/tk/Spektrum5GHz 5 GHz WLAN-Frequenzband] von 5470-5725 MHz mit militärischen und zivilen Radar- und Satelliten-Kommunikationsdiensten teilen müssen, sind wir angehalten, diese nicht zu beeinträchtigen.<br />
<br />
WLAN ist ein sog. Sekundärdienst. Siehe [https://www.rtr.at/de/tk/Spektrum5GHz/1997_bmvit-info-052010de.pdf Seite 2 3.Punkt].<br />
<br />
Somit sind folgende Kanäle bzw. Frequenzen mit der Strahlungsleistung, dh. inkl. Antennengewinn (EIRP) 1W bzw. 30dBm nutzbar:<br />
<br />
{| class="wikitable"<br />
| rowspan="10" style="width: 3em" | 5 GHz<br />
! style="width: 5em" colspan="1" rowspan="2" | Kanal<br />
! style="width: 5em" colspan="1" rowspan="2" | Frequenz<br />
! style="width: 8em" colspan="3" rowspan="1" | Adhoc-Mode<br />
! style="width: 15em" colspan="1" rowspan="1" | AP/Station<br />
|- <br />
! | BSSID-Vertikal <br />
! | BSSID-Horizontal<br />
! | BSSID-Dual <br />
! | ESSID<br />
|-<br />
| 100 || 5500 || 00:FF:01:00:01:20 || 00:FF:01:00:02:20 || 00:FF:01:00:03:20 || ''[node][direction]''.funkfeuer.at<br />
|-<br />
| 104 || 5520 || 00:FF:01:04:01:20 || 00:FF:01:04:02:20 || 00:FF:01:04:03:20 || ''[node][direction]''.funkfeuer.at<br />
|-<br />
| 108 || 5540 || 00:FF:01:08:01:20 || 00:FF:01:08:02:20 || 00:FF:01:08:03:20 || ''[node][direction]''.funkfeuer.at<br />
|-<br />
| 112 || 5560 || 00:FF:01:12:01:20 || 00:FF:01:12:02:20 || 00:FF:01:12:03:20 || ''[node][direction]''.funkfeuer.at<br />
|-<br />
| 116 || 5580 || 00:FF:01:16:01:20 || 00:FF:01:16:02:20 || 00:FF:01:16:03:20 || ''[node][direction]''.funkfeuer.at<br />
|-<br />
| 132 || 5660 || 00:FF:01:32:01:20 || 00:FF:01:32:02:20 || 00:FF:01:32:03:20 || ''[node][direction]''.funkfeuer.at<br />
|-<br />
| 136 || 5680 || 00:FF:01:36:01:20 || 00:FF:01:36:02:20 || 00:FF:01:36:03:20 || ''[node][direction]''.funkfeuer.at<br />
|-<br />
| 140 || 5700 || 00:FF:01:40:01:20 || 00:FF:01:40:02:20 || 00:FF:01:40:03:20 || ''[node][direction]''.funkfeuer.at<br />
|}<br />
<br />
* '''Kanäle 36-48''' ''Diese Kanäle dürfen Outdoor nicht verwendet werden (SAT-Kommunikation)''<br />
* '''Kanäle 120-128''' ''In diesem Bereich befindet sich das [https://wiki.funkfeuer.at/images/6/62/Austro_Control_Vortrag_Funkfeuer_20191104.pdf zivile Wetterradar] (Wiens nähestes funkt auf 5625 MHz), das wir nicht beeinträchtigen wollen''<br />
<br />
Um auf der sicheren Seite zu sein, diese Kanalliste (Frequency Scan List) auf den Antennen einstellen:<br />
5500,5505,5510,5515,5520,5525,5530,5535,5540,5545,5550,5555,5560,5565,5570,5575,5580,5660,5665,5670,5675,5680,5685,5690,5695,5700<br />
<br />
==2.4 GHz 802.11b/g/n== <br />
FunkFeuer Wien hat im [https://www.rtr.at/de/tk/Spektrum2400MHz 2.4 GHz WLAN-Band] seinen Betrieb zu einer Zeit aufgenommen, als Home-Router mit WLAN noch eine Seltenheit waren. Innerhalb der letzten 15 Jahre hat sich die Situation aber drastisch verschärft, und eine Nutzung der 2.4 GHz Frequenzen stellt eine immer größere Herausforderung dar. Aus diesem Grund wird nun versucht, das Netz durch die Aufgabe des Ad-Hoc-Modes zu stabilisieren.<br />
Einige Geräte sind noch in dieser Konfiguration:<br />
<br />
{| class="wikitable"<br />
| rowspan="6" style="width: 3em" | 2.4 GHz<br />
! style="width: 5em" | Kanal<br />
! style="width: 5em" | Frequenz<br />
! style="width: 8em" | ESSID<br />
! style="width: 8em" | BSSID<br />
|-<br />
| 1 || 2412 || v1.freiesnetz.www.funkfeuer.at || 4E:FE:52:36:2E:65<br />
|-<br />
| 4 || 2427 || v4.freiesnetz.www.funkfeuer.at || 26:A4:05:7B:2B:D8<br />
|-<br />
| 7 || 2442 || v7.freiesnetz.www.funkfeuer.at || 7A:55:80:50:08:08<br />
|-<br />
| 10 || 2457 || v10.freiesnetz.www.funkfeuer.at || 52:51:E5:D5:5A:43<br />
|-<br />
| 13 || 2472 || v13.freiesnetz.www.funkfeuer.at || 26:A7:D4:E4:4F:4D<br />
|-<br />
|}<br />
<br />
Bei horizontal polarisiserten Devices wurde die ESSID sinngemäß auf '''h1.freiesnetz.www.funkfeuer.at, h4.freiesnetz....., h7....''' gesetzt.<br />
<br />
Aus historischen Gründen beträgt der Kanalabstand in den WLAN-Bändern 5 MHz. (802.11b). Seit dem vermehrten Einsatz der Normen 802.11g/n benötigt eine WLAN Funkverbindung eine Bandbreite von 20 oder 40 MHz.<br />
<br />
Durch den Betrieb [http://de.wikipedia.org/wiki/Amateurfunk-Fernsehen Amateur-TeleVision eines Amateurfunk-TV Senders] mit einer Sendeleistung von 70 Watt (gegenüber unseren 0,1 Watt bzw. 20dBm) ist Kanal 7 oft stark gestört. <br />
Auch auf den Kanälen 5 und 9 ist kaum ein vernünftiger Datendurchsatz erreichbar, selbst die Kanäle 4 und 10 sind noch etwas eingeschränkt. <br />
<br />
Aus diesem Grund hätten wir nur 2 komplett ungestörte Kanäle zur Verfügung, was leider zuwenig ist. <br />
Daher nehmen wir die gegenseitigen Störungen der Kanäle 1/4 und 10/13 in Kauf und verwenden im Netz von FunkFeuer Wien die WLAN Kanäle 1, 4, (7), 10, 13 anstelle der üblichen [https://de.wikipedia.org/wiki/Wireless_Local_Area_Network#/media/Datei:NonOverlappingChannels2.4GHzWLAN-de.svg 1,5,9 und 13].<br />
<br />
=Bandbreitenwahl=<br />
Bei Wahl der Bandbreite heißt mehr nicht immer besser, denn je breiter diese gewählt hat, desto wahrscheinlicher ist es, dass sich mehrere Verbindungen gegenseitig stören.</div>Erichhttps://wiki.funkfeuer.at/index.php?title=Regionen&diff=3179Regionen2020-12-06T19:10:06Z<p>Erich: </p>
<hr />
<div><br />
== Wien ==<br />
<br />
[[Regionen/Wien]]<br />
<br />
== Graz ==<br />
<br />
[http://graz.funkfeuer.at/ Funkfeuer Graz]<br />
<br />
== Weststeiermark ==<br />
<br />
[[Regionen/Weststeiermark]]<br />
<br />
[http://weststmk.funkfeuer.at/ Funkfeuer Weststmk]<br />
<br />
== Wels ==<br />
<br />
[http://wels.funkfeuer.at/ Funkfeuer Wels]<br />
<br />
== Klosterneuburg ==<br />
<br />
[[Regionen/Klosterneuburg]]<br />
<br />
== Weinviertel ==<br />
<br />
[[Regionen/Weinviertel]]<br />
<br />
== Bad Ischl ==<br />
2006-2012 [http://funkfeuer-ischl.kunstlabor.at/ Funkfeuer Ischl]<br />
<br />
== Oststeiermark ==<br />
<br />
[[Regionen/Oststeiermark]]<br />
<br />
[https://funkfeuer-oststeiermark.webnode.at/ Funkfeuer-Oststeiermark]</div>Erichhttps://wiki.funkfeuer.at/index.php?title=OpenVPN_mit_Debian/Ubuntu&diff=3177OpenVPN mit Debian/Ubuntu2020-11-19T17:08:41Z<p>Erich: </p>
<hr />
<div>Unter Debian installierst Du die Pakete für Openvpn und olsr.<br />
<br />
Voraussetzungen:<br />
* Aktuelles Debian Stable oder Ubuntu LTS<br />
* Pakete für OpenVPN, OLSR (und OLSRv2), bridge-utils<br />
* Funkfeuer-Login<br />
* Funkfeuer-IPv4-Adresse für das Tunneldevice respektive die Bridge aus [[https://portal.funkfeuer.at/wien REDEEMER/FRONTEND/PORTAL]]<br />
* Einen Taschenrechner, der Dezimalzahlen in Hexadezimalzahlen umrechnen kann („programmiertechnischer Modus“)<br />
* Die Funkfeuer NodeID des Knotens, dem der Tunnel zugeordnet wird. Wenn Du im Redeemer/Portal eingeloggt bist, und auf „Nodes“ und den richtigen Namen des Nodes klickst, siehst Du die NodeID in der URL in Deinem Browsers entweder so:<br />
** „&id=9999“ oder so<br />
** „id_nodes=9999“.<br />
Diese Zahl umgewandelt in „Hex“ brauchst Du später für Deine IPv6-Adresse.<br />
<br />
<br />
* apt-get install openvpn openvpn-blacklist olsrd olsrd-plugins bridge-utils ebtables<br />
<br />
Angenommen, Dein Debian oder Ubuntu-Rechner besitzt eine Ethernetschnittstelle eth0 (oder wie das heute eher der Fall ist, en[X]s[Y]), die in derselben Broadcastdomain wie das Provider-Modem liegt, dann wirst Du /etc/network/interfaces editieren und dort zunächst eine statische Route zum Tunnelserver anlegen wollen. Im selben Arbeitsschritt könntest Du auch festlegen, dass der Tunnel unmittelbar nach dem Start der Netzwerkschnittstelle aufgebaut wird. Es ist darüber hinaus zweckmäßig, OLSR auf einer Bridge laufen zu lassen, um sich etwaige OLSR-Neustarts zu ersparen. Wir legen also auch gleich eine Bridge an und weisen ihr die Funkfeuer-IPs für IPv4 und IPv6 (aber nur für 2a02:60::/40) zu. 192.168.1.1 ist in diesem Beispiel das Providermodem als Defaultgateway. Warum setzen wir aber eine Hostroute zu 78.41.118.150/32 oder 78.41.115.16/32? Ganz einfach: Olsr wird die Default-Route überschreiben. In aller Regel passiert dies mit einer Metrik von 2 und sollte nicht stören. Dennoch kommt es manchmal dazu, dass bei Fehlen der Hostroute der Tunnel quasi über sich selbst laufen soll - das funktioniert freilich nicht. Wenn Du aber auch eine Funkschnittstelle mit OLSR hast, dann läufst Du Gefahr, dass der Tunnel zu Funkfeuer über das Funkfeuer-Mesh aufgebaut würde, was absolut keinen Sinn ergibt. Daher die Hostroute.<br />
<br />
/etc/network/interfaces:<br />
iface eth0 inet static<br />
...<br />
up /sbin/ip r a 78.41.115.16/32 dev eth0 via 192.168.1.1 metric 0<br />
up /etc/init.d/openvpn restart<br />
<br />
auto br-ff <br />
iface br-ff inet static<br />
bridge_fd 0<br />
bridge_maxwait 0<br />
bridge_waitport 0<br />
bridge_stp no<br />
bridge_ports none<br />
address [REDEEMER-IP v4]<br />
netmask 255.255.255.255<br />
# IPv6/OLSRv1 Schema 2a02:60:01[Node ID in Hexadezimaldarstellung, erstes Oktett]:[Node ID in Hex, zweites Oktett][Router ID (4 Bit)][Interface ID (4 Bit)]::[irgendwas]<br />
# Nachfolgend für 9999 NodeID 9999(10) = 270F(16); Router 1, Interface 1 mit Adresse „feed“:<br />
post-up /sbin/ip -6 a a 2a02:60:1'''27''':'''0f'''''11''::feed/64 dev br-ff<br />
# Wenn man die MAC-Adresse der Bridge definiert, wirkt sich das auf die IPv6 EUI64-Adresse beginnend mit fe80::/12 aus.<br />
# Man kann sich eine zufällige MAC-Adresse [[https://www.miniwebtool.com/mac-address-generator/ MAC Address Generator]] (lowercase und ":"-Notation) errechnen lassen.<br />
post-up ip link set dev br-ff address bc:75:33:6a:bf:cf<br />
# Die Bridge soll allen Traffic annehmen.<br />
post-up ip link set dev br-ff promisc on<br />
<br />
Auf Distributionen mit systemd würde die Konfiguration üblicherweise in /etc/openvpn/funkfeuer.conf liegen und der Key in /etc/openvpn/funkfeuer.secret. Der Tunnel wird automatisch gestartet, wenn das systemd-snippet dafür aktiviert wird:<br />
<br />
systemctl enable openvpn@funkfeuer<br />
<br />
Starten kann man den Dienst mit<br />
<br />
service openvpn@funkfeuer start<br />
<br />
<br />
Das Startup-Skript älterer Distributionen zieht die Datei /etc/default/openvpn zu seiner Initialisierung heran. Da müsst das Folgende gemacht werden:<br />
<br />
/etc/default/openvpn:<br />
#AUTOSTART="all" -> <br />
AUTOSTART="all" <br />
oder<br />
#AUTOSTART="all" -><br />
AUTOSTART="funkfeuer"<br />
<br />
Die /etc/openvpn/funkfeuer.conf sollte in aller Regel so aussehen:<br />
<br />
dev tap0<br />
proto udp<br />
remote 78.41.115.16<br />
# Die Portnummer XXXX wird Dir von den Tunnelserver-Administratoren zugewiesen, trag sie in der folgenden Zeile anstelle von 50XX ein.<br />
port 50XX<br />
daemon tap0<br />
persist-tun<br />
up-delay<br />
down-pre<br />
up-restart<br />
script-security 2<br />
nobind<br />
ping 10<br />
ping-restart 60<br />
ping-timer-rem<br />
fast-io<br />
sndbuf 524288<br />
rcvbuf 524288<br />
mute 2<br />
verb 0<br />
up /etc/openvpn/funkfeuer-updown.sh<br />
down /etc/openvpn/funkfeuer-updown.sh<br />
secret /etc/openvpn/funkfeuer.secret<br />
auth none<br />
auth-cache none<br />
cipher none<br />
tun-mtu 1500<br />
mssfix<br />
<br />
Und je nach Deinen Gegebenheiten hinsichtlich der MTU (Formel: ermittelte MTU z.B. 1500 Byte - 20 Byte IP-Header - 8 Byte UDP-Header - 4 Byte, wenn Kompression)<br />
<br />
#DSL mit PPPoE (1492 - 20 - 8 = 1464)<br />
fragment 1464<br />
#mit Kompression * (1464 - 4 = 1460) <br />
fragment 1460<br />
<br />
#DSL mit DHCP, Glasfaseranschluss, etc<br />
fragment 1472<br />
#mit Kompression <br />
fragment 1468<br />
<br />
'*) Soweit Dein Tunnel Kompression freigeschaltet bekommen hat, die Kompressionsart<br />
# Headerkomprimierung<br />
compress<br />
<br />
# lzo -Komprimierung<br />
compress lzo<br />
<br />
# lz4-v2 -Komprimierung<br />
compress lz4-v2<br />
<br />
<br />
In älteren Konfigurationen kann es sein, dass einige Zeilen anders sind: funkfeuer.conf:<br />
auth SHA256<br />
cipher none<br />
<br />
Diese Konfigurationsdatei benötigt also noch zwei weitere Dateien. Zum einen wäre das /etc/openvpn/funkfeuer-updown.sh. Dieses Skript wird von OpenVPN aufgerufen, sowie der Tunnel hergestellt oder beendet wird. OpenVPN übergibt diesem Skript Parameter, wie wir sie im Beispiel des Tunnelservers nützen. Für Deine Seite wird das nicht explizit erforderlich sein. Das Skript kann wie folgt aussehen:<br />
<br />
/etc/openvpn/funkfeuer-updown.sh:<br />
#!/bin/bash<br />
# br-ff ist die Bridge aus /etc/network/interfaces<br />
# $dev ist ein Parameter, den Openvpn übergibt. Hier zumeist „tap0“.<br />
br="br-ff"<br />
dev=$1<br />
logger "openvpn: $(echo $@)"<br />
logger "openvpn: $script_type"<br />
case $script_type in<br />
"down")<br />
/sbin/brctl delif $br $dev<br />
/sbin/ebtables -D FORWARD --logical-in ${br} -i ${dev} -j DROP<br />
/sbin/ip link set link dev $dev down<br />
;;<br />
"route-up")<br />
;;<br />
"up")<br />
/sbin/brctl addif $br $dev<br />
/sbin/ebtables -I FORWARD --logical-in ${br} -i ${dev} -j DROP<br />
/sbin/ip link set dev $br promisc on<br />
/sbin/ip link set link dev $dev up<br />
/sbin/ip link set link dev $br up<br />
;;<br />
esac<br />
echo $(date) $script_type $br.$dev $script_type>> /tmp/br-vpn.log<br />
exit 0<br />
<br />
<br />
Das Skript muss ausführbar gemacht werden. chmod +x /etc/openvpn/funkfeuer-updown.sh<br />
<br />
chmod +x /etc/openvpn/funkfeuer-updown.sh<br />
<br />
In der OpenVPN-Konfiguration haben wir den statischen Schlüssel mit /etc/openvpn/funkfeuer.secret angegeben. Exemplarisch schaut das so aus - aber den „echten Key“ bekommt ein Jeder individuell zugeteilt (bitte bei Erich P. anfordern):<br />
<br />
<br />
/etc/openvpn/funkfeuer.secret:<br />
#<br />
# 2048 bit OpenVPN static key<br />
#<br />
-----BEGIN OpenVPN Static key V1-----<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
-----END OpenVPN Static key V1-----<br />
<br />
<br />
Jetzt fehlt noch OLSR... Debian und Ubuntu verwenden /etc/init.d/olsrd als Startscript, das wiederum /etc/default/olsrd zu Initialisierung nutzt. Das Debian-Konzept geht noch von Adhoc-Netzen auf dem lokalen Gerät aus, kann also bis auf drei Zeilen ignoriert werden. Die Interface-Parameter lasse ich bewusst weg. Die Interfaces definiert man besser in der olsrd.conf, wo man individuelle Einstellungen tätigen kann (etwa unter anderem: ein per-Interface-Default-LQ-Multiplier, den Mode und die Gewichtung.)<br />
<br />
<br />
/etc/default/olsrd:<br />
START_OLSRD="YES"<br />
DEBUGLEVEL=0<br />
DAEMON_OPTS="-f /etc/olsrd/olsrd.conf -d $DEBUGLEVEL"<br />
<br />
<br />
Es fehlt noch die OSLR-Konfigurationsdatei (Vorsicht: ich verwende ein selbstkompiliertes OLSR und habe die plugin-Libraries „LoadPlugin“ hardgecodet; wenn der Pfad nicht stimmt, startet OLSR nicht, plaudert aber wirklich nicht darüber, was es stört.) -<br />
<br />
/etc/olsrd/olsrd.conf:<br />
AllowNoInt yes<br />
ClearScreen yes<br />
DebugLevel 0<br />
FIBMetric "flat"<br />
IpVersion 4<br />
LinkQualityAlgorithm "etx_ff"<br />
LinkQualityFishEye 1<br />
LinkQualityLevel 2<br />
MainIp [DIE MAIN-IP BEKOMMT IHR AUS DEM FUNKFEUER PORTAL, WENN IHR EIN GERÄT (DEVICE) ANLEGT]<br />
MprCoverage 1<br />
Pollrate 0.1<br />
TcRedundancy 2<br />
TosValue 16<br />
UseHysteresis no<br />
Willingness 3<br />
InterfaceDefaults<br />
{<br />
AutoDetectChanges yes<br />
HelloInterval 5.0<br />
HelloValidityTime 100.0<br />
TcInterval 2.0<br />
TcValidityTime 300.0<br />
MidInterval 50.0<br />
MidValidityTime 300.0<br />
HnaInterval 50.0<br />
HnaValidityTime 300.0<br />
Ip4Broadcast 255.255.255.255<br />
Mode "mesh"<br />
LinkQualityMult default 0.15<br />
Weight 99<br />
}<br />
Interface "br-ff"<br />
{<br />
AutoDetectChanges yes<br />
LinkQualityMult default 1.0<br />
Weight 0<br />
}<br />
Hna4<br />
{<br />
[SERVER-IP FALLS VORHANDEN - ZUWEISUNG VIA PORTAL] 255.255.255.255<br />
}<br />
LoadPlugin "olsrd_httpinfo.so.0.1"<br />
{<br />
PlParam "Port" "81"<br />
PlParam "Net" "0.0.0.0 0.0.0.0"<br />
PlParam "resolve" "false"<br />
}<br />
LoadPlugin "olsrd_txtinfo.so.1.1"<br />
{<br />
PlParam "port" "2006"<br />
PlParam "accept" "127.0.0.1"<br />
}<br />
LoadPlugin "olsrd_jsoninfo.so.1.1"<br />
{<br />
PlParam "port" "9090"<br />
PlParam "accept" "0.0.0.0"<br />
PlParam "UUIDFile" "/etc/olsrd/olsrd.uuid"<br />
}<br />
<br />
Damit ist eigentlich die Arbeit getan.<br />
<br />
=== 'the quick and dirty hack' für IPv6 ===<br />
<br />
Für OLSR mit IPv6 gibt es noch ein paar Tricks zu wissen und noch etwas mehr Handarbeit.<br />
Kopiere:<br />
<br />
* /etc/default/olsrd nach /etc/default/olsrd6<br />
** Ersetz jedes Vorkommen von olsr(d) durch olsr(d)6.<br />
<br />
mit vim wäre das so: vom input modus in den command modus wechseln (ESC) und in der command line folgendes eingeben: <br />
<br />
%s/olsrd/olsrd6/g<br />
<br />
12 ersetzungen sollten stattfinden. <br />
<br />
%s/OLSRD/OLSRD6/g<br />
<br />
selbiges gilt für die folgenden weiteren Dateien<br />
<br />
* /etc/init.d/olsrd nach /etc/init.d/olsrd6<br />
** Ersetz jedes Vorkommen von olsr(d) durch olsr(d)6. Ersetze /usr/sbin/olsrd durch /etc/alternatives/olsrd6<br />
* Setz einen Link von /usr/sbin/olsrd nach /etc/alternatives/olsrd6.<br />
<br />
ln -s /usr/sbin/olsrd /etc/alternatives/olsrd6<br />
<br />
Das hat den Sinn, dass der Prozess auch olsrd6 heißt, wenn er läuft und Du ihn mit dem pgrep im Startskript suchen kannst.<br />
<br />
* Leg /etc/olsrd/olsrd6.conf an - nachfolgend ein Beispiel.<br />
<br />
AllowNoInt yes<br />
ClearScreen yes<br />
DebugLevel 0<br />
FIBMetric "flat"<br />
IpVersion 6<br />
LinkQualityAlgorithm "etx_ff"<br />
LinkQualityFishEye 1<br />
LinkQualityLevel 2<br />
MprCoverage 1<br />
Pollrate 0.1<br />
TcRedundancy 2<br />
TosValue 16<br />
UseHysteresis no<br />
UseNiit yes<br />
Willingness 3<br />
InterfaceDefaults<br />
{<br />
#Ip6MulticastGlobal ff0e::1<br />
#Ip6MulticastSite ff05::11<br />
IPv6Multicast ff02::6d<br />
Weight 99<br />
AutoDetectChanges yes<br />
HelloInterval 50.0<br />
HelloValidityTime 100.0<br />
HnaInterval 50.0<br />
HnaValidityTime 300.0<br />
LinkQualityMult default 0.33 <br />
MidInterval 50.0<br />
MidValidityTime 300.0<br />
Mode "mesh"<br />
TcInterval 2.0 <br />
TcValidityTime 300.0<br />
Weight 99<br />
}<br />
Hna6<br />
{<br />
}<br />
LoadPlugin "olsrd_httpinfo.so.0.1"<br />
{<br />
PlParam "Net" "0::/0 2000::/3"<br />
PlParam "port" "82"<br />
}<br />
LoadPlugin "olsrd_jsoninfo.so.1.1"<br />
{<br />
PlParam "port" "9090"<br />
PlParam "accept" "::"<br />
PlParam "UUIDFile" "/etc/olsrd/olsrd6.uuid"<br />
PlParam "ipv6only" "true"<br />
}<br />
Interface "br-ff"<br />
{<br />
AutoDetectChanges yes<br />
LinkQualityMult default 0.25 <br />
Mode "ether"<br />
Weight 1<br />
IPv6Multicast ff02::6d<br />
}<br />
<br />
Sollte OLSR nicht starten wollen, liegt es entweder an einem Tippfehler oder an einer falsch formatierten IPv6-Adresse (::/0 oder 0::/0 je nach Plugin...) oder daran, dass olsrd seine Plugins nicht finden kann oder die falsche Version findet, wenn Du ein Update mit selbstkompiliertem OLSR gemacht haben solltest. Aufmerksam lesen und eventuell die LoadPlugin-Zeilen mit absoluten Pfaden zu der jeweiligen ".so" setzen, hilft.<br />
<br />
Es ist auch möglich die plugin sektion ganz wegzulassen, damit eliminiert man evtl ein weiteres Problem.<br />
diese können ja schrittweise bei funktionierender config nachträglich wieder eingefügt werden.<br />
<br />
Ein letzter Hinweis: OLSR wird noch nicht automatisch gestartet. Du kannst das in /etc/network/interfaces bei der Bridge br-ff mittels „up /etc/init.d/olsrd restart“ und „up /etc/init.d/olsrd6 restart“ tun, oder, Du legst die zwei Befehle in das OpenVPN-UP/DOWN-Skript. AutodetecChanges in OLSR sollte eigentlich dafür sorgen, dass der Bridge-Port immer erkannt wird, ohne, dass man den Dienst erneut starten muss.<br />
<br />
Das war's. Dual-Stack OLSRv1 mit Tunnel läuft, sowie Du es gestartet hast.</div>Erichhttps://wiki.funkfeuer.at/index.php?title=OpenVPN_mit_Debian/Ubuntu&diff=3176OpenVPN mit Debian/Ubuntu2020-11-19T17:02:11Z<p>Erich: </p>
<hr />
<div>Unter Debian installierst Du die Pakete für Openvpn und olsr.<br />
<br />
Voraussetzungen:<br />
* Aktuelles Debian Stable oder Ubuntu LTS<br />
* Pakete für OpenVPN, OLSR (und OLSRv2), bridge-utils<br />
* Funkfeuer-Login<br />
* Funkfeuer-IPv4-Adresse für das Tunneldevice respektive die Bridge aus [[https://portal.funkfeuer.at/wien REDEEMER/FRONTEND/PORTAL]]<br />
* Einen Taschenrechner, der Dezimalzahlen in Hexadezimalzahlen umrechnen kann („programmiertechnischer Modus“)<br />
* Die Funkfeuer NodeID des Knotens, dem der Tunnel zugeordnet wird. Wenn Du im Redeemer/Portal eingeloggt bist, und auf „Nodes“ und den richtigen Namen des Nodes klickst, siehst Du die NodeID in der URL in Deinem Browsers entweder so:<br />
** „&id=9999“ oder so<br />
** „id_nodes=9999“.<br />
Diese Zahl umgewandelt in „Hex“ brauchst Du später für Deine IPv6-Adresse.<br />
<br />
<br />
* apt-get install openvpn openvpn-blacklist olsrd olsrd-plugins bridge-utils ebtables<br />
<br />
Angenommen, Dein Debian oder Ubuntu-Rechner besitzt eine Ethernetschnittstelle eth0 (oder wie das heute eher der Fall ist, en[X]s[Y]), die in derselben Broadcastdomain wie das Provider-Modem liegt, dann wirst Du /etc/network/interfaces editieren und dort zunächst eine statische Route zum Tunnelserver anlegen wollen. Im selben Arbeitsschritt könntest Du auch festlegen, dass der Tunnel unmittelbar nach dem Start der Netzwerkschnittstelle aufgebaut wird. Es ist darüber hinaus zweckmäßig, OLSR auf einer Bridge laufen zu lassen, um sich etwaige OLSR-Neustarts zu ersparen. Wir legen also auch gleich eine Bridge an und weisen ihr die Funkfeuer-IPs für IPv4 und IPv6 (aber nur für 2a02:60::/40) zu. 192.168.1.1 ist in diesem Beispiel das Providermodem als Defaultgateway. Warum setzen wir aber eine Hostroute zu 78.41.118.150/32 oder 78.41.115.16/32? Ganz einfach: Olsr wird die Default-Route überschreiben. In aller Regel passiert dies mit einer Metrik von 2 und sollte nicht stören. Dennoch kommt es manchmal dazu, dass bei Fehlen der Hostroute der Tunnel quasi über sich selbst laufen soll - das funktioniert freilich nicht. Wenn Du aber auch eine Funkschnittstelle mit OLSR hast, dann läufst Du Gefahr, dass der Tunnel zu Funkfeuer über das Funkfeuer-Mesh aufgebaut würde, was absolut keinen Sinn ergibt. Daher die Hostroute.<br />
<br />
/etc/network/interfaces:<br />
iface eth0 inet static<br />
...<br />
up /sbin/ip r a 78.41.115.16/32 dev eth0 via 192.168.1.1 metric 0<br />
up /etc/init.d/openvpn restart<br />
<br />
auto br-ff <br />
iface br-ff inet static<br />
bridge_fd 0<br />
bridge_maxwait 0<br />
bridge_waitport 0<br />
bridge_stp no<br />
bridge_ports none<br />
address [REDEEMER-IP v4]<br />
netmask 255.255.255.255<br />
# IPv6/OLSRv1 Schema 2a02:60:01[Node ID in Hexadezimaldarstellung, erstes Oktett]:[Node ID in Hex, zweites Oktett][Router ID (4 Bit)][Interface ID (4 Bit)]::[irgendwas]<br />
# Nachfolgend für 9999 NodeID 9999(10) = 270F(16); Router 1, Interface 1 mit Adresse „feed“:<br />
post-up /sbin/ip -6 a a 2a02:60:1'''27''':'''0f'''''11''::feed/64 dev br-ff<br />
# Wenn man die MAC-Adresse der Bridge definiert, wirkt sich das auf die IPv6 EUI64-Adresse beginnend mit fe80::/12 aus.<br />
# Man kann sich eine zufällige MAC-Adresse [[https://www.miniwebtool.com/mac-address-generator/ MAC Address Generator]] (lowercase und ":"-Notation) errechnen lassen.<br />
post-up ip link set dev br-ff address bc:75:33:6a:bf:cf<br />
# Die Bridge soll allen Traffic annehmen.<br />
post-up ip link set dev br-ff promisc on<br />
<br />
<br />
Die Konfiguration von OpenVPN liegt bei Debian und Ubuntu üblicherweise in /etc/openvpn, wobei das Startup-Skript die Datei /etc/default/openvpn zu seiner Initialisierung heranzieht.<br />
<br />
/etc/default/openvpn:<br />
#AUTOSTART="all" -> <br />
AUTOSTART="all" <br />
oder<br />
#AUTOSTART="all" -><br />
AUTOSTART="funkfeuer"<br />
<br />
Somit erwartet OpenVPN seine Konfiguration in /etc/openvpn/funkfeuer.conf.<br />
<br />
dev tap0<br />
proto udp<br />
remote 78.41.115.16<br />
# Die Portnummer XXXX wird Dir von den Tunnelserver-Administratoren zugewiesen, trag sie in der folgenden Zeile anstelle von 50XX ein.<br />
port 50XX<br />
daemon tap0<br />
persist-tun<br />
up-delay<br />
down-pre<br />
up-restart<br />
script-security 2<br />
nobind<br />
ping 10<br />
ping-restart 60<br />
ping-timer-rem<br />
fast-io<br />
sndbuf 524288<br />
rcvbuf 524288<br />
mute 2<br />
verb 0<br />
up /etc/openvpn/funkfeuer-updown.sh<br />
down /etc/openvpn/funkfeuer-updown.sh<br />
secret /etc/openvpn/funkfeuer.secret<br />
auth none<br />
auth-cache none<br />
cipher none<br />
tun-mtu 1500<br />
mssfix<br />
<br />
Und je nach Deinen Gegebenheiten hinsichtlich der MTU<br />
#DSL mit PPPoE<br />
fragment 1464<br />
#mit Kompression *<br />
fragment 1460<br />
<br />
#DSL mit DHCP, Glasfaseranschluss, etc<br />
fragment 1472<br />
#mit Kompression <br />
fragment 1468<br />
<br />
'*) Soweit Dein Tunnel Kompression freigeschaltet bekommen hat, die Kompressionsart<br />
# Headerkomprimierung<br />
compress<br />
<br />
# lzo -Komprimierung<br />
compress lzo<br />
<br />
# lz4-v2 -Komprimierung<br />
compress lz4-v2<br />
<br />
<br />
In älteren Konfigurationen kann es sein, dass einige Zeilen anders sind: funkfeuer.conf:<br />
auth SHA256<br />
cipher none<br />
<br />
Diese Konfigurationsdatei benötigt also noch zwei weitere Dateien. Zum einen wäre das /etc/openvpn/funkfeuer-updown.sh. Dieses Skript wird von OpenVPN aufgerufen, sowie der Tunnel hergestellt oder beendet wird. OpenVPN übergibt diesem Skript Parameter, wie wir sie im Beispiel des Tunnelservers nützen. Für Deine Seite wird das nicht explizit erforderlich sein. Das Skript kann wie folgt aussehen:<br />
<br />
/etc/openvpn/funkfeuer-updown.sh:<br />
#!/bin/bash<br />
# br-ff ist die Bridge aus /etc/network/interfaces<br />
# $dev ist ein Parameter, den Openvpn übergibt. Hier zumeist „tap0“.<br />
br="br-ff"<br />
dev=$1<br />
logger "openvpn: $(echo $@)"<br />
logger "openvpn: $script_type"<br />
case $script_type in<br />
"down")<br />
/sbin/brctl delif $br $dev<br />
/sbin/ebtables -D FORWARD --logical-in ${br} -i ${dev} -j DROP<br />
/sbin/ip link set link dev $dev down<br />
;;<br />
"route-up")<br />
;;<br />
"up")<br />
/sbin/brctl addif $br $dev<br />
/sbin/ebtables -I FORWARD --logical-in ${br} -i ${dev} -j DROP<br />
/sbin/ip link set dev $br promisc on<br />
/sbin/ip link set link dev $dev up<br />
/sbin/ip link set link dev $br up<br />
;;<br />
esac<br />
echo $(date) $script_type $br.$dev $script_type>> /tmp/br-vpn.log<br />
exit 0<br />
<br />
<br />
Das Skript muss ausführbar gemacht werden. chmod +x /etc/openvpn/funkfeuer-updown.sh<br />
<br />
chmod +x /etc/openvpn/funkfeuer-updown.sh<br />
<br />
In der OpenVPN-Konfiguration haben wir den statischen Schlüssel mit /etc/openvpn/funkfeuer.secret angegeben. Exemplarisch schaut das so aus - aber den „echten Key“ bekommt ein Jeder individuell zugeteilt (bitte bei Erich P. anfordern):<br />
<br />
<br />
/etc/openvpn/funkfeuer.secret:<br />
#<br />
# 2048 bit OpenVPN static key<br />
#<br />
-----BEGIN OpenVPN Static key V1-----<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
-----END OpenVPN Static key V1-----<br />
<br />
<br />
Jetzt fehlt noch OLSR... Debian und Ubuntu verwenden /etc/init.d/olsrd als Startscript, das wiederum /etc/default/olsrd zu Initialisierung nutzt. Das Debian-Konzept geht noch von Adhoc-Netzen auf dem lokalen Gerät aus, kann also bis auf drei Zeilen ignoriert werden. Die Interface-Parameter lasse ich bewusst weg. Die Interfaces definiert man besser in der olsrd.conf, wo man individuelle Einstellungen tätigen kann (etwa unter anderem: ein per-Interface-Default-LQ-Multiplier, den Mode und die Gewichtung.)<br />
<br />
<br />
/etc/default/olsrd:<br />
START_OLSRD="YES"<br />
DEBUGLEVEL=0<br />
DAEMON_OPTS="-f /etc/olsrd/olsrd.conf -d $DEBUGLEVEL"<br />
<br />
<br />
Es fehlt noch die OSLR-Konfigurationsdatei (Vorsicht: ich verwende ein selbstkompiliertes OLSR und habe die plugin-Libraries „LoadPlugin“ hardgecodet; wenn der Pfad nicht stimmt, startet OLSR nicht, plaudert aber wirklich nicht darüber, was es stört.) -<br />
<br />
/etc/olsrd/olsrd.conf:<br />
AllowNoInt yes<br />
ClearScreen yes<br />
DebugLevel 0<br />
FIBMetric "flat"<br />
IpVersion 4<br />
LinkQualityAlgorithm "etx_ff"<br />
LinkQualityFishEye 1<br />
LinkQualityLevel 2<br />
MainIp [DIE MAIN-IP BEKOMMT IHR AUS DEM FUNKFEUER PORTAL, WENN IHR EIN GERÄT (DEVICE) ANLEGT]<br />
MprCoverage 1<br />
Pollrate 0.1<br />
TcRedundancy 2<br />
TosValue 16<br />
UseHysteresis no<br />
Willingness 3<br />
InterfaceDefaults<br />
{<br />
AutoDetectChanges yes<br />
HelloInterval 5.0<br />
HelloValidityTime 100.0<br />
TcInterval 2.0<br />
TcValidityTime 300.0<br />
MidInterval 50.0<br />
MidValidityTime 300.0<br />
HnaInterval 50.0<br />
HnaValidityTime 300.0<br />
Ip4Broadcast 255.255.255.255<br />
Mode "mesh"<br />
LinkQualityMult default 0.15<br />
Weight 99<br />
}<br />
Interface "br-ff"<br />
{<br />
AutoDetectChanges yes<br />
LinkQualityMult default 1.0<br />
Weight 0<br />
}<br />
Hna4<br />
{<br />
[SERVER-IP FALLS VORHANDEN - ZUWEISUNG VIA PORTAL] 255.255.255.255<br />
}<br />
LoadPlugin "olsrd_httpinfo.so.0.1"<br />
{<br />
PlParam "Port" "81"<br />
PlParam "Net" "0.0.0.0 0.0.0.0"<br />
PlParam "resolve" "false"<br />
}<br />
LoadPlugin "olsrd_txtinfo.so.1.1"<br />
{<br />
PlParam "port" "2006"<br />
PlParam "accept" "127.0.0.1"<br />
}<br />
LoadPlugin "olsrd_jsoninfo.so.1.1"<br />
{<br />
PlParam "port" "9090"<br />
PlParam "accept" "0.0.0.0"<br />
PlParam "UUIDFile" "/etc/olsrd/olsrd.uuid"<br />
}<br />
<br />
Damit ist eigentlich die Arbeit getan.<br />
<br />
=== 'the quick and dirty hack' für IPv6 ===<br />
<br />
Für OLSR mit IPv6 gibt es noch ein paar Tricks zu wissen und noch etwas mehr Handarbeit.<br />
Kopiere:<br />
<br />
* /etc/default/olsrd nach /etc/default/olsrd6<br />
** Ersetz jedes Vorkommen von olsr(d) durch olsr(d)6.<br />
<br />
mit vim wäre das so: vom input modus in den command modus wechseln (ESC) und in der command line folgendes eingeben: <br />
<br />
%s/olsrd/olsrd6/g<br />
<br />
12 ersetzungen sollten stattfinden. <br />
<br />
%s/OLSRD/OLSRD6/g<br />
<br />
selbiges gilt für die folgenden weiteren Dateien<br />
<br />
* /etc/init.d/olsrd nach /etc/init.d/olsrd6<br />
** Ersetz jedes Vorkommen von olsr(d) durch olsr(d)6. Ersetze /usr/sbin/olsrd durch /etc/alternatives/olsrd6<br />
* Setz einen Link von /usr/sbin/olsrd nach /etc/alternatives/olsrd6.<br />
<br />
ln -s /usr/sbin/olsrd /etc/alternatives/olsrd6<br />
<br />
Das hat den Sinn, dass der Prozess auch olsrd6 heißt, wenn er läuft und Du ihn mit dem pgrep im Startskript suchen kannst.<br />
<br />
* Leg /etc/olsrd/olsrd6.conf an - nachfolgend ein Beispiel.<br />
<br />
AllowNoInt yes<br />
ClearScreen yes<br />
DebugLevel 0<br />
FIBMetric "flat"<br />
IpVersion 6<br />
LinkQualityAlgorithm "etx_ff"<br />
LinkQualityFishEye 1<br />
LinkQualityLevel 2<br />
MprCoverage 1<br />
Pollrate 0.1<br />
TcRedundancy 2<br />
TosValue 16<br />
UseHysteresis no<br />
UseNiit yes<br />
Willingness 3<br />
InterfaceDefaults<br />
{<br />
#Ip6MulticastGlobal ff0e::1<br />
#Ip6MulticastSite ff05::11<br />
IPv6Multicast ff02::6d<br />
Weight 99<br />
AutoDetectChanges yes<br />
HelloInterval 50.0<br />
HelloValidityTime 100.0<br />
HnaInterval 50.0<br />
HnaValidityTime 300.0<br />
LinkQualityMult default 0.33 <br />
MidInterval 50.0<br />
MidValidityTime 300.0<br />
Mode "mesh"<br />
TcInterval 2.0 <br />
TcValidityTime 300.0<br />
Weight 99<br />
}<br />
Hna6<br />
{<br />
}<br />
LoadPlugin "olsrd_httpinfo.so.0.1"<br />
{<br />
PlParam "Net" "0::/0 2000::/3"<br />
PlParam "port" "82"<br />
}<br />
LoadPlugin "olsrd_jsoninfo.so.1.1"<br />
{<br />
PlParam "port" "9090"<br />
PlParam "accept" "::"<br />
PlParam "UUIDFile" "/etc/olsrd/olsrd6.uuid"<br />
PlParam "ipv6only" "true"<br />
}<br />
Interface "br-ff"<br />
{<br />
AutoDetectChanges yes<br />
LinkQualityMult default 0.25 <br />
Mode "ether"<br />
Weight 1<br />
IPv6Multicast ff02::6d<br />
}<br />
<br />
Sollte OLSR nicht starten wollen, liegt es entweder an einem Tippfehler oder an einer falsch formatierten IPv6-Adresse (::/0 oder 0::/0 je nach Plugin...) oder daran, dass olsrd seine Plugins nicht finden kann oder die falsche Version findet, wenn Du ein Update mit selbstkompiliertem OLSR gemacht haben solltest. Aufmerksam lesen und eventuell die LoadPlugin-Zeilen mit absoluten Pfaden zu der jeweiligen ".so" setzen, hilft.<br />
<br />
Es ist auch möglich die plugin sektion ganz wegzulassen, damit eliminiert man evtl ein weiteres Problem.<br />
diese können ja schrittweise bei funktionierender config nachträglich wieder eingefügt werden.<br />
<br />
Ein letzter Hinweis: OLSR wird noch nicht automatisch gestartet. Du kannst das in /etc/network/interfaces bei der Bridge br-ff mittels „up /etc/init.d/olsrd restart“ und „up /etc/init.d/olsrd6 restart“ tun, oder, Du legst die zwei Befehle in das OpenVPN-UP/DOWN-Skript. AutodetecChanges in OLSR sollte eigentlich dafür sorgen, dass der Bridge-Port immer erkannt wird, ohne, dass man den Dienst erneut starten muss.<br />
<br />
Das war's. Dual-Stack OLSRv1 mit Tunnel läuft, sowie Du es gestartet hast.</div>Erichhttps://wiki.funkfeuer.at/index.php?title=OpenVPN_mit_Debian/Ubuntu&diff=3175OpenVPN mit Debian/Ubuntu2020-11-19T17:00:43Z<p>Erich: </p>
<hr />
<div>Unter Debian installierst Du die Pakete für Openvpn und olsr.<br />
<br />
Voraussetzungen:<br />
* Aktuelles Debian Stable oder Ubuntu LTS<br />
* Pakete für OpenVPN, OLSR (und OLSRv2), bridge-utils<br />
* Funkfeuer-Login<br />
* Funkfeuer-IPv4-Adresse für das Tunneldevice respektive die Bridge aus [[https://portal.funkfeuer.at/wien REDEEMER/FRONTEND/PORTAL]]<br />
* Einen Taschenrechner, der Dezimalzahlen in Hexadezimalzahlen umrechnen kann („programmiertechnischer Modus“)<br />
* Die Funkfeuer NodeID des Knotens, dem der Tunnel zugeordnet wird. Wenn Du im Redeemer/Portal eingeloggt bist, und auf „Nodes“ und den richtigen Namen des Nodes klickst, siehst Du die NodeID in der URL in Deinem Browsers entweder so:<br />
** „&id=9999“ oder so<br />
** „id_nodes=9999“.<br />
Diese Zahl umgewandelt in „Hex“ brauchst Du später für Deine IPv6-Adresse.<br />
<br />
<br />
* apt-get install openvpn openvpn-blacklist olsrd olsrd-plugins bridge-utils ebtables<br />
<br />
Angenommen, Dein Debian oder Ubuntu-Rechner besitzt eine Ethernetschnittstelle eth0 (oder wie das heute eher der Fall ist, en[X]s[Y]), die in derselben Broadcastdomain wie das Provider-Modem liegt, dann wirst Du /etc/network/interfaces editieren und dort zunächst eine statische Route zum Tunnelserver anlegen wollen. Im selben Arbeitsschritt könntest Du auch festlegen, dass der Tunnel unmittelbar nach dem Start der Netzwerkschnittstelle aufgebaut wird. Es ist darüber hinaus zweckmäßig, OLSR auf einer Bridge laufen zu lassen, um sich etwaige OLSR-Neustarts zu ersparen. Wir legen also auch gleich eine Bridge an und weisen ihr die Funkfeuer-IPs für IPv4 und IPv6 (aber nur für 2a02:60::/40) zu. 192.168.1.1 ist in diesem Beispiel das Providermodem als Defaultgateway. Warum setzen wir aber eine Hostroute zu 78.41.118.150/32 oder 78.41.115.16/32? Ganz einfach: Olsr wird die Default-Route überschreiben. In aller Regel passiert dies mit einer Metrik von 2 und sollte nicht stören. Dennoch kommt es manchmal dazu, dass bei Fehlen der Hostroute der Tunnel quasi über sich selbst laufen soll - das funktioniert freilich nicht. Wenn Du aber auch eine Funkschnittstelle mit OLSR hast, dann läufst Du Gefahr, dass der Tunnel zu Funkfeuer über das Funkfeuer-Mesh aufgebaut würde, was absolut keinen Sinn ergibt. Daher die Hostroute.<br />
<br />
/etc/network/interfaces:<br />
iface eth0 inet static<br />
...<br />
up /sbin/ip r a 78.41.115.16/32 dev eth0 via 192.168.1.1 metric 0<br />
up /etc/init.d/openvpn restart<br />
<br />
auto br-ff <br />
iface br-ff inet static<br />
bridge_fd 0<br />
bridge_maxwait 0<br />
bridge_waitport 0<br />
bridge_stp no<br />
bridge_ports none<br />
address [REDEEMER-IP v4]<br />
netmask 255.255.255.255<br />
# IPv6/OLSRv1 Schema 2a02:60:01[Node ID in Hexadezimaldarstellung, erstes Oktett]:[Node ID in Hex, zweites Oktett][Router ID (4 Bit)][Interface ID (4 Bit)]::[irgendwas]<br />
# Nachfolgend für 9999 NodeID 9999(10) = 270F(16); Router 1, Interface 1 mit Adresse „feed“:<br />
post-up /sbin/ip -6 a a 2a02:60:1'''27''':'''0f'''''11''::feed/64 dev br-ff<br />
# Wenn man die MAC-Adresse der Bridge definiert, wirkt sich das auf die IPv6 EUI64-Adresse beginnend mit fe80::/12 aus.<br />
# Man kann sich eine zufällige MAC-Adresse [[https://www.miniwebtool.com/mac-address-generator/ MAC Address Generator]] (lowercase und ":"-Notation) errechnen lassen.<br />
post-up ip link set dev br-ff address bc:75:33:6a:bf:cf<br />
# Die Bridge soll allen Traffic annehmen.<br />
post-up ip link set dev br-ff promisc on<br />
<br />
<br />
Die Konfiguration von OpenVPN liegt bei Debian und Ubuntu üblicherweise in /etc/openvpn, wobei das Startup-Skript die Datei /etc/default/openvpn zu seiner Initialisierung heranzieht.<br />
<br />
/etc/default/openvpn:<br />
#AUTOSTART="all" -> <br />
AUTOSTART="all" <br />
oder<br />
#AUTOSTART="all" -><br />
AUTOSTART="funkfeuer"<br />
<br />
Somit erwartet OpenVPN seine Konfiguration in /etc/openvpn/funkfeuer.conf.<br />
<br />
Neue Konfiguration<br />
dev tap0<br />
proto udp<br />
remote 78.41.115.16<br />
# Die Portnummer XXXX wird Dir von den Tunnelserver-Administratoren zugewiesen, trag sie in der folgenden Zeile anstelle von 50XX ein.<br />
port 50XX<br />
daemon tap0<br />
persist-tun<br />
up-delay<br />
down-pre<br />
up-restart<br />
script-security 2<br />
nobind<br />
ping 10<br />
ping-restart 60<br />
ping-timer-rem<br />
fast-io<br />
sndbuf 524288<br />
rcvbuf 524288<br />
mute 2<br />
verb 0<br />
up /etc/openvpn/funkfeuer-updown.sh<br />
down /etc/openvpn/funkfeuer-updown.sh<br />
secret /etc/openvpn/funkfeuer.secret<br />
auth none<br />
auth-cache none<br />
cipher none<br />
tun-mtu 1500<br />
mssfix<br />
<br />
Und je nach Deinen Gegebenheiten hinsichtlich der MTU<br />
#DSL mit PPPoE<br />
fragment 1464<br />
#mit Kompression *<br />
fragment 1460<br />
<br />
#DSL mit DHCP, Glasfaseranschluss, etc<br />
fragment 1472<br />
#mit Kompression <br />
fragment 1468<br />
<br />
'*) Soweit Dein Tunnel Kompression freigeschaltet bekommen hat, die Kompressionsart<br />
# Headerkomprimierung<br />
compress<br />
<br />
# lzo -Komprimierung<br />
compress lzo<br />
<br />
# lz4-v2 -Komprimierung<br />
compress lz4-v2<br />
<br />
<br />
veraltet, aber noch bei einigen Tunneln in Verwendung /etc/openvpn/funkfeuer.conf:<br />
dev tap0<br />
proto udp<br />
remote 78.41.115.16<br />
# Variante: remote 78.41.118.150 <br />
# Die Portnummer XXXX wird Dir von den Tunnelserver-Administratoren zugewiesen, trag sie in der folgenden Zeile anstelle von XXXX ein.<br />
port XXXX<br />
daemon tap0<br />
persist-tun<br />
up-delay<br />
down-pre<br />
up-restart<br />
comp-lzo<br />
script-security 2<br />
nobind<br />
ping 10<br />
ping-restart 60<br />
ping-timer-rem<br />
fast-io<br />
sndbuf 524288<br />
rcvbuf 524288<br />
mute 2<br />
verb 0<br />
up /etc/openvpn/funkfeuer-updown.sh<br />
down /etc/openvpn/funkfeuer-updown.sh<br />
secret /etc/openvpn/funkfeuer.secret<br />
auth SHA256<br />
cipher none<br />
<br />
Diese Konfigurationsdatei benötigt also noch zwei weitere Dateien. Zum einen wäre das /etc/openvpn/funkfeuer-updown.sh. Dieses Skript wird von OpenVPN aufgerufen, sowie der Tunnel hergestellt oder beendet wird. OpenVPN übergibt diesem Skript Parameter, wie wir sie im Beispiel des Tunnelservers nützen. Für Deine Seite wird das nicht explizit erforderlich sein. Das Skript kann wie folgt aussehen:<br />
<br />
/etc/openvpn/funkfeuer-updown.sh:<br />
#!/bin/bash<br />
# br-ff ist die Bridge aus /etc/network/interfaces<br />
# $dev ist ein Parameter, den Openvpn übergibt. Hier zumeist „tap0“.<br />
br="br-ff"<br />
dev=$1<br />
logger "openvpn: $(echo $@)"<br />
logger "openvpn: $script_type"<br />
case $script_type in<br />
"down")<br />
/sbin/brctl delif $br $dev<br />
/sbin/ebtables -D FORWARD --logical-in ${br} -i ${dev} -j DROP<br />
/sbin/ip link set link dev $dev down<br />
;;<br />
"route-up")<br />
;;<br />
"up")<br />
/sbin/brctl addif $br $dev<br />
/sbin/ebtables -I FORWARD --logical-in ${br} -i ${dev} -j DROP<br />
/sbin/ip link set dev $br promisc on<br />
/sbin/ip link set link dev $dev up<br />
/sbin/ip link set link dev $br up<br />
;;<br />
esac<br />
echo $(date) $script_type $br.$dev $script_type>> /tmp/br-vpn.log<br />
exit 0<br />
<br />
<br />
Das Skript muss ausführbar gemacht werden. chmod +x /etc/openvpn/funkfeuer-updown.sh<br />
<br />
chmod +x /etc/openvpn/funkfeuer-updown.sh<br />
<br />
In der OpenVPN-Konfiguration haben wir den statischen Schlüssel mit /etc/openvpn/funkfeuer.secret angegeben. Exemplarisch schaut das so aus - aber den „echten Key“ bekommt ein Jeder individuell zugeteilt (bitte bei Erich P. anfordern):<br />
<br />
<br />
/etc/openvpn/funkfeuer.secret:<br />
#<br />
# 2048 bit OpenVPN static key<br />
#<br />
-----BEGIN OpenVPN Static key V1-----<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
-----END OpenVPN Static key V1-----<br />
<br />
<br />
Jetzt fehlt noch OLSR... Debian und Ubuntu verwenden /etc/init.d/olsrd als Startscript, das wiederum /etc/default/olsrd zu Initialisierung nutzt. Das Debian-Konzept geht noch von Adhoc-Netzen auf dem lokalen Gerät aus, kann also bis auf drei Zeilen ignoriert werden. Die Interface-Parameter lasse ich bewusst weg. Die Interfaces definiert man besser in der olsrd.conf, wo man individuelle Einstellungen tätigen kann (etwa unter anderem: ein per-Interface-Default-LQ-Multiplier, den Mode und die Gewichtung.)<br />
<br />
<br />
/etc/default/olsrd:<br />
START_OLSRD="YES"<br />
DEBUGLEVEL=0<br />
DAEMON_OPTS="-f /etc/olsrd/olsrd.conf -d $DEBUGLEVEL"<br />
<br />
<br />
Es fehlt noch die OSLR-Konfigurationsdatei (Vorsicht: ich verwende ein selbstkompiliertes OLSR und habe die plugin-Libraries „LoadPlugin“ hardgecodet; wenn der Pfad nicht stimmt, startet OLSR nicht, plaudert aber wirklich nicht darüber, was es stört.) -<br />
<br />
/etc/olsrd/olsrd.conf:<br />
AllowNoInt yes<br />
ClearScreen yes<br />
DebugLevel 0<br />
FIBMetric "flat"<br />
IpVersion 4<br />
LinkQualityAlgorithm "etx_ff"<br />
LinkQualityFishEye 1<br />
LinkQualityLevel 2<br />
MainIp [DIE MAIN-IP BEKOMMT IHR AUS DEM FUNKFEUER PORTAL, WENN IHR EIN GERÄT (DEVICE) ANLEGT]<br />
MprCoverage 1<br />
Pollrate 0.1<br />
TcRedundancy 2<br />
TosValue 16<br />
UseHysteresis no<br />
Willingness 3<br />
InterfaceDefaults<br />
{<br />
AutoDetectChanges yes<br />
HelloInterval 5.0<br />
HelloValidityTime 100.0<br />
TcInterval 2.0<br />
TcValidityTime 300.0<br />
MidInterval 50.0<br />
MidValidityTime 300.0<br />
HnaInterval 50.0<br />
HnaValidityTime 300.0<br />
Ip4Broadcast 255.255.255.255<br />
Mode "mesh"<br />
LinkQualityMult default 0.15<br />
Weight 99<br />
}<br />
Interface "br-ff"<br />
{<br />
AutoDetectChanges yes<br />
LinkQualityMult default 1.0<br />
Weight 0<br />
}<br />
Hna4<br />
{<br />
[SERVER-IP FALLS VORHANDEN - ZUWEISUNG VIA PORTAL] 255.255.255.255<br />
}<br />
LoadPlugin "olsrd_httpinfo.so.0.1"<br />
{<br />
PlParam "Port" "81"<br />
PlParam "Net" "0.0.0.0 0.0.0.0"<br />
PlParam "resolve" "false"<br />
}<br />
LoadPlugin "olsrd_txtinfo.so.1.1"<br />
{<br />
PlParam "port" "2006"<br />
PlParam "accept" "127.0.0.1"<br />
}<br />
LoadPlugin "olsrd_jsoninfo.so.1.1"<br />
{<br />
PlParam "port" "9090"<br />
PlParam "accept" "0.0.0.0"<br />
PlParam "UUIDFile" "/etc/olsrd/olsrd.uuid"<br />
}<br />
<br />
Damit ist eigentlich die Arbeit getan.<br />
<br />
=== 'the quick and dirty hack' für IPv6 ===<br />
<br />
Für OLSR mit IPv6 gibt es noch ein paar Tricks zu wissen und noch etwas mehr Handarbeit.<br />
Kopiere:<br />
<br />
* /etc/default/olsrd nach /etc/default/olsrd6<br />
** Ersetz jedes Vorkommen von olsr(d) durch olsr(d)6.<br />
<br />
mit vim wäre das so: vom input modus in den command modus wechseln (ESC) und in der command line folgendes eingeben: <br />
<br />
%s/olsrd/olsrd6/g<br />
<br />
12 ersetzungen sollten stattfinden. <br />
<br />
%s/OLSRD/OLSRD6/g<br />
<br />
selbiges gilt für die folgenden weiteren Dateien<br />
<br />
* /etc/init.d/olsrd nach /etc/init.d/olsrd6<br />
** Ersetz jedes Vorkommen von olsr(d) durch olsr(d)6. Ersetze /usr/sbin/olsrd durch /etc/alternatives/olsrd6<br />
* Setz einen Link von /usr/sbin/olsrd nach /etc/alternatives/olsrd6.<br />
<br />
ln -s /usr/sbin/olsrd /etc/alternatives/olsrd6<br />
<br />
Das hat den Sinn, dass der Prozess auch olsrd6 heißt, wenn er läuft und Du ihn mit dem pgrep im Startskript suchen kannst.<br />
<br />
* Leg /etc/olsrd/olsrd6.conf an - nachfolgend ein Beispiel.<br />
<br />
AllowNoInt yes<br />
ClearScreen yes<br />
DebugLevel 0<br />
FIBMetric "flat"<br />
IpVersion 6<br />
LinkQualityAlgorithm "etx_ff"<br />
LinkQualityFishEye 1<br />
LinkQualityLevel 2<br />
MprCoverage 1<br />
Pollrate 0.1<br />
TcRedundancy 2<br />
TosValue 16<br />
UseHysteresis no<br />
UseNiit yes<br />
Willingness 3<br />
InterfaceDefaults<br />
{<br />
#Ip6MulticastGlobal ff0e::1<br />
#Ip6MulticastSite ff05::11<br />
IPv6Multicast ff02::6d<br />
Weight 99<br />
AutoDetectChanges yes<br />
HelloInterval 50.0<br />
HelloValidityTime 100.0<br />
HnaInterval 50.0<br />
HnaValidityTime 300.0<br />
LinkQualityMult default 0.33 <br />
MidInterval 50.0<br />
MidValidityTime 300.0<br />
Mode "mesh"<br />
TcInterval 2.0 <br />
TcValidityTime 300.0<br />
Weight 99<br />
}<br />
Hna6<br />
{<br />
}<br />
LoadPlugin "olsrd_httpinfo.so.0.1"<br />
{<br />
PlParam "Net" "0::/0 2000::/3"<br />
PlParam "port" "82"<br />
}<br />
LoadPlugin "olsrd_jsoninfo.so.1.1"<br />
{<br />
PlParam "port" "9090"<br />
PlParam "accept" "::"<br />
PlParam "UUIDFile" "/etc/olsrd/olsrd6.uuid"<br />
PlParam "ipv6only" "true"<br />
}<br />
Interface "br-ff"<br />
{<br />
AutoDetectChanges yes<br />
LinkQualityMult default 0.25 <br />
Mode "ether"<br />
Weight 1<br />
IPv6Multicast ff02::6d<br />
}<br />
<br />
Sollte OLSR nicht starten wollen, liegt es entweder an einem Tippfehler oder an einer falsch formatierten IPv6-Adresse (::/0 oder 0::/0 je nach Plugin...) oder daran, dass olsrd seine Plugins nicht finden kann oder die falsche Version findet, wenn Du ein Update mit selbstkompiliertem OLSR gemacht haben solltest. Aufmerksam lesen und eventuell die LoadPlugin-Zeilen mit absoluten Pfaden zu der jeweiligen ".so" setzen, hilft.<br />
<br />
Es ist auch möglich die plugin sektion ganz wegzulassen, damit eliminiert man evtl ein weiteres Problem.<br />
diese können ja schrittweise bei funktionierender config nachträglich wieder eingefügt werden.<br />
<br />
Ein letzter Hinweis: OLSR wird noch nicht automatisch gestartet. Du kannst das in /etc/network/interfaces bei der Bridge br-ff mittels „up /etc/init.d/olsrd restart“ und „up /etc/init.d/olsrd6 restart“ tun, oder, Du legst die zwei Befehle in das OpenVPN-UP/DOWN-Skript. AutodetecChanges in OLSR sollte eigentlich dafür sorgen, dass der Bridge-Port immer erkannt wird, ohne, dass man den Dienst erneut starten muss.<br />
<br />
Das war's. Dual-Stack OLSRv1 mit Tunnel läuft, sowie Du es gestartet hast.</div>Erichhttps://wiki.funkfeuer.at/index.php?title=OpenVPN_mit_EdgeRouter_X-SFP&diff=3174OpenVPN mit EdgeRouter X-SFP2020-11-19T00:56:17Z<p>Erich: </p>
<hr />
<div>Die allgemeinen Voraussetzungen zum Einrichten eines Tunnels sind in der Übersichtsseite dargestellt. Dieser Artikel geht nur auf die rudimentäre Konfiguration des [[Hardware/EdgeRouter_X-SFP EdgeRouter ein.<br />
Update 02/2018: ein EdgeOS-Wizard hierfür ist in Entwicklung: https://github.com/pocki80/ER-wizard-0xFF-OpenVPN2TS<br />
<br />
== Einrichten des Tunnels ==<br />
<br />
Empfohlen wird, die Konfigurationsdateien und das Skript zuerst auf dem Computer anzulegen, und diese gemeinsam in der Folge per SSH ins Verzeichnis /config/user-data/ zu kopieren. Alternativ über das CLI wie vi anlegen. Wir benötigen:<br />
<br />
1) funkfeuer.ovpn mit folgendem Inhalt - die kursiv dargestellten Zeilen musst Du mit jenen Werten befüllen, die Du von den Tunneladmins zugewiesen bekommen hast:<br />
<br />
dev vtun0<br />
dev-type tap<br />
proto udp4<br />
remote 78.41.115.16<br />
''port [5XXX]''<br />
up-delay<br />
down-pre<br />
up-restart<br />
script-security 2<br />
nobind<br />
ping 10<br />
ping-restart 60<br />
ping-timer-rem<br />
fast-io<br />
sndbuf 524288 <br />
rcvbuf 524288<br />
mute 2<br />
verb 0<br />
secret /config/user-data/funkfeuer.secret<br />
cipher none<br />
auth none<br />
<br />
<br />
Zusätzlich, wenn es erforderlich ist, kannst Du die MTU anpassen wie folgt:<br />
tun-mtu 1500<br />
mssfix<br />
'''UND'''<br />
a) für eine MTU von 1500 Byte (1472 Byte Nutzlast + 20 Byte IP Header + 8 Byte UDP Header):<br />
fragment 1472<br />
<br />
b) bei PPPoE, etwa bei DSL mit einer Fritzbox (1464 Byte Nutzlast + 20 Byte IP Header + 8 Byte UDP Header + 8 Byte PPPoE Header):<br />
fragment 1464<br />
<br />
c) bei anderen Anschlüssen je nach ermitteltem MTU-Wert. Unter EdgeOS, wie auch unter Linux geht das mit<br />
configure<br />
sudo su<br />
ping -Mdo -c1 -s1472 78.41.115.16<br />
- wenn der Befehl einen Zeitwert zurückliefert, ist 1472 OK - siehe a), sonst den Wert um je 2 Byte reduzieren (1470, 1468..., 1252), bis der Ping erfolgreich ist.<br />
Den so ermittelten Wert nennst Du bitte Deinem jeweiligen Ansprechpartner im Tunnelserver-Team, denn Änderungen an der MTU müssen auf beiden Seiten des Tunnels identisch sein.<br />
<br />
Sollte Kompression eingesetzt werden, ist der ermittelte Wert um weitere 4 Byte für die Kompressionsheader zu reduzieren.<br />
Der Parameter "fragment" lautet dann also 1468 bei 1472 für eine Leitungs-MTU 1500 oder 1460 für 1464, was einer Leitungs-MTU von 1492 entspricht.<br />
<br />
<br />
Auf Glasfaserleitungen mit 100 Mbit/s (symmetrisch) kann zusätzlich eingetragen werden:<br />
txqueuelen 10000<br />
<br />
<br />
2) funkfeuer.secret - wenn ein Key angelegt wurde, wie in 1) beschrieben.<br />
<br />
Diese Datei beinhaltet einen individuellen kryptographischen Schlüssel (shared key), der sicherstellt, dass der Tunnel nur von jenen Clients genutzt werden kann, denen er auch tatsächlich zugewiesen wurde. Das soll verhindern, dass ein Tunnel missbräuchlich oder versehentlich mehrfach genützt wird.<br />
Diesen Schlüssel erhältst Du per E-Mail und Du musst ihn lediglich in dieser Datei speichern. <br />
<br />
3) Folgende Config am EdgeRouter vornehmen (lokalen Gateway für Static-Route entsprechend ändern)<br />
<br />
set interfaces bridge br9 address [zugeteilte IP Adresse aus dem Redeemer]/32<br />
set interfaces bridge br9 aging 300<br />
set interfaces bridge br9 bridged-conntrack disable<br />
set interfaces bridge br9 description TUNNEL<br />
set interfaces bridge br9 hello-time 2<br />
set interfaces bridge br9 max-age 20<br />
set interfaces bridge br9 priority 32768<br />
set interfaces bridge br9 stp false<br />
commit<br />
set protocols static route 78.41.115.16/32 next-hop 192.168.0.1 description 'TunnelServer via ISP'<br />
set interfaces openvpn vtun0 config-file /config/user-data/funkfeuer.ovpn<br />
commit<br />
save<br />
<br />
4) Im OLSRd_V1 Wizard für das Interface br9 für OLSR aktivieren. Mode "mesh" kann man bei bedarf auf "silent" umstellen, um Bandbreite zu sparen. Das geht aber nur, wenn der VON-Router keine weiteren OLSR-Router "hinter sich" hat: diese sind dann nur erreichbar, wenn es einen weiteren Pfad (übers Mesh-Netz) bis um Tunnelserver gibt. Das ist nur für Router mit Tunnel und beschränktem Datenvolumen sinnvoll, wenn sie '''nur''' den Tunnel als Partner haben.</div>Erichhttps://wiki.funkfeuer.at/index.php?title=OpenVPN_mit_EdgeRouter_X-SFP&diff=3172OpenVPN mit EdgeRouter X-SFP2020-11-18T22:59:01Z<p>Erich: </p>
<hr />
<div>Die allgemeinen Voraussetzungen zum Einrichten eines Tunnels sind in der Übersichtsseite dargestellt. Dieser Artikel geht nur auf die rudimentäre Konfiguration des [[Hardware/EdgeRouter_X-SFP EdgeRouter ein.<br />
Update 02/2018: ein EdgeOS-Wizard hierfür ist in Entwicklung: https://github.com/pocki80/ER-wizard-0xFF-OpenVPN2TS<br />
<br />
== Einrichten des Tunnels ==<br />
<br />
Empfohlen wird, die Konfigurationsdateien und das Skript zuerst auf dem Computer anzulegen, und diese gemeinsam in der Folge per SSH ins Verzeichnis /config/user-data/ zu kopieren. Alternativ über das CLI wie vi anlegen. Wir benötigen:<br />
<br />
1) funkfeuer.ovpn mit folgendem Inhalt - die kursiv dargestellten Zeilen musst Du mit jenen Werten befüllen, die Du von den Tunneladmins zugewiesen bekommen hast:<br />
<br />
dev vtun0<br />
dev-type tap<br />
proto udp4<br />
remote 78.41.115.16<br />
''port [5XXX]''<br />
up-delay<br />
down-pre<br />
up-restart<br />
script-security 2<br />
nobind<br />
ping 10<br />
ping-restart 60<br />
ping-timer-rem<br />
fast-io<br />
sndbuf 524288 <br />
rcvbuf 524288<br />
mute 2<br />
verb 0<br />
secret /config/user-data/funkfeuer.secret<br />
cipher none<br />
auth none<br />
<br />
<br />
<br />
Zusätzlich, wenn es erforderlich ist, die MTU anzupassen wie folgt<br />
tun-mtu 1500<br />
mssfix<br />
UND<br />
a) für eine MTU von 1500 Byte (1472 Byte Nutzlast + 20 Byte IP Header + 8 Byte UDP Header):<br />
fragment 1472<br />
<br />
b) bei PPPoE, etwa bei DSL mit einer Fritzbox (1464 Byte Nutzlast + 20 Byte IP Header + 8 Byte UDP Header + 8 Byte PPPoE Header):<br />
fragment 1464<br />
<br />
c) bei anderen Anschlüssen je nach ermitteltem MTU-Wert. Unter EdgeOS, wie auch unter Linux geht das mit<br />
configure<br />
sudo su<br />
ping -Mdo -c1 -s1472 78.41.115.16<br />
- wenn der Befehl einen Zeitwert zurückliefert, ist 1472 OK - siehe a), sonst den Wert um je 2 Byte reduzieren (1470, 1468..., 1252), bis der Ping erfolgreich ist.<br />
Den so ermittelten Wert nennst Du bitte Deinem jeweiligen Ansprechpartner im Tunnelserver-Team, denn Änderungen an der MTU müssen auf beiden Seiten des Tunnels identisch sein.<br />
<br />
Sollte Kompression eingesetzt werden, ist der ermittelte Wert um weitere 4 Byte für die Kompressionsheader zu reduzieren.<br />
Der Parameter "fragmetn" lautet dann also 1468 bei 1472 für eine Leitungs-MTU 1500 oder 1460 für 1464, was einer Leitungs-MTU von 1492 entspricht.<br />
<br />
<br />
<br />
<br />
Auf Glasfaserleitungen mit 100 Mbit/s (symmetrisch) kann zusätzlich eingetragen werden:<br />
txqueuelen 10000<br />
<br />
<br />
2) funkfeuer.secret - wenn ein Key angelegt wurde, wie in 1) beschrieben.<br />
<br />
Diese Datei beinhaltet einen individuellen kryptographischen Schlüssel (shared key), der sicherstellt, dass der Tunnel nur von jenen Clients genutzt werden kann, denen er auch tatsächlich zugewiesen wurde. Das soll verhindern, dass ein Tunnel missbräuchlich oder versehentlich mehrfach genützt wird.<br />
Diesen Schlüssel erhältst Du per E-Mail und Du musst ihn lediglich in dieser Datei speichern. <br />
<br />
3) Folgende Config am EdgeRouter vornehmen (lokalen Gateway für Static-Route entsprechend ändern)<br />
<br />
set interfaces bridge br9 address [zugeteilte IP Adresse aus dem Redeemer]/32<br />
set interfaces bridge br9 aging 300<br />
set interfaces bridge br9 bridged-conntrack disable<br />
set interfaces bridge br9 description TUNNEL<br />
set interfaces bridge br9 hello-time 2<br />
set interfaces bridge br9 max-age 20<br />
set interfaces bridge br9 priority 32768<br />
set interfaces bridge br9 stp false<br />
commit<br />
set protocols static route 78.41.115.16/32 next-hop 192.168.0.1 description 'TunnelServer via ISP'<br />
set interfaces openvpn vtun0 config-file /config/user-data/funkfeuer.ovpn<br />
commit<br />
save<br />
<br />
4) Im OLSRd_V1 Wizard für das Interface br9 für OLSR aktivieren. Mode "mesh" kann man bei bedarf auf "silent" umstellen, um Bandbreite zu sparen. Das geht aber nur, wenn der VON-Router keine weiteren OLSR-Router "hinter sich" hat: diese sind dann nur erreichbar, wenn es einen weitern Pfad (übers Mesh-Netz) bis um Tunnelserver gibt. Das ist nur für Router mit Tunnel und beschränktem Datenvolumen sinnvoll, wenn sie '''nur''' den Tunnel als Partner haben.</div>Erichhttps://wiki.funkfeuer.at/index.php?title=OpenVPN_mit_EdgeRouter_X-SFP&diff=3171OpenVPN mit EdgeRouter X-SFP2020-11-18T22:58:04Z<p>Erich: </p>
<hr />
<div>Die allgemeinen Voraussetzungen zum Einrichten eines Tunnels sind in der Übersichtsseite dargestellt. Dieser Artikel geht nur auf die rudimentäre Konfiguration des [[Hardware/EdgeRouter_X-SFP EdgeRouter ein.<br />
Update 02/2018: ein EdgeOS-Wizard hierfür ist in Entwicklung: https://github.com/pocki80/ER-wizard-0xFF-OpenVPN2TS<br />
<br />
== Einrichten des Tunnels ==<br />
<br />
Empfohlen wird, die Konfigurationsdateien und das Skript zuerst auf dem Computer anzulegen, und diese gemeinsam in der Folge per SSH ins Verzeichnis /config/user-data/ zu kopieren. Alternativ über das CLI wie vi anlegen. Wir benötigen:<br />
<br />
1) funkfeuer.ovpn mit folgendem Inhalt - die kursiv dargestellten Zeilen musst Du mit jenen Werten befüllen, die Du von den Tunneladmins zugewiesen bekommen hast:<br />
<br />
dev vtun0<br />
dev-type tap<br />
proto udp4<br />
remote 78.41.115.16<br />
''port [5XXX]''<br />
up-delay<br />
down-pre<br />
up-restart<br />
script-security 2<br />
nobind<br />
ping 10<br />
ping-restart 60<br />
ping-timer-rem<br />
fast-io<br />
sndbuf 524288 <br />
rcvbuf 524288<br />
mute 2<br />
verb 0<br />
secret /config/user-data/funkfeuer.secret<br />
cipher none<br />
auth none<br />
<br />
<br />
<br />
Zusätzlich, wenn es erforderlich ist, die MTU anzupassen wie folgt<br />
tun-mtu 1500<br />
mssfix<br />
UND<br />
a) für eine MTU von 1500 Byte (1472 Byte Nutzlast + 20 Byte IP Header + 8 Byte UDP Header):<br />
fragment 1472<br />
<br />
b) bei PPPoE, etwa bei DSL mit einer Fritzbox (1464 Byte Nutzlast + 20 Byte IP Header + 8 Byte UDP Header + 8 Byte PPPoE Header):<br />
fragment 1464<br />
<br />
c) bei anderen Anschlüssen je nach ermitteltem MTU-Wert. Unter EdgeOS, wie auch unter Linux geht das mit<br />
configure<br />
sudo su<br />
ping -Mdo -c1 -s1472 78.41.115.16<br />
- wenn der Befehl einen Zeitwert zurückliefert, ist 1472 OK - siehe a), sonst den Wert um je 2 Byte reduzieren (1470, 1468..., 1252), bis der Ping erfolgreich ist.<br />
Den so ermittelten Wert nennst Du bitte Deinem jeweiligen Ansprechpartner im Tunnelserver-Team, denn Änderungen an der MTU müssen auf beiden Seiten des Tunnels identisch sein.<br />
<br />
Sollte Kompression eingesetzt werden, ist der ermittelte Wert um weitere 4 Byte für die Kompressionsheader zu reduzieren.<br />
Der Parameter "fragmetn" lautet dann also 1468 bei 1472 für eine Leitungs-MTU 1500 oder 1460 für 1464, was einer Leitungs-MTU von 1492 entspricht.<br />
<br />
<br />
<br />
<br />
Auf Glasfaserleitungen mit 100 Mbit/s (symmetrisch) kann zusätzlich eingetragen werden:<br />
txqueuelen 10000<br />
<br />
<br />
2) funkfeuer.secret - wenn ein Key angelegt wurde, wie in 1) beschrieben.<br />
<br />
Diese Datei beinhaltet einen individuellen kryptographischen Schlüssel (shared key), der sicherstellt, dass der Tunnel nur von jenen Clients genutzt werden kann, denen er auch tatsächlich zugewiesen wurde. Das soll verhindern, dass ein Tunnel missbräuchlich oder versehentlich mehrfach genützt wird.<br />
Diesen Schlüssel erhältst Du per E-Mail und Du musst ihn lediglich in dieser Datei speichern. <br />
<br />
3) Folgende Config am EdgeRouter vornehmen (lokalen Gateway für Static-Route entsprechend ändern)<br />
<br />
set interfaces bridge br9 address 78.41.000.000/32<br />
set interfaces bridge br9 aging 300<br />
set interfaces bridge br9 bridged-conntrack disable<br />
set interfaces bridge br9 description TUNNEL<br />
set interfaces bridge br9 hello-time 2<br />
set interfaces bridge br9 max-age 20<br />
set interfaces bridge br9 priority 32768<br />
set interfaces bridge br9 stp false<br />
commit<br />
set protocols static route 78.41.115.16/32 next-hop 192.168.0.1 description 'TunnelServer via ISP'<br />
set interfaces openvpn vtun0 config-file /config/user-data/funkfeuer.ovpn<br />
commit<br />
save<br />
<br />
4) Im OLSRd_V1 Wizard für das Interface br9 für OLSR aktivieren. Mode "mesh" kann man bei bedarf auf "silent" umstellen, um Bandbreite zu sparen. Das geht aber nur, wenn der VON-Router keine weiteren OLSR-Router "hinter sich" hat: diese sind dann nur erreichbar, wenn es einen weitern Pfad (übers Mesh-Netz) bis um Tunnelserver gibt. Das ist nur für Router mit Tunnel und beschränktem Datenvolumen sinnvoll, wenn sie '''nur''' den Tunnel als Partner haben.</div>Erichhttps://wiki.funkfeuer.at/index.php?title=Services/Organisation/Tunnelserver&diff=2822Services/Organisation/Tunnelserver2020-05-09T23:24:33Z<p>Erich: /* Abhängigkeiten */</p>
<hr />
<div>{{Projekt<br />
|name=Tunnelserver.freiesnetz.wien.funkfeuer.at<br />
|startdate=2017/09/20<br />
|state=Aktiv<br />
|desc=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.<br />
}}<br />
<br />
== Beschreibung ==<br />
<br />
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. <br />
<br />
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.<br />
<br />
== Maintainer ==<br />
* [[Benutzer:erich|Erich N. Pekarek]]<br />
* [[Benutzer:vchrizz|Christoph Lösch]]<br />
* [[Benutzer:Pocki|Christian Pock]]<br />
* [[Benutzer:damadmai|Daniel A. Maierhofer]]<br />
<br />
== Abhängigkeiten ==<br />
<br />
Das Tunnelserverprojekt ist von folgenden Projektgruppen abhängig:<br />
<br />
* Core-Team/Roofnode-Team<br />
* v642-Projekt<br />
* Housing/VM<br />
<br />
<s>Um die wechselseitigen Abhängigkeiten zu reduzieren, lautet der aktuelle Projektfahrplan wie folgt:<br />
Den gegenwärtigen Tunnelserver, der leider auch andere, systemrelevante Aufgaben erledigt, in mehreren Schritten zu migrieren.<br />
* Vorbereitungen:<br />
** Sämtliche Tunnelfunktionen von Tunnel6 und Tunnel auf der „VM-Tunnel6“ zu vereinen.<br />
** Tests neuer Funktionen.<br />
* Hauptphase: Die vereinte VM wird auf eine physische Hardware migriert. Diese Maschine wird wie ein Roofnode mit erhöhter Redundanz eingebunden werden.<br />
* Nacharbeiten:<br />
** Anschließend die VM „Tunnel 6“ stilllegen.<br />
** Die Routing-Funktionen der „VM Tunnel” auf die neuen Roofnodes oder andere Router so verteilen, wie es sinnvoll ist.<br />
** Die VM „Tunnel“ anschließend stilllegen.<br />
</s><br />
* Dauerarbeiten: Wartung und Betreuung.<br />
<br />
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. <s>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.</s> Gegenwärtig nützt nur noch Knoten OZW OLSRv1 mit IPv6 aus dem Prefix 2a02:60:100::/40.<br />
<br />
== Details ==<br />
Gegenwärtiger Status:<br />
<s>* Tunnel VM hat Aufgaben von Tunnel6 vorübergehend übernommen.</s><br />
<s>* 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.</s><br />
<s>* Die physische Maschine ist bereits rudimentär eingerichtet.</s><br />
* 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.<br />
* Migration abgeschlossen, Regelbetrieb.<br />
* Bedarf an einem neuen Tunnel oder Änderungswünsche können u.a. unter https://forum.funkfeuer.at/t/tunnelserver-fuer-funkinseln-und-backuplinks/261 eingemeldet werden. Das Maintainer-Team kümmert sich darum.<br />
<br />
== Verwendung ==<br />
[[OpenVPN-Tunnel_zu_FunkFeuer]]</div>Erichhttps://wiki.funkfeuer.at/index.php?title=Services/Organisation/Tunnelserver&diff=2821Services/Organisation/Tunnelserver2020-05-09T23:20:53Z<p>Erich: /* Details */</p>
<hr />
<div>{{Projekt<br />
|name=Tunnelserver.freiesnetz.wien.funkfeuer.at<br />
|startdate=2017/09/20<br />
|state=Aktiv<br />
|desc=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.<br />
}}<br />
<br />
== Beschreibung ==<br />
<br />
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. <br />
<br />
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.<br />
<br />
== Maintainer ==<br />
* [[Benutzer:erich|Erich N. Pekarek]]<br />
* [[Benutzer:vchrizz|Christoph Lösch]]<br />
* [[Benutzer:Pocki|Christian Pock]]<br />
* [[Benutzer:damadmai|Daniel A. Maierhofer]]<br />
<br />
== Abhängigkeiten ==<br />
<br />
Das Tunnelserverprojekt ist von folgenden Projektgruppen abhängig:<br />
<br />
* Core-Team/Roofnode-Team<br />
* v642-Projekt<br />
* Housing/VM<br />
<br />
<s>Um die wechselseitigen Abhängigkeiten zu reduzieren, lautet der aktuelle Projektfahrplan wie folgt:<br />
Den gegenwärtigen Tunnelserver, der leider auch andere, systemrelevante Aufgaben erledigt, in mehreren Schritten zu migrieren.<br />
* Vorbereitungen:<br />
** Sämtliche Tunnelfunktionen von Tunnel6 und Tunnel auf der „VM-Tunnel6“ zu vereinen.<br />
** Tests neuer Funktionen.<br />
* Hauptphase: Die vereinte VM wird auf eine physische Hardware migriert. Diese Maschine wird wie ein Roofnode mit erhöhter Redundanz eingebunden werden.<br />
* Nacharbeiten:<br />
** Anschließend die VM „Tunnel 6“ stilllegen.<br />
** Die Routing-Funktionen der „VM Tunnel” auf die neuen Roofnodes oder andere Router so verteilen, wie es sinnvoll ist.<br />
** Die VM „Tunnel“ anschließend stilllegen.<br />
</s><br />
* Dauerarbeiten: Wartung und Betreuung.<br />
<br />
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.<br />
<br />
== Details ==<br />
Gegenwärtiger Status:<br />
<s>* Tunnel VM hat Aufgaben von Tunnel6 vorübergehend übernommen.</s><br />
<s>* 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.</s><br />
<s>* Die physische Maschine ist bereits rudimentär eingerichtet.</s><br />
* 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.<br />
* Migration abgeschlossen, Regelbetrieb.<br />
* Bedarf an einem neuen Tunnel oder Änderungswünsche können u.a. unter https://forum.funkfeuer.at/t/tunnelserver-fuer-funkinseln-und-backuplinks/261 eingemeldet werden. Das Maintainer-Team kümmert sich darum.<br />
<br />
== Verwendung ==<br />
[[OpenVPN-Tunnel_zu_FunkFeuer]]</div>Erichhttps://wiki.funkfeuer.at/index.php?title=Services/Organisation/Tunnelserver&diff=2820Services/Organisation/Tunnelserver2020-05-09T23:19:54Z<p>Erich: /* Details */</p>
<hr />
<div>{{Projekt<br />
|name=Tunnelserver.freiesnetz.wien.funkfeuer.at<br />
|startdate=2017/09/20<br />
|state=Aktiv<br />
|desc=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.<br />
}}<br />
<br />
== Beschreibung ==<br />
<br />
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. <br />
<br />
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.<br />
<br />
== Maintainer ==<br />
* [[Benutzer:erich|Erich N. Pekarek]]<br />
* [[Benutzer:vchrizz|Christoph Lösch]]<br />
* [[Benutzer:Pocki|Christian Pock]]<br />
* [[Benutzer:damadmai|Daniel A. Maierhofer]]<br />
<br />
== Abhängigkeiten ==<br />
<br />
Das Tunnelserverprojekt ist von folgenden Projektgruppen abhängig:<br />
<br />
* Core-Team/Roofnode-Team<br />
* v642-Projekt<br />
* Housing/VM<br />
<br />
<s>Um die wechselseitigen Abhängigkeiten zu reduzieren, lautet der aktuelle Projektfahrplan wie folgt:<br />
Den gegenwärtigen Tunnelserver, der leider auch andere, systemrelevante Aufgaben erledigt, in mehreren Schritten zu migrieren.<br />
* Vorbereitungen:<br />
** Sämtliche Tunnelfunktionen von Tunnel6 und Tunnel auf der „VM-Tunnel6“ zu vereinen.<br />
** Tests neuer Funktionen.<br />
* Hauptphase: Die vereinte VM wird auf eine physische Hardware migriert. Diese Maschine wird wie ein Roofnode mit erhöhter Redundanz eingebunden werden.<br />
* Nacharbeiten:<br />
** Anschließend die VM „Tunnel 6“ stilllegen.<br />
** Die Routing-Funktionen der „VM Tunnel” auf die neuen Roofnodes oder andere Router so verteilen, wie es sinnvoll ist.<br />
** Die VM „Tunnel“ anschließend stilllegen.<br />
</s><br />
* Dauerarbeiten: Wartung und Betreuung.<br />
<br />
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.<br />
<br />
== Details ==<br />
Gegenwärtiger Status:<br />
<s>* Tunnel VM hat Aufgaben von Tunnel6 vorübergehend übernommen.</s><br />
<s>* 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.</s><br />
<s>* Die physische Maschine ist bereits rudimentär eingerichtet.</s><br />
* 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.<br />
* Migration abgeschlossen, Regelbetrieb.<br />
* Bedarf an einem neuen Tunnel oder Änderungswünsche können u.a. unter https://forum.funkfeuer.at/t/tunnelserver-fuer-funkinseln-und-backuplinks/261/15 eingemeldet werden. Das Maintainer-Team kümmert sich darum.<br />
<br />
== Verwendung ==<br />
[[OpenVPN-Tunnel_zu_FunkFeuer]]</div>Erichhttps://wiki.funkfeuer.at/index.php?title=Services/Organisation/Tunnelserver&diff=2819Services/Organisation/Tunnelserver2020-05-09T17:20:48Z<p>Erich: </p>
<hr />
<div>{{Projekt<br />
|name=Tunnelserver.freiesnetz.wien.funkfeuer.at<br />
|startdate=2017/09/20<br />
|state=Aktiv<br />
|desc=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.<br />
}}<br />
<br />
== Beschreibung ==<br />
<br />
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. <br />
<br />
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.<br />
<br />
== Maintainer ==<br />
* [[Benutzer:erich|Erich N. Pekarek]]<br />
* [[Benutzer:vchrizz|Christoph Lösch]]<br />
* [[Benutzer:Pocki|Christian Pock]]<br />
* [[Benutzer:damadmai|Daniel A. Maierhofer]]<br />
<br />
== Abhängigkeiten ==<br />
<br />
Das Tunnelserverprojekt ist von folgenden Projektgruppen abhängig:<br />
<br />
* Core-Team/Roofnode-Team<br />
* v642-Projekt<br />
* Housing/VM<br />
<br />
<s>Um die wechselseitigen Abhängigkeiten zu reduzieren, lautet der aktuelle Projektfahrplan wie folgt:<br />
Den gegenwärtigen Tunnelserver, der leider auch andere, systemrelevante Aufgaben erledigt, in mehreren Schritten zu migrieren.<br />
* Vorbereitungen:<br />
** Sämtliche Tunnelfunktionen von Tunnel6 und Tunnel auf der „VM-Tunnel6“ zu vereinen.<br />
** Tests neuer Funktionen.<br />
* Hauptphase: Die vereinte VM wird auf eine physische Hardware migriert. Diese Maschine wird wie ein Roofnode mit erhöhter Redundanz eingebunden werden.<br />
* Nacharbeiten:<br />
** Anschließend die VM „Tunnel 6“ stilllegen.<br />
** Die Routing-Funktionen der „VM Tunnel” auf die neuen Roofnodes oder andere Router so verteilen, wie es sinnvoll ist.<br />
** Die VM „Tunnel“ anschließend stilllegen.<br />
</s><br />
* Dauerarbeiten: Wartung und Betreuung.<br />
<br />
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.<br />
<br />
== Details ==<br />
Gegenwärtiger Status:<br />
<s>* Tunnel VM hat Aufgaben von Tunnel6 vorübergehend übernommen.</s><br />
<s>* 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.</s><br />
<s>* Die physische Maschine ist bereits rudimentär eingerichtet.</s><br />
* 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.<br />
* Migration abgeschlossen, Regelbetrieb.<br />
<br />
== Verwendung ==<br />
[[OpenVPN-Tunnel_zu_FunkFeuer]]</div>Erichhttps://wiki.funkfeuer.at/index.php?title=OpenVPN_mit_Debian/Ubuntu&diff=2774OpenVPN mit Debian/Ubuntu2020-03-28T19:45:21Z<p>Erich: </p>
<hr />
<div>Unter Debian installierst Du die Pakete für Openvpn und olsr.<br />
<br />
Voraussetzungen:<br />
* Aktuelles Debian Stable oder Ubuntu LTS<br />
* Pakete für OpenVPN, OLSR (und OLSRv2), bridge-utils<br />
* Funkfeuer-Login<br />
* Funkfeuer-IPv4-Adresse für das Tunneldevice respektive die Bridge aus [[https://portal.funkfeuer.at/wien REDEEMER/FRONTEND/PORTAL]]<br />
* Einen Taschenrechner, der Dezimalzahlen in Hexadezimalzahlen umrechnen kann („programmiertechnischer Modus“)<br />
* Die Funkfeuer NodeID des Knotens, dem der Tunnel zugeordnet wird. Wenn Du im Redeemer/Portal eingeloggt bist, und auf „Nodes“ und den richtigen Namen des Nodes klickst, siehst Du die NodeID in der URL in Deinem Browsers entweder so:<br />
** „&id=9999“ oder so<br />
** „id_nodes=9999“.<br />
Diese Zahl umgewandelt in „Hex“ brauchst Du später für Deine IPv6-Adresse.<br />
<br />
<br />
* apt-get install openvpn openvpn-blacklist olsrd olsrd-plugins bridge-utils ebtables<br />
<br />
Angenommen, Dein Debian oder Ubuntu-Rechner besitzt eine Ethernetschnittstelle eth0 (oder wie das heute eher der Fall ist, en[X]s[Y]), die in derselben Broadcastdomain wie das Provider-Modem liegt, dann wirst Du /etc/network/interfaces editieren und dort zunächst eine statische Route zum Tunnelserver anlegen wollen. Im selben Arbeitsschritt könntest Du auch festlegen, dass der Tunnel unmittelbar nach dem Start der Netzwerkschnittstelle aufgebaut wird. Es ist darüber hinaus zweckmäßig, OLSR auf einer Bridge laufen zu lassen, um sich etwaige OLSR-Neustarts zu ersparen. Wir legen also auch gleich eine Bridge an und weisen ihr die Funkfeuer-IPs für IPv4 und IPv6 (aber nur für 2a02:60::/40) zu. 192.168.1.1 ist in diesem Beispiel das Providermodem als Defaultgateway. Warum setzen wir aber eine Hostroute zu 78.41.118.150/32 oder 78.41.115.16/32? Ganz einfach: Olsr wird die Default-Route überschreiben. In aller Regel passiert dies mit einer Metrik von 2 und sollte nicht stören. Dennoch kommt es manchmal dazu, dass bei Fehlen der Hostroute der Tunnel quasi über sich selbst laufen soll - das funktioniert freilich nicht. Wenn Du aber auch eine Funkschnittstelle mit OLSR hast, dann läufst Du Gefahr, dass der Tunnel zu Funkfeuer über das Funkfeuer-Mesh aufgebaut würde, was absolut keinen Sinn ergibt. Daher die Hostroute.<br />
<br />
/etc/network/interfaces:<br />
iface eth0 inet static<br />
...<br />
up /sbin/ip r a 78.41.115.16/32 dev eth0 via 192.168.1.1 metric 0<br />
up /etc/init.d/openvpn restart<br />
<br />
auto br-ff <br />
iface br-ff inet static<br />
bridge_fd 0<br />
bridge_maxwait 0<br />
bridge_waitport 0<br />
bridge_stp no<br />
bridge_ports none<br />
address [REDEEMER-IP v4]<br />
netmask 255.255.255.255<br />
# IPv6/OLSRv1 Schema 2a02:60:01[Node ID in Hexadezimaldarstellung, erstes Oktett]:[Node ID in Hex, zweites Oktett][Router ID (4 Bit)][Interface ID (4 Bit)]::[irgendwas]<br />
# Nachfolgend für 9999 NodeID 9999(10) = 270F(16); Router 1, Interface 1 mit Adresse „feed“:<br />
post-up /sbin/ip -6 a a 2a02:60:1'''27''':'''0f'''''11''::feed/64 dev br-ff<br />
# Wenn man die MAC-Adresse der Bridge definiert, wirkt sich das auf die IPv6 EUI64-Adresse beginnend mit fe80::/12 aus.<br />
# Man kann sich eine zufällige MAC-Adresse [[https://www.miniwebtool.com/mac-address-generator/ MAC Address Generator]] (lowercase und ":"-Notation) errechnen lassen.<br />
post-up ip link set dev br-ff address bc:75:33:6a:bf:cf<br />
# Die Bridge soll allen Traffic annehmen.<br />
post-up ip link set dev br-ff promisc on<br />
<br />
<br />
Die Konfiguration von OpenVPN liegt bei Debian und Ubuntu üblicherweise in /etc/openvpn, wobei das Startup-Skript die Datei /etc/default/openvpn zu seiner Initialisierung heranzieht.<br />
<br />
/etc/default/openvpn:<br />
#AUTOSTART="all" -> <br />
AUTOSTART="all" <br />
oder<br />
#AUTOSTART="all" -><br />
AUTOSTART="funkfeuer"<br />
<br />
Somit erwartet OpenVPN seine Konfiguration in /etc/openvpn/funkfeuer.conf.<br />
<br />
/etc/openvpn/funkfeuer.conf:<br />
dev tap0<br />
proto udp<br />
remote 78.41.115.16<br />
# Variante: remote 78.41.118.150 <br />
# Die Portnummer XXXX wird Dir von den Tunnelserver-Administratoren zugewiesen, trag sie in der folgenden Zeile anstelle von XXXX ein.<br />
port XXXX<br />
daemon tap0<br />
persist-tun<br />
up-delay<br />
down-pre<br />
up-restart<br />
comp-lzo<br />
script-security 2<br />
nobind<br />
ping 10<br />
ping-restart 60<br />
ping-timer-rem<br />
fast-io<br />
sndbuf 524288<br />
rcvbuf 524288<br />
mute 2<br />
verb 0<br />
up /etc/openvpn/funkfeuer-updown.sh<br />
down /etc/openvpn/funkfeuer-updown.sh<br />
secret /etc/openvpn/funkfeuer.secret<br />
auth SHA256<br />
cipher none<br />
<br />
Diese Konfigurationsdatei benötigt also noch zwei weitere Dateien. Zum einen wäre das /etc/openvpn/funkfeuer-updown.sh. Dieses Skript wird von OpenVPN aufgerufen, sowie der Tunnel hergestellt oder beendet wird. OpenVPN übergibt diesem Skript Parameter, wie wir sie im Beispiel des Tunnelservers nützen. Für Deine Seite wird das nicht explizit erforderlich sein. Das Skript kann wie folgt aussehen:<br />
<br />
/etc/openvpn/funkfeuer-updown.sh:<br />
#!/bin/bash<br />
# br-ff ist die Bridge aus /etc/network/interfaces<br />
# $dev ist ein Parameter, den Openvpn übergibt. Hier zumeist „tap0“.<br />
br="br-ff"<br />
dev=$1<br />
logger "openvpn: $(echo $@)"<br />
logger "openvpn: $script_type"<br />
case $script_type in<br />
"down")<br />
/sbin/brctl delif $br $dev<br />
/sbin/ebtables -D FORWARD --logical-in ${br} -i ${dev} -j DROP<br />
/sbin/ip link set link dev $dev down<br />
;;<br />
"route-up")<br />
;;<br />
"up")<br />
/sbin/brctl addif $br $dev<br />
/sbin/ebtables -I FORWARD --logical-in ${br} -i ${dev} -j DROP<br />
/sbin/ip link set dev $br promisc on<br />
/sbin/ip link set link dev $dev up<br />
/sbin/ip link set link dev $br up<br />
;;<br />
esac<br />
echo $(date) $script_type $br.$dev $script_type>> /tmp/br-vpn.log<br />
exit 0<br />
<br />
<br />
Das Skript muss ausführbar gemacht werden. chmod +x /etc/openvpn/funkfeuer-updown.sh<br />
<br />
chmod +x /etc/openvpn/funkfeuer-updown.sh<br />
<br />
In der OpenVPN-Konfiguration haben wir den statischen Schlüssel mit /etc/openvpn/funkfeuer.secret angegeben. Exemplarisch schaut das so aus - aber den „echten Key“ bekommt ein Jeder individuell zugeteilt (bitte bei Erich P. anfordern):<br />
<br />
<br />
/etc/openvpn/funkfeuer.secret:<br />
#<br />
# 2048 bit OpenVPN static key<br />
#<br />
-----BEGIN OpenVPN Static key V1-----<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
-----END OpenVPN Static key V1-----<br />
<br />
<br />
Jetzt fehlt noch OLSR... Debian und Ubuntu verwenden /etc/init.d/olsrd als Startscript, das wiederum /etc/default/olsrd zu Initialisierung nutzt. Das Debian-Konzept geht noch von Adhoc-Netzen auf dem lokalen Gerät aus, kann also bis auf drei Zeilen ignoriert werden. Die Interface-Parameter lasse ich bewusst weg. Die Interfaces definiert man besser in der olsrd.conf, wo man individuelle Einstellungen tätigen kann (etwa unter anderem: ein per-Interface-Default-LQ-Multiplier, den Mode und die Gewichtung.)<br />
<br />
<br />
/etc/default/olsrd:<br />
START_OLSRD="YES"<br />
DEBUGLEVEL=0<br />
DAEMON_OPTS="-f /etc/olsrd/olsrd.conf -d $DEBUGLEVEL"<br />
<br />
<br />
Es fehlt noch die OSLR-Konfigurationsdatei (Vorsicht: ich verwende ein selbstkompiliertes OLSR und habe die plugin-Libraries „LoadPlugin“ hardgecodet; wenn der Pfad nicht stimmt, startet OLSR nicht, plaudert aber wirklich nicht darüber, was es stört.) -<br />
<br />
/etc/olsrd/olsrd.conf:<br />
AllowNoInt yes<br />
ClearScreen yes<br />
DebugLevel 0<br />
FIBMetric "flat"<br />
IpVersion 4<br />
LinkQualityAlgorithm "etx_ff"<br />
LinkQualityFishEye 1<br />
LinkQualityLevel 2<br />
MainIp [DIE MAIN-IP BEKOMMT IHR AUS DEM FUNKFEUER PORTAL, WENN IHR EIN GERÄT (DEVICE) ANLEGT]<br />
MprCoverage 1<br />
Pollrate 0.1<br />
TcRedundancy 2<br />
TosValue 16<br />
UseHysteresis no<br />
Willingness 3<br />
InterfaceDefaults<br />
{<br />
AutoDetectChanges yes<br />
HelloInterval 5.0<br />
HelloValidityTime 100.0<br />
TcInterval 2.0<br />
TcValidityTime 300.0<br />
MidInterval 50.0<br />
MidValidityTime 300.0<br />
HnaInterval 50.0<br />
HnaValidityTime 300.0<br />
Ip4Broadcast 255.255.255.255<br />
Mode "mesh"<br />
LinkQualityMult default 0.15<br />
Weight 99<br />
}<br />
Interface "br-ff"<br />
{<br />
AutoDetectChanges yes<br />
LinkQualityMult default 1.0<br />
Weight 0<br />
}<br />
Hna4<br />
{<br />
[SERVER-IP FALLS VORHANDEN - ZUWEISUNG VIA PORTAL] 255.255.255.255<br />
}<br />
LoadPlugin "olsrd_httpinfo.so.0.1"<br />
{<br />
PlParam "Port" "81"<br />
PlParam "Net" "0.0.0.0 0.0.0.0"<br />
PlParam "resolve" "false"<br />
}<br />
LoadPlugin "olsrd_txtinfo.so.1.1"<br />
{<br />
PlParam "port" "2006"<br />
PlParam "accept" "127.0.0.1"<br />
}<br />
LoadPlugin "olsrd_jsoninfo.so.1.1"<br />
{<br />
PlParam "port" "9090"<br />
PlParam "accept" "0.0.0.0"<br />
PlParam "UUIDFile" "/etc/olsrd/olsrd.uuid"<br />
}<br />
<br />
Damit ist eigentlich die Arbeit getan.<br />
<br />
=== 'the quick and dirty hack' für IPv6 ===<br />
<br />
Für OLSR mit IPv6 gibt es noch ein paar Tricks zu wissen und noch etwas mehr Handarbeit.<br />
Kopiere:<br />
<br />
* /etc/default/olsrd nach /etc/default/olsrd6<br />
** Ersetz jedes Vorkommen von olsr(d) durch olsr(d)6.<br />
<br />
mit vim wäre das so: vom input modus in den command modus wechseln (ESC) und in der command line folgendes eingeben: <br />
<br />
%s/olsrd/olsrd6/g<br />
<br />
12 ersetzungen sollten stattfinden. <br />
<br />
%s/OLSRD/OLSRD6/g<br />
<br />
selbiges gilt für die folgenden weiteren Dateien<br />
<br />
* /etc/init.d/olsrd nach /etc/init.d/olsrd6<br />
** Ersetz jedes Vorkommen von olsr(d) durch olsr(d)6. Ersetze /usr/sbin/olsrd durch /etc/alternatives/olsrd6<br />
* Setz einen Link von /usr/sbin/olsrd nach /etc/alternatives/olsrd6.<br />
<br />
ln -s /usr/sbin/olsrd /etc/alternatives/olsrd6<br />
<br />
Das hat den Sinn, dass der Prozess auch olsrd6 heißt, wenn er läuft und Du ihn mit dem pgrep im Startskript suchen kannst.<br />
<br />
* Leg /etc/olsrd/olsrd6.conf an - nachfolgend ein Beispiel.<br />
<br />
AllowNoInt yes<br />
ClearScreen yes<br />
DebugLevel 0<br />
FIBMetric "flat"<br />
IpVersion 6<br />
LinkQualityAlgorithm "etx_ff"<br />
LinkQualityFishEye 1<br />
LinkQualityLevel 2<br />
MprCoverage 1<br />
Pollrate 0.1<br />
TcRedundancy 2<br />
TosValue 16<br />
UseHysteresis no<br />
UseNiit yes<br />
Willingness 3<br />
InterfaceDefaults<br />
{<br />
#Ip6MulticastGlobal ff0e::1<br />
#Ip6MulticastSite ff05::11<br />
IPv6Multicast ff02::6d<br />
Weight 99<br />
AutoDetectChanges yes<br />
HelloInterval 50.0<br />
HelloValidityTime 100.0<br />
HnaInterval 50.0<br />
HnaValidityTime 300.0<br />
LinkQualityMult default 0.33 <br />
MidInterval 50.0<br />
MidValidityTime 300.0<br />
Mode "mesh"<br />
TcInterval 2.0 <br />
TcValidityTime 300.0<br />
Weight 99<br />
}<br />
Hna6<br />
{<br />
}<br />
LoadPlugin "olsrd_httpinfo.so.0.1"<br />
{<br />
PlParam "Net" "0::/0 2000::/3"<br />
PlParam "port" "82"<br />
}<br />
LoadPlugin "olsrd_jsoninfo.so.1.1"<br />
{<br />
PlParam "port" "9090"<br />
PlParam "accept" "::"<br />
PlParam "UUIDFile" "/etc/olsrd/olsrd6.uuid"<br />
PlParam "ipv6only" "true"<br />
}<br />
Interface "br-ff"<br />
{<br />
AutoDetectChanges yes<br />
LinkQualityMult default 0.25 <br />
Mode "ether"<br />
Weight 1<br />
IPv6Multicast ff02::6d<br />
}<br />
<br />
Sollte OLSR nicht starten wollen, liegt es entweder an einem Tippfehler oder an einer falsch formatierten IPv6-Adresse (::/0 oder 0::/0 je nach Plugin...) oder daran, dass olsrd seine Plugins nicht finden kann oder die falsche Version findet, wenn Du ein Update mit selbstkompiliertem OLSR gemacht haben solltest. Aufmerksam lesen und eventuell die LoadPlugin-Zeilen mit absoluten Pfaden zu der jeweiligen ".so" setzen, hilft.<br />
<br />
Es ist auch möglich die plugin sektion ganz wegzulassen, damit eliminiert man evtl ein weiteres Problem.<br />
diese können ja schrittweise bei funktionierender config nachträglich wieder eingefügt werden.<br />
<br />
Ein letzter Hinweis: OLSR wird noch nicht automatisch gestartet. Du kannst das in /etc/network/interfaces bei der Bridge br-ff mittels „up /etc/init.d/olsrd restart“ und „up /etc/init.d/olsrd6 restart“ tun, oder, Du legst die zwei Befehle in das OpenVPN-UP/DOWN-Skript. AutodetecChanges in OLSR sollte eigentlich dafür sorgen, dass der Bridge-Port immer erkannt wird, ohne, dass man den Dienst erneut starten muss.<br />
<br />
Das war's. Dual-Stack OLSRv1 mit Tunnel läuft, sowie Du es gestartet hast.</div>Erichhttps://wiki.funkfeuer.at/index.php?title=OpenVPN_mit_EdgeRouter_X-SFP&diff=2543OpenVPN mit EdgeRouter X-SFP2019-08-25T19:46:11Z<p>Erich: </p>
<hr />
<div>Die allgemeinen Voraussetzungen zum Einrichten eines Tunnels sind in der Übersichtsseite dargestellt. Dieser Artikel geht nur auf die rudimentäre Konfiguration des [[Hardware/EdgeRouter_X-SFP EdgeRouter ein.<br />
Update 02/2018: ein EdgeOS-Wizard hierfür ist in Entwicklung: https://github.com/pocki80/ER-wizard-0xFF-OpenVPN2TS<br />
<br />
== Einrichten des Tunnels ==<br />
<br />
Empfohlen wird, die Konfigurationsdateien und das Skript zuerst auf dem Computer anzulegen, und diese gemeinsam in der Folge per SSH ins Verzeichnis /config/user-data/ zu kopieren. Alternativ über das CLI wie vi anlegen. Wir benötigen:<br />
<br />
1) funkfeuer.ovpn mit folgendem Inhalt - die kursiv dargestellten Zeilen musst Du mit jenen Werten befüllen, die Du von den Tunneladmins zugewiesen bekommen hast:<br />
<br />
dev vtun0<br />
dev-type tap<br />
proto udp<br />
remote 78.41.115.16<br />
''port [5XXX]''<br />
up-delay<br />
down-pre<br />
up-restart<br />
script-security 2<br />
nobind<br />
ping 10<br />
ping-restart 60<br />
ping-timer-rem<br />
fast-io<br />
sndbuf 524288 <br />
rcvbuf 524288<br />
mute 2<br />
verb 0<br />
secret /config/user-data/funkfeuer.secret<br />
cipher none<br />
<br />
Sowie<br />
auth none<br />
oder, wenn man Dir das explizit so mitgeteilt hat:<br />
auth SHA256<br />
<br />
Wir verzichten bei neuen Tunneln im Moment auf Kompression, weil es Probleme mit verschiedenen OpenVPN-Versionen gibt. D.h. außer es steht in den Dir übermittelten Tunnelkonfigurationen so, vermeide jeden Eintrag mit comp-lzo oder compress.<br />
<br />
2) funkfeuer.secret - wenn ein Key angelegt wurde, wie in 1) beschrieben.<br />
<br />
Diese Datei beinhaltet einen individuellen kryptographischen Schlüssel (shared key), der sicherstellt, dass der Tunnel nur von jenen Clients genutzt werden kann, denen er auch tatsächlich zugewiesen wurde. Das soll verhindern, dass ein Tunnel missbräuchlich oder versehentlich mehrfach genützt wird.<br />
Diesen Schlüssel erhältst Du per E-Mail und Du musst ihn lediglich in dieser Datei speichern. <br />
<br />
3) Folgende Config am EdgeRouter vornehmen (lokalen Gateway für Static-Route entsprechend ändern)<br />
<br />
set interfaces bridge br9 address 78.41.000.000/32<br />
set interfaces bridge br9 aging 300<br />
set interfaces bridge br9 bridged-conntrack disable<br />
set interfaces bridge br9 description TUNNEL<br />
set interfaces bridge br9 hello-time 2<br />
set interfaces bridge br9 max-age 20<br />
set interfaces bridge br9 priority 32768<br />
set interfaces bridge br9 stp false<br />
commit<br />
set protocols static route 78.41.115.16/32 next-hop 192.168.0.1 description 'TunnelServer via ISP'<br />
set interfaces openvpn vtun0 config-file /config/user-data/funkfeuer.ovpn<br />
commit<br />
save<br />
<br />
4) Im OLSRd_V1 Wizard für das Interface br9 für OLSR aktivieren. Mode "mesh" kann man bei bedarf auf "silent" umstellen, um Bandbreite zu sparen. Das geht aber nur, wenn der VON-Router keine weiteren OLSR-Router "hinter sich" hat: diese sind dann nur erreichbar, wenn es einen weitern Pfad (übers Mesh-Netz) bis um Tunnelserver gibt.</div>Erichhttps://wiki.funkfeuer.at/index.php?title=OpenVPN_mit_EdgeRouter_X-SFP&diff=2542OpenVPN mit EdgeRouter X-SFP2019-08-25T19:44:13Z<p>Erich: /* Einrichten des Tunnels */</p>
<hr />
<div>Die allgemeinen Voraussetzungen zum Einrichten eines Tunnels sind in der Übersichtsseite dargestellt. Dieser Artikel geht nur auf die rudimentäre Konfiguration des [[Hardware/EdgeRouter_X-SFP EdgeRouter ein.<br />
Update 02/2018: ein EdgeOS-Wizard hierfür ist in Entwicklung: https://github.com/pocki80/ER-wizard-0xFF-OpenVPN2TS<br />
<br />
== Einrichten des Tunnels ==<br />
<br />
Empfohlen wird, die Konfigurationsdateien und das Skript zuerst auf dem Computer anzulegen, und diese gemeinsam in der Folge per SSH ins Verzeichnis /config/user-data/ zu kopieren. Alternativ über das CLI wie vi anlegen. Wir benötigen:<br />
<br />
1) funkfeuer.ovpn mit folgendem Inhalt - die kursiv dargestellten Zeilen musst Du mit jenen Werten befüllen, die Du von den Tunneladmins zugewiesen bekommen hast:<br />
<br />
dev vtun0<br />
dev-type tap<br />
proto udp<br />
remote 78.41.115.16<br />
''port [5XXX]''<br />
up-delay<br />
down-pre<br />
up-restart<br />
script-security 2<br />
nobind<br />
ping 10<br />
ping-restart 60<br />
ping-timer-rem<br />
fast-io<br />
sndbuf 524288 <br />
rcvbuf 524288<br />
mute 2<br />
verb 0<br />
secret /config/user-data/funkfeuer.secret<br />
cipher none<br />
<br />
Sowie<br />
auth none<br />
oder<br />
auth SHA256<br />
<br />
Je nachdem, was Dir von den Tunneladmins mitgeteilt worden ist, eventuell noch<br />
comp-lzo<br />
Wir verzichten bei neuen Tunneln im Moment auf Kompression, weil es Probleme mit verschiedenen OpenVPN-Versionen gibt.<br />
<br />
2) funkfeuer.secret - wenn ein Key angelegt wurde, wie in 1) beschrieben.<br />
<br />
Diese Datei beinhaltet einen individuellen kryptographischen Schlüssel (shared key), der sicherstellt, dass der Tunnel nur von jenen Clients genutzt werden kann, denen er auch tatsächlich zugewiesen wurde. Das soll verhindern, dass ein Tunnel missbräuchlich oder versehentlich mehrfach genützt wird.<br />
Diesen Schlüssel erhältst Du per E-Mail und Du musst ihn lediglich in dieser Datei speichern. <br />
<br />
3) Folgende Config am EdgeRouter vornehmen (lokalen Gateway für Static-Route entsprechend ändern)<br />
<br />
set interfaces bridge br9 address 78.41.000.000/32<br />
set interfaces bridge br9 aging 300<br />
set interfaces bridge br9 bridged-conntrack disable<br />
set interfaces bridge br9 description TUNNEL<br />
set interfaces bridge br9 hello-time 2<br />
set interfaces bridge br9 max-age 20<br />
set interfaces bridge br9 priority 32768<br />
set interfaces bridge br9 stp false<br />
commit<br />
set protocols static route 78.41.115.16/32 next-hop 192.168.0.1 description 'TunnelServer via ISP'<br />
set interfaces openvpn vtun0 config-file /config/user-data/funkfeuer.ovpn<br />
commit<br />
save<br />
<br />
4) Im OLSRd_V1 Wizard für das Interface br9 für OLSR aktivieren. Mode "mesh" kann man bei bedarf auf "silent" umstellen, um Bandbreite zu sparen. Das geht aber nur, wenn der VON-Router keine weiteren OLSR-Router "hinter sich" hat: diese sind dann nur erreichbar, wenn es einen weitern Pfad (übers Mesh-Netz) bis um Tunnelserver gibt.</div>Erichhttps://wiki.funkfeuer.at/index.php?title=OpenVPN_mit_LEDE/OpenWRT_oder_%E2%80%9EBubbles%E2%80%9C&diff=2448OpenVPN mit LEDE/OpenWRT oder „Bubbles“2019-06-16T13:20:59Z<p>Erich: /* Bridge anlegen über die Konsole */</p>
<hr />
<div>ENTWURF - FEEDBACK WILLKOMMEN<br />
<br />
Diese Anleitung unterscheidet sich nicht besonders von dem, was wir für Debian oder für den EdgeRouter brauchen.<br />
Voraussetzung ist ein OpenWRT-Build mit bridge-utils, iproute2 und openvpn.<br />
Wir legen auf OpenWRT eine Bridge ohne Brigeports an, konfigurieren OpenVPN und legen ein ifup-down-Skript für den Tunnel an. OLSR läuft auf der Bridge.<br />
<br />
Paketvorschlag:<br />
luci-app-openvpn luci-i18n-openvpn-de openvpn-mbedtls ip-full <br />
<br />
<br />
== Bridge anlegen über die Konsole ==<br />
[Da klappt etwas noch nicht; OpenWRT startet offenbar eine Bridge ohne Bridgeports in 18.06.2 nicht]<br />
uci set network.ff=interface<br />
uci set network.ff.ifname='ff'<br />
uci set network.ff.type='bridge'<br />
uci set network.ff.proto='static'<br />
uci set network.ff.ipaddr='[FUNKFEUER-IP-ADRESSE-AUS-REDEEMER]'<br />
uci set network.ff.netmask='255.255.255.255'<br />
uci set network.ff.empty_bridge='1'<br />
uci commit<br />
<br />
== [Ergänzen ... OLSR mittels UCI konfigrieren ...] ==<br />
<br />
== Auf die OpenVPN-Konfigurationsdatei verweisen ==<br />
Die Datei /etc/config/openvpn soll beinhalten:<br />
config openvpn 'Funkfeuer'<br />
option enabled '1'<br />
option config '/etc/openvpn/funkfeuer.conf'<br />
<br />
Über UCI legt man das an wie folgt:<br />
uci set openvpn.Funkfeuer=openvpn<br />
uci set openvpn.Funkfeuer.enabled='1'<br />
uci set openvpn.Funkfeuer.config='/etc/openvpn/funkfeuer.conf'<br />
uci commit<br />
<br />
<br />
== Die OpenVPN-Konfigurationsdatei ==<br />
/etc/openvpn/funkfeuer.conf:<br />
dev tap-ff<br />
dev-type tap<br />
proto udp<br />
remote 78.41.115.16<br />
port [5XXX]<br />
up-delay<br />
down-pre<br />
up-restart<br />
# comp-lzo #lassen wir aus Kompatibilitätsgrunden aus<br />
script-security 2<br />
nobind<br />
ping 10<br />
ping-restart 60<br />
ping-timer-rem<br />
fast-io<br />
sndbuf 524288 <br />
rcvbuf 524288<br />
txqueuelen 1000<br />
mute 2<br />
verb 0<br />
secret /etc/openvpn/funkfeuer.secret<br />
auth none<br />
cipher none<br />
up "/etc/openvpn/scripts/funkfeuer-ifupdown.sh"<br />
down "/etc/openvpn/scripts/funkfeuer-ifupdown.sh"<br />
<br />
== Das Secret ==<br />
Die Datei /etc/openvpn/funkfeuer.secret enthält den Key, den Du vom Tunneladmin erhalten hast - Beispielsweise:<br />
<br />
<br />
#<br />
# 2048 bit OpenVPN static key<br />
#<br />
-----BEGIN OpenVPN Static key V1-----<br />
61eaa6a0731c1114b92d98f4c71bc547<br />
a79050f1f888bb87c84355adbe916a8a<br />
b1e0cdd74f516b654c9542e46ea3216c<br />
f65bdb1fdad755022d73a1b35821f46e<br />
c9da48afb8feb3564f3d2de97a690fa9<br />
90ca9b2ddcedc842ee88a1f085c9b3e7<br />
518c8c9ae9a43ce64dc6c55789115652<br />
964af121b3097dddaf0f12a72981a25f<br />
4790575a0254f93e13ca4176433a0e8f<br />
2d526b12280766b32ef37737199c2d6e<br />
e1b006e9432a26a131cef64833421461<br />
ca6ae34349b3088c3a00e3ad6b024e6b<br />
fba26277c3818a99fa32f6be4480b075<br />
525f81b302b527c2e95fff90a4268fe6<br />
f067a05b484f4ea77e57afcf53c2c0b1<br />
79be9d144c9ac7aa874d3d248f6e5b35<br />
-----END OpenVPN Static key V1-----<br />
<br />
== Das ifupdown-Skript == <br />
=== Das Skript-Verzeichnis anlegen ===<br />
mkdir -p /etc/openvpn/scripts<br />
<br />
=== /etc/openvpn/scripts/funkfeuer-ifupdown.sh ===<br />
#!/bin/sh<br />
logger "$dev $script_type"<br />
br=br-ff<br />
case "$script_type" in<br />
up)<br />
/sbin/brctl addif $br $dev<br />
/sbin/ip link set $br promisc on<br />
/sbin/ip link set $dev up<br />
;;<br />
down)<br />
/sbin/ip link set $dev down <br />
/sbin/ip link set $br promisc off<br />
/sbin/brctl delif $br $dev <br />
<br />
;;<br />
*)<br />
esac<br />
exit 0<br />
<br />
=== Das Skript ausführbar machen ===<br />
chmod +x /etc/openvpn/scripts/funkfeuer-ifupdown.sh</div>Erichhttps://wiki.funkfeuer.at/index.php?title=OpenVPN_mit_LEDE/OpenWRT_oder_%E2%80%9EBubbles%E2%80%9C&diff=2447OpenVPN mit LEDE/OpenWRT oder „Bubbles“2019-06-16T07:56:47Z<p>Erich: /* Bridge anlegen über die Konsole */</p>
<hr />
<div>ENTWURF - FEEDBACK WILLKOMMEN<br />
<br />
Diese Anleitung unterscheidet sich nicht besonders von dem, was wir für Debian oder für den EdgeRouter brauchen.<br />
Voraussetzung ist ein OpenWRT-Build mit bridge-utils, iproute2 und openvpn.<br />
Wir legen auf OpenWRT eine Bridge ohne Brigeports an, konfigurieren OpenVPN und legen ein ifup-down-Skript für den Tunnel an. OLSR läuft auf der Bridge.<br />
<br />
Paketvorschlag:<br />
luci-app-openvpn luci-i18n-openvpn-de openvpn-mbedtls ip-full <br />
<br />
<br />
== Bridge anlegen über die Konsole ==<br />
[Da klappt etwas noch nicht; OpenWRT startet offenbar eine Bridge ohne Bridgeports in 18.06.2 nicht]<br />
uci set network.ff=interface<br />
uci set network.ff.ifname='ff'<br />
uci set network.ff.type='bridge'<br />
uci set network.ff.proto='static'<br />
uci set network.ff.ipaddr='[FUNKFEUER-IP-ADRESSE-AUS-REDEEMER]'<br />
uci set network.ff.netmask='255.255.255.255'<br />
uci commit<br />
<br />
== [Ergänzen ... OLSR mittels UCI konfigrieren ...] ==<br />
<br />
== Auf die OpenVPN-Konfigurationsdatei verweisen ==<br />
Die Datei /etc/config/openvpn soll beinhalten:<br />
config openvpn 'Funkfeuer'<br />
option enabled '1'<br />
option config '/etc/openvpn/funkfeuer.conf'<br />
<br />
Über UCI legt man das an wie folgt:<br />
uci set openvpn.Funkfeuer=openvpn<br />
uci set openvpn.Funkfeuer.enabled='1'<br />
uci set openvpn.Funkfeuer.config='/etc/openvpn/funkfeuer.conf'<br />
uci commit<br />
<br />
<br />
== Die OpenVPN-Konfigurationsdatei ==<br />
/etc/openvpn/funkfeuer.conf:<br />
dev tap-ff<br />
dev-type tap<br />
proto udp<br />
remote 78.41.115.16<br />
port [5XXX]<br />
up-delay<br />
down-pre<br />
up-restart<br />
# comp-lzo #lassen wir aus Kompatibilitätsgrunden aus<br />
script-security 2<br />
nobind<br />
ping 10<br />
ping-restart 60<br />
ping-timer-rem<br />
fast-io<br />
sndbuf 524288 <br />
rcvbuf 524288<br />
txqueuelen 1000<br />
mute 2<br />
verb 0<br />
secret /etc/openvpn/funkfeuer.secret<br />
auth none<br />
cipher none<br />
up "/etc/openvpn/scripts/funkfeuer-ifupdown.sh"<br />
down "/etc/openvpn/scripts/funkfeuer-ifupdown.sh"<br />
<br />
== Das Secret ==<br />
Die Datei /etc/openvpn/funkfeuer.secret enthält den Key, den Du vom Tunneladmin erhalten hast - Beispielsweise:<br />
<br />
<br />
#<br />
# 2048 bit OpenVPN static key<br />
#<br />
-----BEGIN OpenVPN Static key V1-----<br />
61eaa6a0731c1114b92d98f4c71bc547<br />
a79050f1f888bb87c84355adbe916a8a<br />
b1e0cdd74f516b654c9542e46ea3216c<br />
f65bdb1fdad755022d73a1b35821f46e<br />
c9da48afb8feb3564f3d2de97a690fa9<br />
90ca9b2ddcedc842ee88a1f085c9b3e7<br />
518c8c9ae9a43ce64dc6c55789115652<br />
964af121b3097dddaf0f12a72981a25f<br />
4790575a0254f93e13ca4176433a0e8f<br />
2d526b12280766b32ef37737199c2d6e<br />
e1b006e9432a26a131cef64833421461<br />
ca6ae34349b3088c3a00e3ad6b024e6b<br />
fba26277c3818a99fa32f6be4480b075<br />
525f81b302b527c2e95fff90a4268fe6<br />
f067a05b484f4ea77e57afcf53c2c0b1<br />
79be9d144c9ac7aa874d3d248f6e5b35<br />
-----END OpenVPN Static key V1-----<br />
<br />
== Das ifupdown-Skript == <br />
=== Das Skript-Verzeichnis anlegen ===<br />
mkdir -p /etc/openvpn/scripts<br />
<br />
=== /etc/openvpn/scripts/funkfeuer-ifupdown.sh ===<br />
#!/bin/sh<br />
logger "$dev $script_type"<br />
br=br-ff<br />
case "$script_type" in<br />
up)<br />
/sbin/brctl addif $br $dev<br />
/sbin/ip link set $br promisc on<br />
/sbin/ip link set $dev up<br />
;;<br />
down)<br />
/sbin/ip link set $dev down <br />
/sbin/ip link set $br promisc off<br />
/sbin/brctl delif $br $dev <br />
<br />
;;<br />
*)<br />
esac<br />
exit 0<br />
<br />
=== Das Skript ausführbar machen ===<br />
chmod +x /etc/openvpn/scripts/funkfeuer-ifupdown.sh</div>Erichhttps://wiki.funkfeuer.at/index.php?title=OpenVPN_mit_EdgeRouter_X-SFP&diff=2446OpenVPN mit EdgeRouter X-SFP2019-06-16T00:19:25Z<p>Erich: </p>
<hr />
<div>Anleitung in Arbeit - Entwurfsstadium<br />
<br />
<br />
Die allgemeinen Voraussetzungen zum Einrichten eines Tunnels sind in der Übersichtsseite dargestellt. Dieser Artikel geht nur auf die rudimentäre Konfiguration des Edge Routers ein.<br />
<br />
Update 02/2018: ein EdgeOS-Wizard hiefür ist in Entwicklung: https://github.com/pocki80/ER-wizard-0xFF-OpenVPN2TS<br />
<br />
== Einrichten des Tunnels ==<br />
<br />
Empfohlen wird, die Konfigurationsdateien und das Skript zuerst auf Deinem Computer anzulegen, und diese gemeinsam in der Folge per SSH ins Verzeichnis /config/user-data/ zu kopieren. Alternativ kannst Du sie auch händisch über das CLI wie vi anlegen. Wir benötigen:<br />
<br />
1) funkfeuer.ovpn mit folgendem Inhalt - die kursiv dargestellten Zeilen musst Du mit jenen Werten befüllen, die Du von den Tunneladmins zugewiesen bekommen hast:<br />
<br />
dev vtun0<br />
dev-type tap<br />
proto udp<br />
remote 78.41.115.16<br />
''port [5XXX]''<br />
up-delay<br />
down-pre<br />
up-restart<br />
comp-lzo<br />
script-security 2<br />
nobind<br />
ping 10<br />
ping-restart 60<br />
ping-timer-rem<br />
fast-io<br />
sndbuf 524288 <br />
rcvbuf 524288<br />
mute 2<br />
verb 0<br />
up "/config/user-data/funkfeuer-ifupdown.sh"<br />
down "/config/user-data/funkfeuer-ifupdown.sh"<br />
<br />
<br />
Es gibt spezielle Betriebsmodi für OLSR, wie etwa den Mode „silent“. Um diesen zu nützen, kann man zwei Zeilen mit einem Skriptparameter anpassen:<br />
<br />
up "/config/user-data/funkfeuer-ifupdown.sh silent"<br />
down "/config/user-data/funkfeuer-ifupdown.sh silent"<br />
<br />
<br />
Wurde für Deinen Tunnel bereits ein shared key/secret angelegt, benötigst Du zusätzlich folgende Zeilen:<br />
<br />
secret /config/user-data/funkfeuer.secret<br />
cipher none<br />
auth none<br />
alternativ<br />
cipher none<br />
auth SHA256<br />
<br />
2) funkfeuer.secret - wenn ein Key angelegt wurde, wie in 1) beschrieben.<br />
<br />
Diese Datei beinhaltet einen individuellen kryptographischen Schlüssel (shared key), der sicherstellt, dass der Tunnel nur von jenen Clients genutzt werden kann, denen er auch tatsächlich zugewiesen wurde. Das soll verhindern, dass ein Tunnel missbräuchlich oder versehentlich mehrfach genützt wird.<br />
Diesen Schlüssel erhältst Du per E-Mail und Du musst ihn lediglich in dieser Datei speichern.<br />
<br />
3) funkfeuer-ifupdown.sh<br />
<br />
Dieses Skript sorgt dafür, dass das Tunnel-Interface, nachdem es gestartet wurde, in die richtige Bridge gelegt wird, auf der bereits OLSR im vorgesehenen Modus läuft. Diese Vorgehensweise ist nicht sonderlich schön, aber sie funktioniert. Wir arbeiten an einer besseren Lösung. Leg Die Datei mit folgendem Inhalt an und mach sie ausführbar.<br />
----<br />
<br />
#!/bin/sh<br />
logger "$dev $script_type"<br />
case "$1" in<br />
silent)<br />
br="br9"<br />
;;<br />
ether)<br />
br="br8"<br />
;;<br />
*)<br />
br="br7"<br />
esac<br />
case "$script_type" in<br />
up)<br />
/sbin/brctl addif $br $dev<br />
/sbin/ip link set $br promisc on<br />
/sbin/ip link set $dev up<br />
;;<br />
down)<br />
/sbin/ip link set $dev down <br />
/sbin/ip link set $br promisc off<br />
/sbin/brctl delif $br $dev<br />
<br />
;;<br />
*)<br />
esac<br />
exit 0<br />
<br />
<br />
chmod +x funkfeuer-ifupdown.sh<br />
<br />
3) Folgende Config am EdgeRouter vornehmen (lokalen Gateway für Static-Route entsprechend ändern)<br />
<br />
set interfaces bridge br9 address 78.41.000.000/32<br />
set interfaces bridge br9 aging 300<br />
set interfaces bridge br9 bridged-conntrack disable<br />
set interfaces bridge br9 description TUNNEL<br />
set interfaces bridge br9 hello-time 2<br />
set interfaces bridge br9 max-age 20<br />
set interfaces bridge br9 priority 32768<br />
set interfaces bridge br9 stp false<br />
commit<br />
set protocols static route 78.41.115.16/32 next-hop 192.168.0.1 description 'TunnelServer via ISP'<br />
set interfaces openvpn vtun0 config-file /config/user-data/funkfeuer.ovpn<br />
commit<br />
save<br />
<br />
3) Im OLSRd_V1 Wizard das interface br9=silent, br8=ether oder br7=mesh für OLSR aktivieren</div>Erichhttps://wiki.funkfeuer.at/index.php?title=OpenVPN_mit_EdgeRouter_X-SFP&diff=2445OpenVPN mit EdgeRouter X-SFP2019-06-16T00:19:04Z<p>Erich: /* Einrichten des Tunnels */</p>
<hr />
<div>Anleitung in Arbeit - Entwurfsstadium<br />
<br />
<br />
Die allgemeinen Voraussetzungen zum Einrichten eines Tunnels sind in der Übersichtsseite dargestellt. Dieser Artikel geht nur auf die rudimentäre Konfiguration des Edge Routers ein.<br />
<br />
Update 02/2018: ein EdgeOS-Wizard hiefür ist in Entwicklung: https://github.com/pocki80/ER-wizard-0xFF-OpenVPN2TS<br />
<br />
== Einrichten des Tunnels ==<br />
<br />
Empfohlen wird, die Konfigurationsdateien und das Skript zuerst auf Deinem Computer anzulegen, und diese gemeinsam in der Folge per SSH ins Verzeichnis /config/user-data/ zu kopieren. Alternativ kannst Du sie auch händisch über das CLI wie vi anlegen. Wir benötigen:<br />
<br />
1) funkfeuer.ovpn mit folgendem Inhalt - die kursiv dargestellten Zeilen musst Du mit jenen Werten befüllen, die Du von den Tunneladmins zugewiesen bekommen hast:<br />
<br />
dev vtun0<br />
dev-type tap<br />
proto udp<br />
remote 78.41.115.16<br />
''port [5XXX]''<br />
up-delay<br />
down-pre<br />
up-restart<br />
comp-lzo<br />
script-security 2<br />
nobind<br />
ping 10<br />
ping-restart 60<br />
ping-timer-rem<br />
fast-io<br />
sndbuf 524288 <br />
rcvbuf 524288<br />
mute 2<br />
verb 0<br />
up "/config/user-data/funkfeuer-ifupdown.sh"<br />
down "/config/user-data/funkfeuer-ifupdown.sh"<br />
<br />
<br />
Es gibt spezielle Betriebsmodi für OLSR, wie etwa den Mode „silent“. Um diesen zu nützen, kann man zwei Zeilen mit einem Skriptparameter anpassen:<br />
<br />
up "/config/user-data/funkfeuer-ifupdown.sh silent"<br />
down "/config/user-data/funkfeuer-ifupdown.sh silent"<br />
<br />
<br />
Wurde für Deinen Tunnel bereits ein shared key/secret angelegt, benötigst Du zusätzlich folgende Zeilen:<br />
<br />
secret /config/user-data/funkfeuer.secret<br />
cipher none<br />
auth none<br />
alternativ<br />
cipher none<br />
auth SHA256<br />
<br />
<br />
2) funkfeuer.secret - wenn ein Key angelegt wurde, wie in 1) beschrieben.<br />
<br />
Diese Datei beinhaltet einen individuellen kryptographischen Schlüssel (shared key), der sicherstellt, dass der Tunnel nur von jenen Clients genutzt werden kann, denen er auch tatsächlich zugewiesen wurde. Das soll verhindern, dass ein Tunnel missbräuchlich oder versehentlich mehrfach genützt wird.<br />
Diesen Schlüssel erhältst Du per E-Mail und Du musst ihn lediglich in dieser Datei speichern.<br />
<br />
3) funkfeuer-ifupdown.sh<br />
<br />
Dieses Skript sorgt dafür, dass das Tunnel-Interface, nachdem es gestartet wurde, in die richtige Bridge gelegt wird, auf der bereits OLSR im vorgesehenen Modus läuft. Diese Vorgehensweise ist nicht sonderlich schön, aber sie funktioniert. Wir arbeiten an einer besseren Lösung. Leg Die Datei mit folgendem Inhalt an und mach sie ausführbar.<br />
----<br />
<br />
#!/bin/sh<br />
logger "$dev $script_type"<br />
case "$1" in<br />
silent)<br />
br="br9"<br />
;;<br />
ether)<br />
br="br8"<br />
;;<br />
*)<br />
br="br7"<br />
esac<br />
case "$script_type" in<br />
up)<br />
/sbin/brctl addif $br $dev<br />
/sbin/ip link set $br promisc on<br />
/sbin/ip link set $dev up<br />
;;<br />
down)<br />
/sbin/ip link set $dev down <br />
/sbin/ip link set $br promisc off<br />
/sbin/brctl delif $br $dev<br />
<br />
;;<br />
*)<br />
esac<br />
exit 0<br />
<br />
<br />
chmod +x funkfeuer-ifupdown.sh<br />
<br />
3) Folgende Config am EdgeRouter vornehmen (lokalen Gateway für Static-Route entsprechend ändern)<br />
<br />
set interfaces bridge br9 address 78.41.000.000/32<br />
set interfaces bridge br9 aging 300<br />
set interfaces bridge br9 bridged-conntrack disable<br />
set interfaces bridge br9 description TUNNEL<br />
set interfaces bridge br9 hello-time 2<br />
set interfaces bridge br9 max-age 20<br />
set interfaces bridge br9 priority 32768<br />
set interfaces bridge br9 stp false<br />
commit<br />
set protocols static route 78.41.115.16/32 next-hop 192.168.0.1 description 'TunnelServer via ISP'<br />
set interfaces openvpn vtun0 config-file /config/user-data/funkfeuer.ovpn<br />
commit<br />
save<br />
<br />
3) Im OLSRd_V1 Wizard das interface br9=silent, br8=ether oder br7=mesh für OLSR aktivieren</div>Erichhttps://wiki.funkfeuer.at/index.php?title=OpenVPN_mit_EdgeRouter_X-SFP&diff=2444OpenVPN mit EdgeRouter X-SFP2019-06-16T00:17:58Z<p>Erich: /* Einrichten des Tunnels */</p>
<hr />
<div>Anleitung in Arbeit - Entwurfsstadium<br />
<br />
<br />
Die allgemeinen Voraussetzungen zum Einrichten eines Tunnels sind in der Übersichtsseite dargestellt. Dieser Artikel geht nur auf die rudimentäre Konfiguration des Edge Routers ein.<br />
<br />
Update 02/2018: ein EdgeOS-Wizard hiefür ist in Entwicklung: https://github.com/pocki80/ER-wizard-0xFF-OpenVPN2TS<br />
<br />
== Einrichten des Tunnels ==<br />
<br />
Empfohlen wird, die Konfigurationsdateien und das Skript zuerst auf Deinem Computer anzulegen, und diese gemeinsam in der Folge per SSH ins Verzeichnis /config/user-data/ zu kopieren. Alternativ kannst Du sie auch händisch über das CLI wie vi anlegen. Wir benötigen:<br />
<br />
1) funkfeuer.ovpn mit folgendem Inhalt - die kursiv dargestellten Zeilen musst Du mit jenen Werten befüllen, die Du von den Tunneladmins zugewiesen bekommen hast:<br />
<br />
dev vtun0<br />
dev-type tap<br />
proto udp<br />
remote 78.41.115.16<br />
''port [5XXX]''<br />
up-delay<br />
down-pre<br />
up-restart<br />
comp-lzo<br />
script-security 2<br />
nobind<br />
ping 10<br />
ping-restart 60<br />
ping-timer-rem<br />
fast-io<br />
sndbuf 524288 <br />
rcvbuf 524288<br />
mute 2<br />
verb 0<br />
up "/config/user-data/funkfeuer-ifupdown.sh"<br />
down "/config/user-data/funkfeuer-ifupdown.sh"<br />
<br />
<br />
Es gibt spezielle Betriebsmodi für OLSR, wie etwa den Mode „silent“. Um diesen zu nützen, kann man zwei Zeilen mit einem Skriptparameter anpassen:<br />
<br />
up "/config/user-data/funkfeuer-ifupdown.sh silent"<br />
down "/config/user-data/funkfeuer-ifupdown.sh silent"<br />
<br />
<br />
Wurde für Deinen Tunnel bereits ein shared key/secret angelegt, benötigst Du zusätzlich folgende Zeilen:<br />
<br />
secret /config/user-data/funkfeuer.secret<br />
auth SHA256<br />
cipher none<br />
<br />
<br />
2) funkfeuer.secret - wenn ein Key angelegt wurde, wie in 1) beschrieben.<br />
<br />
Diese Datei beinhaltet einen individuellen kryptographischen Schlüssel (shared key), der sicherstellt, dass der Tunnel nur von jenen Clients genutzt werden kann, denen er auch tatsächlich zugewiesen wurde. Das soll verhindern, dass ein Tunnel missbräuchlich oder versehentlich mehrfach genützt wird.<br />
Diesen Schlüssel erhältst Du per E-Mail und Du musst ihn lediglich in dieser Datei speichern.<br />
<br />
3) funkfeuer-ifupdown.sh<br />
<br />
Dieses Skript sorgt dafür, dass das Tunnel-Interface, nachdem es gestartet wurde, in die richtige Bridge gelegt wird, auf der bereits OLSR im vorgesehenen Modus läuft. Diese Vorgehensweise ist nicht sonderlich schön, aber sie funktioniert. Wir arbeiten an einer besseren Lösung. Leg Die Datei mit folgendem Inhalt an und mach sie ausführbar.<br />
----<br />
<br />
#!/bin/sh<br />
logger "$dev $script_type"<br />
case "$1" in<br />
silent)<br />
br="br9"<br />
;;<br />
ether)<br />
br="br8"<br />
;;<br />
*)<br />
br="br7"<br />
esac<br />
case "$script_type" in<br />
up)<br />
/sbin/brctl addif $br $dev<br />
/sbin/ip link set $br promisc on<br />
/sbin/ip link set $dev up<br />
;;<br />
down)<br />
/sbin/ip link set $dev down <br />
/sbin/ip link set $br promisc off<br />
/sbin/brctl delif $br $dev<br />
<br />
;;<br />
*)<br />
esac<br />
exit 0<br />
<br />
<br />
chmod +x funkfeuer-ifupdown.sh<br />
<br />
3) Folgende Config am EdgeRouter vornehmen (lokalen Gateway für Static-Route entsprechend ändern)<br />
<br />
set interfaces bridge br9 address 78.41.000.000/32<br />
set interfaces bridge br9 aging 300<br />
set interfaces bridge br9 bridged-conntrack disable<br />
set interfaces bridge br9 description TUNNEL<br />
set interfaces bridge br9 hello-time 2<br />
set interfaces bridge br9 max-age 20<br />
set interfaces bridge br9 priority 32768<br />
set interfaces bridge br9 stp false<br />
commit<br />
set protocols static route 78.41.115.16/32 next-hop 192.168.0.1 description 'TunnelServer via ISP'<br />
set interfaces openvpn vtun0 config-file /config/user-data/funkfeuer.ovpn<br />
commit<br />
save<br />
<br />
3) Im OLSRd_V1 Wizard das interface br9=silent, br8=ether oder br7=mesh für OLSR aktivieren</div>Erichhttps://wiki.funkfeuer.at/index.php?title=OpenVPN_mit_LEDE/OpenWRT_oder_%E2%80%9EBubbles%E2%80%9C&diff=2443OpenVPN mit LEDE/OpenWRT oder „Bubbles“2019-06-15T23:36:26Z<p>Erich: </p>
<hr />
<div>ENTWURF - FEEDBACK WILLKOMMEN<br />
<br />
Diese Anleitung unterscheidet sich nicht besonders von dem, was wir für Debian oder für den EdgeRouter brauchen.<br />
Voraussetzung ist ein OpenWRT-Build mit bridge-utils, iproute2 und openvpn.<br />
Wir legen auf OpenWRT eine Bridge ohne Brigeports an, konfigurieren OpenVPN und legen ein ifup-down-Skript für den Tunnel an. OLSR läuft auf der Bridge.<br />
<br />
Paketvorschlag:<br />
luci-app-openvpn luci-i18n-openvpn-de openvpn-mbedtls ip-full <br />
<br />
<br />
== Bridge anlegen über die Konsole ==<br />
uci set network.ff=interface<br />
uci set network.ff.ifname='ff'<br />
uci set network.ff.type='bridge'<br />
uci set network.ff.proto='static'<br />
uci set network.ff.ipaddr='[FUNKFEUER-IP-ADRESSE-AUS-REDEEMER]'<br />
uci set network.ff.netmask='255.255.255.255'<br />
uci commit<br />
<br />
<br />
== [Ergänzen ... OLSR mittels UCI konfigrieren ...] ==<br />
<br />
== Auf die OpenVPN-Konfigurationsdatei verweisen ==<br />
Die Datei /etc/config/openvpn soll beinhalten:<br />
config openvpn 'Funkfeuer'<br />
option enabled '1'<br />
option config '/etc/openvpn/funkfeuer.conf'<br />
<br />
Über UCI legt man das an wie folgt:<br />
uci set openvpn.Funkfeuer=openvpn<br />
uci set openvpn.Funkfeuer.enabled='1'<br />
uci set openvpn.Funkfeuer.config='/etc/openvpn/funkfeuer.conf'<br />
uci commit<br />
<br />
<br />
== Die OpenVPN-Konfigurationsdatei ==<br />
/etc/openvpn/funkfeuer.conf:<br />
dev tap-ff<br />
dev-type tap<br />
proto udp<br />
remote 78.41.115.16<br />
port [5XXX]<br />
up-delay<br />
down-pre<br />
up-restart<br />
# comp-lzo #lassen wir aus Kompatibilitätsgrunden aus<br />
script-security 2<br />
nobind<br />
ping 10<br />
ping-restart 60<br />
ping-timer-rem<br />
fast-io<br />
sndbuf 524288 <br />
rcvbuf 524288<br />
txqueuelen 1000<br />
mute 2<br />
verb 0<br />
secret /etc/openvpn/funkfeuer.secret<br />
auth none<br />
cipher none<br />
up "/etc/openvpn/scripts/funkfeuer-ifupdown.sh"<br />
down "/etc/openvpn/scripts/funkfeuer-ifupdown.sh"<br />
<br />
== Das Secret ==<br />
Die Datei /etc/openvpn/funkfeuer.secret enthält den Key, den Du vom Tunneladmin erhalten hast - Beispielsweise:<br />
<br />
<br />
#<br />
# 2048 bit OpenVPN static key<br />
#<br />
-----BEGIN OpenVPN Static key V1-----<br />
61eaa6a0731c1114b92d98f4c71bc547<br />
a79050f1f888bb87c84355adbe916a8a<br />
b1e0cdd74f516b654c9542e46ea3216c<br />
f65bdb1fdad755022d73a1b35821f46e<br />
c9da48afb8feb3564f3d2de97a690fa9<br />
90ca9b2ddcedc842ee88a1f085c9b3e7<br />
518c8c9ae9a43ce64dc6c55789115652<br />
964af121b3097dddaf0f12a72981a25f<br />
4790575a0254f93e13ca4176433a0e8f<br />
2d526b12280766b32ef37737199c2d6e<br />
e1b006e9432a26a131cef64833421461<br />
ca6ae34349b3088c3a00e3ad6b024e6b<br />
fba26277c3818a99fa32f6be4480b075<br />
525f81b302b527c2e95fff90a4268fe6<br />
f067a05b484f4ea77e57afcf53c2c0b1<br />
79be9d144c9ac7aa874d3d248f6e5b35<br />
-----END OpenVPN Static key V1-----<br />
<br />
== Das ifupdown-Skript == <br />
=== Das Skript-Verzeichnis anlegen ===<br />
mkdir -p /etc/openvpn/scripts<br />
<br />
=== /etc/openvpn/scripts/funkfeuer-ifupdown.sh ===<br />
#!/bin/sh<br />
logger "$dev $script_type"<br />
br=br-ff<br />
case "$script_type" in<br />
up)<br />
/sbin/brctl addif $br $dev<br />
/sbin/ip link set $br promisc on<br />
/sbin/ip link set $dev up<br />
;;<br />
down)<br />
/sbin/ip link set $dev down <br />
/sbin/ip link set $br promisc off<br />
/sbin/brctl delif $br $dev <br />
<br />
;;<br />
*)<br />
esac<br />
exit 0<br />
<br />
=== Das Skript ausführbar machen ===<br />
chmod +x /etc/openvpn/scripts/funkfeuer-ifupdown.sh</div>Erichhttps://wiki.funkfeuer.at/index.php?title=OpenVPN_mit_LEDE/OpenWRT_oder_%E2%80%9EBubbles%E2%80%9C&diff=2442OpenVPN mit LEDE/OpenWRT oder „Bubbles“2019-06-15T23:35:32Z<p>Erich: /* Die OpenVPN-Konfigurationsdatei */</p>
<hr />
<div>ENTWURF - FEEDBACK WILLKOMMEN<br />
<br />
Diese Anleitung unterscheidet sich nicht besonders von dem, was wir für Debian oder für den EdgeRouter brauchen.<br />
Voraussetzung ist ein OpenWRT-Build mit bridge-utils, iproute2 und openvpn.<br />
Wir legen auf OpenWRT eine Bridge ohne Interfaces an, konfigurieren OpenVPN und legen ein ifup-down-Skript für den Tunnel an. OLSR läuft auf der Bridge.<br />
<br />
Paketvorschlag:<br />
luci-app-openvpn luci-i18n-openvpn-de openvpn-mbedtls ip-full <br />
<br />
<br />
== Bridge anlegen über die Konsole ==<br />
uci set network.ff=interface<br />
uci set network.ff.ifname='ff'<br />
uci set network.ff.type='bridge'<br />
uci set network.ff.proto='static'<br />
uci set network.ff.ipaddr='[FUNKFEUER-IP-ADRESSE-AUS-REDEEMER]'<br />
uci set network.ff.netmask='255.255.255.255'<br />
uci commit<br />
<br />
<br />
== [Ergänzen ... OLSR mittels UCI konfigrieren ...] ==<br />
<br />
== Auf die OpenVPN-Konfigurationsdatei verweisen ==<br />
Die Datei /etc/config/openvpn soll beinhalten:<br />
config openvpn 'Funkfeuer'<br />
option enabled '1'<br />
option config '/etc/openvpn/funkfeuer.conf'<br />
<br />
Über UCI legt man das an wie folgt:<br />
uci set openvpn.Funkfeuer=openvpn<br />
uci set openvpn.Funkfeuer.enabled='1'<br />
uci set openvpn.Funkfeuer.config='/etc/openvpn/funkfeuer.conf'<br />
uci commit<br />
<br />
<br />
== Die OpenVPN-Konfigurationsdatei ==<br />
/etc/openvpn/funkfeuer.conf:<br />
dev tap-ff<br />
dev-type tap<br />
proto udp<br />
remote 78.41.115.16<br />
port [5XXX]<br />
up-delay<br />
down-pre<br />
up-restart<br />
# comp-lzo #lassen wir aus Kompatibilitätsgrunden aus<br />
script-security 2<br />
nobind<br />
ping 10<br />
ping-restart 60<br />
ping-timer-rem<br />
fast-io<br />
sndbuf 524288 <br />
rcvbuf 524288<br />
txqueuelen 1000<br />
mute 2<br />
verb 0<br />
secret /etc/openvpn/funkfeuer.secret<br />
auth none<br />
cipher none<br />
up "/etc/openvpn/scripts/funkfeuer-ifupdown.sh"<br />
down "/etc/openvpn/scripts/funkfeuer-ifupdown.sh"<br />
<br />
== Das Secret ==<br />
Die Datei /etc/openvpn/funkfeuer.secret enthält den Key, den Du vom Tunneladmin erhalten hast - Beispielsweise:<br />
<br />
<br />
#<br />
# 2048 bit OpenVPN static key<br />
#<br />
-----BEGIN OpenVPN Static key V1-----<br />
61eaa6a0731c1114b92d98f4c71bc547<br />
a79050f1f888bb87c84355adbe916a8a<br />
b1e0cdd74f516b654c9542e46ea3216c<br />
f65bdb1fdad755022d73a1b35821f46e<br />
c9da48afb8feb3564f3d2de97a690fa9<br />
90ca9b2ddcedc842ee88a1f085c9b3e7<br />
518c8c9ae9a43ce64dc6c55789115652<br />
964af121b3097dddaf0f12a72981a25f<br />
4790575a0254f93e13ca4176433a0e8f<br />
2d526b12280766b32ef37737199c2d6e<br />
e1b006e9432a26a131cef64833421461<br />
ca6ae34349b3088c3a00e3ad6b024e6b<br />
fba26277c3818a99fa32f6be4480b075<br />
525f81b302b527c2e95fff90a4268fe6<br />
f067a05b484f4ea77e57afcf53c2c0b1<br />
79be9d144c9ac7aa874d3d248f6e5b35<br />
-----END OpenVPN Static key V1-----<br />
<br />
== Das ifupdown-Skript == <br />
=== Das Skript-Verzeichnis anlegen ===<br />
mkdir -p /etc/openvpn/scripts<br />
<br />
=== /etc/openvpn/scripts/funkfeuer-ifupdown.sh ===<br />
#!/bin/sh<br />
logger "$dev $script_type"<br />
br=br-ff<br />
case "$script_type" in<br />
up)<br />
/sbin/brctl addif $br $dev<br />
/sbin/ip link set $br promisc on<br />
/sbin/ip link set $dev up<br />
;;<br />
down)<br />
/sbin/ip link set $dev down <br />
/sbin/ip link set $br promisc off<br />
/sbin/brctl delif $br $dev <br />
<br />
;;<br />
*)<br />
esac<br />
exit 0<br />
<br />
=== Das Skript ausführbar machen ===<br />
chmod +x /etc/openvpn/scripts/funkfeuer-ifupdown.sh</div>Erichhttps://wiki.funkfeuer.at/index.php?title=OpenVPN_mit_LEDE/OpenWRT_oder_%E2%80%9EBubbles%E2%80%9C&diff=2441OpenVPN mit LEDE/OpenWRT oder „Bubbles“2019-06-15T23:34:24Z<p>Erich: </p>
<hr />
<div>ENTWURF - FEEDBACK WILLKOMMEN<br />
<br />
Diese Anleitung unterscheidet sich nicht besonders von dem, was wir für Debian oder für den EdgeRouter brauchen.<br />
Voraussetzung ist ein OpenWRT-Build mit bridge-utils, iproute2 und openvpn.<br />
Wir legen auf OpenWRT eine Bridge ohne Interfaces an, konfigurieren OpenVPN und legen ein ifup-down-Skript für den Tunnel an. OLSR läuft auf der Bridge.<br />
<br />
Paketvorschlag:<br />
luci-app-openvpn luci-i18n-openvpn-de openvpn-mbedtls ip-full <br />
<br />
<br />
== Bridge anlegen über die Konsole ==<br />
uci set network.ff=interface<br />
uci set network.ff.ifname='ff'<br />
uci set network.ff.type='bridge'<br />
uci set network.ff.proto='static'<br />
uci set network.ff.ipaddr='[FUNKFEUER-IP-ADRESSE-AUS-REDEEMER]'<br />
uci set network.ff.netmask='255.255.255.255'<br />
uci commit<br />
<br />
<br />
== [Ergänzen ... OLSR mittels UCI konfigrieren ...] ==<br />
<br />
== Auf die OpenVPN-Konfigurationsdatei verweisen ==<br />
Die Datei /etc/config/openvpn soll beinhalten:<br />
config openvpn 'Funkfeuer'<br />
option enabled '1'<br />
option config '/etc/openvpn/funkfeuer.conf'<br />
<br />
Über UCI legt man das an wie folgt:<br />
uci set openvpn.Funkfeuer=openvpn<br />
uci set openvpn.Funkfeuer.enabled='1'<br />
uci set openvpn.Funkfeuer.config='/etc/openvpn/funkfeuer.conf'<br />
uci commit<br />
<br />
<br />
== Die OpenVPN-Konfigurationsdatei ==<br />
/etc/openvpn/funkfeuer.conf:<br />
dev tap-ff<br />
dev-type tap<br />
proto udp<br />
remote 78.41.115.16<br />
port [5XXX]<br />
up-delay<br />
down-pre<br />
up-restart<br />
# comp-lzo #lassen wir aus Kompatibilitätsgrunden aus<br />
script-security 2<br />
nobind<br />
ping 10<br />
ping-restart 60<br />
ping-timer-rem<br />
fast-io<br />
sndbuf 524288 <br />
rcvbuf 524288<br />
mute 2<br />
verb 0<br />
secret /etc/openvpn/funkfeuer.secret<br />
auth none<br />
cipher none<br />
up "/etc/openvpn/scripts/funkfeuer-ifupdown.sh"<br />
down "/etc/openvpn/scripts/funkfeuer-ifupdown.sh"<br />
<br />
== Das Secret ==<br />
Die Datei /etc/openvpn/funkfeuer.secret enthält den Key, den Du vom Tunneladmin erhalten hast - Beispielsweise:<br />
<br />
<br />
#<br />
# 2048 bit OpenVPN static key<br />
#<br />
-----BEGIN OpenVPN Static key V1-----<br />
61eaa6a0731c1114b92d98f4c71bc547<br />
a79050f1f888bb87c84355adbe916a8a<br />
b1e0cdd74f516b654c9542e46ea3216c<br />
f65bdb1fdad755022d73a1b35821f46e<br />
c9da48afb8feb3564f3d2de97a690fa9<br />
90ca9b2ddcedc842ee88a1f085c9b3e7<br />
518c8c9ae9a43ce64dc6c55789115652<br />
964af121b3097dddaf0f12a72981a25f<br />
4790575a0254f93e13ca4176433a0e8f<br />
2d526b12280766b32ef37737199c2d6e<br />
e1b006e9432a26a131cef64833421461<br />
ca6ae34349b3088c3a00e3ad6b024e6b<br />
fba26277c3818a99fa32f6be4480b075<br />
525f81b302b527c2e95fff90a4268fe6<br />
f067a05b484f4ea77e57afcf53c2c0b1<br />
79be9d144c9ac7aa874d3d248f6e5b35<br />
-----END OpenVPN Static key V1-----<br />
<br />
== Das ifupdown-Skript == <br />
=== Das Skript-Verzeichnis anlegen ===<br />
mkdir -p /etc/openvpn/scripts<br />
<br />
=== /etc/openvpn/scripts/funkfeuer-ifupdown.sh ===<br />
#!/bin/sh<br />
logger "$dev $script_type"<br />
br=br-ff<br />
case "$script_type" in<br />
up)<br />
/sbin/brctl addif $br $dev<br />
/sbin/ip link set $br promisc on<br />
/sbin/ip link set $dev up<br />
;;<br />
down)<br />
/sbin/ip link set $dev down <br />
/sbin/ip link set $br promisc off<br />
/sbin/brctl delif $br $dev <br />
<br />
;;<br />
*)<br />
esac<br />
exit 0<br />
<br />
=== Das Skript ausführbar machen ===<br />
chmod +x /etc/openvpn/scripts/funkfeuer-ifupdown.sh</div>Erichhttps://wiki.funkfeuer.at/index.php?title=OpenVPN_mit_LEDE/OpenWRT_oder_%E2%80%9EBubbles%E2%80%9C&diff=2440OpenVPN mit LEDE/OpenWRT oder „Bubbles“2019-06-15T23:24:30Z<p>Erich: </p>
<hr />
<div>ENTWURF - FEEDBACK WILLKOMMEN<br />
<br />
Diese Anleitung unterscheidet sich nicht besonders von dem, was wir für Debian oder für den EdgeRouter brauchen.<br />
Voraussetzung ist ein OpenWRT-Build mit bridge-utils, iproute2 und openvpn.<br />
Wir legen auf OpenWRT eine Bridge ohne Interfaces an, konfigurieren OpenVPN und legen ein ifup-down-Skript für den Tunnel an. OLSR läuft auf der Bridge.<br />
<br />
Paketvorschlag:<br />
luci-app-openvpn luci-i18n-openvpn-de openvpn-mbedtls ip-full <br />
<br />
Bridge anlegen über die Konsole:<br />
uci set network.ff=interface<br />
uci set network.ff.ifname='ff'<br />
uci set network.ff.type='bridge'<br />
uci set network.ff.proto='static'<br />
uci set network.ff.ipaddr='[FUNKFEUER-IP-ADRESSE-AUS-REDEEMER]'<br />
uci set network.ff.netmask='255.255.255.255'<br />
uci commit<br />
<br />
<br />
[Ergänzen ... OLSR mittels UCI konfigurieren ...]<br />
<br />
/etc/config/openvpn:<br />
config openvpn 'Funkfeuer'<br />
option enabled '1'<br />
option config '/etc/openvpn/funkfeuer.conf'<br />
<br />
/etc/openvpn/funkfeuer.conf:<br />
dev tap-ff<br />
dev-type tap<br />
proto udp<br />
remote 78.41.115.16<br />
port [5XXX]<br />
up-delay<br />
down-pre<br />
up-restart<br />
# comp-lzo #lassen wir aus Kompatibilitätsgrunden aus<br />
script-security 2<br />
nobind<br />
ping 10<br />
ping-restart 60<br />
ping-timer-rem<br />
fast-io<br />
sndbuf 524288 <br />
rcvbuf 524288<br />
mute 2<br />
verb 0<br />
secret /etc/openvpn/funkfeuer.secret<br />
auth none<br />
cipher none<br />
up "/etc/openvpn/scripts/funkfeuer-ifupdown.sh"<br />
down "/etc/openvpn/scripts/funkfeuer-ifupdown.sh"<br />
<br />
<br />
/etc/openvpn/funkfeuer.secret:<br />
<br />
<br />
/etc/openvpn/scripts/funkfeuer-ifupdown.sh:<br />
#!/bin/sh<br />
logger "$dev $script_type"<br />
br=br-ff<br />
case "$script_type" in<br />
up)<br />
/sbin/brctl addif $br $dev<br />
/sbin/ip link set $br promisc on<br />
/sbin/ip link set $dev up<br />
;;<br />
down)<br />
/sbin/ip link set $dev down <br />
/sbin/ip link set $br promisc off<br />
/sbin/brctl delif $br $dev <br />
<br />
;;<br />
*)<br />
esac<br />
exit 0</div>Erichhttps://wiki.funkfeuer.at/index.php?title=OpenVPN_mit_LEDE/OpenWRT_oder_%E2%80%9EBubbles%E2%80%9C&diff=2439OpenVPN mit LEDE/OpenWRT oder „Bubbles“2019-06-15T23:22:47Z<p>Erich: Die Seite wurde neu angelegt: „ENTWURF - FEEDBACK WILLKOMMEN Diese Anleitung unterscheidet sich nicht besonders von dem, was wir für Debian oder für den EdgeRouter brauchen. Voraussetzung…“</p>
<hr />
<div>ENTWURF - FEEDBACK WILLKOMMEN<br />
<br />
Diese Anleitung unterscheidet sich nicht besonders von dem, was wir für Debian oder für den EdgeRouter brauchen.<br />
Voraussetzung ist ein OpenWRT-Build mit bridge-utils, iproute2 und openvpn.<br />
Wir legen auf OpenWRT eine Bridge ohne Interfaces an, konfigurieren OpenVPN und legen ein ifup-down-Skript für den Tunnel an. OLSR läuft auf der Bridge.<br />
<br />
Paketvorschlag:<br />
luci-app-openvpn luci-i18n-openvpn-de openvpn-mbedtls ip-full <br />
<br />
Bridge anlegen über die Konsole:<br />
uci set network.ff=interface<br />
uci set network.ff.ifname='ff'<br />
uci set network.ff.type='bridge'<br />
uci set network.ff.proto='static'<br />
uci set network.ff.ipaddr='[FUNKFEUER-IP-ADRESSE-AUS-REDEEMER]'<br />
uci set network.ff.netmask='255.255.255.255'<br />
uci commit<br />
<br />
<br />
[Ergänzen ... OLSR mittels UCI konfigurieren ...]<br />
<br />
/etc/config/openvpn:<br />
config openvpn 'Funkfeuer'<br />
option enabled '1'<br />
option config '/etc/openvpn/funkfeuer.conf'<br />
<br />
/etc/openvpn/funkfeuer.conf:<br />
<nowiki><br />
dev tap-ff<br />
dev-type tap<br />
proto udp<br />
remote 78.41.115.16<br />
port [5XXX]<br />
up-delay<br />
down-pre<br />
up-restart<br />
# comp-lzo #lassen wir aus Kompatibilitätsgrunden aus<br />
script-security 2<br />
nobind<br />
ping 10<br />
ping-restart 60<br />
ping-timer-rem<br />
fast-io<br />
sndbuf 524288 <br />
rcvbuf 524288<br />
mute 2<br />
verb 0<br />
secret /etc/openvpn/funkfeuer.secret<br />
auth none<br />
cipher none<br />
up "/etc/openvpn/scripts/funkfeuer-ifupdown.sh"<br />
down "/etc/openvpn/scripts/funkfeuer-ifupdown.sh"<br />
</nowiki><br />
<br />
/etc/openvpn/funkfeuer.secret:<br />
<br />
<br />
/etc/openvpn/scripts/funkfeuer-ifupdown.sh:<br />
#!/bin/sh<br />
logger "$dev $script_type"<br />
br=br-ff<br />
case "$script_type" in<br />
up)<br />
/sbin/brctl addif $br $dev<br />
/sbin/ip link set $br promisc on<br />
/sbin/ip link set $dev up<br />
;;<br />
down)<br />
/sbin/ip link set $dev down <br />
/sbin/ip link set $br promisc off<br />
/sbin/brctl delif $br $dev<br />
<br />
;;<br />
*)<br />
esac<br />
exit 0</div>Erichhttps://wiki.funkfeuer.at/index.php?title=Datei:Stimmrechts%C3%BCbertragung-GV2019-blanko.pdf&diff=2389Datei:Stimmrechtsübertragung-GV2019-blanko.pdf2019-05-26T19:14:10Z<p>Erich: Erich lud eine neue Version von Datei:Stimmrechtsübertragung-GV2019-blanko.pdf hoch</p>
<hr />
<div></div>Erichhttps://wiki.funkfeuer.at/index.php?title=Regionen/Wien/Verein&diff=2388Regionen/Wien/Verein2019-05-26T19:01:45Z<p>Erich: /* Generalversammlung 2019 */</p>
<hr />
<div>Der Verein dient als Plattform zur Verbreitung des Wissens, das nötig ist, um ein solches Netzwerk aufzubauen und zu betreiben. Um dies zu bewerkstelligen, gibt es die [[Regionen/Wien/Montagstreffen | Montagstreffen]] und die Mailinglisten.<br />
<br />
== Offizielles ==<br />
<br />
=== Presseanfragen ===<br />
Presseanfragen bitte an: [mailto:presse@funkfeuer.at presse@funkfeuer.at]<br />
<br />
=== Rechnungen, Buchhaltung ===<br />
<br />
Rechnungen bitte an [mailto:billing@funkfeuer.at billing@funkfeuer.at].<br />
<br />
=== Offizielle Vereinsadressen ===<br />
==== Postanschrift ====<br />
<br />
Verein FunkFeuer Wien<br /><br />
Postfach 44<br /><br />
1016 Wien<br /><br />
Email: [mailto:vorstand@funkfeuer.at vorstand@funkfeuer.at]<br />
<br />
==== Vereinsanschrift laut ZVR ====<br />
<br />
Verein FunkFeuer Wien<br /><br />
Gonzagagasse 11/25<br /><br />
1010 Wien<br /><br />
<br />
(Anm.: Diese Adresse gibt es nur, weil das LPD Wien kein Postfach als Vereinsadresse akzeptiert. '''Kleine Sendungen bitte an unsere Postanschrift (siehe oben), größere Lieferungen bitte vorher vereinbaren.''')<br />
<br />
==== USt.-UID, ZVR-Nummer ====<br />
<br />
* ZVR: 814804682<br />
* UID: ATU67830859<br />
<br />
=== Kontoverbindung ===<br />
<br />
Inhaber: Verein FunkFeuer Wien<br /><br />
IBAN: AT552023000000143982<br /><br />
BIC/SWIFT: SPLSAT21<br />
<br />
<br />
=== Vorstand ===<br />
<br />
Per 22.05.2018<br />
<br />
* Obmann: Albert Rafetseder<br />
* Obmann Stv.: Markus Kittenberger<br />
* Kassier: Thomas Mutschlechner<br />
* Kassier Stv.: Markus Gschwendt<br />
* Schriftführer: Matthias Šubik<br />
* Schriftführer Stv.: Manfred Sengeis<br />
<br />
<br />
=== Statuten, Mitgliedsantrag, Stimmrechtsübertragung ===<br />
<br />
Hier geht's zu den [[Media:Statuten_Funkfeuer_Wien.pdf | Statuten]] und dem [[Media:Mitgliedsantrag-Funkfeuer-Wien.pdf | Mitgliedsantrag]]<br />
== Spenden ==<br />
<br />
Der laufende Betrieb des FunkFeuer-Netzes setzt einiges an Hardware voraus. Um diese Unkosten zu decken, bitten wir euch um freiwillige Spenden. Entscheidet selbst, was euch das Netz wert ist.<br />
<br />
== Generalversammlung 2019 ==<br />
Die GV 2019 findet am Montag 27.05.2019 in der Laxenburger Straße 4 um 18:00 statt.<br />
Weitere Informationen dazu gibt es [[Regionen/Wien/Verein/201905_GV|hier im Wiki]].<br />
<br />
[[Media:Stimmrechts%C3%BCbertragung-GV2019-blanko.pdf | Stimmrechtsübertragung GV2019]].<br />
<br />
== Generalversammlung 2018 ==<br />
[[Events/Generalversammlung_2018|Die GV 2018]] fand am Dienstag 22.05.2018 um 18:00 im Metalab statt. Das Protokoll liegt [[Regionen/Wien/Verein/201805_GV_Protokoll|hier im Wiki]].<br />
<br />
[[Media:Stimmrechts%C3%BCbertragung-GV2018-blanko.pdf | Stimmrechtsübertragung GV2018]].</div>Erichhttps://wiki.funkfeuer.at/index.php?title=Datei:Stimmrechts%C3%BCbertragung-GV2019-blanko.pdf&diff=2387Datei:Stimmrechtsübertragung-GV2019-blanko.pdf2019-05-26T18:59:53Z<p>Erich: </p>
<hr />
<div></div>Erichhttps://wiki.funkfeuer.at/index.php?title=Services/Organisation/Tunnelserver&diff=2266Services/Organisation/Tunnelserver2019-02-02T02:54:34Z<p>Erich: </p>
<hr />
<div>{{Projekt<br />
|name=Tunnelserver<br />
|startdate=2017/09/20<br />
|state=Aktiv<br />
|desc=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.<br />
}}<br />
<br />
== Beschreibung ==<br />
<br />
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. <br />
<br />
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.<br />
<br />
== Maintainer ==<br />
Erich N. Pekarek,Christoph Lösch,Christian Pock,Bernhard Marker<br />
<br />
== Abhängigkeiten ==<br />
<br />
Das Tunnelserverprojekt ist von folgenden Projektgruppen abhängig:<br />
<br />
* Core-Team/Roofnode-Team<br />
* v642-Projekt<br />
* Housing/VM<br />
<br />
<s>Um die wechselseitigen Abhängigkeiten zu reduzieren, lautet der aktuelle Projektfahrplan wie folgt:<br />
Den gegenwärtigen Tunnelserver, der leider auch andere, systemrelevante Aufgaben erledigt, in mehreren Schritten zu migrieren.<br />
* Vorbereitungen:<br />
** Sämtliche Tunnelfunktionen von Tunnel6 und Tunnel auf der „VM-Tunnel6“ zu vereinen.<br />
** Tests neuer Funktionen.<br />
* Hauptphase: Die vereinte VM wird auf eine physische Hardware migriert. Diese Maschine wird wie ein Roofnode mit erhöhter Redundanz eingebunden werden.<br />
* Nacharbeiten:<br />
** Anschließend die VM „Tunnel 6“ stilllegen.<br />
** Die Routing-Funktionen der „VM Tunnel” auf die neuen Roofnodes oder andere Router so verteilen, wie es sinnvoll ist.<br />
** Die VM „Tunnel“ anschließend stilllegen.<br />
</s><br />
* Dauerarbeiten: Wartung und Betreuung.<br />
<br />
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.<br />
<br />
== Details ==<br />
Gegenwärtiger Status:<br />
<s>* Tunnel VM hat Aufgaben von Tunnel6 vorübergehend übernommen.</s><br />
<s>* 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.</s><br />
<s>* Die physische Maschine ist bereits rudimentär eingerichtet.</s><br />
* 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.<br />
* Migration abgeschlossen, Regelbetrieb.<br />
<br />
== Verwendung ==<br />
[[OpenVPN-Tunnel_zu_Funkfeuer]]</div>Erichhttps://wiki.funkfeuer.at/index.php?title=Services&diff=2265Services2019-02-02T02:48:37Z<p>Erich: </p>
<hr />
<div><br />
*'''[[Services/Organisation|Organisation]]'''<br />
<br />
*'''[https://portal.funkfeuer.at/wien/ Portal Wien (Redeemer, Frontend Benutzerdatenbank)]''' ''Stammdaten-, Node- und IP-Adressverwaltung ''<br />
*'''[https://forum.funkfeuer.at/ Forum]'''<br />
<br />
*'''[http://lists.funkfeuer.at/mailman/listinfo Mailinglisten]'''<br />
<br />
*'''[https://wiki.funkfeuer.at/wiki/Projekte/Housing Housing]'''<br />
<br />
*'''[https://wiki.funkfeuer.at/wiki/5V/8W_Housing 5V/8W Housing]'''<br />
<br />
*'''[http://gallery.funkfeuer.at/ Gallery]'''<br />
<br />
*'''Tunnelserver''' [https://wiki.funkfeuer.at/wiki/Projekte/Tunnelserver Weiterführende Infos]<br />
**'''[http://tunnel.wien.funkfeuer.at/ Tunnelserver StatusInfo]''' ''der OpenVPN-Tunnel Clients im Netz von Funkfeuer-Wien: Suidao''<br />
<br />
*'''Weathermaps''' ''zeigen Auslastung und aktuelle Trends unserer Infrastruktur'':<br />
**'''[https://nms.bb.funkfeuer.at/plugins/Weathermap/output/bbcoreint-bw.png Backbone-Core-Intern]''' ''an der physischen Struktur angelehnt''<br />
**'''[https://nms.bb.funkfeuer.at/plugins/Weathermap/output/the4.png The-4-Zones]''' ''nach logischem Netzwerkaufbau orientiert''<br />
<br />
*'''[https://lg.bb.funkfeuer.at Backbone Routing]''' ''bird looking glass ermöglicht traceroute''<br />
*'''[https://portal.funkfeuer.at/wien/smokeping/ Smokeping]''' ''Netzwerklatenzübersicht''<br />
<br />
*'''[https://voip.funkfeuer.at VoIP Telefonie]''' ''im Netz von Funkfeuer-Wien''<br />
*'''[http://download.funkfeuer.at Downloadbereich]''' Funkfeuer-CI<br />
<br />
*'''[[Services/Security]]'''<br />
*'''[[Services/Safety]]'''<br />
*'''[[Services/DNS]]'''</div>Erichhttps://wiki.funkfeuer.at/index.php?title=Vorschl%C3%A4ge_Locations&diff=2093Vorschläge Locations2018-09-20T21:19:31Z<p>Erich: /* 1140 Wien, Gurkgasse */</p>
<hr />
<div>'''Eure Mithilfe ist gefragt:''' Nehmt die Vorlage (am Ende der Seite) zur Hand, sucht Locations und dokumentiert sie hier im Wiki so ausführlich wie möglich!<br />
<br />
=== Dein Vorschlag ===<br />
*<br />
*<br />
<br />
=== 1140 Wien, Gurkgasse ===<br />
* ehemaliges großes Kellermagazin in einem Zinshaus nahe U3 Hütteldorfer Straße, dzt. nicht vermietet.<br />
* weitläufiger Keller, Beton/Ziegel; in Frage kommender Bereich betoniert.<br />
* Angeblich Glasfaser in Meiselstraße und/oder Gurkgasse vorhanden (früher einmal gesehen auf open-net.at)<br />
* Gute Kontakte zum Eigentümer, Funkfeuer-Knoten des bereits am Dach (Hausmeister).<br />
* Kosten sind noch zu eruieren, werden aber nicht exorbitant sein.<br />
* Strom wird neu zu machen sein,<br />
* ebenso werden ein paar Trockenbauwände für Einteilung in „Kammerl“ zu machen sein, wenn das gewünscht ist.<br />
<br />
=== 1010 Wien, Rathausstraße 15 ===<br />
* schräg gegenüber der ÖBV.<br />
* Haus wurde von GraWe Immo verwaltet.<br />
* Keller grenzt an das alte Vivi an (Glasfaser).<br />
* Eine angrenzende Location war daher damals, als das Vivi aufgelöst wurde, schon im Gespräch. Keller wurde damals (2006/2007 besichtigt).<br />
* Miete unbekannt, Abteile eher klein.<br />
<br />
=== Metalab-Keller ===<br />
<br />
* Adresse: 1010 Wien, Rathausstraße 6, 1. Untergeschoß<br />
* Typ: Keller mit Ziegelwänden<br />
* Öffis, Parkplätze: Wie Metalab (2er, 5er, U2; Kurzparkzone)<br />
* Status & nächste Schritte: Schon besichtigt, Kontakt mit HVW folgt KW38<br />
* Raum und Maße: ~5 vielversprechende Räume; von LxBxH 5x5x2,5m bis 2x2x2,5m<br />
* Wie funktioniert der Zugang? Via Metalab und dessen Lichthof<br />
* Bodenbeschaffenheit: Stein (?)<br />
* Wände: eher trocken, unverputzt, größtenteils tragend<br />
* Luftzufuhr: über Metalab-Lichthof; eventuell zur Straße hinaus, eventuell zugänglicher Luftschacht<br />
* Strom, Glasfaser: Wien Energie hat Mittelspannungstrafo & Glas im Keller!<br />
* Preis, Befristung, Fotos --- noch nichts bekannt<br />
* Vorgeschlagen von: Clemens<br />
* Datum für nächstes Update? 23.09.2018<br />
<br />
=== Notizen von Runout ===<br />
<br />
==== besichtigt ====<br />
<br />
* [[Vorschläge_Locations/1180_schulgasse_18]]<br />
* [[Vorschläge_Locations/1070_kaiserstrasse_76]]<br />
<br />
<br />
==== gefunden ====<br />
<br />
* [https://www.wohnnet.at/immobilien/lager-1090-wien-alsergrund-miete-128013245 1090-wien-alsergrund] 90m² 390€ Pasteurgasse<br />
* [https://www.wohnnet.at/immobilien/lager-1070-wien-neubau-miete-272556913 1070-wien-neubau] 50² 309€ Spittelberg<br />
* [https://www.wohnnet.at/immobilien/lager-1080-wien-josefstadt-miete-270300488 1080-wien-josefstadt] 196m² 4€/m² Josefstädter Straße 76<br />
* [https://www.wohnnet.at/immobilien/lager-1150-wien-rudolfsheim-fuenfhaus-miete-274033494 1150-wien-rudolfsheim-fuenfhaus] 112m² 385€<br />
* [https://www.wohnnet.at/immobilien/lager-1050-wien-margareten-miete-2-zimmer-274964063 1050-wien-margareten] 90m² 421€ Arbeiterg.<br />
* [https://www.wohnnet.at/immobilien/lager-1150-wien-rudolfsheim-fuenfhaus-miete-274898419 1150-wien-rudolfsheim-fuenfhaus] 73m² 341€ Sechshauser Straße<br />
<br />
== Vorlage ==<br />
<br />
* Adresse (inklusive Stockwerk)<br />
* Typ: z.B. Keller, Garage, Serverraum<br />
* Öffis, Parkplätze, Kurzparkzone, Parkpickerl<br />
* Vorgeschlagen von $DIR<br />
* Status & nächste Schritte: Davon gehört? Gelesen? Schon besichtigt? Ansprechpartner_in gefunden? In Preisverhandlung?<br />
* Preis (pro Quadratmeter, HE, kW, ...)<br />
* Befristung<br />
* Fotos<br />
* Wie funktioniert der Zugang?<br />
* Nächste Schritte, Datum für Update?<br />
* Raum und Maße: Anzahl, Länge, Breite, Höhe<br />
* Bodenbeschaffenheit: Lehm, Beton (tragfähig?), Doppelboden<br />
* Wände: z.B. trocken/feucht, verputzt, Rigips; tragend<br />
* Luftzufuhr: z.B. in einen Lichthof, zur Straße hinaus, zugänglicher Luftschacht, Klimaanlage<br />
* Strom: 3 Phasen 16 A aufwärts<br />
* Glasfaser: Betreiber, Entfernung<br />
* Preis pro Quadratmeter</div>Erichhttps://wiki.funkfeuer.at/index.php?title=Vorschl%C3%A4ge_Locations&diff=2092Vorschläge Locations2018-09-20T21:13:52Z<p>Erich: /* 1010 Wien, Rathausstraße 15 */</p>
<hr />
<div>'''Eure Mithilfe ist gefragt:''' Nehmt die Vorlage (am Ende der Seite) zur Hand, sucht Locations und dokumentiert sie hier im Wiki so ausführlich wie möglich!<br />
<br />
=== Dein Vorschlag ===<br />
*<br />
*<br />
<br />
=== 1140 Wien, Gurkgasse ===<br />
* ehemaliges großes Magazin in einem Zinshaus nahe U3, dzt. nicht vermietet. Angeblich Glasfaser in Meiselstraße und/oder Gurkgasse vorhanden (früher gesehen auf open-net.at). Gute Kontakte zum Eigentümer, Funkfeuer-Knoten des bereits am Dach (Hausmeister). Kosten sind noch zu eruieren, werden aber nicht exorbitant sein. Strom wird neu zu machen sein, ebenso werden ein paar Trockenbauwände für Einteilung in „Kammerl“ zu machen sein, wenn das gewünscht ist.<br />
<br />
=== 1010 Wien, Rathausstraße 15 ===<br />
* schräg gegenüber der ÖBV.<br />
* Haus wurde von GraWe Immo verwaltet.<br />
* Keller grenzt an das alte Vivi an (Glasfaser).<br />
* Eine angrenzende Location war daher damals, als das Vivi aufgelöst wurde, schon im Gespräch. Keller wurde damals (2006/2007 besichtigt).<br />
* Miete unbekannt, Abteile eher klein.<br />
<br />
=== Metalab-Keller ===<br />
<br />
* Adresse: 1010 Wien, Rathausstraße 6, 1. Untergeschoß<br />
* Typ: Keller mit Ziegelwänden<br />
* Öffis, Parkplätze: Wie Metalab (2er, 5er, U2; Kurzparkzone)<br />
* Status & nächste Schritte: Schon besichtigt, Kontakt mit HVW folgt KW38<br />
* Raum und Maße: ~5 vielversprechende Räume; von LxBxH 5x5x2,5m bis 2x2x2,5m<br />
* Wie funktioniert der Zugang? Via Metalab und dessen Lichthof<br />
* Bodenbeschaffenheit: Stein (?)<br />
* Wände: eher trocken, unverputzt, größtenteils tragend<br />
* Luftzufuhr: über Metalab-Lichthof; eventuell zur Straße hinaus, eventuell zugänglicher Luftschacht<br />
* Strom, Glasfaser: Wien Energie hat Mittelspannungstrafo & Glas im Keller!<br />
* Preis, Befristung, Fotos --- noch nichts bekannt<br />
* Vorgeschlagen von: Clemens<br />
* Datum für nächstes Update? 23.09.2018<br />
<br />
=== Notizen von Runout ===<br />
<br />
==== besichtigt ====<br />
<br />
* [[Vorschläge_Locations/1180_schulgasse_18]]<br />
* [[Vorschläge_Locations/1070_kaiserstrasse_76]]<br />
<br />
<br />
==== gefunden ====<br />
<br />
* [https://www.wohnnet.at/immobilien/lager-1090-wien-alsergrund-miete-128013245 1090-wien-alsergrund] 90m² 390€ Pasteurgasse<br />
* [https://www.wohnnet.at/immobilien/lager-1070-wien-neubau-miete-272556913 1070-wien-neubau] 50² 309€ Spittelberg<br />
* [https://www.wohnnet.at/immobilien/lager-1080-wien-josefstadt-miete-270300488 1080-wien-josefstadt] 196m² 4€/m² Josefstädter Straße 76<br />
* [https://www.wohnnet.at/immobilien/lager-1150-wien-rudolfsheim-fuenfhaus-miete-274033494 1150-wien-rudolfsheim-fuenfhaus] 112m² 385€<br />
* [https://www.wohnnet.at/immobilien/lager-1050-wien-margareten-miete-2-zimmer-274964063 1050-wien-margareten] 90m² 421€ Arbeiterg.<br />
* [https://www.wohnnet.at/immobilien/lager-1150-wien-rudolfsheim-fuenfhaus-miete-274898419 1150-wien-rudolfsheim-fuenfhaus] 73m² 341€ Sechshauser Straße<br />
<br />
== Vorlage ==<br />
<br />
* Adresse (inklusive Stockwerk)<br />
* Typ: z.B. Keller, Garage, Serverraum<br />
* Öffis, Parkplätze, Kurzparkzone, Parkpickerl<br />
* Vorgeschlagen von $DIR<br />
* Status & nächste Schritte: Davon gehört? Gelesen? Schon besichtigt? Ansprechpartner_in gefunden? In Preisverhandlung?<br />
* Preis (pro Quadratmeter, HE, kW, ...)<br />
* Befristung<br />
* Fotos<br />
* Wie funktioniert der Zugang?<br />
* Nächste Schritte, Datum für Update?<br />
* Raum und Maße: Anzahl, Länge, Breite, Höhe<br />
* Bodenbeschaffenheit: Lehm, Beton (tragfähig?), Doppelboden<br />
* Wände: z.B. trocken/feucht, verputzt, Rigips; tragend<br />
* Luftzufuhr: z.B. in einen Lichthof, zur Straße hinaus, zugänglicher Luftschacht, Klimaanlage<br />
* Strom: 3 Phasen 16 A aufwärts<br />
* Glasfaser: Betreiber, Entfernung<br />
* Preis pro Quadratmeter</div>Erichhttps://wiki.funkfeuer.at/index.php?title=Vorschl%C3%A4ge_Locations&diff=2091Vorschläge Locations2018-09-20T21:11:31Z<p>Erich: /* 1010 Wien, Rathausstraße 15 */</p>
<hr />
<div>'''Eure Mithilfe ist gefragt:''' Nehmt die Vorlage (am Ende der Seite) zur Hand, sucht Locations und dokumentiert sie hier im Wiki so ausführlich wie möglich!<br />
<br />
=== Dein Vorschlag ===<br />
*<br />
*<br />
<br />
=== 1140 Wien, Gurkgasse ===<br />
* ehemaliges großes Magazin in einem Zinshaus nahe U3, dzt. nicht vermietet. Angeblich Glasfaser in Meiselstraße und/oder Gurkgasse vorhanden (früher gesehen auf open-net.at). Gute Kontakte zum Eigentümer, Funkfeuer-Knoten des bereits am Dach (Hausmeister). Kosten sind noch zu eruieren, werden aber nicht exorbitant sein. Strom wird neu zu machen sein, ebenso werden ein paar Trockenbauwände für Einteilung in „Kammerl“ zu machen sein, wenn das gewünscht ist.<br />
<br />
=== 1010 Wien, Rathausstraße 15 ===<br />
* schräg gegenüber der ÖBV. Haus wurde von GraWe Immo verwaltet. Keller grenzt an das alte Vivi an. Eine angrenzende Location war daher damals, als das Vivi aufgelöst wurde, schon im Gespräch. Es sind im Haus eventuell einige Kellerabteile frei - das wäre noch abzuklären. Tür und Strom müsste dann wohl neu gemacht werden.<br />
<br />
=== Metalab-Keller ===<br />
<br />
* Adresse: 1010 Wien, Rathausstraße 6, 1. Untergeschoß<br />
* Typ: Keller mit Ziegelwänden<br />
* Öffis, Parkplätze: Wie Metalab (2er, 5er, U2; Kurzparkzone)<br />
* Status & nächste Schritte: Schon besichtigt, Kontakt mit HVW folgt KW38<br />
* Raum und Maße: ~5 vielversprechende Räume; von LxBxH 5x5x2,5m bis 2x2x2,5m<br />
* Wie funktioniert der Zugang? Via Metalab und dessen Lichthof<br />
* Bodenbeschaffenheit: Stein (?)<br />
* Wände: eher trocken, unverputzt, größtenteils tragend<br />
* Luftzufuhr: über Metalab-Lichthof; eventuell zur Straße hinaus, eventuell zugänglicher Luftschacht<br />
* Strom, Glasfaser: Wien Energie hat Mittelspannungstrafo & Glas im Keller!<br />
* Preis, Befristung, Fotos --- noch nichts bekannt<br />
* Vorgeschlagen von: Clemens<br />
* Datum für nächstes Update? 23.09.2018<br />
<br />
=== Notizen von Runout ===<br />
<br />
==== besichtigt ====<br />
<br />
* [[Vorschläge_Locations/1180_schulgasse_18]]<br />
* [[Vorschläge_Locations/1070_kaiserstrasse_76]]<br />
<br />
<br />
==== gefunden ====<br />
<br />
* [https://www.wohnnet.at/immobilien/lager-1090-wien-alsergrund-miete-128013245 1090-wien-alsergrund] 90m² 390€ Pasteurgasse<br />
* [https://www.wohnnet.at/immobilien/lager-1070-wien-neubau-miete-272556913 1070-wien-neubau] 50² 309€ Spittelberg<br />
* [https://www.wohnnet.at/immobilien/lager-1080-wien-josefstadt-miete-270300488 1080-wien-josefstadt] 196m² 4€/m² Josefstädter Straße 76<br />
* [https://www.wohnnet.at/immobilien/lager-1150-wien-rudolfsheim-fuenfhaus-miete-274033494 1150-wien-rudolfsheim-fuenfhaus] 112m² 385€<br />
* [https://www.wohnnet.at/immobilien/lager-1050-wien-margareten-miete-2-zimmer-274964063 1050-wien-margareten] 90m² 421€ Arbeiterg.<br />
* [https://www.wohnnet.at/immobilien/lager-1150-wien-rudolfsheim-fuenfhaus-miete-274898419 1150-wien-rudolfsheim-fuenfhaus] 73m² 341€ Sechshauser Straße<br />
<br />
== Vorlage ==<br />
<br />
* Adresse (inklusive Stockwerk)<br />
* Typ: z.B. Keller, Garage, Serverraum<br />
* Öffis, Parkplätze, Kurzparkzone, Parkpickerl<br />
* Vorgeschlagen von $DIR<br />
* Status & nächste Schritte: Davon gehört? Gelesen? Schon besichtigt? Ansprechpartner_in gefunden? In Preisverhandlung?<br />
* Preis (pro Quadratmeter, HE, kW, ...)<br />
* Befristung<br />
* Fotos<br />
* Wie funktioniert der Zugang?<br />
* Nächste Schritte, Datum für Update?<br />
* Raum und Maße: Anzahl, Länge, Breite, Höhe<br />
* Bodenbeschaffenheit: Lehm, Beton (tragfähig?), Doppelboden<br />
* Wände: z.B. trocken/feucht, verputzt, Rigips; tragend<br />
* Luftzufuhr: z.B. in einen Lichthof, zur Straße hinaus, zugänglicher Luftschacht, Klimaanlage<br />
* Strom: 3 Phasen 16 A aufwärts<br />
* Glasfaser: Betreiber, Entfernung<br />
* Preis pro Quadratmeter</div>Erichhttps://wiki.funkfeuer.at/index.php?title=Vorschl%C3%A4ge_Locations&diff=2090Vorschläge Locations2018-09-20T21:09:08Z<p>Erich: /* 1010 Wien, Rathausstraße 15 */</p>
<hr />
<div>'''Eure Mithilfe ist gefragt:''' Nehmt die Vorlage (am Ende der Seite) zur Hand, sucht Locations und dokumentiert sie hier im Wiki so ausführlich wie möglich!<br />
<br />
=== Dein Vorschlag ===<br />
*<br />
*<br />
<br />
=== 1140 Wien, Gurkgasse ===<br />
* ehemaliges großes Magazin in einem Zinshaus nahe U3, dzt. nicht vermietet. Angeblich Glasfaser in Meiselstraße und/oder Gurkgasse vorhanden (früher gesehen auf open-net.at). Gute Kontakte zum Eigentümer, Funkfeuer-Knoten des bereits am Dach (Hausmeister). Kosten sind noch zu eruieren, werden aber nicht exorbitant sein. Strom wird neu zu machen sein, ebenso werden ein paar Trockenbauwände für Einteilung in „Kammerl“ zu machen sein, wenn das gewünscht ist.<br />
<br />
=== 1010 Wien, Rathausstraße 15 ===<br />
* schräg gegenüber der ÖBV. Haus wird von GraWe Immo verwaltet. Keller grenzt an das alte Vivi an. Eine angrenzende Location war daher damals, als das Vivi aufgelöst wurde, schon im Gespräch. Es sind im Haus eventuell einige Kellerabteile frei - das wäre noch abzuklären. Tür und Strom müsste dann wohl neu gemacht werden.<br />
<br />
=== Metalab-Keller ===<br />
<br />
* Adresse: 1010 Wien, Rathausstraße 6, 1. Untergeschoß<br />
* Typ: Keller mit Ziegelwänden<br />
* Öffis, Parkplätze: Wie Metalab (2er, 5er, U2; Kurzparkzone)<br />
* Status & nächste Schritte: Schon besichtigt, Kontakt mit HVW folgt KW38<br />
* Raum und Maße: ~5 vielversprechende Räume; von LxBxH 5x5x2,5m bis 2x2x2,5m<br />
* Wie funktioniert der Zugang? Via Metalab und dessen Lichthof<br />
* Bodenbeschaffenheit: Stein (?)<br />
* Wände: eher trocken, unverputzt, größtenteils tragend<br />
* Luftzufuhr: über Metalab-Lichthof; eventuell zur Straße hinaus, eventuell zugänglicher Luftschacht<br />
* Strom, Glasfaser: Wien Energie hat Mittelspannungstrafo & Glas im Keller!<br />
* Preis, Befristung, Fotos --- noch nichts bekannt<br />
* Vorgeschlagen von: Clemens<br />
* Datum für nächstes Update? 23.09.2018<br />
<br />
=== Notizen von Runout ===<br />
<br />
==== besichtigt ====<br />
<br />
* [[Vorschläge_Locations/1180_schulgasse_18]]<br />
* [[Vorschläge_Locations/1070_kaiserstrasse_76]]<br />
<br />
<br />
==== gefunden ====<br />
<br />
* [https://www.wohnnet.at/immobilien/lager-1090-wien-alsergrund-miete-128013245 1090-wien-alsergrund] 90m² 390€ Pasteurgasse<br />
* [https://www.wohnnet.at/immobilien/lager-1070-wien-neubau-miete-272556913 1070-wien-neubau] 50² 309€ Spittelberg<br />
* [https://www.wohnnet.at/immobilien/lager-1080-wien-josefstadt-miete-270300488 1080-wien-josefstadt] 196m² 4€/m² Josefstädter Straße 76<br />
* [https://www.wohnnet.at/immobilien/lager-1150-wien-rudolfsheim-fuenfhaus-miete-274033494 1150-wien-rudolfsheim-fuenfhaus] 112m² 385€<br />
* [https://www.wohnnet.at/immobilien/lager-1050-wien-margareten-miete-2-zimmer-274964063 1050-wien-margareten] 90m² 421€ Arbeiterg.<br />
* [https://www.wohnnet.at/immobilien/lager-1150-wien-rudolfsheim-fuenfhaus-miete-274898419 1150-wien-rudolfsheim-fuenfhaus] 73m² 341€ Sechshauser Straße<br />
<br />
== Vorlage ==<br />
<br />
* Adresse (inklusive Stockwerk)<br />
* Typ: z.B. Keller, Garage, Serverraum<br />
* Öffis, Parkplätze, Kurzparkzone, Parkpickerl<br />
* Vorgeschlagen von $DIR<br />
* Status & nächste Schritte: Davon gehört? Gelesen? Schon besichtigt? Ansprechpartner_in gefunden? In Preisverhandlung?<br />
* Preis (pro Quadratmeter, HE, kW, ...)<br />
* Befristung<br />
* Fotos<br />
* Wie funktioniert der Zugang?<br />
* Nächste Schritte, Datum für Update?<br />
* Raum und Maße: Anzahl, Länge, Breite, Höhe<br />
* Bodenbeschaffenheit: Lehm, Beton (tragfähig?), Doppelboden<br />
* Wände: z.B. trocken/feucht, verputzt, Rigips; tragend<br />
* Luftzufuhr: z.B. in einen Lichthof, zur Straße hinaus, zugänglicher Luftschacht, Klimaanlage<br />
* Strom: 3 Phasen 16 A aufwärts<br />
* Glasfaser: Betreiber, Entfernung<br />
* Preis pro Quadratmeter</div>Erichhttps://wiki.funkfeuer.at/index.php?title=Vorschl%C3%A4ge_Locations&diff=2089Vorschläge Locations2018-09-20T21:08:50Z<p>Erich: /* 1140 Wien, Gurkgasse */</p>
<hr />
<div>'''Eure Mithilfe ist gefragt:''' Nehmt die Vorlage (am Ende der Seite) zur Hand, sucht Locations und dokumentiert sie hier im Wiki so ausführlich wie möglich!<br />
<br />
=== Dein Vorschlag ===<br />
*<br />
*<br />
<br />
=== 1140 Wien, Gurkgasse ===<br />
* ehemaliges großes Magazin in einem Zinshaus nahe U3, dzt. nicht vermietet. Angeblich Glasfaser in Meiselstraße und/oder Gurkgasse vorhanden (früher gesehen auf open-net.at). Gute Kontakte zum Eigentümer, Funkfeuer-Knoten des bereits am Dach (Hausmeister). Kosten sind noch zu eruieren, werden aber nicht exorbitant sein. Strom wird neu zu machen sein, ebenso werden ein paar Trockenbauwände für Einteilung in „Kammerl“ zu machen sein, wenn das gewünscht ist.<br />
<br />
=== 1010 Wien, Rathausstraße 15 ===<br />
gegenüber der ÖBV. Haus wird von GraWe Immo verwaltet. Keller grenzt an das alte Vivi an. Eine angrenzende Location war daher damals, als das Vivi aufgelöst wurde, schon im Gespräch. Es sind im Haus eventuell einige Kellerabteile frei - das wäre noch abzuklären. Tür und Strom müsste dann wohl neu gemacht werden.<br />
<br />
=== Metalab-Keller ===<br />
<br />
* Adresse: 1010 Wien, Rathausstraße 6, 1. Untergeschoß<br />
* Typ: Keller mit Ziegelwänden<br />
* Öffis, Parkplätze: Wie Metalab (2er, 5er, U2; Kurzparkzone)<br />
* Status & nächste Schritte: Schon besichtigt, Kontakt mit HVW folgt KW38<br />
* Raum und Maße: ~5 vielversprechende Räume; von LxBxH 5x5x2,5m bis 2x2x2,5m<br />
* Wie funktioniert der Zugang? Via Metalab und dessen Lichthof<br />
* Bodenbeschaffenheit: Stein (?)<br />
* Wände: eher trocken, unverputzt, größtenteils tragend<br />
* Luftzufuhr: über Metalab-Lichthof; eventuell zur Straße hinaus, eventuell zugänglicher Luftschacht<br />
* Strom, Glasfaser: Wien Energie hat Mittelspannungstrafo & Glas im Keller!<br />
* Preis, Befristung, Fotos --- noch nichts bekannt<br />
* Vorgeschlagen von: Clemens<br />
* Datum für nächstes Update? 23.09.2018<br />
<br />
=== Notizen von Runout ===<br />
<br />
==== besichtigt ====<br />
<br />
* [[Vorschläge_Locations/1180_schulgasse_18]]<br />
* [[Vorschläge_Locations/1070_kaiserstrasse_76]]<br />
<br />
<br />
==== gefunden ====<br />
<br />
* [https://www.wohnnet.at/immobilien/lager-1090-wien-alsergrund-miete-128013245 1090-wien-alsergrund] 90m² 390€ Pasteurgasse<br />
* [https://www.wohnnet.at/immobilien/lager-1070-wien-neubau-miete-272556913 1070-wien-neubau] 50² 309€ Spittelberg<br />
* [https://www.wohnnet.at/immobilien/lager-1080-wien-josefstadt-miete-270300488 1080-wien-josefstadt] 196m² 4€/m² Josefstädter Straße 76<br />
* [https://www.wohnnet.at/immobilien/lager-1150-wien-rudolfsheim-fuenfhaus-miete-274033494 1150-wien-rudolfsheim-fuenfhaus] 112m² 385€<br />
* [https://www.wohnnet.at/immobilien/lager-1050-wien-margareten-miete-2-zimmer-274964063 1050-wien-margareten] 90m² 421€ Arbeiterg.<br />
* [https://www.wohnnet.at/immobilien/lager-1150-wien-rudolfsheim-fuenfhaus-miete-274898419 1150-wien-rudolfsheim-fuenfhaus] 73m² 341€ Sechshauser Straße<br />
<br />
== Vorlage ==<br />
<br />
* Adresse (inklusive Stockwerk)<br />
* Typ: z.B. Keller, Garage, Serverraum<br />
* Öffis, Parkplätze, Kurzparkzone, Parkpickerl<br />
* Vorgeschlagen von $DIR<br />
* Status & nächste Schritte: Davon gehört? Gelesen? Schon besichtigt? Ansprechpartner_in gefunden? In Preisverhandlung?<br />
* Preis (pro Quadratmeter, HE, kW, ...)<br />
* Befristung<br />
* Fotos<br />
* Wie funktioniert der Zugang?<br />
* Nächste Schritte, Datum für Update?<br />
* Raum und Maße: Anzahl, Länge, Breite, Höhe<br />
* Bodenbeschaffenheit: Lehm, Beton (tragfähig?), Doppelboden<br />
* Wände: z.B. trocken/feucht, verputzt, Rigips; tragend<br />
* Luftzufuhr: z.B. in einen Lichthof, zur Straße hinaus, zugänglicher Luftschacht, Klimaanlage<br />
* Strom: 3 Phasen 16 A aufwärts<br />
* Glasfaser: Betreiber, Entfernung<br />
* Preis pro Quadratmeter</div>Erichhttps://wiki.funkfeuer.at/index.php?title=Vorschl%C3%A4ge_Locations&diff=2088Vorschläge Locations2018-09-20T21:00:30Z<p>Erich: /* 1140 Wien, Gurkgasse */</p>
<hr />
<div>'''Eure Mithilfe ist gefragt:''' Nehmt die Vorlage (am Ende der Seite) zur Hand, sucht Locations und dokumentiert sie hier im Wiki so ausführlich wie möglich!<br />
<br />
=== Dein Vorschlag ===<br />
*<br />
*<br />
<br />
=== 1140 Wien, Gurkgasse ===<br />
* ehemaliges großes Magazin in einem Zinshaus nahe U3, dzt. nicht vermietet. Angeblich Glasfaser in Meiselstraße und/oder Gurkgasse vorhanden (früher gesehen auf open-net.at). Gute Kontakte zum Eigentümer, Funkfeuer-Knoten des bereits am Dach (Hausmeister). Kosten sind noch zu eruieren, werden aber nicht exorbitant sein. Strom wird neu zu machen sein, ebenso werden ein paar Trockenbauwände für Einteilung in „Kammerl“ zu machen sein, wenn das gewünscht ist.<br />
<br />
=== Metalab-Keller ===<br />
<br />
* Adresse: 1010 Wien, Rathausstraße 6, 1. Untergeschoß<br />
* Typ: Keller mit Ziegelwänden<br />
* Öffis, Parkplätze: Wie Metalab (2er, 5er, U2; Kurzparkzone)<br />
* Status & nächste Schritte: Schon besichtigt, Kontakt mit HVW folgt KW38<br />
* Raum und Maße: ~5 vielversprechende Räume; von LxBxH 5x5x2,5m bis 2x2x2,5m<br />
* Wie funktioniert der Zugang? Via Metalab und dessen Lichthof<br />
* Bodenbeschaffenheit: Stein (?)<br />
* Wände: eher trocken, unverputzt, größtenteils tragend<br />
* Luftzufuhr: über Metalab-Lichthof; eventuell zur Straße hinaus, eventuell zugänglicher Luftschacht<br />
* Strom, Glasfaser: Wien Energie hat Mittelspannungstrafo & Glas im Keller!<br />
* Preis, Befristung, Fotos --- noch nichts bekannt<br />
* Vorgeschlagen von: Clemens<br />
* Datum für nächstes Update? 23.09.2018<br />
<br />
=== Notizen von Runout ===<br />
<br />
==== besichtigt ====<br />
<br />
* [[Vorschläge_Locations/1180_schulgasse_18]]<br />
* [[Vorschläge_Locations/1070_kaiserstrasse_76]]<br />
<br />
<br />
==== gefunden ====<br />
<br />
* [https://www.wohnnet.at/immobilien/lager-1090-wien-alsergrund-miete-128013245 1090-wien-alsergrund] 90m² 390€ Pasteurgasse<br />
* [https://www.wohnnet.at/immobilien/lager-1070-wien-neubau-miete-272556913 1070-wien-neubau] 50² 309€ Spittelberg<br />
* [https://www.wohnnet.at/immobilien/lager-1080-wien-josefstadt-miete-270300488 1080-wien-josefstadt] 196m² 4€/m² Josefstädter Straße 76<br />
* [https://www.wohnnet.at/immobilien/lager-1150-wien-rudolfsheim-fuenfhaus-miete-274033494 1150-wien-rudolfsheim-fuenfhaus] 112m² 385€<br />
* [https://www.wohnnet.at/immobilien/lager-1050-wien-margareten-miete-2-zimmer-274964063 1050-wien-margareten] 90m² 421€ Arbeiterg.<br />
* [https://www.wohnnet.at/immobilien/lager-1150-wien-rudolfsheim-fuenfhaus-miete-274898419 1150-wien-rudolfsheim-fuenfhaus] 73m² 341€ Sechshauser Straße<br />
<br />
== Vorlage ==<br />
<br />
* Adresse (inklusive Stockwerk)<br />
* Typ: z.B. Keller, Garage, Serverraum<br />
* Öffis, Parkplätze, Kurzparkzone, Parkpickerl<br />
* Vorgeschlagen von $DIR<br />
* Status & nächste Schritte: Davon gehört? Gelesen? Schon besichtigt? Ansprechpartner_in gefunden? In Preisverhandlung?<br />
* Preis (pro Quadratmeter, HE, kW, ...)<br />
* Befristung<br />
* Fotos<br />
* Wie funktioniert der Zugang?<br />
* Nächste Schritte, Datum für Update?<br />
* Raum und Maße: Anzahl, Länge, Breite, Höhe<br />
* Bodenbeschaffenheit: Lehm, Beton (tragfähig?), Doppelboden<br />
* Wände: z.B. trocken/feucht, verputzt, Rigips; tragend<br />
* Luftzufuhr: z.B. in einen Lichthof, zur Straße hinaus, zugänglicher Luftschacht, Klimaanlage<br />
* Strom: 3 Phasen 16 A aufwärts<br />
* Glasfaser: Betreiber, Entfernung<br />
* Preis pro Quadratmeter</div>Erichhttps://wiki.funkfeuer.at/index.php?title=Vorschl%C3%A4ge_Locations&diff=2087Vorschläge Locations2018-09-20T20:55:41Z<p>Erich: /* 1140 Wien, Gurkgasse */</p>
<hr />
<div>'''Eure Mithilfe ist gefragt:''' Nehmt die Vorlage (am Ende der Seite) zur Hand, sucht Locations und dokumentiert sie hier im Wiki so ausführlich wie möglich!<br />
<br />
=== Dein Vorschlag ===<br />
*<br />
*<br />
<br />
=== 1140 Wien, Gurkgasse ===<br />
* ehemaliges großes Magazin in einem Zinshaus nahe U3, dzt. nicht vermietet. Angeblich Glasfaser in Meiselstraße und/oder Gurkgasse vorhanden (früher gesehen auf open-net.at). Gute Kontakte zum Eigentümer, Funkfeuer-Knoten bereits am Dach. Kosten sind noch zu eruieren, werden aber nicht exorbitant sein. Strom wird neu zu machen sein, ebenso ein paar Trockenbauwände für „Kammerl“.<br />
<br />
=== Metalab-Keller ===<br />
<br />
* Adresse: 1010 Wien, Rathausstraße 6, 1. Untergeschoß<br />
* Typ: Keller mit Ziegelwänden<br />
* Öffis, Parkplätze: Wie Metalab (2er, 5er, U2; Kurzparkzone)<br />
* Status & nächste Schritte: Schon besichtigt, Kontakt mit HVW folgt KW38<br />
* Raum und Maße: ~5 vielversprechende Räume; von LxBxH 5x5x2,5m bis 2x2x2,5m<br />
* Wie funktioniert der Zugang? Via Metalab und dessen Lichthof<br />
* Bodenbeschaffenheit: Stein (?)<br />
* Wände: eher trocken, unverputzt, größtenteils tragend<br />
* Luftzufuhr: über Metalab-Lichthof; eventuell zur Straße hinaus, eventuell zugänglicher Luftschacht<br />
* Strom, Glasfaser: Wien Energie hat Mittelspannungstrafo & Glas im Keller!<br />
* Preis, Befristung, Fotos --- noch nichts bekannt<br />
* Vorgeschlagen von: Clemens<br />
* Datum für nächstes Update? 23.09.2018<br />
<br />
=== Notizen von Runout ===<br />
<br />
==== besichtigt ====<br />
<br />
* [[Vorschläge_Locations/1180_schulgasse_18]]<br />
* [[Vorschläge_Locations/1070_kaiserstrasse_76]]<br />
<br />
<br />
==== gefunden ====<br />
<br />
* [https://www.wohnnet.at/immobilien/lager-1090-wien-alsergrund-miete-128013245 1090-wien-alsergrund] 90m² 390€ Pasteurgasse<br />
* [https://www.wohnnet.at/immobilien/lager-1070-wien-neubau-miete-272556913 1070-wien-neubau] 50² 309€ Spittelberg<br />
* [https://www.wohnnet.at/immobilien/lager-1080-wien-josefstadt-miete-270300488 1080-wien-josefstadt] 196m² 4€/m² Josefstädter Straße 76<br />
* [https://www.wohnnet.at/immobilien/lager-1150-wien-rudolfsheim-fuenfhaus-miete-274033494 1150-wien-rudolfsheim-fuenfhaus] 112m² 385€<br />
* [https://www.wohnnet.at/immobilien/lager-1050-wien-margareten-miete-2-zimmer-274964063 1050-wien-margareten] 90m² 421€ Arbeiterg.<br />
* [https://www.wohnnet.at/immobilien/lager-1150-wien-rudolfsheim-fuenfhaus-miete-274898419 1150-wien-rudolfsheim-fuenfhaus] 73m² 341€ Sechshauser Straße<br />
<br />
== Vorlage ==<br />
<br />
* Adresse (inklusive Stockwerk)<br />
* Typ: z.B. Keller, Garage, Serverraum<br />
* Öffis, Parkplätze, Kurzparkzone, Parkpickerl<br />
* Vorgeschlagen von $DIR<br />
* Status & nächste Schritte: Davon gehört? Gelesen? Schon besichtigt? Ansprechpartner_in gefunden? In Preisverhandlung?<br />
* Preis (pro Quadratmeter, HE, kW, ...)<br />
* Befristung<br />
* Fotos<br />
* Wie funktioniert der Zugang?<br />
* Nächste Schritte, Datum für Update?<br />
* Raum und Maße: Anzahl, Länge, Breite, Höhe<br />
* Bodenbeschaffenheit: Lehm, Beton (tragfähig?), Doppelboden<br />
* Wände: z.B. trocken/feucht, verputzt, Rigips; tragend<br />
* Luftzufuhr: z.B. in einen Lichthof, zur Straße hinaus, zugänglicher Luftschacht, Klimaanlage<br />
* Strom: 3 Phasen 16 A aufwärts<br />
* Glasfaser: Betreiber, Entfernung<br />
* Preis pro Quadratmeter</div>Erichhttps://wiki.funkfeuer.at/index.php?title=Vorschl%C3%A4ge_Locations&diff=2086Vorschläge Locations2018-09-20T20:53:20Z<p>Erich: /* Dein Vorschlag */</p>
<hr />
<div>'''Eure Mithilfe ist gefragt:''' Nehmt die Vorlage (am Ende der Seite) zur Hand, sucht Locations und dokumentiert sie hier im Wiki so ausführlich wie möglich!<br />
<br />
=== Dein Vorschlag ===<br />
*<br />
*<br />
<br />
=== 1140 Wien, Gurkgasse ===<br />
* ehemaliges großes Magazin in einem Zinshaus nahe U3, dzt. nicht vermietet. Angeblich Glasfaser in Meiselstraße und/oder Gurkgasse vorhanden. Gute Kontakte zum Eigentümer, Funkfeuer-Knoten bereits am Dach. Kosten sind noch zu eruieren, werden aber nicht exorbitant sein. Strom wird neu zu machen sein, ebenso ein paar Trockenbauwände für „Kammerl“.<br />
<br />
=== Metalab-Keller ===<br />
<br />
* Adresse: 1010 Wien, Rathausstraße 6, 1. Untergeschoß<br />
* Typ: Keller mit Ziegelwänden<br />
* Öffis, Parkplätze: Wie Metalab (2er, 5er, U2; Kurzparkzone)<br />
* Status & nächste Schritte: Schon besichtigt, Kontakt mit HVW folgt KW38<br />
* Raum und Maße: ~5 vielversprechende Räume; von LxBxH 5x5x2,5m bis 2x2x2,5m<br />
* Wie funktioniert der Zugang? Via Metalab und dessen Lichthof<br />
* Bodenbeschaffenheit: Stein (?)<br />
* Wände: eher trocken, unverputzt, größtenteils tragend<br />
* Luftzufuhr: über Metalab-Lichthof; eventuell zur Straße hinaus, eventuell zugänglicher Luftschacht<br />
* Strom, Glasfaser: Wien Energie hat Mittelspannungstrafo & Glas im Keller!<br />
* Preis, Befristung, Fotos --- noch nichts bekannt<br />
* Vorgeschlagen von: Clemens<br />
* Datum für nächstes Update? 23.09.2018<br />
<br />
=== Notizen von Runout ===<br />
<br />
==== besichtigt ====<br />
<br />
* [[Vorschläge_Locations/1180_schulgasse_18]]<br />
* [[Vorschläge_Locations/1070_kaiserstrasse_76]]<br />
<br />
<br />
==== gefunden ====<br />
<br />
* [https://www.wohnnet.at/immobilien/lager-1090-wien-alsergrund-miete-128013245 1090-wien-alsergrund] 90m² 390€ Pasteurgasse<br />
* [https://www.wohnnet.at/immobilien/lager-1070-wien-neubau-miete-272556913 1070-wien-neubau] 50² 309€ Spittelberg<br />
* [https://www.wohnnet.at/immobilien/lager-1080-wien-josefstadt-miete-270300488 1080-wien-josefstadt] 196m² 4€/m² Josefstädter Straße 76<br />
* [https://www.wohnnet.at/immobilien/lager-1150-wien-rudolfsheim-fuenfhaus-miete-274033494 1150-wien-rudolfsheim-fuenfhaus] 112m² 385€<br />
* [https://www.wohnnet.at/immobilien/lager-1050-wien-margareten-miete-2-zimmer-274964063 1050-wien-margareten] 90m² 421€ Arbeiterg.<br />
* [https://www.wohnnet.at/immobilien/lager-1150-wien-rudolfsheim-fuenfhaus-miete-274898419 1150-wien-rudolfsheim-fuenfhaus] 73m² 341€ Sechshauser Straße<br />
<br />
== Vorlage ==<br />
<br />
* Adresse (inklusive Stockwerk)<br />
* Typ: z.B. Keller, Garage, Serverraum<br />
* Öffis, Parkplätze, Kurzparkzone, Parkpickerl<br />
* Vorgeschlagen von $DIR<br />
* Status & nächste Schritte: Davon gehört? Gelesen? Schon besichtigt? Ansprechpartner_in gefunden? In Preisverhandlung?<br />
* Preis (pro Quadratmeter, HE, kW, ...)<br />
* Befristung<br />
* Fotos<br />
* Wie funktioniert der Zugang?<br />
* Nächste Schritte, Datum für Update?<br />
* Raum und Maße: Anzahl, Länge, Breite, Höhe<br />
* Bodenbeschaffenheit: Lehm, Beton (tragfähig?), Doppelboden<br />
* Wände: z.B. trocken/feucht, verputzt, Rigips; tragend<br />
* Luftzufuhr: z.B. in einen Lichthof, zur Straße hinaus, zugänglicher Luftschacht, Klimaanlage<br />
* Strom: 3 Phasen 16 A aufwärts<br />
* Glasfaser: Betreiber, Entfernung<br />
* Preis pro Quadratmeter</div>Erichhttps://wiki.funkfeuer.at/index.php?title=Vorschl%C3%A4ge_Locations&diff=2085Vorschläge Locations2018-09-20T20:51:44Z<p>Erich: /* Dein Vorschlag */</p>
<hr />
<div>'''Eure Mithilfe ist gefragt:''' Nehmt die Vorlage (am Ende der Seite) zur Hand, sucht Locations und dokumentiert sie hier im Wiki so ausführlich wie möglich!<br />
<br />
=== Dein Vorschlag ===<br />
* 1140 Wien, Gurkgasse.<br />
* ehemaliges Magazin in einem Zinshaus nahe U3, dzt. nicht vermietet. Angeblich Glasfaser in Meiselstraße und/oder Gurkgasse vorhanden. Gute Kontakte zum Eigentümer, Funkfeuer-Knoten bereits am Dach. Kosten sind noch zu eruieren, werden aber nicht exorbitant sein.<br />
<br />
=== Metalab-Keller ===<br />
<br />
* Adresse: 1010 Wien, Rathausstraße 6, 1. Untergeschoß<br />
* Typ: Keller mit Ziegelwänden<br />
* Öffis, Parkplätze: Wie Metalab (2er, 5er, U2; Kurzparkzone)<br />
* Status & nächste Schritte: Schon besichtigt, Kontakt mit HVW folgt KW38<br />
* Raum und Maße: ~5 vielversprechende Räume; von LxBxH 5x5x2,5m bis 2x2x2,5m<br />
* Wie funktioniert der Zugang? Via Metalab und dessen Lichthof<br />
* Bodenbeschaffenheit: Stein (?)<br />
* Wände: eher trocken, unverputzt, größtenteils tragend<br />
* Luftzufuhr: über Metalab-Lichthof; eventuell zur Straße hinaus, eventuell zugänglicher Luftschacht<br />
* Strom, Glasfaser: Wien Energie hat Mittelspannungstrafo & Glas im Keller!<br />
* Preis, Befristung, Fotos --- noch nichts bekannt<br />
* Vorgeschlagen von: Clemens<br />
* Datum für nächstes Update? 23.09.2018<br />
<br />
=== Notizen von Runout ===<br />
<br />
==== besichtigt ====<br />
<br />
* [[Vorschläge_Locations/1180_schulgasse_18]]<br />
* [[Vorschläge_Locations/1070_kaiserstrasse_76]]<br />
<br />
<br />
==== gefunden ====<br />
<br />
* [https://www.wohnnet.at/immobilien/lager-1090-wien-alsergrund-miete-128013245 1090-wien-alsergrund] 90m² 390€ Pasteurgasse<br />
* [https://www.wohnnet.at/immobilien/lager-1070-wien-neubau-miete-272556913 1070-wien-neubau] 50² 309€ Spittelberg<br />
* [https://www.wohnnet.at/immobilien/lager-1080-wien-josefstadt-miete-270300488 1080-wien-josefstadt] 196m² 4€/m² Josefstädter Straße 76<br />
* [https://www.wohnnet.at/immobilien/lager-1150-wien-rudolfsheim-fuenfhaus-miete-274033494 1150-wien-rudolfsheim-fuenfhaus] 112m² 385€<br />
* [https://www.wohnnet.at/immobilien/lager-1050-wien-margareten-miete-2-zimmer-274964063 1050-wien-margareten] 90m² 421€ Arbeiterg.<br />
* [https://www.wohnnet.at/immobilien/lager-1150-wien-rudolfsheim-fuenfhaus-miete-274898419 1150-wien-rudolfsheim-fuenfhaus] 73m² 341€ Sechshauser Straße<br />
<br />
== Vorlage ==<br />
<br />
* Adresse (inklusive Stockwerk)<br />
* Typ: z.B. Keller, Garage, Serverraum<br />
* Öffis, Parkplätze, Kurzparkzone, Parkpickerl<br />
* Vorgeschlagen von $DIR<br />
* Status & nächste Schritte: Davon gehört? Gelesen? Schon besichtigt? Ansprechpartner_in gefunden? In Preisverhandlung?<br />
* Preis (pro Quadratmeter, HE, kW, ...)<br />
* Befristung<br />
* Fotos<br />
* Wie funktioniert der Zugang?<br />
* Nächste Schritte, Datum für Update?<br />
* Raum und Maße: Anzahl, Länge, Breite, Höhe<br />
* Bodenbeschaffenheit: Lehm, Beton (tragfähig?), Doppelboden<br />
* Wände: z.B. trocken/feucht, verputzt, Rigips; tragend<br />
* Luftzufuhr: z.B. in einen Lichthof, zur Straße hinaus, zugänglicher Luftschacht, Klimaanlage<br />
* Strom: 3 Phasen 16 A aufwärts<br />
* Glasfaser: Betreiber, Entfernung<br />
* Preis pro Quadratmeter</div>Erichhttps://wiki.funkfeuer.at/index.php?title=IP-Adresskonzept&diff=1931IP-Adresskonzept2018-06-18T19:34:15Z<p>Erich: /* Link-lokale Adressen */</p>
<hr />
<div>== Überblick der FunkFeuer-IPv6-Adressbereiche ==<br />
Präfix-<br />
länge 16| 32| 48| 64| 80| 96| 112| 128|<br />
FunkFeuer IPv6 (0<=x<=7) 29 2a02:006x:....:....:....:....:....:....<br />
|<br />
+- Early Registration 40 2a02:0060:00..:....:....:....:....:....<br />
|<br />
+- User Blocks 32 2a02:0061:....:....:....:....:....:....<br />
|<br />
+- Infrastruktur 48 2a02:0061:0000:....:....:....:....:....<br />
| |<br />
| +- 4in6, Egress 80 2a02:0061:0000:00ee:0000:....:....:....<br />
| +- 4in6, Ingress 80 2a02:0061:0000:00ee:0001:....:....:....<br />
| +- Loopback 64 2a02:0061:0000:00ff:....:....:....:....<br />
|<br />
+- Per-Node (nnnn!=0) 48 2a02:0061:nnnn:....:....:....:....:....<br />
<br />
<br />
== Ausgangssituation und Rahmenbedingungen ==<br />
Der Verein Funkfeuer Wien verfügt über den IPv6 Global Unicast Adressraum 2a02:60/29. Aufgrund von “early registration” sind die Netze 2a02:60:0::/48, 2a02:60:1::/48 sowie <br />
2a02:60:2::/48 vergeben und teilweise im operativen Einsatz. Mit einem Betrachtungsfokus der nächst höheren Verwaltungsebene (eines /40 Prefix), ist daher der gesamte Netzbereich 2a02:60::/40 als teilweise belegt zu berücksichtigen.<br />
<br />
== Anforderungsprofil an das 0xFF-Adressierungkonzept ==<br />
# IPv6 soll das präferierte Layer-3-Protokoll innerhalb des Netzes sein.<br />
# IPv4 soll zumindest während dem Übergang mittels OLSRv1 weiter unterstützt werden.<br />
# Der für das Mesh-Netz vergebene Adressbereich soll nach außen aggregierbar sein.<br />
# Durch vorausschauende Wahl geeigneter Boundaries soll die Möglichkeit zur Delegation von DNS Reverse Zonen beachtet werden.<br />
# Das Design soll skalierbar sein, sodass andere Communities (z.B. 0xFF Graz) sich dem Konzept anschließen können.<br />
# IPv6: Die Vergabe von IPv6 Adressen soll RFC6177 konform sein.<br />
# IPv6: Gemäß IPv6 Design Guidelines, sollen Prefixe standortorientiert vergeben werden.<br />
# IPv6: Der Einsatz von “stateless modified EUI64” Adressierung soll möglich sein.<br />
# IPv4: Im verwendeten IPv6 Adressraum sollen IPv4-Adressen in Übereinstimmung mit RFC4291 mittels eines “Mapping-Mechanismus” abgebildet bzw. “gemappt” werden können.<br />
<br />
== Umsetzung des IPv6-Adressierungskonzeptes ==<br />
Die Vorgabe nach Standortorientierung (lt. RFC6177) legt nahe, die “Node-ID” des Redeemer als Teil der IPv6-Adresse heranzuziehen. Wir gehen davon aus, dass 65535 Standorte für den Verwaltungbereich von Funkfeuer Wien, das entspricht 16 Bit im Adressfeld, ausreichend sind. (Anm.: Die Node-ID mit der Nummer Null gilt als reserviert. Erklärung im Text unten.)<br />
<br />
Der Empfehlung von RFC6177 nach vorausschauender Kapazitätsplanung wird nachgekommen, indem pro Standort bis zu 65535 lokale Netze realisierbar sind. Das ermöglicht eine flexible Segmentierung mit /64 Netzen pro Interface. Durch die jeweiligen Standortbetreiber sind diese Adressbits, entsprechend den individuellen Erfordernissen und Gegebenheiten, selbstständig zu vergeben.<br />
<br />
Die Realisierung einer “modified EUI64” Adressierung gemäß RFC4291 Appendix A, erfordert die Bereitstellung von 64 Bit im Host-Teil der IPv6-Adresse.<br />
<br />
Unter Berücksichtigung aller oben beschriebenen Fakten, ergibt sich ein erforderlicher Adressraum eines /32 Prefixes. Auf Grund bereits bestehender Teilbelegungen ist in der /32 Verwaltungsebene der nächstmögliche freie und zusammenhängende Adressraum: 2a02:61::/32.<br />
<br />
Das ist in voller Schreibweise:<br />
<br />
Allocation: 2a02:61::/32<br />
Bitgrenze: 16| 32| 48| 64| 80| 96| 112| 128|<br />
Erste Adresse: 2a02:0061:0000:0000:0000:0000:0000:0000<br />
Letzte Adresse: 2a02:0061:ffff:ffff:ffff:ffff:ffff:ffff<br />
<br />
Dieser Bereich ist für das Mesh-Netz von 0xFF, Funkfeuer Wien, zu wählen.<br />
<br />
== IPv6-Bereich für Infrastruktur ==<br />
Für Infrastruktur abseits der User Blocks wird der Bereich 2a02:61::/48 reserviert. Innerhalb von diesem Bereich finden sich die Loopback Adressen und auch die Tunnel Bereiche.<br />
<br />
Allocation: 2a02:61::/48<br />
Bitgrenze: 16| 32| 48| 64| 80| 96| 112| 128|<br />
Erste Adresse: 2a02:0061:0000:0000:0000:0000:0000:0000<br />
Letzte Adresse: 2a02:0061:0000:ffff:ffff:ffff:ffff:ffff<br />
<br />
== IPv6-Adressen für Nodes ==<br />
<br />
=== Link-lokale Adressen ===<br />
Geräte generieren pro Device-Interface automatisch mindestens eine link-lokale Adresse aus dem Bereich fe80::/64. Diese werden für die OLSRv2-Kommunikation zwischen Devices verwendet. Da dieseselben Adressen (auf verschiedenen Links) mehrfach vorkommen können, identifiziert OLSRv2 Devices über andere, global gültige Adressen (siehen unten). OLSRv1 kann damit ''nicht'' umgehen [Anm: Bitte klarstellen, warum nicht?]<br />
<br />
Allocation & used: fe80::/64<br />
Bitgrenze: 16| 32| 48| 64| 80| 96| 112| 128|<br />
Erste Adresse: fe80:0000:0000:0000:0000:0000:0000:0000<br />
Letzte Adresse: fe80:0000:0000:0000:ffff:ffff:ffff:ffff<br />
<br />
=== Loopback-Adressen ===<br />
Devices generieren mindestens eine global gültige Adresse aus dem Bereich 2a02:61:0:ff::/64 per EUI64. Diese Adresse identifiziert das Interface eindeutig und wird auch von OLSRv2 als Identifier herangezogen. Aufgrund der Eindeutigkeit der EUI64 zugrunde liegenden MAC-Adressen ist sicher gestellt, dass keine Adresse mehrfach verwendet wird. Weiters ermöglicht dieses Vorgehen, ein Device ohne vorherige Adresszuweisung in Betrieb nehmen zu können.<br />
<br />
Allocation & used: 2a02:61:0:ff::/64<br />
Bitgrenze: 16| 32| 48| 64| 80| 96| 112| 128|<br />
Erste Adresse: 2a02:0061:0000:00ff:0000:0000:0000:0000<br />
Letzte Adresse: 2a02:0061:0000:00ff:ffff:ffff:ffff:ffff<br />
<br />
=== User-Blocks ===<br />
Hierbei handelt es sich um Adressbereiche, die pro Knoten zugewiesen werden können, um anschließend in Subnetzen "hinter" dem Knoten Verwendung zu finden. Dazu wird eine eindeutige Standortkennung in die Bits 33-48 der IPv6-Adresse eingefügt. Diese 16 Bits sind aus der “Node-ID” des Redeemer abgeleitet. Somit resultiert für jeden registrierten Standort ein 48 Bit langes “Site-Prefix”. Die Node-ID mit der Nummer Null (0x0000) ist dabei für Infrastruktur reserviert (siehe unten) und wird nicht vergeben.<br />
<br />
Bitgrenze: 16| 32| 48| 64| 80| 96| 112| 128|<br />
Erste Adresse: 2a02:0061:0001:0000:0000:0000:0000:0000<br />
Letzte Adresse: 2a02:0061:ffff:ffff:ffff:ffff:ffff:ffff<br />
<br />
== IPv4-Adressen für Nodes ==<br />
'''Wichtig:''' Diese Adressierung ist nur für reine IPv6 Knoten relevant. Knoten die weiterhin über Dual Stack angebunden sind benötigen diese idR nicht.<br />
<br />
IPv4-Adressen werden auf Devices als native IPv4-Interfaces bereit gestellt. Für den Transport des IPv4-Traffics über das IPv6-Netz wird das 4in6-Verfahren angewandt, das im Linux-Kernel seit längerem zuverlässig implementiert ist und einen zustandslosen Tunnel zwischen dem Device und einem Tunnel-Server herstellt. Für das Mapping von IPv4-Adressen auf IPv6 wird der Bereich 2a02:61:0:ee::/64 verwendet. IPv4-Adressen werden dabei auf die letzten 32 Bit gemappt, wobei für eingehenden und ausgehenden Traffic unterschiedliche Subnetze verwendet werden, wodurch zwischen 0xFF und dem Rest des Internets unterschieden werden kann (Details siehen unten). Das Konzept ist im Detail unter [[Projekte/v642/IPv4_Support]] erklärt.<br />
<br />
Es werden IPv4-Adressen aus dem Bereich 185.194.20.0/23 vergeben. Pro Knoten wird grundsätzlich eine (1) IPv4-Adresse vergeben. Es wird nicht automatisch eine IPv4-Adresse pro Knoten alloziert, sondern die IPv4-Adresse muss angefragt werden. Die Zuweisung soll automatisiert werden.<br />
<br />
Allocation: 2a02:61:0:ee::/64<br />
Bitgrenze: 16| 32| 48| 64| 80| 96| 112| 128|<br />
Erste Adresse: 2a02:0061:0000:00ee:0000:0000:0000:0000<br />
Letzte Adresse: 2a02:0061:0000:00ee:ffff:ffff:ffff:ffff<br />
<br />
=== Outbound-Traffic (von Device zu Tunnel-Server) ===<br />
Für das Mapping der IPv4 Adressen für Traffic vom FunkFeuer Netz ins Internet wird der Bereich 2a02:61:0:ee::/80 verwendet. Der gesamte Adressbereich wird durch die Tunnel-Server angekündigt, wodurch sämtlicher getunnelter IPv4-Traffic seinen Weg dorthin nimmt.<br />
<br />
Used: 2a02:61:0:ee::/80<br />
Bitgrenze: 16| 32| 48| 64| 80| 96| 112| 128|<br />
Erste Adresse: 2a02:0061:0000:00ee:0000:0000:0000:0000<br />
Letzte Adresse: 2a02:0061:0000:00ee:0000:ffff:ffff:ffff<br />
<br />
=== Inbound-Traffic (von Tunnel-Server zu Device) ===<br />
Für das Mapping der IPv4 Adressen für Traffic vom Internet ins FunkFeuer Netz wird der Bereich 2a02:61:0:ee:1::/80 verwendet. Adressen aus den 0xFF zugewiesenen IPv4-Adressblöcken werden dabei wie o.g. User-Blocks behandelt: Technisch werden diese durch den innehabenden Knoten über ihre Loopback-(IPv6)-Adresse angekündigt, organisatorisch werden diese zugeteilt.<br />
<br />
Used: 2a02:61:0:ee:1::/80<br />
Bitgrenze: 16| 32| 48| 64| 80| 96| 112| 128|<br />
Erste Adresse: 2a02:0061:0000:00ee:0001:0000:0000:0000<br />
Letzte Adresse: 2a02:0061:0000:00ee:0001:ffff:ffff:ffff</div>Erichhttps://wiki.funkfeuer.at/index.php?title=OpenVPN_mit_EdgeRouter_X-SFP&diff=1930OpenVPN mit EdgeRouter X-SFP2018-06-18T10:24:08Z<p>Erich: </p>
<hr />
<div>Anleitung in Arbeit - Entwurfsstadium<br />
<br />
<br />
Die allgemeinen Voraussetzungen zum Einrichten eines Tunnels sind in der Übersichtsseite dargestellt. Dieser Artikel geht nur auf die rudimentäre Konfiguration des Edge Routers ein.<br />
<br />
Update 02/2018: ein EdgeOS-Wizard hiefür ist in Entwicklung: https://github.com/pocki80/ER-wizard-0xFF-OpenVPN2TS<br />
<br />
== Einrichten des Tunnels ==<br />
<br />
Empfohlen wird, die Konfigurationsdateien und das Skript zuerst auf Deinem Computer anzulegen, und diese gemeinsam in der Folge per SSH ins Verzeichnis /config/user-data/ zu kopieren. Alternativ kannst Du sie auch händisch über das CLI wie vi anlegen. Wir benötigen:<br />
<br />
1) funkfeuer.ovpn mit folgendem Inhalt - die kursiv dargestellten Zeilen musst Du mit jenen Werten befüllen, die Du von den Tunneladmins zugewiesen bekommen hast:<br />
<br />
dev vtun0<br />
dev-type tap<br />
proto udp<br />
remote 78.41.115.16<br />
''port [5XXX]''<br />
daemon vtun0<br />
up-delay<br />
down-pre<br />
up-restart<br />
comp-lzo<br />
script-security 2<br />
nobind<br />
ping 10<br />
ping-restart 60<br />
ping-timer-rem<br />
fast-io<br />
sndbuf 524288 <br />
rcvbuf 524288<br />
mute 2<br />
verb 0<br />
up "/config/user-data/funkfeuer-ifupdown.sh"<br />
down "/config/user-data/funkfeuer-ifupdown.sh"<br />
<br />
<br />
Es gibt spezielle Betriebsmodi für OLSR, wie etwa den Mode „silent“. Um diesen zu nützen, kann man zwei Zeilen mit einem Skriptparameter anpassen:<br />
<br />
up "/config/user-data/funkfeuer-ifupdown.sh silent"<br />
down "/config/user-data/funkfeuer-ifupdown.sh silent"<br />
<br />
<br />
Wurde für Deinen Tunnel bereits ein shared key/secret angelegt, benötigst Du zusätzlich folgende Zeilen:<br />
<br />
secret /config/user-data/funkfeuer.secret<br />
auth SHA256<br />
cipher none<br />
<br />
<br />
2) funkfeuer.secret - wenn ein Key angelegt wurde, wie in 1) beschrieben.<br />
<br />
Diese Datei beinhaltet einen individuellen kryptographischen Schlüssel (shared key), der sicherstellt, dass der Tunnel nur von jenen Clients genutzt werden kann, denen er auch tatsächlich zugewiesen wurde. Das soll verhindern, dass ein Tunnel missbräuchlich oder versehentlich mehrfach genützt wird.<br />
Diesen Schlüssel erhältst Du per E-Mail und Du musst ihn lediglich in dieser Datei speichern.<br />
<br />
3) funkfeuer-ifupdown.sh<br />
<br />
Dieses Skript sorgt dafür, dass das Tunnel-Interface, nachdem es gestartet wurde, in die richtige Bridge gelegt wird, auf der bereits OLSR im vorgesehenen Modus läuft. Diese Vorgehensweise ist nicht sonderlich schön, aber sie funktioniert. Wir arbeiten an einer besseren Lösung. Leg Die Datei mit folgendem Inhalt an und mach sie ausführbar.<br />
----<br />
<br />
#!/bin/sh<br />
logger "$dev $script_type"<br />
case "$1" in<br />
silent)<br />
br="br9"<br />
;;<br />
ether)<br />
br="br8"<br />
;;<br />
*)<br />
br="br7"<br />
esac<br />
case "$script_type" in<br />
up)<br />
/sbin/brctl addif $br $dev<br />
/sbin/ip link set $br promisc on<br />
/sbin/ip link set $dev up<br />
;;<br />
down)<br />
/sbin/ip link set $dev down <br />
/sbin/ip link set $br promisc off<br />
/sbin/brctl delif $br $dev<br />
<br />
;;<br />
*)<br />
esac<br />
exit 0<br />
<br />
<br />
chmod +x funkfeuer-ifupdown.sh<br />
<br />
3) Folgende Config am EdgeRouter vornehmen (lokalen Gateway für Static-Route entsprechend ändern)<br />
<br />
set interfaces bridge br9 address 78.41.000.000/32<br />
set interfaces bridge br9 aging 300<br />
set interfaces bridge br9 bridged-conntrack disable<br />
set interfaces bridge br9 description TUNNEL<br />
set interfaces bridge br9 hello-time 2<br />
set interfaces bridge br9 max-age 20<br />
set interfaces bridge br9 priority 32768<br />
set interfaces bridge br9 stp false<br />
commit<br />
set protocols static route 78.41.118.150/32 next-hop 192.168.0.1 description 'TunnelServer via ISP'<br />
set interfaces openvpn vtun0 config-file /config/user-data/funkfeuer.ovpn<br />
commit<br />
save<br />
<br />
3) Im OLSRd_V1 Wizard das interface br9=silent, br8=ether oder br7=mesh für OLSR aktivieren</div>Erichhttps://wiki.funkfeuer.at/index.php?title=OpenVPN_mit_Debian/Ubuntu&diff=1929OpenVPN mit Debian/Ubuntu2018-06-18T10:23:23Z<p>Erich: </p>
<hr />
<div>Unter Debian installierst Du die Pakete für Openvpn und olsr.<br />
<br />
Voraussetzungen:<br />
* Aktuelles Debian Stable oder Ubuntu LTS<br />
* Pakete für OpenVPN, OLSR (und OLSRv2), bridge-utils<br />
* Funkfeuer-Login<br />
* Funkfeuer-IPv4-Adresse für das Tunneldevice respektive die Bridge aus [[https://portal.funkfeuer.at/wien REDEEMER/FRONTEND/PORTAL]]<br />
* Einen Taschenrechner, der Dezimalzahlen in Hexadezimalzahlen umrechnen kann („programmiertechnischer Modus“)<br />
* Die Funkfeuer NodeID des Knotens, dem der Tunnel zugeordnet wird. Wenn Du im Redeemer/Portal eingeloggt bist, und auf „Nodes“ und den richtigen Namen des Nodes klickst, siehst Du die NodeID in der URL in Deinem Browsers entweder so:<br />
** „&id=9999“ oder so<br />
** „id_nodes=9999“.<br />
Diese Zahl umgewandelt in „Hex“ brauchst Du später für Deine IPv6-Adresse.<br />
<br />
<br />
* apt-get install openvpn openvpn-blacklist olsrd olsrd-plugins bridge-utils ebtables<br />
<br />
Angenommen, Dein Debian oder Ubuntu-Rechner besitzt eine Ethernetschnittstelle eth0 (oder wie das heute eher der Fall ist, en[X]s[Y]), die in derselben Broadcastdomain wie das Provider-Modem liegt, dann wirst Du /etc/network/interfaces editieren und dort zunächst eine statische Route zum Tunnelserver anlegen wollen. Im selben Arbeitsschritt könntest Du auch festlegen, dass der Tunnel unmittelbar nach dem Start der Netzwerkschnittstelle aufgebaut wird. Es ist darüber hinaus zweckmäßig, OLSR auf einer Bridge laufen zu lassen, um sich etwaige OLSR-Neustarts zu ersparen. Wir legen also auch gleich eine Bridge an und weisen ihr die Funkfeuer-IPs für IPv4 und IPv6 (aber nur für 2a02:60::/40) zu. 192.168.1.1 ist in diesem Beispiel das Providermodem als Defaultgateway. Warum setzen wir aber eine Hostroute zu 78.41.118.150/32 oder 78.41.115.16/32? Ganz einfach: Olsr wird die Default-Route überschreiben. In aller Regel passiert dies mit einer Metrik von 2 und sollte nicht stören. Dennoch kommt es manchmal dazu, dass bei Fehlen der Hostroute der Tunnel quasi über sich selbst laufen soll - das funktioniert freilich nicht. Wenn Du aber auch eine Funkschnittstelle mit OLSR hast, dann läufst Du Gefahr, dass der Tunnel zu Funkfeuer über das Funkfeuer-Mesh aufgebaut würde, was absolut keinen Sinn ergibt. Daher die Hostroute.<br />
<br />
/etc/network/interfaces:<br />
iface eth0 inet static<br />
...<br />
up /sbin/ip r a 78.41.115.16/32 dev eth0 via 192.168.1.1 metric 0<br />
up /etc/init.d/openvpn restart<br />
<br />
auto br-ff <br />
iface br-ff inet static<br />
bridge_fd 0<br />
bridge_maxwait 0<br />
bridge_waitport 0<br />
bridge_stp no<br />
bridge_ports none<br />
address [REDEEMER-IP v4]<br />
netmask 255.255.255.255<br />
# IPv6/OLSRv1 Schema 2a02:60:01[Node ID in Hexadezimaldarstellung, erstes Oktett]:[Node ID in Hex, zweites Oktett][Router ID (4 Bit)][Interface ID (4 Bit)]::[irgendwas]<br />
# Nachfolgend für 9999 NodeID 9999(10) = 270F(16); Router 1, Interface 1 mit Adresse „feed“:<br />
post-up /sbin/ip -6 a a 2a02:60:1'''27''':'''0f'''''11''::feed/64 dev br-ff<br />
# Wenn man die MAC-Adresse der Bridge definiert, wirkt sich das auf die IPv6 EUI64-Adresse beginnend mit fe80::/12 aus.<br />
# Man kann sich eine zufällige MAC-Adresse [[https://www.miniwebtool.com/mac-address-generator/ MAC Address Generator]] (lowercase und ":"-Notation) errechnen lassen.<br />
post-up ip link set dev br-ff address bc:75:33:6a:bf:cf<br />
# Die Bridge soll allen Traffic annehmen.<br />
post-up ip link set dev br-ff promisc on<br />
<br />
<br />
Die Konfiguration von OpenVPN liegt bei Debian und Ubuntu üblicherweise in /etc/openvpn, wobei das Startup-Skript die Datei /etc/default/openvpn zu seiner Initialisierung heranzieht.<br />
<br />
/etc/default/openvpn:<br />
#AUTOSTART="all" -> <br />
AUTOSTART="all" <br />
oder<br />
#AUTOSTART="all" -><br />
AUTOSTART="funkfeuer"<br />
<br />
Somit erwartet OpenVPN seine Konfiguration in /etc/openvpn/funkfeuer.conf.<br />
<br />
/etc/openvpn/funkfeuer.conf:<br />
dev tap0<br />
proto udp<br />
remote 78.41.115.16<br />
# Variante: remote 78.41.118.150 <br />
# Die Portnummer XXXX wird Dir von den Tunnelserver-Administratoren zugewiesen, trag sie in der folgenden Zeile anstelle von XXXX ein.<br />
port XXXX<br />
daemon tap0<br />
persist-tun<br />
up-delay<br />
down-pre<br />
up-restart<br />
comp-lzo<br />
script-security 2<br />
nobind<br />
ping 10<br />
ping-restart 60<br />
ping-timer-rem<br />
fast-io<br />
sndbuf 524288<br />
rcvbuf 524288<br />
mute 2<br />
verb 0<br />
up /etc/openvpn/funkfeuer-updown.sh<br />
down /etc/openvpn/funkfeuer-updown.sh<br />
secret /etc/openvpn/funkfeuer.secret<br />
auth SHA256<br />
cipher none<br />
<br />
Diese Konfigurationsdatei benötigt also noch zwei weitere Dateien. Zum einen wäre das /etc/openvpn/funkfeuer-updown.sh. Dieses Skript wird von OpenVPN aufgerufen, sowie der Tunnel hergestellt oder beendet wird. OpenVPN übergibt diesem Skript Parameter, wie wir sie im Beispiel des Tunnelservers nützen. Für Deine Seite wird das nicht explizit erforderlich sein. Das Skript kann wie folgt aussehen:<br />
<br />
/etc/openvpn/funkfeuer-updown.sh:<br />
#!/bin/bash<br />
# br-ff ist die Bridge aus /etc/network/interfaces<br />
# $dev ist ein Parameter, den Openvpn übergibt. Hier zumeist „tap0“.<br />
br="br-ff"<br />
dev=$1<br />
logger "openvpn: $(echo $@)"<br />
logger "openvpn: $script_type"<br />
case $script_type in<br />
"down")<br />
/sbin/brctl delif $br $dev<br />
/sbin/ip link set link dev $dev down<br />
;;<br />
"route-up")<br />
;;<br />
"up")<br />
/sbin/brctl addif $br $dev<br />
/sbin/ip link set dev $br promisc on<br />
/sbin/ip link set link dev $dev up<br />
/sbin/ip link set link dev $br up<br />
;;<br />
esac<br />
echo $(date) $script_type $br.$dev $script_type>> /tmp/br-vpn.log<br />
exit 0<br />
<br />
<br />
Das Skript muss ausführbar gemacht werden. chmod +x /etc/openvpn/funkfeuer-updown.sh<br />
<br />
chmod +x /etc/openvpn/funkfeuer-updown.sh<br />
<br />
In der OpenVPN-Konfiguration haben wir den statischen Schlüssel mit /etc/openvpn/funkfeuer.secret angegeben. Exemplarisch schaut das so aus - aber den „echten Key“ bekommt ein Jeder individuell zugeteilt (bitte bei Erich P. anfordern):<br />
<br />
<br />
/etc/openvpn/funkfeuer.secret:<br />
#<br />
# 2048 bit OpenVPN static key<br />
#<br />
-----BEGIN OpenVPN Static key V1-----<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
-----END OpenVPN Static key V1-----<br />
<br />
<br />
Jetzt fehlt noch OLSR... Debian und Ubuntu verwenden /etc/init.d/olsrd als Startscript, das wiederum /etc/default/olsrd zu Initialisierung nutzt. Das Debian-Konzept geht noch von Adhoc-Netzen auf dem lokalen Gerät aus, kann also bis auf drei Zeilen ignoriert werden. Die Interface-Parameter lasse ich bewusst weg. Die Interfaces definiert man besser in der olsrd.conf, wo man individuelle Einstellungen tätigen kann (etwa unter anderem: ein per-Interface-Default-LQ-Multiplier, den Mode und die Gewichtung.)<br />
<br />
<br />
/etc/default/olsrd:<br />
START_OLSRD="YES"<br />
DEBUGLEVEL=0<br />
DAEMON_OPTS="-f /etc/olsrd/olsrd.conf -d $DEBUGLEVEL"<br />
<br />
<br />
Es fehlt noch die OSLR-Konfigurationsdatei (Vorsicht: ich verwende ein selbstkompiliertes OLSR und habe die plugin-Libraries „LoadPlugin“ hardgecodet; wenn der Pfad nicht stimmt, startet OLSR nicht, plaudert aber wirklich nicht darüber, was es stört.) -<br />
<br />
/etc/olsrd/olsrd.conf:<br />
AllowNoInt yes<br />
ClearScreen yes<br />
DebugLevel 0<br />
FIBMetric "flat"<br />
IpVersion 4<br />
LinkQualityAlgorithm "etx_ff"<br />
LinkQualityFishEye 1<br />
LinkQualityLevel 2<br />
MainIp [DIE MAIN-IP BEKOMMT IHR AUS DEM FUNKFEUER PORTAL, WENN IHR EIN GERÄT (DEVICE) ANLEGT]<br />
MprCoverage 1<br />
Pollrate 0.1<br />
TcRedundancy 2<br />
TosValue 16<br />
UseHysteresis no<br />
Willingness 3<br />
InterfaceDefaults<br />
{<br />
AutoDetectChanges yes<br />
HelloInterval 5.0<br />
HelloValidityTime 100.0<br />
TcInterval 2.0<br />
TcValidityTime 300.0<br />
MidInterval 50.0<br />
MidValidityTime 300.0<br />
HnaInterval 50.0<br />
HnaValidityTime 300.0<br />
Ip4Broadcast 255.255.255.255<br />
Mode "mesh"<br />
LinkQualityMult default 0.15<br />
Weight 99<br />
}<br />
Interface "br-ff"<br />
{<br />
AutoDetectChanges yes<br />
LinkQualityMult default 1.0<br />
Weight 0<br />
}<br />
Hna4<br />
{<br />
[SERVER-IP FALLS VORHANDEN - ZUWEISUNG VIA PORTAL] 255.255.255.255<br />
}<br />
LoadPlugin "olsrd_httpinfo.so.0.1"<br />
{<br />
PlParam "Port" "81"<br />
PlParam "Net" "0.0.0.0 0.0.0.0"<br />
PlParam "resolve" "false"<br />
}<br />
LoadPlugin "olsrd_txtinfo.so.1.1"<br />
{<br />
PlParam "port" "2006"<br />
PlParam "accept" "127.0.0.1"<br />
}<br />
LoadPlugin "olsrd_jsoninfo.so.1.1"<br />
{<br />
PlParam "port" "9090"<br />
PlParam "accept" "0.0.0.0"<br />
PlParam "UUIDFile" "/etc/olsrd/olsrd.uuid"<br />
}<br />
<br />
Damit ist eigentlich die Arbeit getan.<br />
<br />
=== 'the quick and dirty hack' für IPv6 ===<br />
<br />
Für OLSR mit IPv6 gibt es noch ein paar Tricks zu wissen und noch etwas mehr Handarbeit.<br />
Kopiere:<br />
<br />
* /etc/default/olsrd nach /etc/default/olsrd6<br />
** Ersetz jedes Vorkommen von olsr(d) durch olsr(d)6.<br />
<br />
mit vim wäre das so: vom input modus in den command modus wechseln (ESC) und in der command line folgendes eingeben: <br />
<br />
%s/olsrd/olsrd6/g<br />
<br />
12 ersetzungen sollten stattfinden. <br />
<br />
%s/OLSRD/OLSRD6/g<br />
<br />
selbiges gilt für die folgenden weiteren Dateien<br />
<br />
* /etc/init.d/olsrd nach /etc/init.d/olsrd6<br />
** Ersetz jedes Vorkommen von olsr(d) durch olsr(d)6. Ersetze /usr/sbin/olsrd durch /etc/alternatives/olsrd6<br />
* Setz einen Link von /usr/sbin/olsrd nach /etc/alternatives/olsrd6.<br />
<br />
ln -s /usr/sbin/olsrd /etc/alternatives/olsrd6<br />
<br />
Das hat den Sinn, dass der Prozess auch olsrd6 heißt, wenn er läuft und Du ihn mit dem pgrep im Startskript suchen kannst.<br />
<br />
* Leg /etc/olsrd/olsrd6.conf an - nachfolgend ein Beispiel.<br />
<br />
AllowNoInt yes<br />
ClearScreen yes<br />
DebugLevel 0<br />
FIBMetric "flat"<br />
IpVersion 6<br />
LinkQualityAlgorithm "etx_ff"<br />
LinkQualityFishEye 1<br />
LinkQualityLevel 2<br />
MprCoverage 1<br />
Pollrate 0.1<br />
TcRedundancy 2<br />
TosValue 16<br />
UseHysteresis no<br />
UseNiit yes<br />
Willingness 3<br />
InterfaceDefaults<br />
{<br />
#Ip6MulticastGlobal ff0e::1<br />
#Ip6MulticastSite ff05::11<br />
IPv6Multicast ff02::6d<br />
Weight 99<br />
AutoDetectChanges yes<br />
HelloInterval 50.0<br />
HelloValidityTime 100.0<br />
HnaInterval 50.0<br />
HnaValidityTime 300.0<br />
LinkQualityMult default 0.33 <br />
MidInterval 50.0<br />
MidValidityTime 300.0<br />
Mode "mesh"<br />
TcInterval 2.0 <br />
TcValidityTime 300.0<br />
Weight 99<br />
}<br />
Hna6<br />
{<br />
}<br />
LoadPlugin "olsrd_httpinfo.so.0.1"<br />
{<br />
PlParam "Net" "0::/0 2000::/3"<br />
PlParam "port" "82"<br />
}<br />
LoadPlugin "olsrd_jsoninfo.so.1.1"<br />
{<br />
PlParam "port" "9090"<br />
PlParam "accept" "::"<br />
PlParam "UUIDFile" "/etc/olsrd/olsrd6.uuid"<br />
PlParam "ipv6only" "true"<br />
}<br />
Interface "br-ff"<br />
{<br />
AutoDetectChanges yes<br />
LinkQualityMult default 0.25 <br />
Mode "ether"<br />
Weight 1<br />
IPv6Multicast ff02::6d<br />
}<br />
<br />
Sollte OLSR nicht starten wollen, liegt es entweder an einem Tippfehler oder an einer falsch formatierten IPv6-Adresse (::/0 oder 0::/0 je nach Plugin...) oder daran, dass olsrd seine Plugins nicht finden kann oder die falsche Version findet, wenn Du ein Update mit selbstkompiliertem OLSR gemacht haben solltest. Aufmerksam lesen und eventuell die LoadPlugin-Zeilen mit absoluten Pfaden zu der jeweiligen ".so" setzen, hilft.<br />
<br />
Es ist auch möglich die plugin sektion ganz wegzulassen, damit eliminiert man evtl ein weiteres Problem.<br />
diese können ja schrittweise bei funktionierender config nachträglich wieder eingefügt werden.<br />
<br />
Ein letzter Hinweis: OLSR wird noch nicht automatisch gestartet. Du kannst das in /etc/network/interfaces bei der Bridge br-ff mittels „up /etc/init.d/olsrd restart“ und „up /etc/init.d/olsrd6 restart“ tun, oder, Du legst die zwei Befehle in das OpenVPN-UP/DOWN-Skript. AutodetecChanges in OLSR sollte eigentlich dafür sorgen, dass der Bridge-Port immer erkannt wird, ohne, dass man den Dienst erneut starten muss.<br />
<br />
Das war's. Dual-Stack OLSRv1 mit Tunnel läuft, sowie Du es gestartet hast.</div>Erichhttps://wiki.funkfeuer.at/index.php?title=OpenVPN_mit_Debian/Ubuntu&diff=1909OpenVPN mit Debian/Ubuntu2018-06-10T08:28:04Z<p>Erich: </p>
<hr />
<div>Unter Debian installierst Du die Pakete für Openvpn und olsr.<br />
<br />
Voraussetzungen:<br />
* Aktuelles Debian Stable oder Ubuntu LTS<br />
* Pakete für OpenVPN, OLSR (und OLSRv2), bridge-utils<br />
* Funkfeuer-Login<br />
* Funkfeuer-IPv4-Adresse für das Tunneldevice respektive die Bridge aus [[https://portal.funkfeuer.at/wien REDEEMER/FRONTEND/PORTAL]]<br />
* Einen Taschenrechner, der Dezimalzahlen in Hexadezimalzahlen umrechnen kann („programmiertechnischer Modus“)<br />
* Die Funkfeuer NodeID des Knotens, dem der Tunnel zugeordnet wird. Wenn Du im Redeemer/Portal eingeloggt bist, und auf „Nodes“ und den richtigen Namen des Nodes klickst, siehst Du die NodeID in der URL in Deinem Browsers entweder so:<br />
** „&id=9999“ oder so<br />
** „id_nodes=9999“.<br />
Diese Zahl umgewandelt in „Hex“ brauchst Du später für Deine IPv6-Adresse.<br />
<br />
<br />
* apt-get install openvpn openvpn-blacklist olsrd olsrd-plugins bridge-utils ebtables<br />
<br />
Angenommen, Dein Debian oder Ubuntu-Rechner besitzt eine Ethernetschnittstelle eth0 (oder wie das heute eher der Fall ist, en[X]s[Y]), die in derselben Broadcastdomain wie das Provider-Modem liegt, dann wirst Du /etc/network/interfaces editieren und dort zunächst eine statische Route zum Tunnelserver anlegen wollen. Im selben Arbeitsschritt könntest Du auch festlegen, dass der Tunnel unmittelbar nach dem Start der Netzwerkschnittstelle aufgebaut wird. Es ist darüber hinaus zweckmäßig, OLSR auf einer Bridge laufen zu lassen, um sich etwaige OLSR-Neustarts zu ersparen. Wir legen also auch gleich eine Bridge an und weisen ihr die Funkfeuer-IPs für IPv4 und IPv6 (aber nur für 2a02:60::/40) zu. 192.168.1.1 ist in diesem Beispiel das Providermodem als Defaultgateway. Warum setzen wir aber eine Hostroute zu 78.41.118.150/32? Ganz einfach: Olsr wird die Default-Route überschreiben. In aller Regel passiert dies mit einer Metrik von 2 und sollte nicht stören. Dennoch kommt es manchmal dazu, dass bei Fehlen der Hostroute der Tunnel quasi über sich selbst laufen soll - das funktioniert freilich nicht. Wenn Du aber auch eine Funkschnittstelle mit OLSR hast, dann läufst Du Gefahr, dass der Tunnel zu Funkfeuer über das Funkfeuer-Mesh aufgebaut würde, was absolut keinen Sinn ergibt. Daher die Hostroute.<br />
<br />
/etc/network/interfaces:<br />
iface eth0 inet static<br />
...<br />
up /sbin/ip r a 78.41.118.150/32 dev eth0 via 192.168.1.1 metric 0<br />
up /etc/init.d/openvpn restart<br />
<br />
auto br-ff <br />
iface br-ff inet static<br />
bridge_fd 0<br />
bridge_maxwait 0<br />
bridge_waitport 0<br />
bridge_stp no<br />
bridge_ports none<br />
address [REDEEMER-IP v4]<br />
netmask 255.255.255.255<br />
# IPv6/OLSRv1 Schema 2a02:60:01[Node ID in Hexadezimaldarstellung, erstes Oktett]:[Node ID in Hex, zweites Oktett][Router ID (4 Bit)][Interface ID (4 Bit)]::[irgendwas]<br />
# Nachfolgend für 9999 NodeID 9999(10) = 270F(16); Router 1, Interface 1 mit Adresse „feed“:<br />
post-up /sbin/ip -6 a a 2a02:60:1'''27''':'''0f'''''11''::feed/64 dev br-ff<br />
# Wenn man die MAC-Adresse der Bridge definiert, wirkt sich das auf die IPv6 EUI64-Adresse beginnend mit fe80::/12 aus.<br />
# Man kann sich eine zufällige MAC-Adresse [[https://www.miniwebtool.com/mac-address-generator/ MAC Address Generator]] (lowercase und ":"-Notation) errechnen lassen.<br />
post-up ip link set dev br-ff address bc:75:33:6a:bf:cf<br />
# Die Bridge soll allen Traffic annehmen.<br />
post-up ip link set dev br-ff promisc on<br />
<br />
<br />
Die Konfiguration von OpenVPN liegt bei Debian und Ubuntu üblicherweise in /etc/openvpn, wobei das Startup-Skript die Datei /etc/default/openvpn zu seiner Initialisierung heranzieht.<br />
<br />
/etc/default/openvpn:<br />
#AUTOSTART="all" -> <br />
AUTOSTART="all" <br />
oder<br />
#AUTOSTART="all" -><br />
AUTOSTART="funkfeuer"<br />
<br />
Somit erwartet OpenVPN seine Konfiguration in /etc/openvpn/funkfeuer.conf.<br />
<br />
/etc/openvpn/funkfeuer.conf:<br />
dev tap0<br />
proto udp<br />
remote 78.41.118.150<br />
# Die Portnummer XXXX wird Dir von den Tunnelserver-Administratoren zugewiesen, trag sie in der folgenden Zeile anstelle von XXXX ein.<br />
port XXXX<br />
daemon tap0<br />
persist-tun<br />
up-delay<br />
down-pre<br />
up-restart<br />
comp-lzo<br />
script-security 2<br />
nobind<br />
ping 10<br />
ping-restart 60<br />
ping-timer-rem<br />
fast-io<br />
sndbuf 524288<br />
rcvbuf 524288<br />
mute 2<br />
verb 0<br />
up /etc/openvpn/funkfeuer-updown.sh<br />
down /etc/openvpn/funkfeuer-updown.sh<br />
secret /etc/openvpn/funkfeuer.secret<br />
auth SHA256<br />
cipher none<br />
<br />
Diese Konfigurationsdatei benötigt also noch zwei weitere Dateien. Zum einen wäre das /etc/openvpn/funkfeuer-updown.sh. Dieses Skript wird von OpenVPN aufgerufen, sowie der Tunnel hergestellt oder beendet wird. OpenVPN übergibt diesem Skript Parameter, wie wir sie im Beispiel des Tunnelservers nützen. Für Deine Seite wird das nicht explizit erforderlich sein. Das Skript kann wie folgt aussehen:<br />
<br />
/etc/openvpn/funkfeuer-updown.sh:<br />
#!/bin/bash<br />
# br-ff ist die Bridge aus /etc/network/interfaces<br />
# $dev ist ein Parameter, den Openvpn übergibt. Hier zumeist „tap0“.<br />
br="br-ff"<br />
dev=$1<br />
logger "openvpn: $(echo $@)"<br />
logger "openvpn: $script_type"<br />
case $script_type in<br />
"down")<br />
/sbin/brctl delif $br $dev<br />
/sbin/ip link set link dev $dev down<br />
;;<br />
"route-up")<br />
;;<br />
"up")<br />
/sbin/brctl addif $br $dev<br />
/sbin/ip link set dev $br promisc on<br />
/sbin/ip link set link dev $dev up<br />
/sbin/ip link set link dev $br up<br />
;;<br />
esac<br />
echo $(date) $script_type $br.$dev $script_type>> /tmp/br-vpn.log<br />
exit 0<br />
<br />
<br />
Das Skript muss ausführbar gemacht werden. chmod +x /etc/openvpn/funkfeuer-updown.sh<br />
<br />
chmod +x /etc/openvpn/funkfeuer-updown.sh<br />
<br />
In der OpenVPN-Konfiguration haben wir den statischen Schlüssel mit /etc/openvpn/funkfeuer.secret angegeben. Exemplarisch schaut das so aus - aber den „echten Key“ bekommt ein Jeder individuell zugeteilt (bitte bei Erich P. anfordern):<br />
<br />
<br />
/etc/openvpn/funkfeuer.secret:<br />
#<br />
# 2048 bit OpenVPN static key<br />
#<br />
-----BEGIN OpenVPN Static key V1-----<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
-----END OpenVPN Static key V1-----<br />
<br />
<br />
Jetzt fehlt noch OLSR... Debian und Ubuntu verwenden /etc/init.d/olsrd als Startscript, das wiederum /etc/default/olsrd zu Initialisierung nutzt. Das Debian-Konzept geht noch von Adhoc-Netzen auf dem lokalen Gerät aus, kann also bis auf drei Zeilen ignoriert werden. Die Interface-Parameter lasse ich bewusst weg. Die Interfaces definiert man besser in der olsrd.conf, wo man individuelle Einstellungen tätigen kann (etwa unter anderem: ein per-Interface-Default-LQ-Multiplier, den Mode und die Gewichtung.)<br />
<br />
<br />
/etc/default/olsrd:<br />
START_OLSRD="YES"<br />
DEBUGLEVEL=0<br />
DAEMON_OPTS="-f /etc/olsrd/olsrd.conf -d $DEBUGLEVEL"<br />
<br />
<br />
Es fehlt noch die OSLR-Konfigurationsdatei (Vorsicht: ich verwende ein selbstkompiliertes OLSR und habe die plugin-Libraries „LoadPlugin“ hardgecodet; wenn der Pfad nicht stimmt, startet OLSR nicht, plaudert aber wirklich nicht darüber, was es stört.) -<br />
<br />
/etc/olsrd/olsrd.conf:<br />
AllowNoInt yes<br />
ClearScreen yes<br />
DebugLevel 0<br />
FIBMetric "flat"<br />
IpVersion 4<br />
LinkQualityAlgorithm "etx_ff"<br />
LinkQualityFishEye 1<br />
LinkQualityLevel 2<br />
MainIp [DIE MAIN-IP BEKOMMT IHR AUS DEM FUNKFEUER PORTAL, WENN IHR EIN GERÄT (DEVICE) ANLEGT]<br />
MprCoverage 1<br />
Pollrate 0.1<br />
TcRedundancy 2<br />
TosValue 16<br />
UseHysteresis no<br />
Willingness 3<br />
InterfaceDefaults<br />
{<br />
AutoDetectChanges yes<br />
HelloInterval 5.0<br />
HelloValidityTime 100.0<br />
TcInterval 2.0<br />
TcValidityTime 300.0<br />
MidInterval 50.0<br />
MidValidityTime 300.0<br />
HnaInterval 50.0<br />
HnaValidityTime 300.0<br />
Ip4Broadcast 255.255.255.255<br />
Mode "mesh"<br />
LinkQualityMult default 0.15<br />
Weight 99<br />
}<br />
Interface "br-ff"<br />
{<br />
AutoDetectChanges yes<br />
LinkQualityMult default 1.0<br />
Weight 0<br />
}<br />
Hna4<br />
{<br />
[SERVER-IP FALLS VORHANDEN - ZUWEISUNG VIA PORTAL] 255.255.255.255<br />
}<br />
LoadPlugin "olsrd_httpinfo.so.0.1"<br />
{<br />
PlParam "Port" "81"<br />
PlParam "Net" "0.0.0.0 0.0.0.0"<br />
PlParam "resolve" "false"<br />
}<br />
LoadPlugin "olsrd_txtinfo.so.1.1"<br />
{<br />
PlParam "port" "2006"<br />
PlParam "accept" "127.0.0.1"<br />
}<br />
LoadPlugin "olsrd_jsoninfo.so.1.1"<br />
{<br />
PlParam "port" "9090"<br />
PlParam "accept" "0.0.0.0"<br />
PlParam "UUIDFile" "/etc/olsrd/olsrd.uuid"<br />
}<br />
<br />
Damit ist eigentlich die Arbeit getan.<br />
<br />
=== 'the quick and dirty hack' für IPv6 ===<br />
<br />
Für OLSR mit IPv6 gibt es noch ein paar Tricks zu wissen und noch etwas mehr Handarbeit.<br />
Kopiere:<br />
<br />
* /etc/default/olsrd nach /etc/default/olsrd6<br />
** Ersetz jedes Vorkommen von olsr(d) durch olsr(d)6.<br />
<br />
mit vim wäre das so: vom input modus in den command modus wechseln (ESC) und in der command line folgendes eingeben: <br />
<br />
%s/olsrd/olsrd6/g<br />
<br />
12 ersetzungen sollten stattfinden. <br />
<br />
%s/OLSRD/OLSRD6/g<br />
<br />
selbiges gilt für die folgenden weiteren Dateien<br />
<br />
* /etc/init.d/olsrd nach /etc/init.d/olsrd6<br />
** Ersetz jedes Vorkommen von olsr(d) durch olsr(d)6. Ersetze /usr/sbin/olsrd durch /etc/alternatives/olsrd6<br />
* Setz einen Link von /usr/sbin/olsrd nach /etc/alternatives/olsrd6.<br />
<br />
ln -s /usr/sbin/olsrd /etc/alternatives/olsrd6<br />
<br />
Das hat den Sinn, dass der Prozess auch olsrd6 heißt, wenn er läuft und Du ihn mit dem pgrep im Startskript suchen kannst.<br />
<br />
* Leg /etc/olsrd/olsrd6.conf an - nachfolgend ein Beispiel.<br />
<br />
AllowNoInt yes<br />
ClearScreen yes<br />
DebugLevel 0<br />
FIBMetric "flat"<br />
IpVersion 6<br />
LinkQualityAlgorithm "etx_ff"<br />
LinkQualityFishEye 1<br />
LinkQualityLevel 2<br />
MprCoverage 1<br />
Pollrate 0.1<br />
TcRedundancy 2<br />
TosValue 16<br />
UseHysteresis no<br />
UseNiit yes<br />
Willingness 3<br />
InterfaceDefaults<br />
{<br />
#Ip6MulticastGlobal ff0e::1<br />
#Ip6MulticastSite ff05::11<br />
IPv6Multicast ff02::6d<br />
Weight 99<br />
AutoDetectChanges yes<br />
HelloInterval 50.0<br />
HelloValidityTime 100.0<br />
HnaInterval 50.0<br />
HnaValidityTime 300.0<br />
LinkQualityMult default 0.33 <br />
MidInterval 50.0<br />
MidValidityTime 300.0<br />
Mode "mesh"<br />
TcInterval 2.0 <br />
TcValidityTime 300.0<br />
Weight 99<br />
}<br />
Hna6<br />
{<br />
}<br />
LoadPlugin "olsrd_httpinfo.so.0.1"<br />
{<br />
PlParam "Net" "0::/0 2000::/3"<br />
PlParam "port" "82"<br />
}<br />
LoadPlugin "olsrd_jsoninfo.so.1.1"<br />
{<br />
PlParam "port" "9090"<br />
PlParam "accept" "::"<br />
PlParam "UUIDFile" "/etc/olsrd/olsrd6.uuid"<br />
PlParam "ipv6only" "true"<br />
}<br />
Interface "br-ff"<br />
{<br />
AutoDetectChanges yes<br />
LinkQualityMult default 0.25 <br />
Mode "ether"<br />
Weight 1<br />
IPv6Multicast ff02::6d<br />
}<br />
<br />
Sollte OLSR nicht starten wollen, liegt es entweder an einem Tippfehler oder an einer falsch formatierten IPv6-Adresse (::/0 oder 0::/0 je nach Plugin...) oder daran, dass olsrd seine Plugins nicht finden kann oder die falsche Version findet, wenn Du ein Update mit selbstkompiliertem OLSR gemacht haben solltest. Aufmerksam lesen und eventuell die LoadPlugin-Zeilen mit absoluten Pfaden zu der jeweiligen ".so" setzen, hilft.<br />
<br />
Es ist auch möglich die plugin sektion ganz wegzulassen, damit eliminiert man evtl ein weiteres Problem.<br />
diese können ja schrittweise bei funktionierender config nachträglich wieder eingefügt werden.<br />
<br />
Ein letzter Hinweis: OLSR wird noch nicht automatisch gestartet. Du kannst das in /etc/network/interfaces bei der Bridge br-ff mittels „up /etc/init.d/olsrd restart“ und „up /etc/init.d/olsrd6 restart“ tun, oder, Du legst die zwei Befehle in das OpenVPN-UP/DOWN-Skript. AutodetecChanges in OLSR sollte eigentlich dafür sorgen, dass der Bridge-Port immer erkannt wird, ohne, dass man den Dienst erneut starten muss.<br />
<br />
Das war's. Dual-Stack OLSRv1 mit Tunnel läuft, sowie Du es gestartet hast.</div>Erichhttps://wiki.funkfeuer.at/index.php?title=OpenVPN_mit_Debian/Ubuntu&diff=1908OpenVPN mit Debian/Ubuntu2018-06-09T18:34:32Z<p>Erich: </p>
<hr />
<div>Unter Debian installierst Du die Pakete für Openvpn und olsr.<br />
<br />
Voraussetzungen:<br />
* Aktuelles Debian Stable oder Ubuntu LTS<br />
* Pakete für OpenVPN, OLSR (und OLSRv2), bridge-utils<br />
* Funkfeuer-Login<br />
* Funkfeuer-IPv4-Adresse für das Tunneldevice respektive die Bridge aus [[https://portal.funkfeuer.at/wien REDEEMER/FRONTEND/PORTAL]]<br />
* Einen Taschenrechner, der Dezimalzahlen in Hexadezimalzahlen umrechnen kann („programmiertechnischer Modus“)<br />
* Die Funkfeuer NodeID des Knotens, dem der Tunnel zugeordnet wird. Wenn Du im Redeemer/Portal eingeloggt bist, und auf „Nodes“ und den richtigen Namen des Nodes klickst, siehst Du die NodeID in der URL in Deinem Browsers entweder so:<br />
** „&id=9999“ oder so<br />
** „id_nodes=9999“.<br />
Diese Zahl umgewandelt in „Hex“ brauchst Du später für Deine IPv6-Adresse.<br />
<br />
<br />
* apt-get install openvpn openvpn-blacklist olsrd olsrd-plugins bridge-utils ebtables<br />
<br />
Angenommen, Dein Debian oder Ubuntu-Rechner besitzt eine Ethernetschnittstelle eth0 (oder wie das heute eher der Fall ist, en[X]s[Y]), die in derselben Broadcastdomain wie das Provider-Modem liegt, dann wirst Du /etc/network/interfaces editieren und dort zunächst eine statische Route zum Tunnelserver anlegen wollen. Im selben Arbeitsschritt könntest Du auch festlegen, dass der Tunnel unmittelbar nach dem Start der Netzwerkschnittstelle aufgebaut wird. Es ist darüber hinaus zweckmäßig, OLSR auf einer Bridge laufen zu lassen, um sich etwaige OLSR-Neustarts zu ersparen. Wir legen also auch gleich eine Bridge an und weisen ihr die Funkfeuer-IPs für IPv4 und IPv6 (aber nur für 2a02:60::/40) zu. 192.168.1.1 ist in diesem Beispiel das Providermodem als Defaultgateway. Warum setzen wir aber eine Hostroute zu 78.41.118.150/32? Ganz einfach: Olsr wird die Default-Route überschreiben. In aller Regel passiert dies mit einer Metrik von 2 und sollte nicht stören. Dennoch kommt es manchmal dazu, dass bei Fehlen der Hostroute der Tunnel quasi über sich selbst laufen soll - das funktioniert freilich nicht. Wenn Du aber auch eine Funkschnittstelle mit OLSR hast, dann läufst Du Gefahr, dass der Tunnel zu Funkfeuer über das Funkfeuer-Mesh aufgebaut würde, was absolut keinen Sinn ergibt. Daher die Hostroute.<br />
<br />
/etc/network/interfaces:<br />
iface eth0 inet static<br />
...<br />
up /sbin/ip r a 78.41.118.150/32 dev eth0 via 192.168.1.1 metric 0<br />
up /etc/init.d/openvpn restart<br />
<br />
auto br-ff <br />
iface br-ff inet static<br />
bridge_fd 0<br />
bridge_maxwait 0<br />
bridge_waitport 0<br />
bridge_stp no<br />
bridge_ports none<br />
address [REDEEMER-IP v4]<br />
netmask 255.255.255.255<br />
# IPv6/OLSRv1 Schema 2a02:60:01[Node ID in Hexadezimaldarstellung, erstes Oktett]:[Node ID in Hex, zweites Oktett][Router ID (4 Bit)][Interface ID (4 Bit)]::[irgendwas]<br />
# Nachfolgend für 9999 NodeID 9999(10) = 270F(16); Router 1, Interface 1 mit Adresse „feed“:<br />
post-up /sbin/ip -6 a a 2a02:60:1'''27''':'''0f'''''11''::feed/64 dev br-ff<br />
# Wenn man die MAC-Adresse der Bridge definiert, wirkt sich das auf die IPv6 EUI64-Adresse beginnend mit fe80::/12 aus.<br />
# Man kann sich eine zufällige MAC-Adresse [[https://www.miniwebtool.com/mac-address-generator/ MAC Address Generator]] (lowercase und ":"-Notation) errechnen lassen.<br />
post-up ip link set dev br-ff address bc:75:33:6a:bf:cf<br />
# Die Bridge soll allen Traffic annehmen.<br />
post-up ip link set dev br-ff promisc on<br />
<br />
<br />
Die Konfiguration von OpenVPN liegt bei Debian und Ubuntu üblicherweise in /etc/openvpn, wobei das Startup-Skript die Datei /etc/default/openvpn zu seiner Initialisierung heranzieht.<br />
<br />
/etc/default/openvpn:<br />
#AUTOSTART="all" -> <br />
AUTOSTART="all" <br />
oder<br />
#AUTOSTART="all" -><br />
AUTOSTART="funkfeuer"<br />
<br />
Somit erwartet OpenVPN seine Konfiguration in /etc/openvpn/funkfeuer.conf.<br />
<br />
/etc/openvpn/funkfeuer.conf:<br />
dev tap0<br />
proto udp<br />
remote 78.41.118.150<br />
# Die Portnummer XXXX wird Dir von den Tunnelserver-Administratoren zugewiesen, trag sie in der folgenden Zeile anstelle von XXXX ein.<br />
port XXXX<br />
daemon tap0<br />
persist-tun<br />
up-delay<br />
down-pre<br />
up-restart<br />
comp-lzo<br />
script-security 2<br />
nobind<br />
ping 10<br />
ping-restart 60<br />
ping-timer-rem<br />
fast-io<br />
sndbuf 524288<br />
rcvbuf 524288<br />
mute 2<br />
verb 0<br />
up /etc/openvpn/funkfeuer-updown.sh<br />
down /etc/openvpn/funkfeuer-updown.sh<br />
secret /etc/openvpn/funkfeuer.secret<br />
auth SHA256<br />
cipher none<br />
<br />
Diese Konfigurationsdatei benötigt also noch zwei weitere Dateien. Zum einen wäre das /etc/openvpn/funkfeuer-updown.sh. Dieses Skript wird von OpenVPN aufgerufen, sowie der Tunnel hergestellt oder beendet wird. OpenVPN übergibt diesem Skript Parameter, wie wir sie im Beispiel des Tunnelservers nützen. Für Deine Seite wird das nicht explizit erforderlich sein. Das Skript kann wie folgt aussehen:<br />
<br />
/etc/openvpn/funkfeuer-updown.sh:<br />
#!/bin/bash<br />
# br-ff ist die Bridge aus /etc/network/interfaces<br />
# $dev ist ein Parameter, den Openvpn übergibt. Hier zumeist „tap0“.<br />
br="br-ff"<br />
dev=$1<br />
logger "openvpn: $(echo $@)"<br />
logger "openvpn: $script_type"<br />
case $script_type in<br />
"down")<br />
/sbin/brctl delif $br $dev<br />
/sbin/ip link set link dev $dev down<br />
;;<br />
"route-up")<br />
;;<br />
"up")<br />
/sbin/brctl addif $br $dev<br />
/sbin/ip link set dev $br promisc on<br />
/sbin/ip link set link dev $dev up<br />
/sbin/ip link set link dev $br up<br />
;;<br />
esac<br />
echo $(date) $script_type $br.$dev $script_type>> /tmp/br-vpn.log<br />
exit 0<br />
<br />
<br />
Das Skript muss ausführbar gemacht werden. chmod +x /etc/openvpn/funkfeuer-updown.sh<br />
<br />
chmod +x /etc/openvpn/funkfeuer-updown.sh<br />
<br />
In der OpenVPN-Konfiguration haben wir den statischen Schlüssel mit /etc/openvpn/funkfeuer.secret angegeben. Exemplarisch schaut das so aus - aber den „echten Key“ bekommt ein Jeder individuell zugeteilt (bitte bei Erich P. anfordern):<br />
<br />
<br />
/etc/openvpn/funkfeuer.secret:<br />
#<br />
# 2048 bit OpenVPN static key<br />
#<br />
-----BEGIN OpenVPN Static key V1-----<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
-----END OpenVPN Static key V1-----<br />
<br />
<br />
Jetzt fehlt noch OLSR... Debian und Ubuntu verwenden /etc/init.d/olsrd als Startscript, das wiederum /etc/default/olsrd zu Initialisierung nutzt. Das Debian-Konzept geht noch von Adhoc-Netzen auf dem lokalen Gerät aus, kann also bis auf drei Zeilen ignoriert werden. Die Interface-Parameter lasse ich bewusst weg. Die Interfaces definiert man besser in der olsrd.conf, wo man individuelle Einstellungen tätigen kann (etwa unter anderem: ein per-Interface-Default-LQ-Multiplier, den Mode und die Gewichtung.)<br />
<br />
<br />
/etc/default/olsrd:<br />
START_OLSRD="YES"<br />
DEBUGLEVEL=0<br />
DAEMON_OPTS="-f /etc/olsrd/olsrd.conf -d $DEBUGLEVEL"<br />
<br />
<br />
Es fehlt noch die OSLR-Konfigurationsdatei (Vorsicht: ich verwende ein selbstkompiliertes OLSR und habe die plugin-Libraries „LoadPlugin“ hardgecodet; wenn der Pfad nicht stimmt, startet OLSR nicht, plaudert aber wirklich nicht darüber, was es stört.) -<br />
<br />
/etc/olsrd/olsrd.conf:<br />
AllowNoInt yes<br />
ClearScreen yes<br />
DebugLevel 0<br />
FIBMetric "flat"<br />
IpVersion 4<br />
LinkQualityAlgorithm "etx_ff"<br />
LinkQualityFishEye 1<br />
LinkQualityLevel 2<br />
MainIp [DIE MAIN-IP BEKOMMT IHR AUS DEM FUNKFEUER PORTAL, WENN IHR EIN GERÄT (DEVICE) ANLEGT]<br />
MprCoverage 1<br />
Pollrate 0.1<br />
TcRedundancy 2<br />
TosValue 16<br />
UseHysteresis no<br />
Willingness 3<br />
InterfaceDefaults<br />
{<br />
AutoDetectChanges yes<br />
HelloInterval 5.0<br />
HelloValidityTime 100.0<br />
TcInterval 2.0<br />
TcValidityTime 300.0<br />
MidInterval 50.0<br />
MidValidityTime 300.0<br />
HnaInterval 50.0<br />
HnaValidityTime 300.0<br />
Ip4Broadcast 255.255.255.255<br />
Mode "mesh"<br />
LinkQualityMult default 0.15<br />
Weight 99<br />
}<br />
Interface "br-ff"<br />
{<br />
AutoDetectChanges yes<br />
LinkQualityMult default 1.0<br />
Weight 0<br />
}<br />
Hna4<br />
{<br />
[SERVER-IP FALLS VORHANDEN - ZUWEISUNG VIA PORTAL] 255.255.255.255<br />
}<br />
LoadPlugin "olsrd_httpinfo.so.0.1"<br />
{<br />
PlParam "Port" "81"<br />
PlParam "Net" "0.0.0.0 0.0.0.0"<br />
PlParam "resolve" "false"<br />
}<br />
LoadPlugin "olsrd_txtinfo.so.1.1"<br />
{<br />
PlParam "port" "2006"<br />
PlParam "accept" "127.0.0.1"<br />
}<br />
LoadPlugin "olsrd_jsoninfo.so.1.1"<br />
{<br />
PlParam "port" "9090"<br />
PlParam "accept" "0.0.0.0"<br />
PlParam "UUIDFile" "/etc/olsrd/olsrd.uuid"<br />
}<br />
<br />
Damit ist eigentlich die Arbeit getan.<br />
<br />
=== 'the quick and dirty hack' für IPv6 ===<br />
<br />
Für OLSR mit IPv6 gibt es noch ein paar Tricks zu wissen und noch etwas mehr Handarbeit.<br />
Kopiere:<br />
<br />
* /etc/default/olsrd nach /etc/default/olsrd6<br />
** Ersetz jedes Vorkommen von olsr(d) durch olsr(d)6.<br />
<br />
mit vim wäre das so: vom input modus in den command modus wechseln (ESC) und in der command line folgendes eingeben: <br />
<br />
%s/olsrd/olsrd6/g<br />
<br />
12 ersetzungen sollten stattfinden. <br />
<br />
%s/OLSRD/OLSRD6/g<br />
<br />
selbiges gilt für die folgenden weiteren Dateien<br />
<br />
* /etc/init.d/olsrd nach /etc/init.d/olsrd6<br />
** Ersetz jedes Vorkommen von olsr(d) durch olsr(d)6. Ersetze /usr/sbin/olsrd durch /etc/alternatives/olsrd6<br />
* Setz einen Link von /usr/sbin/olsrd nach /etc/alternatives/olsrd6.<br />
<br />
ln -s /usr/sbin/olsrd /etc/alternatives/olsrd6<br />
<br />
Das hat den Sinn, dass der Prozess auch olsrd6 heißt, wenn er läuft und Du ihn mit dem pgrep im Startskript suchen kannst.<br />
<br />
* Leg /etc/olsrd/olsrd6.conf an - nachfolgend ein Beispiel.<br />
<br />
AllowNoInt yes<br />
ClearScreen yes<br />
DebugLevel 0<br />
FIBMetric "flat"<br />
IpVersion 6<br />
LinkQualityAlgorithm "etx_ff"<br />
LinkQualityFishEye 1<br />
LinkQualityLevel 2<br />
MprCoverage 1<br />
Pollrate 0.1<br />
TcRedundancy 2<br />
TosValue 16<br />
UseHysteresis no<br />
UseNiit yes<br />
Willingness 3<br />
InterfaceDefaults<br />
{<br />
#Ip6MulticastGlobal ff0e::1<br />
#Ip6MulticastSite ff05::11<br />
IPv6Multicast ff02::6d<br />
Weight 99<br />
AutoDetectChanges yes<br />
HelloInterval 50.0<br />
HelloValidityTime 100.0<br />
HnaInterval 50.0<br />
HnaValidityTime 300.0<br />
LinkQualityMult default 0.33 <br />
MidInterval 50.0<br />
MidValidityTime 300.0<br />
Mode "mesh"<br />
TcInterval 2.0 <br />
TcValidityTime 300.0<br />
Weight 99<br />
}<br />
Hna6<br />
{<br />
}<br />
LoadPlugin "olsrd_httpinfo.so.0.1"<br />
{<br />
PlParam "Net" "0::/0 2000::/3"<br />
PlParam "port" "82"<br />
}<br />
LoadPlugin "olsrd_jsoninfo.so.1.1"<br />
{<br />
PlParam "port" "9090"<br />
PlParam "accept" "::"<br />
PlParam "UUIDFile" "/etc/olsrd/olsrd6.uuid"<br />
PlParam "ipv6only" "true"<br />
}<br />
Interface "br-ff"<br />
{<br />
AutoDetectChanges yes<br />
LinkQualityMult default 0.25 <br />
Mode "ether"<br />
Weight 1<br />
IPv6Multicast ff02::6d<br />
}<br />
<br />
Sollte OLSR nicht starten wollen, liegt es entweder an einem Tippfehler oder an einer falsch formatierten IPv6-Adresse (::/0 oder 0::/0 je nach Plugin...) oder daran, dass olsrd seine Plugins nicht finden kann oder die falsche Version findet, wenn Du ein Update mit selbstkompiliertem OLSR gemacht haben solltest. Aufmerksam lesen und eventuell die LoadPlugin-Zeilen mit absoluten Pfaden zu der jeweiligen ".so" setzen, hilft.<br />
<br />
Es ist auch möglich die plugin sektion ganz wegzulassen, damit eliminiert man evtl ein weiteres Problem.<br />
diese können ja schrittweise bei funktionierender config nachträglich wieder eingefügt werden.<br />
<br />
Ein letzter Hinweis: OLSR wird noch nicht automatisch gestartet. Du kannst das in /etc/network/interfaces bei der Bridge br-ff mittels „up /etc/init.d/olsrd restart“ und „up /etc/init.d/olsrd6 restart“ tun, oder, Du legst die zwei Befehle in das OpenVPN-UP/DOWN-Skript. AutodetecChanges in OLSR sollte eigentlich dafür sorgen, dass der Bridge-Port immer erkannt wird, ohne, dass man den Dienst erneut starten muss.<br />
<br />
Das war's. Dual-Stack OLSRv1 mit Tunnel läuft, sowie Du es gestartet hast.</div>Erichhttps://wiki.funkfeuer.at/index.php?title=Services/Organisation/Gallery&diff=1907Services/Organisation/Gallery2018-06-08T23:36:36Z<p>Erich: /* Maintainer */</p>
<hr />
<div>== Beschreibung ==<br />
Photo Gallery zur Ablage von Bildern von Knoten, Events, Workshops, Konferenzen,...<br />
<br />
== Abhängigkeiten ==<br />
<br />
Anregung:<br />
Für Inklusion in der nodeDB wäre es sehr gut, wenn jedes Photo und uach jeder node (== standort) einen statischen permalink hat, der sich auch bei Versions-upgrades nicht mehr ändert.<br />
Bitte das in die Entscheidung bei der Auswahl der gallery berücksichtigen.<br />
<br />
<br />
== Verwendung ==<br />
Die Gallery soll grundsätzlich offen für alle Funkfeuer-User sein.<br />
<br />
--> Frage: IP range Funkfeuer oder Funkfeuer login (nodeDB/redeemer)?<br />
<br />
Gesonderte Zugriffsrechte für manche Bereiche wären wünschenswert - etwa für einzelne Bilder oder Standorte (Alben).<br />
<br />
== Maintainer ==<br />
Markus Gschwendt <br />
<br />
<del>Erich N. Pekarek</del>mit 09.06.2018 von der Funktion zurückgetreten, da eine Einigung mit dem 1.Maintainer nicht möglich war.<br />
<br />
== Brainstorming ==<br />
<br />
=== Anforderungen ===<br />
<br />
Die bisherige Gallery basiert auf G2. Gallery2 und Gallery3 werden nicht mehr weiterentwickelt. Die Migration auf ein anderes System ist erforderlich.<br />
<br />
* möglichst kein externes Cloud Service<br />
* möglichst keine PHP Software (auch für andere Projekte - warum eigentlich? -> Diskussionsseite)<br />
* möglichst statische Seiten<br />
* ev. (shell-)Scripts die die Bilder darstellen<br />
und Bilder-Upload getrennt davon (möglichst Userfreundlich)<br />
* Upload soll für 'Neue' möglich sein (selfregistration -> entspricht das dem Workflow? -> Diskussionsseite)<br />
* künftige Erfassung der Fotorechte<br />
<br />
weiterführende Informationen zu Alternativen:<br />
https://www.it-pulse.eu/webanwendungen/menalto-gallery/gallery-team-verkuendet-aus-fotogalerie-software-1809.html<br />
<br />
=== Mögliche Lösungen ===<br />
<br />
* Neuer Lösungsansatz: Keine Gallery mehr benützen, sondern die Bilder in Forenbeiträgen im neuen [https://forum.funkfeuer.at Forum] ablegen. Spart Maintership, ist kein PHP, Forum ist per se eine Form von Social-Media mit Kommentarfunktion, User können entscheiden, ob sie Daten sichtbar machen oder nicht.<br />
<br />
Die nachfolgenden Projekte sind in alphabetischer Reihenfolge sortiert.<br />
<br />
==== Coppermine ====<br />
<br />
<br />
* Website: http://coppermine-gallery.net/<br />
* Programmiersprache: PHP<br />
* Lizenz: GPL v3.0 [http://documentation.coppermine-gallery.net/en/copyrights.htm]<br />
<br />
* Demo: http://coppermine-gallery.net/demo/cpg15x/<br />
* Plugins: http://coppermine-gallery.net/plugins.php?cpg_version=both<br />
<br />
(+)zahlreiche Plugins verfügbar (Backup, Massimport, Panoramaviewer, Timeline, ...)<br />
(+)individuell konfigurierbare Userprofil-Einträge<br />
(+)Passwortgeschützte Alben möglich<br />
<br />
===== Migration von G2 zu Coppermine 1.5.x =====<br />
http://forum.coppermine-gallery.net/index.php?topic=76143.0<br />
<br />
==== DAlbum ====<br />
<br />
* Website: http://www.dalbum.org<br />
* Programmiersprache: PHP<br />
* Lizenz: GPL v2+ [http://www.dalbum.org/index.php?go=Copyrights]<br />
<br />
(+) baut auf lokaler Ordnerstruktur auf, welche indiziert wird<br />
(-)kein integrierter Bilder Upload (ist via FTP [http://www.dalbum.org/index.php?go=Upload gedacht])<br />
(·)[http://dalbum.org/index.php?go=Access User Verwaltung]<br />
(·)beim Indizieren werden auch Thumbnails erstellt<br />
(+)Pic-Infos werden ausgelesen und lassen sich ein/ausblenden<br />
<br />
==== Drupal + Node Gallery ====<br />
<br />
* Website: https://www.drupal.org<br />
* Website Modul: https://www.drupal.org/project/node_gallery<br />
* Programmiersprache: PHP 5.6 oder 7.x<br />
* Lizenz: GPL 2<br />
<br />
(+) Flexibilität: Es handelt sich um ein stark DB-orientiertes CMS mit zahlreichen Modulen<br />
(+) Erweiterbar<br />
(+) Code-Updates über Cronjob mittels "drush -y up"<br />
(+) Darstellung der Nodes über Views anpassbar - ermöglicht Filter, Sortierung, Gruppierung.<br />
(-) Bedarf des Einlernens<br />
(-) Bedarf der Anpassung<br />
<br />
==== Hugo + Hugo-gallery oder Hugo + HugoPhotoswipe + PhotoSwipe ====<br />
<br />
* Hugo Website: https://gohugo.io/tools/<br />
* Programmiersprache: Go<br />
<br />
* Hugo-Gallery<br />
** Repository: https://github.com/icecreammatt/hugo-gallery/blob/master/README.md<br />
** Lizenz: MIT [https://github.com/icecreammatt/hugo-gallery/blob/master/LICENSE]<br />
<br />
* HugoPhotoSwipe<br />
** Repository: https://github.com/GjjvdBurg/HugoPhotoSwipe/blob/master/README.rst<br />
** Lizenz: GPL v3.0 [https://github.com/GjjvdBurg/HugoPhotoSwipe/blob/master/LICENSE]<br />
<br />
* PhotoSwipe<br />
** Website: http://photoswipe.com/<br />
** Lizenz: MIT 'with Wordpress exception'<br />
<br />
(·) Hugo ist ein statischer Websitegenerator auf Basis von Go; die beiden Erweiterungen können scriptbasiert Galerien erstellen.<br />
(·) PhotoSwipe ist rein auf Javascript aufgebaut und nutzt vordefinierte Bildgrößen. Dokumentation [http://photoswipe.com/documentation/getting-started.html]<br />
<br />
Meinungen: <br />
sieht auch nach einem guten statischen Generator aus.<br />
<br />
==== Media Goblin ====<br />
<br />
* Website: http://www.mediagoblin.org/<br />
* Lizenz: GNU AGPLv3 [http://mediagoblin.readthedocs.io/en/stable/siteadmin/about.html#how-is-gnu-mediagoblin-licensed]<br />
<br />
(+) War schon mal Projekt bei Google Summer of Code, und reicht regelmäßig dort ein.<br />
(-) Es ist riesig, sowohl bezüglich Funktionalität (Video-Transkodierung etc.) als auch Sourcen.<br />
(·) Medien landen in einer (lokalen) Datenbank, nicht Verzeichnisbaum.<br />
(·) Bringt sein eigenes Django-artiges (?) Framework, aber eben nicht Django.<br />
(+) Debian/Ubuntu-Pakete, Fedora/Redhat vorhanden; Abhängigkeiten:<br />
Python 2.7 or Python 3.4+<br />
python-lxml<br />
git<br />
SQLite/PostgreSQL<br />
Python Imaging Library (PIL)<br />
virtualenv<br />
nodejs<br />
http://mediagoblin.readthedocs.io/en/stable/siteadmin/deploying.html<br />
<br />
Meinungen:<br />
"This project is part of the GNU Project." Supporttechnisch sicher nicht übel.<br />
<br />
==== nextcloud ====<br />
(getestet)<br />
<br />
* Website: http://nextcloud.com/<br />
* Demo: https://demo.nextcloud.com/<br />
* Programmiersprache: PHP<br />
* Lizenz: GNU AGPL 3.0 [https://github.com/nextcloud/nextcloud.com/blob/master/LICENSE]<br />
<br />
(-) keine Baum-Darstellung der Gallery<br />
(-) kein Resizing der Bilder<br />
(-) keine Pic-Infos,... in der Gallery-Darstellung<br />
<br />
Meinung: mbmn als Gallery ungeeignet [+/-] (2/0)<br />
<br />
==== PhotoFloat ====<br />
<br />
* Website: https://git.zx2c4.com/PhotoFloat/about/<br />
* Programmiersprache: Python2<br />
* Lizenz: GPL v2.0+ [https://git.zx2c4.com/PhotoFloat/about/]<br />
<br />
Eindrücke:<br />
PhotoFloat hat eine serverseitige Authentifizierung basierend auf flask-login, sodass man Alben etc. mit Login "schützen" kann. https://flask-login.readthedocs.io/en/latest/<br />
<br />
Allerdings sehe ich da weder ein Web-Interface für Selbstregistrierung, noch Unterstützung für mehr als zwei (!?) User.<br />
<br />
Es dürfte auch keinen Web-Bilder-Upload geben, und von PEP-8 [5] hat der Autor wohl noch nichts gehört :-) https://www.python.org/dev/peps/pep-0008/#tabs-or-spaces<br />
<br />
Fazit: (Auch) PhotoFloat bräuchte einige Anpassungen und Umbauten für den Gallery-Anwendungsfall.<br />
<br />
==== Piwigo ====<br />
(getestet)<br />
<br />
* Website: http://piwigo.org<br />
* Programmiersprache: PHP<br />
* Lizenz: GNU GPLv2 [http://piwigo.org/basics/license]<br />
<br />
(·) wird oft als Ersatz für G2 und G3 Projekte verwendet.<br />
<br />
Meinungen:<br />
* schaut interessant aus<br />
<br />
===== Migration von G2 nach Piwigo =====<br />
Migration von G2 mittels Scripts möglich etwa: <br />
https://github.com/dschwen/g2piwigo<br />
<br />
==== Sigal ====<br />
<br />
* Website: http://sigal.saimon.org/<br />
* Programmiersprache: Python<br />
* Lizenz: MIT [http://sigal.saimon.org/en/latest/]<br />
<br />
(·) album metadaten via markdown files.<br />
(+) generiert wenn gewünscht auch eine nette Karte basierend auf den Koordinaten in den Photo-Metadaten via leaflet / openstreetmap.<br />
(+) einfach zu installieren und konfigurieren.<br />
(+) könnte als cronjob, git post-receive hook oder dergleichen laufen.<br />
(?) die offene frage wäre dann wie man sicher fotos von selbst registrierten users in einen lokalen ordner am server bekommt.<br />
<br />
Meinungen: <br />
sieht nach einem guten statischen Generator aus.<br />
<br />
==== WordPress ====<br />
<br />
* Website:<br />
* Programmiersprache: PHP<br />
* Lizenz: GPL v2 + [https://wordpress.org/about/license/]<br />
<br />
(·) via Plugin: Gallery Manager<br />
<br />
Meinungen:<br />
* ganz allgemein... Hände weg von wordpress; Gegenfrage: warum?<br />
* Sicherheitslücken...; Gegenargument: die werden aber üblicherweise flott gestopft...;<br />
<br />
==== Zenphoto ====<br />
(getestet)<br />
<br />
* Website: http://www.zenphoto.org/<br />
* Programmiersprache: PHP<br />
* Lizenz: GPL v2+ [http://www.zenphoto.org/pages/licenses/]<br />
<br />
(·) eher als Foto-CMS gedacht<br />
(?) Userrechte für verschiedene Fotogrößen?<br />
<br />
===== Migration von G2 zu Zenphoto =====<br />
http://www.zenphoto.org/news/gallery2-to-zenphoto-migration/<br />
<br />
==== GoGallery ====<br />
<br />
* Website: https://github.com/smancke/gogallery<br />
* Programmiersprache: Go<br />
* Lizenz: MIT License [https://github.com/smancke/gogallery/blob/master/LICENSE]<br />
<br />
==== Chevereto Free ====<br />
<br />
* Website: https://chevereto.com/free<br />
* Programmiersprache: PHP<br />
* Lizenz: GNU Affero General Public License v3.0 [https://github.com/Chevereto/Chevereto-Free/blob/master/LICENSE]<br />
* Demo: https://demo.chevereto.com/<br />
<br />
=== Zeitplan ===<br />
<br />
* Brainstormingphase ... bis Herbst 2017<br />
* Sept. 2017 Entscheidung über System.<br />
* Umsetzung bis Anfang 2018.<br />
<br />
=== Diverse Links ===<br />
<br />
https://en.wikipedia.org/wiki/Comparison_of_photo_gallery_software<br />
<br />
wiki deutsch listet teilweise andere auf<br />
https://de.wikipedia.org/wiki/Webgalerie<br />
<br />
https://www.heise.de/download/products/foto/web-galerien</div>Erichhttps://wiki.funkfeuer.at/index.php?title=OpenVPN_mit_Debian/Ubuntu&diff=1904OpenVPN mit Debian/Ubuntu2018-06-08T11:08:12Z<p>Erich: </p>
<hr />
<div>Unter Debian installierst Du die Pakete für Openvpn und olsr.<br />
<br />
Voraussetzungen:<br />
* Aktuelles Debian Stable oder Ubuntu LTS<br />
* Pakete für OpenVPN, OLSR (und OLSRv2), bridge-utils<br />
* Funkfeuer-Login<br />
* Funkfeuer-IPv4-Adresse für das Tunneldevice respektive die Bridge aus [[https://portal.funkfeuer.at/wien REDEEMER/FRONTEND/PORTAL]]<br />
* Einen Taschenrechner, der Dezimalzahlen in Hexadezimalzahlen umrechnen kann („programmiertechnischer Modus“)<br />
* Die Funkfeuer NodeID des Knotens, dem der Tunnel zugeordnet wird. Wenn Du im Redeemer/Portal eingeloggt bist, und auf „Nodes“ und den richtigen Namen des Nodes klickst, siehst Du die NodeID in der URL in Deinem Browsers entweder so:<br />
** „&id=9999“ oder so<br />
** „id_nodes=9999“.<br />
Diese Zahl umgewandelt in „Hex“ brauchst Du später für Deine IPv6-Adresse.<br />
<br />
<br />
* apt-get install openvpn openvpn-blacklist olsrd olsrd-plugins bridge-utils ebtables<br />
<br />
Angenommen, Dein Debian oder Ubuntu-Rechner besitzt eine Ethernetschnittstelle eth0 (oder wie das heute eher der Fall ist, en[X]s[Y]), die in derselben Broadcastdomain wie das Provider-Modem liegt, dann wirst Du /etc/network/interfaces editieren und dort zunächst eine statische Route zum Tunnelserver anlegen wollen. Im selben Arbeitsschritt könntest Du auch festlegen, dass der Tunnel unmittelbar nach dem Start der Netzwerkschnittstelle aufgebaut wird. Es ist darüber hinaus zweckmäßig, OLSR auf einer Bridge laufen zu lassen, um sich etwaige OLSR-Neustarts zu ersparen. Wir legen also auch gleich eine Bridge an und weisen ihr die Funkfeuer-IPs für IPv4 und IPv6 (aber nur für 2a02:60::/40) zu. 192.168.1.1 ist in diesem Beispiel das Providermodem als Defaultgateway. Warum setzen wir aber eine Hostroute zu 78.41.118.150/32? Ganz einfach: Olsr wird die Default-Route überschreiben. In aller Regel passiert dies mit einer Metrik von 2 und sollte nicht stören. Dennoch kommt es manchmal dazu, dass bei Fehlen der Hostroute der Tunnel quasi über sich selbst laufen soll - das funktioniert freilich nicht. Wenn Du aber auch eine Funkschnittstelle mit OLSR hast, dann läufst Du Gefahr, dass der Tunnel zu Funkfeuer über das Funkfeuer-Mesh aufgebaut würde, was absolut keinen Sinn ergibt. Daher die Hostroute.<br />
<br />
/etc/network/interfaces:<br />
iface eth0 inet static<br />
...<br />
up /sbin/ip r a 78.41.118.150/32 dev eth0 via 192.168.1.1 metric 0<br />
up /etc/init.d/openvpn restart<br />
<br />
iface br-ff inet static<br />
bridge_fd 0<br />
bridge_maxwait 0<br />
bridge_waitport 0<br />
bridge_stp no<br />
bridge_ports none<br />
address [REDEEMER-IP v4]<br />
netmask 255.255.255.255<br />
# IPv6/OLSRv1 Schema 2a02:60:01[Node ID in Hexadezimaldarstellung, erstes Oktett]:[Node ID in Hex, zweites Oktett][Router ID (4 Bit)][Interface ID (4 Bit)]::[irgendwas]<br />
# Nachfolgend für 9999 NodeID 9999(10) = 270F(16); Router 1, Interface 1 mit Adresse „feed“:<br />
post-up /sbin/ip -6 a a 2a02:60:1'''27''':'''0f'''''11''::feed/64 dev br-ff<br />
# Wenn man die MAC-Adresse der Bridge definiert, wirkt sich das auf die IPv6 EUI64-Adresse beginnend mit fe80::/12 aus.<br />
# Man kann sich eine zufällige MAC-Adresse [[https://www.miniwebtool.com/mac-address-generator/ MAC Address Generator]] (lowercase und ":"-Notation) errechnen lassen.<br />
post-up ip link set dev br-ff address bc:75:33:6a:bf:cf<br />
# Die Bridge soll allen Traffic annehmen.<br />
post-up ip link set dev br-ff promisc on<br />
<br />
<br />
Die Konfiguration von OpenVPN liegt bei Debian und Ubuntu üblicherweise in /etc/openvpn, wobei das Startup-Skript die Datei /etc/default/openvpn zu seiner Initialisierung heranzieht.<br />
<br />
/etc/default/openvpn:<br />
#AUTOSTART="all" -> <br />
AUTOSTART="all" <br />
oder<br />
#AUTOSTART="all" -><br />
AUTOSTART="funkfeuer"<br />
<br />
Somit erwartet OpenVPN seine Konfiguration in /etc/openvpn/funkfeuer.conf.<br />
<br />
/etc/openvpn/funkfeuer.conf:<br />
dev tap0<br />
proto udp<br />
remote 78.41.118.150<br />
# Die Portnummer XXXX wird Dir von den Tunnelserver-Administratoren zugewiesen, trag sie in der folgenden Zeile anstelle von XXXX ein.<br />
port XXXX<br />
daemon tap0<br />
persist-tun<br />
up-delay<br />
down-pre<br />
up-restart<br />
comp-lzo<br />
script-security 2<br />
nobind<br />
ping 10<br />
ping-restart 60<br />
ping-timer-rem<br />
fast-io<br />
sndbuf 524288<br />
rcvbuf 524288<br />
mute 2<br />
verb 0<br />
up /etc/openvpn/funkfeuer-updown.sh<br />
down /etc/openvpn/funkfeuer-updown.sh<br />
secret /etc/openvpn/funkfeuer.secret<br />
auth SHA256<br />
cipher none<br />
<br />
Diese Konfigurationsdatei benötigt also noch zwei weitere Dateien. Zum einen wäre das /etc/openvpn/funkfeuer-updown.sh. Dieses Skript wird von OpenVPN aufgerufen, sowie der Tunnel hergestellt oder beendet wird. OpenVPN übergibt diesem Skript Parameter, wie wir sie im Beispiel des Tunnelservers nützen. Für Deine Seite wird das nicht explizit erforderlich sein. Das Skript kann wie folgt aussehen:<br />
<br />
/etc/openvpn/funkfeuer-updown.sh:<br />
#!/bin/bash<br />
# br-ff ist die Bridge aus /etc/network/interfaces<br />
# $dev ist ein Parameter, den Openvpn übergibt. Hier zumeist „tap0“.<br />
br="br-ff"<br />
dev=$1<br />
logger "openvpn: $(echo $@)"<br />
logger "openvpn: $script_type"<br />
case $script_type in<br />
"down")<br />
/sbin/brctl delif $br $dev<br />
/sbin/ip link set link dev $dev down<br />
;;<br />
"route-up")<br />
;;<br />
"up")<br />
/sbin/brctl addif $br $dev<br />
/sbin/ip link set dev $br promisc on<br />
/sbin/ip link set link dev $dev up<br />
/sbin/ip link set link dev $br up<br />
;;<br />
esac<br />
echo $(date) $script_type $br.$dev $script_type>> /tmp/br-vpn.log<br />
exit 0<br />
<br />
<br />
Das Skript muss ausführbar gemacht werden. chmod +x /etc/openvpn/funkfeuer-updown.sh<br />
<br />
chmod +x /etc/openvpn/funkfeuer-updown.sh<br />
<br />
In der OpenVPN-Konfiguration haben wir den statischen Schlüssel mit /etc/openvpn/funkfeuer.secret angegeben. Exemplarisch schaut das so aus - aber den „echten Key“ bekommt ein Jeder individuell zugeteilt (bitte bei Erich P. anfordern):<br />
<br />
<br />
/etc/openvpn/funkfeuer.secret:<br />
#<br />
# 2048 bit OpenVPN static key<br />
#<br />
-----BEGIN OpenVPN Static key V1-----<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
-----END OpenVPN Static key V1-----<br />
<br />
<br />
Jetzt fehlt noch OLSR... Debian und Ubuntu verwenden /etc/init.d/olsrd als Startscript, das wiederum /etc/default/olsrd zu Initialisierung nutzt. Das Debian-Konzept geht noch von Adhoc-Netzen auf dem lokalen Gerät aus, kann also bis auf drei Zeilen ignoriert werden. Die Interface-Parameter lasse ich bewusst weg. Die Interfaces definiert man besser in der olsrd.conf, wo man individuelle Einstellungen tätigen kann (etwa unter anderem: ein per-Interface-Default-LQ-Multiplier, den Mode und die Gewichtung.)<br />
<br />
<br />
/etc/default/olsrd:<br />
START_OLSRD="YES"<br />
DEBUGLEVEL=0<br />
DAEMON_OPTS="-f /etc/olsrd/olsrd.conf -d $DEBUGLEVEL"<br />
<br />
<br />
Es fehlt noch die OSLR-Konfigurationsdatei (Vorsicht: ich verwende ein selbstkompiliertes OLSR und habe die plugin-Libraries „LoadPlugin“ hardgecodet; wenn der Pfad nicht stimmt, startet OLSR nicht, plaudert aber wirklich nicht darüber, was es stört.) -<br />
<br />
/etc/olsrd/olsrd.conf:<br />
AllowNoInt yes<br />
ClearScreen yes<br />
DebugLevel 0<br />
FIBMetric "flat"<br />
IpVersion 4<br />
LinkQualityAlgorithm "etx_ff"<br />
LinkQualityFishEye 1<br />
LinkQualityLevel 2<br />
MainIp [DIE MAIN-IP BEKOMMT IHR AUS DEM FUNKFEUER PORTAL, WENN IHR EIN GERÄT (DEVICE) ANLEGT]<br />
MprCoverage 1<br />
Pollrate 0.1<br />
TcRedundancy 2<br />
TosValue 16<br />
UseHysteresis no<br />
Willingness 3<br />
InterfaceDefaults<br />
{<br />
AutoDetectChanges yes<br />
HelloInterval 5.0<br />
HelloValidityTime 100.0<br />
TcInterval 2.0<br />
TcValidityTime 300.0<br />
MidInterval 50.0<br />
MidValidityTime 300.0<br />
HnaInterval 50.0<br />
HnaValidityTime 300.0<br />
Ip4Broadcast 255.255.255.255<br />
Mode "mesh"<br />
LinkQualityMult default 0.15<br />
Weight 99<br />
}<br />
Interface "br-ff"<br />
{<br />
AutoDetectChanges yes<br />
LinkQualityMult default 1.0<br />
Weight 0<br />
}<br />
Hna4<br />
{<br />
[SERVER-IP FALLS VORHANDEN - ZUWEISUNG VIA PORTAL] 255.255.255.255<br />
}<br />
LoadPlugin "olsrd_httpinfo.so.0.1"<br />
{<br />
PlParam "Port" "81"<br />
PlParam "Net" "0.0.0.0 0.0.0.0"<br />
PlParam "resolve" "false"<br />
}<br />
LoadPlugin "olsrd_txtinfo.so.1.1"<br />
{<br />
PlParam "port" "2006"<br />
PlParam "accept" "127.0.0.1"<br />
}<br />
LoadPlugin "olsrd_jsoninfo.so.1.1"<br />
{<br />
PlParam "port" "9090"<br />
PlParam "accept" "0.0.0.0"<br />
PlParam "UUIDFile" "/etc/olsrd/olsrd.uuid"<br />
}<br />
<br />
Damit ist eigentlich die Arbeit getan.<br />
<br />
=== 'the quick and dirty hack' für IPv6 ===<br />
<br />
Für OLSR mit IPv6 gibt es noch ein paar Tricks zu wissen und noch etwas mehr Handarbeit.<br />
Kopiere:<br />
<br />
* /etc/default/olsrd nach /etc/default/olsrd6<br />
** Ersetz jedes Vorkommen von olsr(d) durch olsr(d)6.<br />
<br />
mit vim wäre das so: vom input modus in den command modus wechseln (ESC) und in der command line folgendes eingeben: <br />
<br />
%s/olsrd/olsrd6/g<br />
<br />
12 ersetzungen sollten stattfinden. <br />
<br />
%s/OLSRD/OLSRD6/g<br />
<br />
selbiges gilt für die folgenden weiteren Dateien<br />
<br />
* /etc/init.d/olsrd nach /etc/init.d/olsrd6<br />
** Ersetz jedes Vorkommen von olsr(d) durch olsr(d)6. Ersetze /usr/sbin/olsrd durch /etc/alternatives/olsrd6<br />
* Setz einen Link von /usr/sbin/olsrd nach /etc/alternatives/olsrd6.<br />
<br />
ln -s /usr/sbin/olsrd /etc/alternatives/olsrd6<br />
<br />
Das hat den Sinn, dass der Prozess auch olsrd6 heißt, wenn er läuft und Du ihn mit dem pgrep im Startskript suchen kannst.<br />
<br />
* Leg /etc/olsrd/olsrd6.conf an - nachfolgend ein Beispiel.<br />
<br />
AllowNoInt yes<br />
ClearScreen yes<br />
DebugLevel 0<br />
FIBMetric "flat"<br />
IpVersion 6<br />
LinkQualityAlgorithm "etx_ff"<br />
LinkQualityFishEye 1<br />
LinkQualityLevel 2<br />
MprCoverage 1<br />
Pollrate 0.1<br />
TcRedundancy 2<br />
TosValue 16<br />
UseHysteresis no<br />
UseNiit yes<br />
Willingness 3<br />
InterfaceDefaults<br />
{<br />
#Ip6MulticastGlobal ff0e::1<br />
#Ip6MulticastSite ff05::11<br />
IPv6Multicast ff02::6d<br />
Weight 99<br />
AutoDetectChanges yes<br />
HelloInterval 50.0<br />
HelloValidityTime 100.0<br />
HnaInterval 50.0<br />
HnaValidityTime 300.0<br />
LinkQualityMult default 0.33 <br />
MidInterval 50.0<br />
MidValidityTime 300.0<br />
Mode "mesh"<br />
TcInterval 2.0 <br />
TcValidityTime 300.0<br />
Weight 99<br />
}<br />
Hna6<br />
{<br />
}<br />
LoadPlugin "olsrd_httpinfo.so.0.1"<br />
{<br />
PlParam "Net" "0::/0 2000::/3"<br />
PlParam "port" "82"<br />
}<br />
LoadPlugin "olsrd_jsoninfo.so.1.1"<br />
{<br />
PlParam "port" "9090"<br />
PlParam "accept" "::"<br />
PlParam "UUIDFile" "/etc/olsrd/olsrd6.uuid"<br />
PlParam "ipv6only" "true"<br />
}<br />
Interface "br-ff"<br />
{<br />
AutoDetectChanges yes<br />
LinkQualityMult default 0.25 <br />
Mode "ether"<br />
Weight 1<br />
IPv6Multicast ff02::6d<br />
}<br />
<br />
Sollte OLSR nicht starten wollen, liegt es entweder an einem Tippfehler oder an einer falsch formatierten IPv6-Adresse (::/0 oder 0::/0 je nach Plugin...) oder daran, dass olsrd seine Plugins nicht finden kann oder die falsche Version findet, wenn Du ein Update mit selbstkompiliertem OLSR gemacht haben solltest. Aufmerksam lesen und eventuell die LoadPlugin-Zeilen mit absoluten Pfaden zu der jeweiligen ".so" setzen, hilft.<br />
<br />
Es ist auch möglich die plugin sektion ganz wegzulassen, damit eliminiert man evtl ein weiteres Problem.<br />
diese können ja schrittweise bei funktionierender config nachträglich wieder eingefügt werden.<br />
<br />
Ein letzter Hinweis: OLSR wird noch nicht automatisch gestartet. Du kannst das in /etc/network/interfaces bei der Bridge br-ff mittels „up /etc/init.d/olsrd restart“ und „up /etc/init.d/olsrd6 restart“ tun, oder, Du legst die zwei Befehle in das OpenVPN-UP/DOWN-Skript. AutodetecChanges in OLSR sollte eigentlich dafür sorgen, dass der Bridge-Port immer erkannt wird, ohne, dass man den Dienst erneut starten muss.<br />
<br />
Das war's. Dual-Stack OLSRv1 mit Tunnel läuft, sowie Du es gestartet hast.</div>Erich