wiki.freifunk.net - Neue Beiträge | freifunk.net

Monic: /* Following fields should be shown in the GUI (think of newbees, that's why it should not contain to many tech details) */

= API for map of communities =

Idea for the map is to use open streetmap with a minimalistic style, eg. [http://mapbox.com/tour/#section-tech this mapbox]. A hover shows for each lokal community, that is using the API, a tooltipp with some details and link to the communities website.

== Following fields should be shown in the GUI (think of newbees, that's why it should not contain to many tech details) ==

*name of community
*city
*url

*url node map (optional)
*mailinglist (optional)
*amount of nodes (optional)

*phone (optional)
*email (optional)
*facebook (optional)
*twitter (optional)
*irc (optional)
*jabber (optional)
*identica (optional)


*events (optional; for weekly meetings, eg. name, time, location, text)

== Following fields should be in the API, but not in GUI ==

*latitude
*longitude
*timestamp (here we need a rule, when to mark inactive communities grey and send them a request to update; when should they be deleted?)
*newsfeed (optional; will be aggregated as community feeds on freifunk.net)

== Following fields could be in the API, but not in GUI or maybe as an expand ==

They are representing the info from [[Freifunk Firmware/Übersicht Communities]] ... which we can use then for the wikipage as well?

*topodata (optional)
*ipbereich (optional; ipv6 o. ipv4)
*firmware (optional)
*routing (optional)
*FW-update (optional)
*splashpage (optional)
*VPN Network (optional)
*Keyexchange (optional)
*Bootstrap (optional)
*Störerhaftung (optional)


[[Category:Website]]

Raku:

Auf dem spätsommerlichen Straßenfest war ein Internet-Cafe eingerichtet, in dem man über das Phänomen plauderte, wie man sich etwas teilen kann und es davon mehr wird.

[[Datei:Freifunk-Internetcafe.jpg]]


[[Datei:Freifunk-Internetcafe2.jpg]]

Raku: Die Seite wurde neu angelegt: „ Präsentation der Freifunk-Idee auf dem Rotlintstraßenfest 2005“

[[Präsentation der Freifunk-Idee auf dem Rotlintstraßenfest 2005]]

Mario Behling:

Back to << [[Wireless Community Weekend 2014]]

Please add your info here. Include Nick/Name, Community, Blog, Days you participate, Special Cost (vegetarian etc.). Thank you!

# Mario Behling (freifunk), Friday, Saturday, Sunday, preferably vegetarian
# name..
# name..

[[Kategorie:Freifunk-Community]]
[[Kategorie:Konferenzen]]
[[Kategorie:English]]
{{Navigationsleiste Wireless Community Weekend}}

Mario Behling:

{| class="prettytable float-right" width="300"
! align="center" colspan="2" style="background-color:#f2f2f4;" | <font size="+1">Freifunk Wireless Community Weekend 2014</font>
|- style="background: #ffffff;" align="center"
! align="center" colspan="2" | [[Datei:freifunk-wireless-community-weekend.png|border|Freifunk Wireless Community Weekend 2014]]
|-
! colspan="2" style="background-color:#f2f2f4;" | Basics
|- style="background: #ffffff;"
|Date: || May 29 - 1 June 2014
|- style="background: #ffffff;"
| participants || [[WCW13:participants]]
|- style="background: #ffffff;"
| entrance fee: || free, but [http://start.freifunk.net/node/8 donations] are welcome
|- style="background: #ffffff;"
| Images|| [http://flickr.com/photos/tags/ffwcw2014/ on flickr]
|- style="background: #ffffff;"
| Radio || [http://www.freie-radios.net/portal/suche.php?such=true&query=FFWCW-2014&Submit=Suche+starten on free Radios]
|-
|social || [https://twitter.com/#!/ffwcw on twitter]
|-
|}

==Freifunk Wireless Community Weekend 2014==

Starting Friday May 30 till Sunday June 1, 2014 freifunk.net, c-base and the German community invite you to the "Freifunk Wireless Community Weekend" at the c-base space station in Berlin.

==when==
* 30 May till 1 June 2014 at c-base berlin

==where==
* c-base space station, Rungestrasse 20 10179 Berlin Germany Terra
* [http://www.c-base.org c-base] e.V.
* [http://www.openstreetmap.org/?box=yes&bbox=13.42013%2C52.51297%2C13.42013%2C52.51297 OpenStreetMap c-base]
* [http://www.fahrinfo-berlin.de/Fahrinfo/bin/stboard.bin/dn?ld=0.1&seqnr=2&ident=kp.0234871.1205455780&input=9100004&boardType=arr&time=10:00&date=17.05.12&productsFilter=1111111 S+U Jannowitzbrücke, City Railway and Subway Station] (Info of BVG, Berlin Public Transport Company)

===inside locations===
* main hall
* c-base beachpark

== Topics ==

*B B Q

*Maps

==TimeTable==
=== Pre-Meeting 2014 May 28, Wednesday ===
Regularly there is WaveLöten with a monthly lecture called "freifunk für Fortgeschrittene" / freifunk advanced workshop.

=== Ascension Day 2014 May 29, Thursday===
wine/ beer and Hausmannskost ;)

===Friday 2014 May 30===

'''You can add workshops and panels if you want to give one.'''
{| border="1" cellpadding="5" cellspacing="0" "width:100%;" style="background:#ffdead;"
! Name/Title
! Time/Duration
! Location
! Done by
! Notes
!presentation Download
|-
|}

===Saturday 2014 May 31===
'''You can add workshops and panels if you want to give one.'''
{| border="1" cellpadding="5" cellspacing="0" "width:100%;" style="background:#ffdead;"
! Name/Title
! Time/Duration
! Location
! Done by
! Notes
!presentation Download
|-
|}

===Sunday 2014 June 1 ===
'''You can add workshops and panels if you want to give one.'''
{| border="1" cellpadding="5" cellspacing="0" "width:100%;" style="background:#ffdead;"
! Name/Title
! Time/Duration
! Location
! Done by
! Notes
!presentation Download
|-
|}

==who will be there==
check out and sign in! [[WCW14:participants]]


==see also==
* Please add Media Coverage of the event into the [[Medienspiegel]]

[[Kategorie:Freifunk-Community]]
[[Kategorie:Konferenzen]]
[[Kategorie:Praxis]]
[[Kategorie:English]]
{{Navigationsleiste Wireless Community Weekend}}

Andre:

[[Freifunk Hamburg/Geekend01]]-Teilnehmende


== '''Da wiki.freifunk.net z.Z. keine neuen Benutzer zu lässt, ist diese Seite auf [http://wiki.hamburg.freifunk.net/index.php?title=Freifunk_Hamburg/Geekend01/Teilnehmende http://wiki.hamburg.freifunk.net/index.php?title=Freifunk_Hamburg/Geekend01/Teilnehmende] umgezogen.''' ==


[[Kategorie:Hamburg]]

Andre:

{| class="prettytable float-right" width="400"
! align="center" colspan="2" style="background-color:#f2f2f4;" | <font size="+1">Freifunk Geekend01 in Hamburg</font>
|- style="background: #ffffff;" align="center"
! align="center" colspan="2" | [[Datei:ffhh-geekend01_blink.gif|border|Freifunk Geekend01 in Hamburg]]
|-
! colspan="2" style="background-color:#f2f2f4;" | Wer? Wie? Was?
|- style="background: #ffffff;"
|'''Wann?''' || 24.-26. Mai 2013
|- style="background: #ffffff;"
|'''Wo?''' || [https://blog.attraktor.org/anfahrt/ Attraktor], Mexikoring 21, 22297 Hamburg
|- style="background: #ffffff;"
| '''Wer?''' || [http://wiki.hamburg.freifunk.net/index.php?title=Freifunk_Hamburg/Geekend01/Teilnehmende Teilnehmende]
|- style="background: #ffffff;"
| '''Eintritt:''' || frei. Da der Attraktor uns kostenlos Räumlichkeiten und Infrastruktur zur Verfügung stellt, sind Spenden für den Attraktor sehr willkommen
|- style="background: #ffffff;"
| '''Agenda Pad:''' || https://ffhh.pads.ccc.de/geekend01-agenda
|- style="background: #ffffff;"
| '''Chat:''' || {{IRC|irc.eu.hackint.org|ffhh}}
|- style="background: #ffffff;"
| '''Post/Fragen:''' || [mailto:geekend@hamburg.freifunk.net geekend@hamburg.freifunk.net]
|- style="background: #ffffff;"
|}

== Geekend ==
Du brauchst root-Zugriff auf [http://hamburg.freifunk.net hamburg.freifunk.net]? Das k&ouml;nnen wir vielleicht nicht versprechen. ;-) Aber wenn Du bei Freifunk mitmachen m&ouml;chtest, sei es deinem Router zus&auml;tzliche Funktionen zu geben, am Netzwerk zu arbeiten, &Ouml;ffentlichkeitsarbeit zu machen oder auch nur Fragen zu stellen und Freifunk und nette Leute kennen zu lerenen, dann komme zum geekend01!

Im Attraktor stehen Räume für kreatives Zusammenarbeiten offen. Ein einleitendes Treffen findet am Freitag, 18:30 Uhr statt. Vorschläge zum Ablauf befinden sich in der vorläufigen [[https://ffhh.pads.ccc.de/geekend01-agenda Agenda]]. Besucher sind jederzeit willkommen!

Wir freuen uns auf Dich!

== Wer ==
Wir freuen uns auf euer zahlreiches Erscheinen! Bitte trage dich unter [http://wiki.hamburg.freifunk.net/index.php?title=Freifunk_Hamburg/Geekend01/Teilnehmende Teilnehmende] ein, damit wir ausreichend Mate auftreiben koennen :)


== Agenda ==
===Freitag===
* 18:30 Uhr Kennenlernen der Teilnehmer/innen
* 19:00 Projektgruppen finden und planen des Geekends

===Samstag===
* ''kommt noch''

===Sonntag===
* ''kommt noch''
* 17:00 Ende


== Arbeitsgruppen (Vorschlag) ==

===Gateway===
* DNS
* SIP
* ICVPN
* alternative VPN-Anbieter integrieren?
* offline Router kontaktieren
* Verbindungsprobleme 01

===Basteln===
Die Attraktor Werkstatt darf (mit Ausnahme der Maschinen) genutzt werden!
* Wetterfeste router basteln
* Antennen basteln

===Öffentlichkeitsarbeit===
* mehr Gastro zum Freifunk überreden
* neue Seite (mit wordpress)
* Wiki strukturieren und aufräumen

===Firmware===
* verstehen


== Vortrag: Freifunk Hamburg ==
Freifunk Hamburg stellt sich und die Idee eines freien W-LANs für alle vor.

Ziel des Projektes ist es, mittelfristig ein flächendeckendes, freies Bürgernetz in Hamburg aufzubauen – ohne kommerzielle Interessen.
Freifunk steht allen Interessierten, sowohl als Nutzer als auch als Knotenbetreiber offen.

Das Projekt Freifunk beschäftigt sich nicht nur mit technischen Fragen sondern bietet vielmehr auch einen Raum für soziale Vernetzung und Austausch.
Inhalt der Veranstaltung soll, neben einer kurzen Vorstellung, ein offener Gedankenaustausch über das Projekt und die Aspekte der Teilhabe an Kultur und Bildung im Digitalen Zeitalter sein

[[Kategorie:Konferenzen]]

Andrenarchy: IPB hinzugefügt

= Standort Lützowstr./IPB =

== Allgemein ==
* Adresse: [http://www.openstreetmap.org/?mlat=52.501963&mlon=13.369141&zoom=18&layers=M Lützowstr. 105, 10785 Berlin]
* Ansprechpartner: [[User:andrenarchy|andrenarchy]]
* Aktuell in Planung, d.h. noch nicht in Betrieb!
* Vielen Dank an [http://ipb.de/ IPB]!
* [http://zoom.it/bYTq Panorama vom Dach in Richtung Süden/Osten, Übersicht, 29.04.2013]
* [http://zoom.it/kgLL Panorama vom Dach in Richtung Norden/Westen, Übersicht, 29.04.2013]
* [http://zoom.it/tndZ Panorama vom Dach in Richtung Süden/Osten, gezoomt, 29.04.2013]
* [http://zoom.it/ai1h Panorama vom Dach in Richtung Norden/Westen, gezoomt, 29.04.2013]

Sven-ola: /* Aktueller Stand */

= Berliner VPN-Server (2013) =

Ende 2011 / Anfang 2012 hat der Verein freie Netze e.V. auf seiner Jahreshauptversammlung beschlossen einen VPN-Server für alle Freifunker anzubieten. Der Verein ist vom Status her Access-Provider und es war Konsens, dass wir diesen Status nutzen wollen um die Störerhaftungs-Problematik für alle diejenigen zu entschärfen, die Internet auf ihren Freifunk-Routern anbieten wollen.

Eine einfachere Anleitung für den TP-Link TL-WR741ND ist [[Tutorial_TL-WR741ND|hier]].

= Personen =

Hardware-Admin: Daniel

Server-VM-Admin: Wulf

OpenVPN-Implementation: Sven-Ola

Rechtliches (DSE): Puck152

Org/Verein: JuergeN

Weitere Admins / Supporter / Mitmacher: Yves, André, Nico, Phillip

= Technik =

Wir haben eine VM, die unter vpn03.berlin.freifunk.net erreichbar ist. Dort ist ein OpenVPN installiert. Eingehende Pakete werden in das Internet weitergeroutet. Wir haben 64 IP-Adressen für diesen Zweck. OpenVPN-Konfigs und Schlüssel zum Testen gibt es derzeit über interne E-Mail-Kommunikation.

= Aktueller Stand =

Der Server ist aktuell im Aufbau. Bekannte Fehler sind:

* Das auf dem VPN-Server aktive Zapp-Script kann nicht so gut mit dem Multi-IP-Outgoing umgehen. Die Filesharing-Erkennungs-Rate ist deutlich zu niedrig.

* Das autoipv6node auf der aktuellen PBerg funktioniert. Inkl. HNA6 ::/0. Seltsamerweise. Ich hab' was gegen Dinge die normalerweise nicht funktionieren es dann aber plötzlich doch tun. To be determined.

* Das hier ist ein SPOF. Es braucht mindestens einen weiteren VPN-Server.

= FAQ =

* Ungewöhnlich viele Verbindungen zu verschiedenen Rechnern -> Zwangsproxy(4h).

* Kein NAT auf den Tunneln, sonst Zwangsproxy für alle Router-Nutzer zusammen.

* NAT passiert grundsätzlich auf dem VPN-Gateway. Outgoing IP aus einem Pool.

* Rückroute über Tunnel gibt es automatisch wenn eine Incoming-IP entdeckt wird.

* Generell: IPs (auch DHCP-IPs) nur aus 104.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12.

* Doppelte IPs vermeiden (sonst togglen die Rückrouten). Berlin -> IPVergabe(104).

* Tunnel sind nicht (nur) für Road-Warrior, sondern für Router mit ganzen Mesh-Netzen dahinter.

* Schlüssel nur einmal gleichzeitig verwendbar. Neuer Router-mit-Internet, neuer Schlüssel. Wenn die OpenVPN-Verbindung alle Minute beendet und wieder aufgebaut wird ist höchstwahrscheinlich der Schlüssel durch eine andere OpenVPN-Instanz benutzt.

* Tipp: VPN-Server hostet Opkg's (OpenVPN+SSL) für OpenWRT-Router mit wenig Platz. Beispiel-Script siehe unten.

* Wenn gleichzeitig andere VPNs betrieben werden sollen (z.B. [http://bbb-vpn.berlin.freifunk.net]) braucht es eine manuell gesetzte Host-Route für den zweiten VPN-Server. Andernfalls wird der Datenverkehr des zweiten VPNs über das Internet-VPN erfolgen. Das funktioniert, ist aber langsam und sollte nicht sein.

= Konfig empfangen =

'''Vorbemerkung''': Konfigs gibt es im Moment auf persönliche Anfrage von mir (Sven-Ola).

Für eine Konfig brauchen wir eine (deine) E-Mail-Adresse als "Kümmerer-Kontakt" und einen Tunnel-Namen. Der Tunnel-Name muss auf dem VPN03-Server eindeutig sein und sollte den Tunnel beschreiben, z.B. vdsl-fraktion-die-mitte-rathaus-wetterberg. Dann wird ein Script angeworfen, dass ein OpenVPN-Client-Konfig erzeugt. Diese bekommst du per E-Mail zurück. Die E-Mail-Adresse ist außerdem Teil der Konfiguration - die E-Mail-Adresse ist auch im Klient-Zertifikat hinterlegt. Mit der E-Mail-Adresse können wir später mal wenn z.B. der Dienst umzieht oder eine allgemeine Konfigurationsänderung ansteht mit allen Kontakt aufnehmen. Mit dem Tunnelnamen identifiziert sich der Router bzw. der OpenVPN-Klient beim Server. Ein Zusammenhang zwischen übertragenen Daten und E-Mail-Adresse bzw. Tunnelnamen wird auf dem VPN-Server nicht gespeichert.

Wenn du also eine Konfiguration bekommst, ist diese in einem *.tgz-Archiv enthalten. Darin sind folgende Dateien enthalten ("tunnel-test" wurde als Tunnelname angegeben):

{| class="wikitable"
!Datei
!Erläuterung
|-
|freifunk-ca.crt
|Diese Datei beweist, dass die ausgegebenen *.crt / *.key vom OpenVPN-Server stammen. Ist wie ein Pubkey, darf also gerne veröffentlicht werden.
|-
|freifunk_tunnel-test-android.p12
|Das ist ein Experiment mit IPSec. Diese Datei kann in den Android / Windows-Keystore importiert werden um damit L2TP oder XAuth-VPN-Verbindungen anzulegen. Das mit dem IPSec ist allerdings grausam zu konfigurieren, fehlerbehaftet und der entsprechende Daemon ("racoon") ist derzeit ausgeschaltet. Kennwort für diese Datei ist "freifunc".
|-
|freifunk_tunnel-test.crt freifunk_tunnel-test.key
|Diese Dateien enthalten den Klient-Schlüssel und eine Echtheitsbestätigung desselben. Diese Dateien bitte nicht veröffentlichen.
|-
|freifunk_tunnel-test-tcp.ovpn
|Konfigurationsdatei für eine sichere Verbindung. Diese Konfiguration nur im Ausnahmefall verwenden, z.B. aus dem unsicheren Ausland heraus oder wenn du dem DSL-Provider nicht traust.
|-
|freifunk_tunnel-test-udp.ovpn
|Konfigurationsdatei für eine schnelle unverschlüsselte Verbindung. Diese Konfiguration im Regelfall verwenden. Die OpenWRT-Router sind nicht so schnell und Verschlüsselung kostet CPU und damit Übertragungsbandbreite.
|-
|readme.txt
|Kurztext zur Erläuterung
|}

Für einen ersten Test kannst du das *.tgz auspacken und gleich verwenden. Unter Android in /sdcard/openvpn/ auspacken und mit OpenVPN-Settings-App verwenden (braucht "root"). Unter Windows in C:\Progra~1\OpenVPN\Config auspacken und mit der OpenVPN-GUI-App verwenden (braucht "Administrator"). Unter Linux irgendwohin auspacken und mit "sudo openvpn --config *-udp.ovpn" starten (braucht "sudo").

= Router einrichten =

Die nachfolgende Anleitung ist für die aktuelle PBerg-Freifunk-Firmware (Backfire oder Attitude). Für die uralte Freifunk-Firmware mit Kernel 2.4 siehe weiter hinten ([[#Uralte_Firmware]]).

== Firmware flashen ==

Ich habe noch einen ganz normalen TP-Link WR1043ND v1. Den werde ich jetzt mal als OpenVPN-Client einrichten.

Zunächst einmal die Software besorgen. Gibt es unter http://firmware.pberg.freifunk.net/attitude_adjustment/ genauer http://firmware.pberg.freifunk.net/attitude_adjustment/12.09/ar71xx/openwrt-ar71xx-generic-tl-wr1043nd-v1-squashfs-factory.bin herunterladen.

Ich brauche noch eine Freifunk-IP. http://berlin.freifunk.net/ aufrufen. Schöne neue Seite, aber wo ist die IP-Vergabe? Gut, dass ich noch http://ip.berlin.freifunk.net im Gedächtnis habe. "Neue IP" wählen, Postleitzahl eingeben und ausgegebene IP aufschreiben: "104.198.0.108". Ich brauch noch weitere IPs für DHCP. Ich wünsch mir 16 Stück, hintereinander angefangen bei einer durch 16 teilbaren letzten Nummer. In der IP-Vergabe also 16 mal klicken und die Wunsch-IPs registrieren (104.198.108.32-47 oder auch "sipcalc 104.198.108.32/28").

'''Hinweis''': Bitte nicht weniger als 16 wegen Klickfaul. Bei einem /29 mit 8 IP-Adressen ist eine Netzadresse, eine Router-Adresse, eine Broadcast-Adresse und eine Reserve-Adresse (LuCI-Foo) enthalten. Also nur 4 DHCP-Clients. Die sind schnell alle belegt, weil die Leute den Rechner zuklappen ohne den DHCP-Lease freizugeben. Symptom: "Hilfe, ich bekomme keine IP-Adresse per DHCP".

Dann eine Ethernet-Leitung an einen der LAN-Anschlüsse des Routers anschließen. Das andere Ende in meinen PC. Stromversorgung herstellen und lange auf den Reset-Taster des Routers drücken (mit Kugelschreiber). Warten bis die LEDs blinken. Unter http://192.168.1.1/ mit admin/admin taucht nun die grüne Standard-Oberfläche des Routers auf.

System-Tools: Firmware-Upgrade aufrufen und mit der *.bin-Datei die Firmware aktualisieren. Nach Abschluss taucht das blaue "Freifunk" Willkommen unter http://192.168.1.1/cgi-bin/luci auf.

== Freifunk Assistent ==

Als nächstes den Freifunk-Assistenten durchlaufen lassen. Der macht die grundsätzliche Einrichtung.

Dazu auf [Essentials] klicken und mit leerem Kennwort auf [Anmelden]. Die Passwort-Änderungs-Aufforderungen ignoriere ich, denn das macht gleich der Menüpunkt "Freifunk: Freifunk-Assistent". Das Assistenten-Formular gewissenhaft ausfüllen:

* Passwort, Bestätigung, Community="Freifunk Berlin", Name="sven-ola-ovpn", Standort="Zuhause", E-Mail eingeben.

* RADIO0 aktivieren, Kanal 10 auswählen, Mesh IP (104.198.0.108), RADIO0-DHCP aktivieren, die RADIO8-Mesh-DHCP-IP auf 104.198.108.32/28, Virtuellen AP aktivieren, eine SSID für den VAP eingeben (sven-ola-ovpn.freifunk.net).

* Ui! Sogar der Openstreetmap-Link geht heute. Dann wähle ich auch meine Geo-Position aus ;-)

* Dann noch "Eigenen Internetzugang freigeben" aktivieren. Und meist auch die Optionen "WAN-Zugriff auf Gateway beschränken" und "Zugriff vom WAN auf auf das Geraet erlauben" einschalten.

* Jetzt noch die LAN-IP von 192.168.1.1 auf 192.168.108.1 ändern, denn ich will später den WAN-Anschluss an meinen Internet-Router anschließen und der hat zufällig auch 192.168.1.1.

* Und [Absenden]

Danach darf ich ein bisschen am LAN meines PCs spielen, bis die neue LAN-IP akzeptiert ist und ich auf http://192.168.108.1/ eine Anzeige bekomme.

Jetzt gucken wir mal mit der Kommandozeile. Mit "ssh-keygen -R 192.168.108.1;ssh root@192.168.108.1" die Kommandozeile des Routers aufrufen. Wenn alles funktioniert hat und andere Freifunk-Router in Reichweite sind zeigt "ip r" eine ordentliche Liste und "ping 151.1.1.1" sagt: wir haben Netz.

Das mit dem Netz ist schön, aber ich hab' ein Sonderproblem. Ich will den neuen Router über WAN an das Internet anschließen. Ich hab' aber kein DSL, nur Freifunk. Wenn der neue Router jetzt auch "Internet anbietet" wird mein Standard-Internet-Router einen schönen Kreis bauen. Ich mache also das Mesh auf dem neuen Router absichtlich kaputt:
<pre>uci show wireless
uci set wireless.@wifi-iface[1].bssid=02:CA:FF:EE:DE:AD
uci commit
exec reboot</pre>

Jetzt die Netzwerk-Leitung vom neuen Router (WAN) in das Internet stecken (LAN eines anderen Routers, z.B. ein DSL-Router). Ich benutze auf meinen PC die Wireless-Konfiguration um mich mit "sven-ola-ovpn.freifunk.net" zu verbinden.

In diesem Drahtlos-Netz hat der neue Router eine andere IP: 104.198.108.33. Auf meinem PC rufe ich die Router-Kommandozeile auf mit: "ssh root@104.198.108.33". Wieder "ping 151.1.1.1" um zu prüfen, ob das Internet am WAN-Port ankommt. "ip r" zeigt an, dass dies funktioniert (default via 192.168.1.1 dev eth0.2, alles fein).

== OpenVPN einrichten ==

Jetzt noch diese OpenVPN-Geschichte. Es gibt zwar ein passendes Paket für die Firmware (siehe "opkg update;opkg list|grep -i openvpn"). Aber das Start-Skript dafür hat noch nie ordentlich funktioniert und die angebotene LuCI-OpenVPN-Konfigurationsoberfläche verwirrt mich. Mein TP-Link 1043 hat zwar ordentlich Platz im Flash, aber das hier soll ja auch für billigere Router mit wenig Platz laufen. Ich nehme also das RAM-Disk-Startscript (siehe [[#OpenWRT_Startscript]]). Damit es einfach wird, hab' ich es als *.ipk zusammengepackt und auf dem Freifunk-Download-Server abgelegt.

Auf dem Router ausführen:
<pre>opkg update
opkg install kmod-tun
opkg install http://download.berlin.freifunk.net/sven-ola/vpn03/vpn03-install-to-ramdisk_all.ipk</pre>

Die per E-Mail erhaltene Konfigurations-Archivdatei sende ich von meinen PC auf den Router. Auf dem PC "scp freifunk_tunnel-test.tgz root@104.198.108.33:/tmp/" ausführen.

Auf dem Router das OpenVPN-Verzeichnis anlegen, die Konfigurationsdatei entpacken und die UDP-Konfiguration durch umbenennen aktivieren:
<pre>mkdir /etc/openvpn
cd /etc/openvpn
tar xzf /tmp/freifunk_tunnel-test.tgz
mv freifunk_tunnel-test-udp.ovpn freifunk_tunnel-test-udp.conf</pre>

Dann den Router neu starten ("exec reboot"). Nach dem Neustart noch einmal auf den Router verbinden (PC: "ssh root@104.198.108.33") und fragen, ob sich etwas tut: "logread && logread -f". Irgend etwas geht immer schief, also schau einfach auf die Meldungen. Hilfreich sind sicher auch die Hinweise unter [[#OpenWRT_Startscript]] und [[#Troubleshooting]].

Tante Google fragen, ob wir jetzt "drin" sind. http://www.google.de/search?q=my+ip und irgendwas auswählen. Zeigt eine IP aus "77.87.49.*" und "Foerderverein Freie Netzwerke".

'''Tipp''': wenn es so gar nicht will und "ping" etwas mit "administrative prohibited" ausgibt: da ist eine Nervseite. Die will beantwortet werden!

== Firewall einrichten ==

'''Hinweis''': mit der Installation des OpenWrt-Startscript-Paketes sind die folgende Schritte bereits durchgeführt.

Jetzt fehlt noch die Firewall-Integration für die Freifunk-Firmware. Das erfordert ein paar Eingriffe in die unter /etc/config gespeicherte Konfiguration. Zunächst legen wir mal ein Interface für den Tunnel an:
<pre>uci set network.vpn03=interface
uci set network.vpn03.ifname=tun0
uci set network.vpn03.proto=none
uci commit</pre>

Dann die Nummer der "Freifunk"-Zonen-Definition heraussuchen und zum Schlüssel "network" das neue Interface hinzufügen:
<pre>uci show firewall|grep @zone|grep name # zeigt zone[1]
uci set firewall.@zone[1].network="vpn03 $(uci get firewall.@zone[1].network)"
uci commit</pre>

Irgendwas im LuCI mogelt noch ein "tunl0" in die Firewall-Zone hinein. Das OpenVPN-Interface heisst jedenfalls "tun0". K.A. wozu tunl0 gut ist, aber ich lass' es einfach drin.

Eigentlich sollte das Folgende nicht nötig sein, aber doppelt hält besser. Dass der Freifunk-Router alles hinter WAN als "böse" ansieht und dagegen eine Firewall hat ist ja gut und schön. Aber in vielen Fällen ist hinter WAN das Wohnzimmer-Netzwerk des freundlichen Menschen, der sein Internet via DHCP zur Verfügung stellt. Dieses Wohnzimmer-Netzwerk für alle Gäste zu öffnen ist nicht nett. Das werden viele so machen. Und falls es Fehler in Freifunk-Assistenten gibt, kann dies hier nicht schaden:
<pre>uci add firewall rule
uci set firewall.@rule[-1].name=Disallow-Private
uci set firewall.@rule[-1].src=freifunk
uci set firewall.@rule[-1].dest=wan
uci set firewall.@rule[-1].dest_ip=192.168.0.0/16
uci set firewall.@rule[-1].proto=all
uci set firewall.@rule[-1].family=ipv4
uci set firewall.@rule[-1].target=REJECT
uci commit</pre>

== Gimmiks ==

Die Kneipe, in der Router später stehen soll, hat eine Homepage. Außerdem nervt die Nervseite alle Stunde, das ist deutlich zu kurz. Alle Tage reicht auch:
<pre>uci set luci_splash.general.leasetime=23
uci set freifunk.community.homepage=http://provinz-berlin.de/
uci commit</pre>

Auf einigen Routern wird die per DHCP erlangte Default-Route am WAN-Port hin und wieder gelöscht. K.A. warum. Mit folgendem Hack (eine statische Route auf den VPN-Server) kann man das überschreiben:
<pre>uci add network route
uci set network.@route[-1].interface=wan
uci set network.@route[-1].target=77.87.48.10
uci set network.@route[-1].netmask=255.255.255.255
uci set network.@route[-1].gateway=192.168.1.1
uci commit</pre>

Natürlich hätte ich auch gerne IPv6. Und eine Ankündigung, dass über diesen Router IPv6-Internet zu haben ist (Test: "ping6 ipv6.google.com"). Eigentlich ganz einfach: es muss evt. eingeschaltet werden. Habe nicht ganz kapiert, wieso es funktioniert (die Internet-Gateway-Erkennung ist arg selbständig) aber es funktioniert: <pre>uci set autoipv6node.olsr_node.enable=1
uci commit</pre>

Und wenn ich mal Zeit habe, schreib' ich noch was zur Konfiguration eines zweiten Tunnels (viele haben http://bbb-vpn.berlin.freifunk.net) und wie man den Gateway-Owner per Policy-Routing vom Tunnel ausnimmt (geht für den Eigentümer schneller).

== Uralte Firmware ==

Bei der uralten Freifunk-Firmware für WRT54G hat die "full"-Version das OpenVPN bereits an Bord und es gibt auf den Admin-Seiten entsprechende Konfigurationsformulare. Allerdings kann die Verschlüsselung mit den Einstellungen der Weboberfläche nicht ausgeschaltet werden.

Wir behelfen uns mit einem kleinen Hack. Die OpenVPN-Konfigurationsdateien werden ja bei Start des Routers aus NVRAM-Einstellungen heraus erzeugt. In die Einstellung "Remote" der Konfigurationsseite OpenVPN, OpenVPN2, OpenVPN3 usw. kann man auf der Kommandozeile zusätzliche Optionen einschmuggeln. Diese Einstellung entspricht ff_ovpn_remote, ff_ovpn_remote2, ff_ovpn_remote3 usw. die wir mit folgendem Befehl auf der Kommandozeile ändern: <pre>nvram set ff_ovpn_remote="vpn03.berlin.freifunk.net 1194
cipher none
comp-lzo no
port" commit</pre>

'''Hinweis''': Die Weboberfläche reicht den Zeilenumbruch nicht korrekt weiter. Änderst du die Einstellungen auf der entsprechenden OpenVPN-Seite der Web-Oberfläche, musst du den obigen Befehl ein weiteres mal ausführen.

= OpenWRT Startscript =

OpenVPN ist prima, aber OpenWRT lässt auf manchen Routern nicht genug Platz um die benötigten Programme und Bibliotheken zu installieren. Etwas Entspannung bringt OpenVPN+PolarSSL, ist aber immer noch über 1Mb groß. Ein typisches Beispiel ist der TP-LINK TL-WR741ND: 4 Mb Flash, 32 Mb RAM, preiswert, gern genommen.

Für diese Geräte gibt es ein Start-Script, mit dem ein Internet-Tunnel über OpenVPN zuverlässig betrieben werden kann. Dabei werden die benötigten *.ipk-Dateien beim Router-Start vom VPN-Server per SCP heruntergeladen und in die RAM-Disk installiert. Das Startscript steht außerdem FYI auf der Diskussions-Seite [[Diskussion:Vpn03]]. Und so geht es:<pre>opkg update
opkg install kmod-tun
opkg install http://download.berlin.freifunk.net/sven-ola/vpn03/vpn03-install-to-ramdisk_all.ipk</pre>

Das war es schon. Wenn der Router Internet über $(uci get network.wan.ifname) hat und es eine Datei /etc/openvpn/*.conf gibt sollte das beim nächsten Reboot starten. Wenn es nicht auf Anhieb funktioniert, hier ein paar Tipps. Das Script kann man manuell starten: "/etc/init.d/vpn03 debug". Es lädt Dateien für die installierte OpenWRT-Version herunter. OpenVPN-2.2.x-OpenSSL. Und wenn das Kommando "ip" und ein IPv6-Kernel-Modul vorhanden sind auch das neuere OpenVPN-2.3-PolarSSL. Beim ersten Herunterladen der *.ipk werden auf dem Router MD5-Prüfsummen gespeichert, so dass bei späteren Router-Neustarts auch wirklich die gleichen Dateien installiert werden.

'''Note''': Der DNS-Name vpn03.berlin.freifunk.net liefert eine IPv6 und eine IPv4-Adresse. Das SCP-Programm (Dropbear) versucht erst ein Download über IPv6, was regelmäßig nicht klappt und fällt dann zu IPv4 zurück. Darum kann es bis zu 30 Sekunden dauern, bis ein einzelner Download über SCP startet.

'''Tipp''': Nebenbei wird auch ein "tcpdump" mit installiert. Sowie 2 kleine Test-Scripts "test.sh" und "tst.sh", mit der man die Geschwindigkeit zu alten und neuen Freifunk-Firmware-Routern testen kann (10 Sekunden-Downloads aus /dev/zero). "tcpdump -ni wlan0 icmp" und "ping 151.1.1.1" sind freundliche Befehle die Dir helfen können.

'''Frage''': Warum SCP?

Antwort: nicht alle Firmwares haben wget und auf dem VPN-Server gibt es keinen Web-Server.

'''Frage''': Warum vom VPN-Server?

Antwort: Wenn der VPN-Server nicht erreichbar ist braucht es auch keine OpenVPN-Software. Selbst wenn man sich die Default-Route mit OpenVPN verfummelt hat: der VPN-Server sollte immer erreichbar sein (z.B. über die Host-Route auf den VPN-Server, die OpenVPN beim Start setzt). Zudem wechselt der Inhalt der Pberg-Paket-Repositories recht häufig und die MD5-Prüfsummen stimmen dann nicht mehr. Darum stehen die *.ipk auf dem VPN-Server.

'''Frage''': Ich brauch kein tcpdump. Kann das weg?

Antwort: Klar. Lösch' es einfach aus der Liste, die steht am Anfang von /etc/init.d/vpn03

'''Frage''': Für welche OpenWRT-Versionen geht das?

Antwort: auf dem Server sind *.ipk für 12.9 (Attitude, ar71xx/atheros/x86 usw.), 10.3.1 und 10.3.2 (Backfire, nur ar71xx) hinterlegt.

'''Frage''': Was soll diese Extra-Firewall-Regel mit "uci get network.wan.ifname" im Startscript? Oder: woher kommt ein "daemon.err openvpn: write UDPv4: Operation not permitted (code=1)" im "logread"?

Antwort: Internet gibt's auf den Routern oft auf kunterbunten Wegen (mithin: von irgendwo). Dieses Paket ist für Leute mit DSL-Anschluss an WAN. Wenn das Internet über ein anderes Gateway im Mesh-Netzwerk zur Verfügung gestellt wird und dein Router "Internet hier!" ankündigt gibt es eine nette Kreisroute und nichts funktioniert. Wenn also dein DSL mal ausfällt, soll das OpenVPN auf deinem Router eben gerade ''nicht'' irgend ein anderes Internet-Gateway verwenden (siehe auch [[#Troubleshooting]]).

= Stapelzertifikate =

Bei Diskussionen rund um Ausfallsicherheit und Migration bestehender VPN-Server kam die Frage auf, ob Stapelzertifikate (engl. Stacked Certificates) mit OpenVPN laufen. Das funktioniert sowohl mit der OpenSSL-basierten OpenVPN-Variante als auch mit PolarSSL-Variante.

Hintergrund: wir möchten beispielsweise einen zweiten OpenVPN-Server nutzen, der immer dann verwendet wird wenn der erste OpenVPN-Server mal ausfällt. Damit das funktioniert, müssen beide Server den Verbindungswunsch eines Clients akzeptieren. Man hat also entweder genau eine zentrale Stelle, die RSA-Keys herausgibt (wieder ein SPOF). Oder man macht etwas mit Haupt-CA und Unter-CA (kompliziert, fehleranfällig). Am einfachsten wäre es, wenn ein Server einfach Keys von Dritten akzeptiert. Und das geht mit Stapelzertifikaten.

Und so geht es (Server):

* Du nimmst die unter der "ca" Option angegeben *.crt zweier Server.

* Einfach zusammenkopieren: "cat erster-ca.crt zweiter-ca.crt > stacked-ca.crt".

* Die "ca" Option in der Serverkonfiguration anpassen.

Und jetzt noch einmal (Client):

* In den erhaltenen Konfigurationen für zwei OpenVPN-Server sind ja *-ca.crt enthalten.

* Auch hier die CA-Zertifikate zusammenkopieren "cat a-ca.crt b-ca.crt > stacked-ca.crt".

* Dann noch die "ca" Option in der Clientkonfiguration auf die neue Datei anpassen.

Das war es schon. Und das beste: die CA-Zertifkate kann man einfach veröffentlichen. Da ist nichts geheimes enthalten, die entsprechenden Dateien sind in jeder Client-Konfiguration enthalten (unseres steht hier [http://download-master.berlin.freifunk.net/sven-ola/vpn03/freifunk-ca.crt]). Auf dem Server müsste mal allerdings überlegen, von wem bzw. welche CA-Zertifikate man akzeptieren bzw. hinzufügen will.

= IPv6 =

Der VPN-Server hat IPv6; im Moment als 6-to-4, damit ist er unter 2002:4d57:300a:ffff::1/48 zu erreichen. Außerdem ist das derzeit aktuelle OpenVPN-2.3.0 installiert, genauer eine Version mit den "dynamic-iroute"-Patch aus [http://sven-ola.dyndns.org/repo/]. Damit sind folgende Dinge möglich:

* Transport über IPv6: OpenVPN-Clients können zu Vpn03 über <nowiki>remote 2002:4d57:300a:ffff::1 1194 udp6</nowiki> (UDP) oder <nowiki>remote 2002:4d57:300a:ffff::1 443 tcp6</nowiki> verbinden.

* Transport von IPv6: der Transport von IPv6-Paketen über einen Tunnel ist ab OpenVPN-2.3.0 offizielles Feature. OpenVPN-Clients erhalten eine IPv6-Adresse und eine IPv6-Default-Route auf dem Tunnel-Interface. Das Tunnel-Interface selbst erhält 2002:4d57:300a:fffe::xxxx (UDP) bzw. 2002:4d57:300a:fffd::xxxx (TCP), die genaue IPv6-Adresse wird von OpenVPN-Server aufsteigend vergeben. Die "dynamic-iroute" Mechanik (siehe oben) greift auf bei IPv6.

'''Hinweis''': Wenn eine ältere OpenVPN-Version auf dem Client noch keinen Transport von IPv6 kennt, gibt es ein paar Warnungen bei der Einwahl und es wird kein IPv6 verwendet. Bei Debian / Ubuntu sind die IPv6-Patches seit längeren enthalten, bei OpenWRT derzeit nur in den Entwicklerversionen (Paketname enthält MD5 Prüfsumme).

== MAP66 ==

Kommen wir zum beliebten Spiel "welches Prefix hätten Sie gern heute". Wie man IPv6-Prefixe über wechselnde Internet-Gateways an Nodes im Mesh verteilt ist Gegenstand von Debatten und Basteleien. ULA ("private IPv6") und IP6IP6-Tunneleien waren zumindest bis jetzt heiße Kandidaten. Funktioniert leider alles nicht zuverlässig, auch wenn es hier und da laufende IPv6-Inseln in unseren Mesh-Netzwerken geben soll.

Deshalb gibt es auf dem VPN03-Server eine zusätzlich nutzbare Adressumsetzung. Das ist eine Art "stateless NAT", mithin eine Mechanik zum Umsetzen von intern verwendeten Prefixen auf das "offizielle" Prefix des VPN-Servers. Eine nähere Erläuterung findet sich hier: [http://sourceforge.net/projects/map66/] (Code / README.html lesen).

== Prefixe ==

Auf einem Freifunk-Router kann ein beliebiges Prefix verwendet werden (aus 2000::/3 oder fc00::/7), solange als untere 64 Host-Bits ::0 bis ::fff verwendet wird. Außerdem darf die ULA fdca:ffee:babe::/48 verwendet werden. Dies müsste sowohl für die alte Berliner-Freifunk-Firmware (ULA mit fdca:ffee:babe:0000:macaddr-aus-stateless-autoconfig) als auch die neuere PBerg-Firmware (IPv6 je nach Default-Gateway N des nächsten Nachbars mit zufälligem X-aus-65536 aber manuellen Hostbits ::1, also nnnn:nnnn:nnnn:xxxx::1/64) passen.

'''Achtung''': wenn nur ein Gateway in Eurem Mesh-Netzwerk über Vpn03 geleitet wird, sind möglicherweise alle IPv6-fähigen Freifunk-Router aus dem Internet heraus erreichbar. Zumindest theoretisch, wenn man die IPv6-Adressarithmetik beherrscht. Je nachdem, wie die Freifunk-Router die Konfiguration angeschlossener PCs machen evt. sogar die Windows / MACs / Androiden dahinter. Ich überlege noch, ob da ein paar Firewall-Regeln auf dem Gateway nötig wird, z.B. Beschränkung eingehender Verbindungen auf Port 22 (SSH) und Port 80 (http). Kommt darauf an, ob die üblicherweise eingesetzten Firmware IPv6-Firewall-Regeln wirksam einsetzen oder nicht. MAP66 hat außerdem Privacy-Issues, jedenfalls funktioniert use_tempaddr (IPv6-Privacy-Extensions, siehe [http://www.google.de/search?q=ipv6+privacy+extensions]) damit nicht so ohne weiteres.

== IPv6 over IPv6 ==

Der OpenVPN-Tunnel zum Server kann auch über IPv6 aufgebaut werden (also: OpenVPN-Transport über IPv6). Dazu ist der DNS-Name des Servers (vpn03.berlin.freifunk.net) mit einem passenden AAAA-Eintrag versehen (2002:4d57:300a:ffff::1). Das funktioniert mit udp6 (Port 1194) und tcp6 (Port 443). Leider gibt es mit IPv6 kein Port-Forwarding, daher funktionieren die mit IPv4 nutzbaren Ausweich-Ports (UDP-53 bzw. TCP-80) nicht mit IPv6.

Außerdem unterstützt OpenVPN ab Version 2.3.0 zwar IPv6, aber es gibt mit IPv6 keine Option "Setze Host-Route zum OpenVPN-Server bevor die Default-Route geändert wird". Wenn also sowohl IPv6-Transport als auch IPv6-im-Tunnel verwendet wird, würde sich ein Client die IPv6-Verbindung zum VPN-Server sozusagen selbst wegkonfigurieren, indem er seine Default-Route auf den Tunnel setzt. Um dies zu verhindern, wird der VPN03-Server in diesem Fall eine ganze Menge IPv6-Routen setzen. Genauer: alle IPv6-Routen bis auf die IPv6-Route zum VPN03-Server. Nur falls sich wer wundert, das sieht dann auf einem Client so aus:

<pre>
/sbin/ip -6 addr add 2002:4d57:300a:fffe::1000/64 dev tun0
add_route_ipv6(2002:4d57:300b::/48 -> 2002:4d57:300a:fffe::1 metric -1) dev tun0
add_route_ipv6(2002:4d57:3008::/47 -> 2002:4d57:300a:fffe::1 metric -1) dev tun0
add_route_ipv6(2002:4d57:300c::/46 -> 2002:4d57:300a:fffe::1 metric -1) dev tun0
add_route_ipv6(2002:4d57:3000::/45 -> 2002:4d57:300a:fffe::1 metric -1) dev tun0
add_route_ipv6(2002:4d57:3010::/44 -> 2002:4d57:300a:fffe::1 metric -1) dev tun0
add_route_ipv6(2002:4d57:3020::/43 -> 2002:4d57:300a:fffe::1 metric -1) dev tun0
add_route_ipv6(2002:4d57:3040::/42 -> 2002:4d57:300a:fffe::1 metric -1) dev tun0
add_route_ipv6(2002:4d57:3080::/41 -> 2002:4d57:300a:fffe::1 metric -1) dev tun0
add_route_ipv6(2002:4d57:3100::/40 -> 2002:4d57:300a:fffe::1 metric -1) dev tun0
add_route_ipv6(2002:4d57:3200::/39 -> 2002:4d57:300a:fffe::1 metric -1) dev tun0
add_route_ipv6(2002:4d57:3400::/38 -> 2002:4d57:300a:fffe::1 metric -1) dev tun0
add_route_ipv6(2002:4d57:3800::/37 -> 2002:4d57:300a:fffe::1 metric -1) dev tun0
add_route_ipv6(2002:4d57:2000::/36 -> 2002:4d57:300a:fffe::1 metric -1) dev tun0
add_route_ipv6(2002:4d57::/35 -> 2002:4d57:300a:fffe::1 metric -1) dev tun0
add_route_ipv6(2002:4d57:4000::/34 -> 2002:4d57:300a:fffe::1 metric -1) dev tun0
add_route_ipv6(2002:4d57:8000::/33 -> 2002:4d57:300a:fffe::1 metric -1) dev tun0
add_route_ipv6(2002:4d56::/32 -> 2002:4d57:300a:fffe::1 metric -1) dev tun0
add_route_ipv6(2002:4d54::/31 -> 2002:4d57:300a:fffe::1 metric -1) dev tun0
add_route_ipv6(2002:4d50::/30 -> 2002:4d57:300a:fffe::1 metric -1) dev tun0
add_route_ipv6(2002:4d58::/29 -> 2002:4d57:300a:fffe::1 metric -1) dev tun0
add_route_ipv6(2002:4d40::/28 -> 2002:4d57:300a:fffe::1 metric -1) dev tun0
add_route_ipv6(2002:4d60::/27 -> 2002:4d57:300a:fffe::1 metric -1) dev tun0
add_route_ipv6(2002:4d00::/26 -> 2002:4d57:300a:fffe::1 metric -1) dev tun0
add_route_ipv6(2002:4d80::/25 -> 2002:4d57:300a:fffe::1 metric -1) dev tun0
add_route_ipv6(2002:4c00::/24 -> 2002:4d57:300a:fffe::1 metric -1) dev tun0
add_route_ipv6(2002:4e00::/23 -> 2002:4d57:300a:fffe::1 metric -1) dev tun0
add_route_ipv6(2002:4800::/22 -> 2002:4d57:300a:fffe::1 metric -1) dev tun0
add_route_ipv6(2002:4000::/21 -> 2002:4d57:300a:fffe::1 metric -1) dev tun0
add_route_ipv6(2002:5000::/20 -> 2002:4d57:300a:fffe::1 metric -1) dev tun0
add_route_ipv6(2002:6000::/19 -> 2002:4d57:300a:fffe::1 metric -1) dev tun0
add_route_ipv6(2002::/18 -> 2002:4d57:300a:fffe::1 metric -1) dev tun0
add_route_ipv6(2002:8000::/17 -> 2002:4d57:300a:fffe::1 metric -1) dev tun0
add_route_ipv6(2003::/16 -> 2002:4d57:300a:fffe::1 metric -1) dev tun0
add_route_ipv6(2000::/15 -> 2002:4d57:300a:fffe::1 metric -1) dev tun0
add_route_ipv6(2004::/14 -> 2002:4d57:300a:fffe::1 metric -1) dev tun0
add_route_ipv6(2008::/13 -> 2002:4d57:300a:fffe::1 metric -1) dev tun0
add_route_ipv6(2010::/12 -> 2002:4d57:300a:fffe::1 metric -1) dev tun0
add_route_ipv6(2020::/11 -> 2002:4d57:300a:fffe::1 metric -1) dev tun0
add_route_ipv6(2040::/10 -> 2002:4d57:300a:fffe::1 metric -1) dev tun0
add_route_ipv6(2080::/9 -> 2002:4d57:300a:fffe::1 metric -1) dev tun0
add_route_ipv6(2100::/8 -> 2002:4d57:300a:fffe::1 metric -1) dev tun0
add_route_ipv6(2200::/7 -> 2002:4d57:300a:fffe::1 metric -1) dev tun0
add_route_ipv6(2400::/6 -> 2002:4d57:300a:fffe::1 metric -1) dev tun0
add_route_ipv6(2800::/5 -> 2002:4d57:300a:fffe::1 metric -1) dev tun0
add_route_ipv6(3000::/4 -> 2002:4d57:300a:fffe::1 metric -1) dev tun0
add_route_ipv6(::/3 -> 2002:4d57:300a:fffe::1 metric -1) dev tun0</pre>

= Troubleshooting =

Irgendwas geht immer schief. Damit es bei dir klappt, sind hier ein paar typische Fehlermeldungen und Lösungsvorschläge aufgeschrieben. Wenn du das [[#OpenWRT_Startscript]] verwendest einfach mal mit "/etc/init.d/vpn03 debug" starten.

'''Meldung''': write UDPv4: Operation not permitted (code=1)

OpenVPN beschwert sich, dass die Firewall keine Verbindung zum VPN-Server zulässt. Du hast einen konfigurierten WAN-Port, die Internet-Verbindung läuft aber über eine andere Schnittstelle. Lösung: Um z.B. die LAN-Schnittstelle anzugeben führe aus: "/etc/init.d/vpn03 inetvia br-lan". Um die Firewall-Regel zur Verhinderung der Nutzung irgendeines Mesh-Gateways komplett auszuschalten führe aus: "/etc/init.d/vpn03 inetvia disable"

'''Meldung''': VERIFY ERROR: depth=1, error=certificate is not yet valid

Das Datum auf deinem Router stimmt nicht. Ohne Echtzeituhr starten die Geräte mit 1.1.1970. Die Zertifikate und Keys wurden aber alle nach Ende November 2012 erstellt. Lösung: baue in deine Startscripts folgendes ein: "if [ $(date +%s) -lt $(date -d 2012.12.01-00:00:0000000000 +%s) ];then date -s 2012.12.01-00:00:0000000000;fi".

'''Meldung''': Authenticate/Decrypt packet error: cipher final failed

OpenVPN verwendet eine Verschlüsselung, der VPN03-Server verwendet auf UDP aber keine Verschlüsselung. Lösung: Die fehlende Optionen "cipher none" und evt. auch "comp-lzo no" in deiner OpenVPN-Konfiguration ergänzen.

'''Meldung''': SIGUSR1[soft,ping-restart] received, process restarting (alle Minute)

Der lokale OpenVPN startet regelmäßig neu, wenn die Verbindung zum VPN03-Server nicht funktioniert. Das kann viele Ursachen haben. Es ist aber auch möglich dass derselbe Client-Schlüssel gleichzeitig noch auf einem anderen Router / Rechner verwendet wird.

'''Meldung''': Keine, aber es geht kein Ping durch den Tunnel

OpenVPN verwendet die LZO-Kompression, der VPN03-Server verwendet auf UDP aber keine Kompression. Lösung: Die fehlende Option "comp-lzo no" in deiner OpenVPN-Konfiguration ergänzen.

'''Meldung''': Keine, aber der Tunnel ist zu langsam (nur 100 kByte/sek. bzw. 1 Mbit/s oder so).

Das ist noch nicht ganz 'raus woran das liegen könnte. Aber der Tunnel sollte auf einem Standard-Router etwa 600-900 kByte/sek. übertragen. Evt. hast du die QoS-Scripts in Betrieb: "uci show qos|grep enable". Wenn da "qos.wan.enabled=1" angezeigt wird, musst du auch die Geschwindigkeit deines DSL-Anschlusses korrekt angeben, etwa "uci set qos.wan.upload=10000;uci set qos.wan.download=50000;uci commit" für eine 50Mbit-VDSL.

'''Note''': Geht nicht schneller[http://www.cse.wustl.edu/~jain/cse567-08/ftp/ovpn/index.html], da das OpenVPN auf dem Router alle Daten user-to-kernel kopieren muss und die Kernel-basierten Tunnelsachen (IPSec und co.) einfach zu kompliziert und fehleranfällig sind. Der VPN-Server hat jedenfalls mind. 10000 kByte/sek bzw. 100 Mbit/s.

= Admin Howto =

Soso. Wir haben dich zum Admin des VPN03-Servers gemacht. Du hast die DSE-Schulung mitgemacht und die entsprechende DSE-Erklärung ist unterschrieben und beim Verein abgeheftet. Du hast also ein Benutzer-Account und kannst dich mit deinen Pubkey per SSH verbinden. Der Befehl "sudo bash" klappt auch. Dann helfen dir die folgenden Zeilen.

== Neue Konfig ==

Es kommt jemand auf dich zu und möchte eine Konfiguration. Frage zunächst nach dem Freifunk-Zusammenhang. Akzeptierte Nutzungen sind z.B. Router in Kneipen & Kaffeestuben. Oder jemand stellt seine DSL-Leitung für eine Freifunk-Wolke zur Verfügung. Wir sind nicht der VPN-Dienstleister für alle, die für sich privat einfach nur ein Umsonst-Account haben wollen. Die schickst du weiter zu Relakks & Co, z.B. Tante Google fragen welcher VPN-Dienstleister Barzahlung / Bitcoins o.ä. akzeptiert. Gibt es sicher mittlerweile auch Werbefinanziert und auf Basis von Youtube-QRCode-In-Video-Übertragungen. Das hier ist ein "Besser schlafen"-Dienst für Freifunker.

Jedenfalls brauchst du einen Tunnelnamen (muss eindeutig sein, Länge etwa 10-30 Zeichen, keine Leerzeichen, keine Sonderzeichen). Ort und Gelegenheit wären schön, z.B. schalander-kneipe-in-bad-schandau wär' ein guter Tunnelname. Dann brauchst du noch eine E-Mail-Adresse. Am besten von der Person die sich um den Router kümmert. Also nicht info@stadt-schandau.de sondern jana.lustig@coldmail.com. Jetzt kann eine Konfiguration erzeugt werden: <pre>
sudo bash
openvpn-build-key schalander-kneipe-in-bad-schandau jana.lustig@coldmail.com
cd /etc
git add --all
git commit</pre>

Der letzte Befehl führt zu einem Editor-Fester, wo ein Kommentar für das /etc-Commit eingegeben wird. Drücke [i] für Einfügemodus des VI-Editors, tippe etwas ähnliches wie "Sven-Ola: neuer Schlüssel für Bad Schandau" und schieße das ganze mit [Esc]:wq ab. Eine automatische E-Mail-Sendefunktion steht auf der Todo-Liste. Bis dahin muss die Konfigurationsdatei manuell gesendet werden. Rufe auf <pre>cp /etc/openvpn/clients/freifunk_schalander-kneipe-in-bad-schandau.tgz ~/</pre>

Das kopiert die nur für den Root-User zugreifbare Konfigurationsdatei in dein Home-Verzeichnis. Von da aus kannst du die *.tgz auf deinen Rechner übertragen und per E-Mail an Frau Lustig senden.

'''Bemerkung''': Frau Lustig hat evt. einen Bart, trägt Sonnenbrille und macht sich Sorgen um die Verwendung der E-Mail-Adresse. Wir wollen bei technischem Ärger einen Admin-C, z.B. für "Festplattencrash auf dem VPN-Server. 1 Woche Downtime, prepare for Impact - bitte Spende für die neue Platte wenn es geht". Es geht nicht darum, die Einstweilige des beleidigten Bürgermeisters durchzusetzen der möglicherweise letztes Jahr einen Tweet empfangen hat und der angeblich über irgend einen Freifunk-Router gesendet wurde. Ein Zusammenhang zwischen Einzelnutzerdatenübertragungen und der E-Mail-Adresse kann auf dem VPN03-Server wenn überhaupt nur in Echtzeit hergestellt werden. Das muss Frau Lustig uns schon glauben, dafür machen wir das mit den mehreren Admins und der DSE.

== Schlüssel sperren ==

Die Sache mit dem Router in Bad Schandau ist vorbei. Der Wirt hatte keine Lust mehr, der Schlüssel wurde im letzen Jahr nicht benutzt und Frau Lustig meldet sich und sagt "bitte Löschen". Leider kann man einmal erzeugte Private-Keys nicht löschen. Aber man kann die Keys für ungültig erklären. Dafür gibt es eine CRL (Certificate Revoke List).

Dazu musst du dich auf dem VPN03-Server anmelden. Gib die folgenden Befehle ein: <pre>sudo bash
openvpn-revoke-crl schalander-kneipe-in-bad-schandau</pre>

'''Hinweis''': Der OpenVPN-Daemon muss jetzt nicht neu gestartet werden. Die CRL tritt sofort in Kraft. Wenn die VPN-Verbindung aktuell besteht wird der OpenVPN-Daemon spätestens bei der nächsten Verbindungsaufnahme den Schlüssel ablehnen.

== Systempflege ==

Die Software auf dem VPN03-Server ist ein gut abgehangenes Debian-Linux. Da muss nicht viel geupdated werden, außerdem macht das üblicherweise Wulf Coulmann. Aber sagen wir mal es ist ein fürchterliche Software-Lücke im OpenVPN entdeckt worden und weder Wulf noch Sven-Ola sind greifbar. Normalerweise würde man einfach warten, bis es aktualisierte Debian-Pakete gibt und die Sache mit einem "apt-get update;apt-get upgrade" aus der Welt schaffen.

Es gibt aber zwei Pakete auf dem VPN03-Server, die sind "spezial": freifunk-openvpn und map66-dkms. Die Quellen dazu sind u.a. in /usr/src/ abgelegt. Wahlweise tut es ein einfaches "apt-get -b source freifunk-openvpn" in deinem HOME-Verzeichnis um eins der beiden Spezialpakete zu kompilieren. Damit kann im Notfall ein Patch eingebaut werden und das so reparierte Paket mit "dpkg install xxx.deb" und /etc/init.d/openvpn restart" integriert werden. "Bescheid sagen" wär' natürlich hilfreich. Diese beiden Spezial-Pakete werden jedenfalls in meinem Privat-Repo gehostet, dazu findest du eine Datei unter /etc/apt/sources.list.d, etwa <pre>sven-ola@vpn03:~$ cat /etc/apt/sources.list.d/sven-ola.list
deb http://sven-ola.dyndns.org/repo squeeze main
deb-src http://sven-ola.dyndns.org/repo squeeze main
</pre>

Wo ich gerade bei "Spezial" bin. Das Freifunk-OpenVPN ist ein ganz normales OpenVPN-2.3.x mit dem zusätzlichen "dynamic-iroute" Feature, dass den Routing-Daemon-losen Betrieb erlaubt. Das MAP66 ist ein Kernel-Modul zur Umsetzung von IPv6-Präfixen (siehe für beides auch [[#IPv6]]). Das ganze ist mit /etc/openvpn/*.conf, /etc/openvpn/mark-and-change-snat-ip, /etc/rc.local und /etc/network/interfaces konfiguriert. In diesen Konfigurationsdateien ist auch sowohl die Client-IP-zu-Outgoing-SNAT-IP-Mechanik als auch die fdca:ffee:babe:: zu Globally-valid-6to4 Prefix-Umsetung zu finden.

Die SNAT-Mechanik sieht etwa so aus. Beim Start des OpenVPN-Daemons wird ein Script ausgeführt, das folgendes enthält: <pre>sven-ola@vpn03:~$ grep -- -A /etc/openvpn/mark-and-change-snat-ip
iptables -t mangle -A PREROUTING -i ${dev} -j IPMARK --addr src --and-mask 0x3f --or-mask 0x1000</pre>

Da könnte man später auch mal ein "xor $RANDOM" einbauen, dass einmal die Woche wechselt. Jedenfalls gibt es eine IPTables-Regel, die die so markierten hereinkommenden Pakete dann auf die offiziellen IPv4-Adressen des Servers umsetzt: <pre>sven-ola@vpn03:~$ sed -n 24,29p /etc/rc.local
iptables -t nat -F POSTROUTING
for net in 104.0.0.0/8 10.0.0.0/8 172.16.0.0/12;do
for ip in $(seq 0 1 63);do
iptables -t nat -A POSTROUTING -o ${INET_DEV} -s ${net} -m mark \
--mark $(( 0x1000 + ${ip} )) -j SNAT --to 77.87.49.${ip}
done
done</pre>

Das mit der IPv6-Adress-Umsetzung ist etwas komplizierter. Zusammenfassend übersetzen die vielen "--u32"-Matches in /etc/rc.local die ULA fdca:ffee:babe::/48 auf die 6to4 2002:4d57:3100::/48 des tun64b-Interfaces und umgekehrt. Außerdem werden alle IPv6-IPs, die auf ::0001 bis ::0fff enden auf die 6to4 2002:4d57:300a::/48 des tun64a-Interfaces übersetzt (einfaches Swap obere 64 gegen untere 64 Bits, ist sogar Prüfsummen-neutral). Das kann sich ändern, wenn wir ein "offizielles" Not-6to4 IPv6-Präfix vom IN-Berlin erhalten. Im Moment jedenfalls ist die Sendeanbindung über die Anycast ::192.88.99.1 ausreichend schnell.

== Die Sache mit dem ZAPP ==

Auf dem VPN03-Server ist ein Script /usr/local/sbin/freifunk-zapp, welches über einen Cronjob jede Minute ausgeführt wird. Das Script liest die /proc/net/ip_conntrack und zählt / bewertet, wieviele Verbindungen zu wieviel verschiedenen Rechnern ein Client im Moment hat. Wenn die Zählung einen Wert über einen gewissen Schwellwert ergibt werden Maßnahmen ergriffen, den wahrscheinlich auf dem Client "vergessenen" Hintergrund-Bittorrent-Client zu blocken.

Eine weitere Mechanik des ZAPP-Skripts funktioniert derzeit nicht ausreichend. Wenn gerade ein Bittorrent o.ä. aktiv ist, dann kommen jede Menge unbestellte Verbindungsanfragen von irgendwo draußen herein. Das sind die "bekomme ich auch was" Anfragen der Torrent-Wolke. In diesem Zeitfenster kann man die Empfindlichkeit / den Schwellwert für das Blockieren heruntersetzen. Das muss mit der MARK-and-SNAT-Mechanik (siehe oben) und dem evt. noch einzubauenden XOR $Random verknüpft werden.

Jedenfalls: solange dieser Server den Status "im Aufbau" hat, speichere ich die blockierten IP-Adressen in /var/log/zappfile.txt zur späteren Untersuchung. Ich will wissen, wieviele und warum es mögliche "False Positives" gibt. Das muss natürlich weg, spätestens wenn wir den Status "Offizieller Echtbetrieb" haben.

'''Tipp''': Den aktuellen Blockier-Status kannst du als Admin mit "freifunk-zapp status" abfragen. Mit "freifunk-zapp unblock 10.1.2.3" kann man eine blockierte IPv4-Adresse manuell freigeben. "freifunk-zapp help" gibt eine kurze Hilfe aus.

...To be continued...

Andrenarchy: typos

= Standort FluxFM =

== Allgemein ==
* Adresse: [http://www.openstreetmap.org/?mlat=52.502867&mlon=13.441027&zoom=18&layers=M Pfuelstr. 5, 10997 Berlin]
* Ansprechpartner: [[User:andrenarchy|andrenarchy]]
* noch nicht in Betrieb
* [http://zoom.it/nuFZW Panorama vom Dach, Übersicht, 19.04.2013]
* [http://zoom.it/UmXX Panorama vom Dach, gezoomt, 19.04.2013]
* [http://zoom.it/pZKl Panorama von Terasse, Übersicht, 19.04.2013]
* [http://zoom.it/VxJ0 Panorama von Terasse, gezoomt, 19.04.2013]

Cven:

'''(Bitte gibt uns einen Hinweis, wenn du kein Fleisch isst.)'''

# Jamalaka ([[Freifunk_Luebeck|Freifunk Lübeck]]), fleischfrei
# mwarning (Freifunk Bielefeld)
# Bodems (Freifunk Bielefeld)
# Basti ([[Freifunk_Weimar|Freifunk Weimar]])
# Simon ([[Freifunk_Weimar|Freifunk Weimar]], http://guerillamesh.net/)
# Andi ([[Freifunk_Weimar|Freifunk Weimar]])
# nbd (OpenWrt)
# [[Benutzer:andrenarchy|andrenarchy]] (Freifunk Berlin), fleischfrei
# [[Benutzer:cven|cven]] (Freifunk Berlin) c-base
# ZioPRoTo Saverio (Ninux.org)
# Bernd ([[Freifunk_Weimar|Freifunk Weimar]])
# blogic (OpenWrt)
# jow (OpenWrt)
# KanjiMonster (OpenWrt)
# p4u (qMp, CONFINE)
# Nico (Altermundi)
# Gui (Altermundi)
# Axel (BMX, CONFINE)
# G10h4ck Gioacchino ( eigenLab.org / Ninux.org )
# Aero ( eigenLab.org )
# Luke ( eigenLab.org )
# lynxis (c-base)
# dtaht (bufferbloat.net)
# kaleng (kbu.freifunk.net)
# rampone (kbu.freifunk.net)
# yanosz (kbu.freifunk.net)
# [[Benutzer:JuergeN|JuergeN]] (Freifunk [Berlin])
# stargieg (Freifunk [Berlin])
# soma (Freifunk Augsburg), kein Fleisch
# T_X ([[Freifunk_Luebeck|Freifunk Lübeck]]), fleischfrei
# Berik ([[Freifunk_Luebeck|Freifunk Lübeck]])
# Ufo (Freifunk Leipzig), fleischarm
# Reto, Frankfurt - fleischfrei
# Mario, Berlin - fleischarm
# Hong Phuc, Vietnam - fleischarm
# [[User:Keksdosenmann|Keks]], Berlin, Germany, [[Freifunk Berlin BNO|Freifunk Berlin NordOst]] - meet the meat
# [[User:Sidd|Sidd]] aka kinolux - FF Berlin, Leipzig

[[Kategorie:Freifunk-Community]]
[[Kategorie:Konferenzen]]
{{Navigationsleiste Wireless Community Weekend}}

RubenKelevra: Die Seite wurde neu angelegt: „{{TabBar Freifunk_Firmware_Gluon}} {{SubTabBar Freifunk Firmware Gluon/Gateway}} {{In Bearbeitung}}“

{{TabBar Freifunk_Firmware_Gluon}}

{{SubTabBar Freifunk Firmware Gluon/Gateway}}

{{In Bearbeitung}}

RubenKelevra:

{{TabBar Freifunk_Firmware_Gluon}}

{{SubTabBar Freifunk Firmware Gluon/Gateway}}

{{In Bearbeitung}}

Das InterCity-VPN ist ein Netzwerk zwischen den verschiedenen Communitys, es verbindet Lokale Dienste mit allen anderen Städten, so dass diese aus jeder Stadt erreichbar sind.

Für das InterCity-VPN werden [[Tinc]] und [[Bird]] verwendet.

== Registrierung ==

== Einrichtung ==

Zuerst muss eine AS-Nummer im Artikel [[AS-Nummern]] registriert werden. Danach eine IP im 10.207.0.0/16er Netz im Artikel [[IC-VPN#BGP_Einrichten|IC-VPN]].

AS-Nummer ist <tt>$ASNummer</tt>, IP ist <tt>$IC-VPN-IP</tt>.

Wir erstellen den Ordner für die Tinc-Konfiguration:

{{ic|# mkdir -p /etc/tinc/icvpn/hosts}}
{{ic|cd /etc/tinc/icvpn}}
{{ic|touch tinc.conf tinc-{down,up} hosts/$Stadt1}}

{{hc|nano hosts/$Stadt1|<nowiki>Name = $Stadt11
PrivateKeyFile = /etc/tinc/icvpn/rsa_key.priv
Mode = Switch
PingTimeout = 30
Port = 655
Hostnames=yes
Device = /dev/net/tun
ConnectTo = berlin1 //example
ConnectTo = berlin2 //example</nowiki>}}

{{hc|nano tinc-down|#!/bin/sh
# This file closes down the tap device.
ifconfig $INTERFACE down}}

RubenKelevra: Die Seite wurde neu angelegt: „{{TabBar Freifunk_Firmware_Gluon}} {{SubTabBar Freifunk Firmware Gluon/Gateway}} {{In Bearbeitung}}“

{{TabBar Freifunk_Firmware_Gluon}}

{{SubTabBar Freifunk Firmware Gluon/Gateway}}

{{In Bearbeitung}}

RubenKelevra: Die Seite wurde neu angelegt: „{{TabBar Freifunk_Firmware_Gluon}} {{SubTabBar Freifunk Firmware Gluon/Gateway}} {{In Bearbeitung}}“

{{TabBar Freifunk_Firmware_Gluon}}

{{SubTabBar Freifunk Firmware Gluon/Gateway}}

{{In Bearbeitung}}

RubenKelevra: Die Seite wurde neu angelegt: „{{TabBar Freifunk_Firmware_Gluon}} {{SubTabBar Freifunk Firmware Gluon/Gateway}} {{In Bearbeitung}}“

{{TabBar Freifunk_Firmware_Gluon}}

{{SubTabBar Freifunk Firmware Gluon/Gateway}}

{{In Bearbeitung}}

RubenKelevra: Die Seite wurde neu angelegt: „{{TabBar Freifunk_Firmware_Gluon}} {{SubTabBar Freifunk Firmware Gluon/Gateway}} {{In Bearbeitung}}“

{{TabBar Freifunk_Firmware_Gluon}}

{{SubTabBar Freifunk Firmware Gluon/Gateway}}

{{In Bearbeitung}}

RubenKelevra:

{{TabBar fnetstat}}

'''fnetstat''' ist ein Diagnose-Werkzeug, und ein Statistik-Tool mit dem Freifunk-Router überwacht werden und eine Statistik komprimiert und verschlüsselt an definierte Server übertragen kann. Es ist in Shell-Script geschrieben.

In der Standardkonfiguration wird das Script menütlich mit dem Parameter {{c|cronjob}} gestartet. Dieses sammelt die statistischen Daten im /tmp-Verzeichnis. In per Konfiguration definerten Intervallen werden diese Informationen bzip2-Komprimiert und auf den Server per SCP übertragen.

Einmal täglich werden statische Daten wie die Position, eine Kontaktadresse und diverse Hard- und Softwareparameterzusätzlich erfasst und an den Server übertragen.

Das Script lässt sich ebenfalls ohne den Parameter aufrufen um einen Status des Systems zu erhalten.

Es wird von [[Benutzer:RubenKelevra|RubenKelevra]] entwickelt, das Reposition befindet sich [https://github.com/FF-NRW/fnetstat hier].

RubenKelevra: /* dns */

{{TabBar Freifunk_Firmware_Gluon}}

{{SubTabBar Freifunk Firmware Gluon/Gateway}}

{{In Bearbeitung}}

== Annahmen für diese Anleitung ==
* Netzwerkinterface des Servers <tt>$eth</tt> z.B. eth0.
* Servername als <tt>$Servername</tt> z.B. alpha
* Die IP von <tt>$eth</tt> ist <tt>$PublicIP</tt> z.B. 1.2.3.4
* Stadt ist <tt>$Stadt</tt> z.B. [[Freifunk Musterstadt|Musterstadt]]
* Kürzel der Stadt ist <tt>$sd</tt> z.B. MS für Musterstadt
* [[IP-Netze|IP-Bereich]] ist <tt>$IPBereich</tt> z.B. <tt>16</tt>
* Subnetzmaske ist <tt>$SubnetzMaske</tt> z.B. <tt>255.255.0.0</tt>
*NBetzadresse ist <tt>$Netzaddresse</tt> z.B. <tt>10.0.0.0</tt>
* IP vom Gateway <tt>$GatewayIP</tt> ist z.B. <tt>10.0.0.1</tt>
* MAC vom Gateway-Interface im Freifunk ist <tt>e6:64:e1:dd:e8:60</tt><br>Generiert mit [[Freifunk Firmware Gluon/MAC-Generator|MAC-Generator]]
* IPv6 Netz ist <tt>$IPv6NET</tt> z.B. <tt>fd11:1111:1111:1234::</tt>
* IPv6 ULA ist <tt>$IPv6ULA</tt> z.B. <tt>fd11:1111:1111:1234::/64</tt>

== Installation der Software ==

Nach der Installation von Arch-Linux nach der [https://wiki.archlinux.de/title/Anleitung_f%C3%BCr_Einsteiger#Teil_1:_Installation_des_Grundsystems Anleitung in der Arch-Linux-Wiki] wird die, für das Gateway benötigte Software, installiert.

{{ic|# pacman -S iproute2 base-devel net-tools bird bird6 dhcp radvd bind openvpn haveged bridge-utils tinc}}
{{ic|yaourt -S fastd batctl batman-adv netcfg}}

== Konfiguration ==

=== fastd ===

Wir erstellen einen Benutzer für fastd<br>
{{ic|# useradd --system --no-create-home --shell /bin/false fastd}}

Wir erstellen eine Konfigurationsdatei für <tt>fastd</tt> <br>
{{ic|# mkdir -p /var/log/fastd/}}
{{ic|# mkdir -p /etc/fastd/$Stadt/}}
{{ic|# cd /etc/fastd/$Stadt/}}

Secret-Key erstellen und den Secret xxx speichern wir in der Datei secret.conf.<br>
{{ic|# fastd --generate-key}}
{{hc|# nano secret.conf|secret "xxx"; # Das Secret von 'fastd --generate-key'}}

fastd.conf erstellen:<br>
{{hc|# nano fastd.conf|bind $PublicIP:10000; # UDP Port 10000 der IP $PublicIP
mode tap; # TAP ist Layer2, TUN waere Layer3
interface "ff$sd-mesh-vpn";
log to syslog level info;
log to "/var/log/fastd/$Stadt-vpn.log" level debug;
user "fastd";
method "xsalsa20-poly1305"; # Verschluesselungsalgorithmus festlegen
include "secret.conf";
mtu 1426;

include peers from "peers";

on up "
ip link set address <mac> up dev $INTERFACE

batctl -m mesh-$sd if add $INTERFACE
";}}
Die MAC-Adresse generieren wir mit dem [[Freifunk Firmware Gluon/MAC-Generator|MAC-Generator]].

Wir legen nun das Verzeichnis peers an, und werden die öffentlichen Schlüssel dort ablegen.<br>
{{ic|# mkdir peers}}

nun erstellen wir dort die Datei mit dem Dateinamen des $Servername und tragen dort unseren Server ein:<br>
{{hc|# nano peers/$Servername|key "yyy"; #public key
remote ipv4 "server.$Stadt.freifunk.net" port 10000;}}

Zum automatischen Start wird fastd nun noch per systemctl aktiviert:

{{ic|# systemctl enable fastd@$Stadt}}

=== BATMAN ===

Wir fügen der Datei <tt>modules.conf</tt> das Batman-Modul an.<br>
{{ic|# echo 'batman-adv' >> /etc/modules-load.d/modules.conf}}

=== network.d ===

Nun kümmern wir uns um die Netzwerkgeräte die wir für unser Gateway benötigen. Zuerst definieren wir für eth0 eine fixe IP, damit diese nicht beim booten per DHCP bezogen werden muss. Die IP von eth0, sowie die Subnetzmaske finden wir per <tt>ifconfig</tt>, das Gateway per <tt>route</tt>.

{{hc|# nano /etc/network.d/eth0|<nowiki>CONNECTION='ethernet'
DESCRIPTION='A basic static ethernet connection using iproute'
INTERFACE='eth0'
IP='static'
ADDR='xx.xx.xx.xx'
NETMASK='nn'
GATEWAY='xx.xx.xx.xx'
DNS=('8.8.8.8', '8.8.4.4')

## For IPv6 autoconfiguration
#IP6=stateless

## For IPv6 static address configuration
#IP6='static'
#ADDR6=('1234:5678:9abc:def::1/64' '1234:3456::123/96')
#ROUTES6=('abcd::1234')
#GATEWAY6='1234:0:123::abcd'</nowiki>}}

Nun deaktivieren wir den DHCP-Client Daemon mit einem der beiden folgenden Kommandos:

{{ic|# systemctl disable dhcpcd}}

{{ic|# systemctl disable dhcpcd@eth0}}

{{hc|# nano /etc/network.d/freifunk-$sd|<nowiki>INTERFACE='freifunk-$sd'
CONNECTION='bridge'
DESCRIPTION='freifunk-$sd bridge'
FWD_DELAY=0

IP='static'
//mit $Netzaddresse ersetzen
IPCFG=("link set down address e6:64:e1:dd:e8:60 dev $INTERFACE"
"addr add $GatewayIP/$IPBereich broadcast x.x.255.255 dev $INTERFACE"
"addr add $IPv6NETc01/64 dev $INTERFACE" "link set up dev $INTERFACE")</nowiki>}}

{{hc|# nano /etc/network.d/mesh-$sd|<nowiki>CONNECTION='ethernet'
DESCRIPTION='mesh-$sd'
INTERFACE='mesh-$sd'

PRE_UP=("ip link set address e6:64:e1:dd:e8:60 dev $INTERFACE")

IP='static'
IPCFG=("addr flush dev $INTERFACE")
POST_UP=("brctl addif freifunk-$sd $INTERFACE")
PRE_DOWN=("brctl delif freifunk-$sd $INTERFACE || true")</nowiki>}}

Zusätzlich erstellen wir noch zwei andere benötigte Dateien:

{{hc|# nano /etc/systemd/system/netcfg-freifunk@.service|<nowiki>[Unit]
Description=Freifunk mesh networking service for interface %I
BindsTo=sys-subsystem-net-devices-%i.device

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/bin/netcfg check-iface %I
ExecStop=-/usr/bin/netcfg down %I
KillMode=none</nowiki>}}

{{hc|# nano /etc/udev/rules.d/99-freifunk-netcfg-auto.rules|<nowiki>ACTION=="remove", GOTO="netcfg_auto_end"

SUBSYSTEM=="net", KERNEL=="mesh-$sd", TAG+="systemd", ENV{SYSTEMD_WANTS}+="netcfg-freifunk@mesh\x2dwk.service"

LABEL="netcfg_auto_end"</nowiki>}}

Nun müssen wir noch Konfigurieren welche Interfaces gestartet werden sollen.

{{hc|# nano /etc/conf.d/netcfg|<nowiki># Enable these netcfg profiles at boot time.
# Network profiles are found in /etc/network.d
NETWORKS=(eth0 freifunk-$sd)

# Specify the name of your wired interface for net-auto-wired
#WIRED_INTERFACE="eth0"

# Specify the name of your wireless interface for net-auto-wireless
#WIRELESS_INTERFACE="wlan0"</nowiki>}}

{{ic|# systemctl enable netcfg}}

Durch die beiden Dateien wird das Netzwerkinterface mesh-ms immer wenn es nötig ist neu konfiguriert.

Es sollte nun ff<tt>$sd</tt>-mesh-vpn in <tt>ifconfig</tt> erscheinen.

=== dhcp ===

Wir erstellen eine Konfiguration für den ISC-DHCP-Server:

{{hc|# nano /etc/dhcpd.conf|# configuration for server.$Stadt.freifunk.net

ddns-update-style none;

# options
server-identifier server;
ignore client-updates;

# security options
deny declines;
one-lease-per-client true;

#ignore network boot requests
ignore bootp;

default-lease-time 600;
max-lease-time 3600;

authoritative;

log-facility local7;

# $Stadt.freifunk.net subnet and dhcp range for server

subnet $Netzaddresse netmask $SubnetzMaske {
range x.x.0.2 x.x.5.255; //mit $Netzaddresse ersetzen
option broadcast-address x.x.255.255; //mit $Netzaddresse ersetzen
option routers $GatewayIP;
option domain-name "server.town.freifunk.net";
option domain-name-servers $GatewayIP;
option ntp-servers $GatewayIP;
interface freifunk-$sd;
}

#example

#host examplehost {
# hardware ethernet 28:00:02:8D:44:22;
# fixed-address x.x.0.24; //mit $Netzaddresse ersetzen
# option host-name "examplehost";
#}}}

Zum automatischen Start wird dhcpd nun noch per systemctl aktiviert:

{{ic|# systemctl enable dhcpd4}}

=== radvd ===

{{hc|# nano /etc/radvd.conf|interface freifunk-$sd #$Stadt
{
AdvSendAdvert on;
IgnoreIfMissing on;
MaxRtrAdvInterval 200;

prefix $IPv6ULA
{
};

RDNSS $IPv6NETc01
{
};
};}}

Zum automatischen Start wird radvd nun noch per systemctl aktiviert:

{{ic|# systemctl enable radvd}}

=== iptables ===

Hiermit leiten wir alle Pakete aus den Freifunkinterfaces in eine eigene Routingtabelle, die Tabelle 42, um. Dort kann dann eine andere Defaultroute als in der Systemroutingtabelle verwendet werden.

{{hc|# nano /etc/systemd/system/iprules.service|<nowiki>[Unit]
Description=ip rule
Before=network.target

[Service]
Type=oneshot
ExecStart=/usr/sbin/ip rule add from all fwmark 0x1 table 42
ExecStop=/usr/sbin/ip rule del from all fwmark 0x1 table 42
RemainAfterExit=yes

[Install]
WantedBy=network.target</nowiki>}}

Diese Regel aktivieren wir mit :

{{ic|# systemctl enable iprules.service}}


Hiermit setzen wir die Markierung bei Traffic vom Interface <tt>freifunk-$sd</tt>.

{{hc|# nano /etc/iptables/iptables.rules|*filter
:INPUT ACCEPT [11844:1916189]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [6263:1020836]
COMMIT
*mangle
:PREROUTING ACCEPT [174173:29763433]
:INPUT ACCEPT [173743:29726484]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [95448:18280029]
:POSTROUTING ACCEPT [95459:18280541]
-A PREROUTING -i freifunk-$sd -j MARK --set-xmark 0x1/0xffffffff
COMMIT
*nat
:PREROUTING ACCEPT [516:46790]
:INPUT ACCEPT [80:9421]
:OUTPUT ACCEPT [48:3433]
:POSTROUTING ACCEPT [47:3349]
-A POSTROUTING -o tun-vpn-01 -j MASQUERADE
COMMIT}}

{{ic|# systemctl enable iptables}}

Und wir aktivieren das Forwarding im Kernel in dem wir folgende Zeile auf 1 setzen.

{{hc|# nano /etc/sysctl.conf|<nowiki>net.ipv4.ip_forward = 1</nowiki>}}

=== OpenVPN ===

Erstellen eines Systembenutzers für OpenVPN:<br>
{{ic|# useradd --system --no-create-home --shell /bin/false openvpn}}

Wir erstellen eine Konfiguration für das VPN-Interface <tt>tun-vpn-01</tt>.<br>

{{hc|# nano /etc/openvpn/tun-01.conf|client
dev tun-vpn-01
dev-type tun
; Hole keine Routen vom Server
route-nopull
proto udp
user openvpn
group openvpn
remote remote.host.com portnumber
cipher AES-128-CBC
resolv-retry infinite
nobind
persist-key
persist-tun
mute-replay-warnings
ca ./tun-01.pem
verb 3
auth-user-pass ./tun-01_pass.txt
; aktivieren wenn Hoster Kompression unterstützt
; comp-lzo
reneg-sec 0
script-security 2

up ./tun-01_up.sh
down ./tun-01_down.sh}}

Wir erstellen das Up-Script:

{{hc|# nano /etc/openvpn/tun-01_up.sh|#!/bin/sh
ip route replace 0.0.0.0/1 via $5 table 42
ip route replace 128.0.0.0/1 via $5 table 42
exit 0}}

Wir benötigen kein Downscript.

Wir müssen die Up/Down-Scripte ausführbar machen:<br>

{{ic|# chmod +x /etc/openvpn/tun-01_up.sh}}
{{ic|# chmod +x /etc/openvpn/tun-01_down.sh}}

In der tun-vpn-01_pass.txt muss der Benutzername und das Passwort hinterlegt werden:<br>
{{hc|# nano /etc/openvpn/tun-01_pass.txt|user
password}}

Zum automatischen Start wird OpenVPN nun noch per systemctl aktiviert:

{{ic|# systemctl enable openvpn@tun-01}}

=== dns ===

Wir richten bind9 ein nur auf netzinterne Anfragen zu reagieren und alle anderen Anfragen zu ignorieren. Selbst definierte Domains liefert bind9 in der Konfiguration trotzdem ins Internet aus.

{{hc|# nano /etc/named.conf|<nowiki>//
// /etc/named.conf
//

options {
directory "/var/named";
pid-file "/run/named/named.pid";
auth-nxdomain yes;
datasize default;
interface-interval 0;
// Uncomment these to enable IPv6 connections support
// IPv4 will still work:
listen-on-v6 { any; };
// IPv4
listen-on { any; };
### hiermit kann das selbstständige Auflösen deaktiviert werden
#forwarders { 8.8.8.8; 8.8.4.4; };
#forward only;
###
// Default security settings.
allow-recursion { freifunk; ownserver; };
allow-transfer { none; };
allow-update { none; };
allow-query { any; };
version none;
hostname none;
server-id none;
};

acl freifunk {
127.0.0.1;
10.0.0.0/8;
172.16.0.0/12;
192.168.0.0/16;
};

acl ownserver {
#hier muss ein zweiter DNS-Server der Zugriff auf die eigenen Definitionen haben darf abgelegt werden
xx.xx.xx.xx;
};

zone "localhost" IN {
type master;
file "localhost.zone";
allow-transfer { any; };
};

zone "0.0.127.in-addr.arpa" IN {
type master;
file "127.0.0.zone";
allow-transfer { any; };
};

zone "." IN {
type hint;
file "root.hint";
};

### Beispieldefinition
#zone "ms.freifunk.net" {
# type master;
# file "ms.freifunk.net.zone";
# allow-transfer { ownserver; };
#};
#
#zone "musterstadt.freifunk.net" {
# type master;
# file "musterstadt.freifunk.net.zone";
# allow-transfer { ownserver; };
#};

logging {
channel xfer-log {
file "/var/log/named.log";
print-category yes;
print-severity yes;
print-time yes;
severity info;
};
category xfer-in { xfer-log; };
category xfer-out { xfer-log; };
category notify { xfer-log; };
};</nowiki>}}

Nun aktivieren wir unseren bind9-Server.

{{ic|# systemctl enable named}}

=== Gateway Check ===

Hiermit prüft man per Cronjob periodisch ob die OpenVPN-Verbindung funktioniert, wenn nicht startet er diese neu:

{{hc|# nano /usr/local/bin/tun-vpn-01_check.sh|<nowiki>#!/bin/bash
INTERFACE=tun-vpn-01
MESH=mesh-$sd
shopt -s nullglob

ping -q -I $INTERFACE 8.8.8.8 -c 4 -i 1 -W 5 >/dev/null 2>&1

if test $? -eq 0; then
NEW_STATE=server
else
NEW_STATE=off
fi

if [ "$NEW_STATE" == "off" ]; then
logger "try a restart of openvpn@tun-01 via systemctl"
systemctl restart openvpn@tun-01
fi

OLD_STATE="$(cat /sys/class/net/$MESH/mesh/gw_mode)"
[ "$OLD_STATE" == "$NEW_STATE" ] && exit
echo $NEW_STATE > /sys/class/net/$MESH/mesh/gw_mode
echo 96MBit/96MBit > /sys/class/net/$MESH/mesh/gw_bandwidth
logger "batman gateway mode changed to $NEW_STATE"
</nowiki>}}

Wir machen das Script wieder ausführbar:


{{ic|# chmod +x /usr/local/bin/tun-vpn-01_check.sh}}

Um dieses Script nun per Cron auszuführen muss dies konfiguriert werden:

{{hc|<nowiki># export EDITOR=nano; export VISUAL=nano; crontab -e</nowiki>|<nowiki>*/1 * * * * /usr/local/bin/tun-vpn-01_check.sh</nowiki>}}

Die OpenVPN-Verbindung wird nun jede Minuten (<tt>*/1 *</tt>) geprüft.

Wir deaktiveren noch rp_filter mittels:

{{ic|# touch /etc/sysctl.d/50-default.conf}}

Danach starten wir den Server neu.

RubenKelevra:

{{TabBar Freifunk_Firmware_Gluon}}

{{SubTabBar Freifunk Firmware Gluon/Gateway}}

{{In Bearbeitung}}

Dieser Artikel bezieht sich auf einen KVM-vServer z.B. von Netcup.

= Voraussetzungen =

* Arch Linux
* Kernel Module
* [https://wiki.archlinux.org/index.php/Yaourt yaourt]