FunkFeuer Wiki - Benutzerbeiträge [de]

OpenVPN mit Debian/Ubuntu

2018-05-25T11:21:51Z

Franzlax: /* 'the quick and dirty hack' für IPv6 */

Unter Debian installierst Du die Pakete für Openvpn und olsr.

Voraussetzungen:
* Aktuelles Debian Stable oder Ubuntu LTS
* Pakete für OpenVPN, OLSR (und OLSRv2), bridge-utils
* Funkfeuer-Login
* Funkfeuer-IPv4-Adresse für das Tunneldevice respektive die Bridge aus [[https://portal.funkfeuer.at/wien REDEEMER/FRONTEND/PORTAL]]
* Einen Taschenrechner, der Dezimalzahlen in Hexadezimalzahlen umrechnen kann („programmiertechnischer Modus“)
* 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:
** „&id=9999“ oder so
** „id_nodes=9999“.
Diese Zahl umgewandelt in „Hex“ brauchst Du später für Deine IPv6-Adresse.

* apt-get install openvpn openvpn-blacklist olsrd olsrd-plugins bridge-utils

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.

/etc/network/interfaces:
iface eth0 inet static
...
up /sbin/ip r a 78.41.118.150/32 dev eth0 via 192.168.1.1 metric 0
up /etc/init.d/openvpn restart

iface br-ff inet static
bridge_fd 0
bridge_maxwait 0
bridge_waitport 0
bridge_stp no
bridge_ports none
address [REDEEMER-IP v4]
netmask 255.255.255.255
# 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]
# Nachfolgend für 9999 NodeID 9999(10) = 270F(16); Router 1, Interface 1 mit Adresse „feed“:
post-up /sbin/ip -6 a a 2a02:60:1'''27''':'''0f'''''11''::feed/64 dev br-ff
# Wenn man die MAC-Adresse der Bridge definiert, wirkt sich das auf die IPv6 EUI64-Adresse beginnend mit fe80::/12 aus.
# Man kann sich eine zufällige MAC-Adresse [[https://www.miniwebtool.com/mac-address-generator/ MAC Address Generator]] (lowercase und ":"-Notation) errechnen lassen.
post-up ip link set dev br-ff address bc:75:33:6a:bf:cf
# Die Bridge soll allen Traffic annehmen.
post-up ip link set dev br-ff promisc on

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.

/etc/default/openvpn:
#AUTOSTART="all" ->
AUTOSTART="all"
oder
#AUTOSTART="all" ->
AUTOSTART="funkfeuer"

Somit erwartet OpenVPN seine Konfiguration in /etc/openvpn/funkfeuer.conf.

/etc/openvpn/funkfeuer.conf:
dev tap0
proto udp
remote 78.41.118.150
# Die Portnummer XXXX wird Dir zugewiesen
port XXXX
daemon tap0
persist-tun
up-delay
down-pre
up-restart
comp-lzo
script-security 2
nobind
ping 10
ping-restart 60
ping-timer-rem
fast-io
sndbuf 524288
rcvbuf 524288
mute 2
verb 0
up /etc/openvpn/funkfeuer-updown.sh
down /etc/openvpn/funkfeuer-updown.sh
secret /etc/openvpn/funkfeuer.secret
auth SHA256
cipher none

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:

/etc/openvpn/funkfeuer-updown.sh:
#!/bin/bash
# br-ff ist die Bridge aus /etc/network/interfaces
# $dev ist ein Parameter, den Openvpn übergibt. Hier zumeist „tap0“.
br="br-ff"
dev=$1
logger "openvpn: $(echo $@)"
logger "openvpn: $script_type"
case $script_type in
"down")
/sbin/brctl delif $br $dev
/sbin/ip link set link dev $dev down
;;
"route-up")
;;
"up")
/sbin/brctl addif $br $dev
/sbin/ip link set dev $br promisc on
/sbin/ip link set link dev $dev up
/sbin/ip link set link dev $br up
;;
esac
echo $(date) $script_type $br.$dev $script_type>> /tmp/br-vpn.log
exit 0

Das Skript muss ausführbar gemacht werden. chmod +x /etc/openvpn/funkfeuer-updown.sh

chmod +x /etc/openvpn/funkfeuer-updown.sh

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):

/etc/openvpn/funkfeuer.secret:
#
# 2048 bit OpenVPN static key
#
-----BEGIN OpenVPN Static key V1-----
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
-----END OpenVPN Static key V1-----

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.)

/etc/default/olsrd:
START_OLSRD="YES"
DEBUGLEVEL=0
DAEMON_OPTS="-f /etc/olsrd/olsrd.conf -d $DEBUGLEVEL"

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.) -

/etc/olsrd/olsrd.conf:
AllowNoInt yes
ClearScreen yes
DebugLevel 0
FIBMetric "flat"
IpVersion 4
LinkQualityAlgorithm "etx_ff"
LinkQualityFishEye 1
LinkQualityLevel 2
MainIp [DIE MAIN-IP BEKOMMT IHR AUS DEM FUNKFEUER PORTAL, WENN IHR EIN GERÄT (DEVICE) ANLEGT]
MprCoverage 1
Pollrate 0.1
TcRedundancy 2
TosValue 16
UseHysteresis no
Willingness 3
InterfaceDefaults
{
AutoDetectChanges yes
HelloInterval 5.0
HelloValidityTime 100.0
TcInterval 2.0
TcValidityTime 300.0
MidInterval 50.0
MidValidityTime 300.0
HnaInterval 50.0
HnaValidityTime 300.0
Ip4Broadcast 255.255.255.255
Mode "mesh"
LinkQualityMult default 0.15
Weight 99
}
Interface "br-ff"
{
AutoDetectChanges yes
LinkQualityMult default 1.0
Weight 0
}
Hna4
{
[SERVER-IP FALLS VORHANDEN - ZUWEISUNG VIA PORTAL] 255.255.255.255
}
LoadPlugin "olsrd_httpinfo.so.0.1"
{
PlParam "Port" "81"
PlParam "Net" "0.0.0.0 0.0.0.0"
PlParam "resolve" "false"
}
LoadPlugin "olsrd_txtinfo.so.1.1"
{
PlParam "port" "2006"
PlParam "accept" "127.0.0.1"
}
LoadPlugin "olsrd_jsoninfo.so.1.1"
{
PlParam "port" "9090"
PlParam "accept" "0.0.0.0"
PlParam "UUIDFile" "/etc/olsrd/olsrd.uuid"
}

Damit ist eigentlich die Arbeit getan.

=== 'the quick and dirty hack' für IPv6 ===

Für OLSR mit IPv6 gibt es noch ein paar Tricks zu wissen und noch etwas mehr Handarbeit.
Kopiere:

* /etc/default/olsrd nach /etc/default/olsrd6
** Ersetz jedes Vorkommen von olsr(d) durch olsr(d)6.

mit vim wäre das so: vom input modus in den command modus wechseln (ESC) und in der command line folgendes eingeben:

%s/olsrd/olsrd6/g

12 ersetzungen sollten stattfinden.

%s/OLSRD/OLSRD6/g

selbiges gilt für die folgenden weiteren Dateien

* /etc/init.d/olsrd nach /etc/init.d/olsrd6
** Ersetz jedes Vorkommen von olsr(d) durch olsr(d)6. Ersetze /usr/sbin/olsrd durch /etc/alternatives/olsrd6
* Setz einen Link von /usr/sbin/olsrd nach /etc/alternatives/olsrd6.

ln -s /usr/sbin/olsrd /etc/alternatives/olsrd6

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.

* Leg /etc/olsrd/olsrd6.conf an - nachfolgend ein Beispiel.

AllowNoInt yes
ClearScreen yes
DebugLevel 0
FIBMetric "flat"
IpVersion 6
LinkQualityAlgorithm "etx_ff"
LinkQualityFishEye 1
LinkQualityLevel 2
MprCoverage 1
Pollrate 0.1
TcRedundancy 2
TosValue 16
UseHysteresis no
UseNiit yes
Willingness 3
InterfaceDefaults
{
#Ip6MulticastGlobal ff0e::1
#Ip6MulticastSite ff05::11
IPv6Multicast ff02::6d
Weight 99
AutoDetectChanges yes
HelloInterval 50.0
HelloValidityTime 100.0
HnaInterval 50.0
HnaValidityTime 300.0
LinkQualityMult default 0.33
MidInterval 50.0
MidValidityTime 300.0
Mode "mesh"
TcInterval 2.0
TcValidityTime 300.0
Weight 99
}
Hna6
{
}
LoadPlugin "olsrd_httpinfo.so.0.1"
{
PlParam "Net" "0::/0 2000::/3"
PlParam "port" "82"
}
LoadPlugin "olsrd_jsoninfo.so.1.1"
{
PlParam "port" "9090"
PlParam "accept" "::"
PlParam "UUIDFile" "/etc/olsrd/olsrd6.uuid"
PlParam "ipv6only" "true"
}
Interface "br-ff"
{
AutoDetectChanges yes
LinkQualityMult default 0.25
Mode "ether"
Weight 1
IPv6Multicast ff02::6d
}

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.

Es ist auch möglich die plugin sektion ganz wegzulassen, damit eliminiert man evtl ein weiteres Problem.
diese können ja schrittweise bei funktionierender config nachträglich wieder eingefügt werden.

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.

Das war's. Dual-Stack OLSRv1 mit Tunnel läuft, sowie Du es gestartet hast.

OpenVPN mit Debian/Ubuntu

2018-05-25T11:20:46Z

Franzlax: /* 'the quick and dirty hack' für IPv6 */

Unter Debian installierst Du die Pakete für Openvpn und olsr.

Voraussetzungen:
* Aktuelles Debian Stable oder Ubuntu LTS
* Pakete für OpenVPN, OLSR (und OLSRv2), bridge-utils
* Funkfeuer-Login
* Funkfeuer-IPv4-Adresse für das Tunneldevice respektive die Bridge aus [[https://portal.funkfeuer.at/wien REDEEMER/FRONTEND/PORTAL]]
* Einen Taschenrechner, der Dezimalzahlen in Hexadezimalzahlen umrechnen kann („programmiertechnischer Modus“)
* 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:
** „&id=9999“ oder so
** „id_nodes=9999“.
Diese Zahl umgewandelt in „Hex“ brauchst Du später für Deine IPv6-Adresse.

* apt-get install openvpn openvpn-blacklist olsrd olsrd-plugins bridge-utils

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.

/etc/network/interfaces:
iface eth0 inet static
...
up /sbin/ip r a 78.41.118.150/32 dev eth0 via 192.168.1.1 metric 0
up /etc/init.d/openvpn restart

iface br-ff inet static
bridge_fd 0
bridge_maxwait 0
bridge_waitport 0
bridge_stp no
bridge_ports none
address [REDEEMER-IP v4]
netmask 255.255.255.255
# 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]
# Nachfolgend für 9999 NodeID 9999(10) = 270F(16); Router 1, Interface 1 mit Adresse „feed“:
post-up /sbin/ip -6 a a 2a02:60:1'''27''':'''0f'''''11''::feed/64 dev br-ff
# Wenn man die MAC-Adresse der Bridge definiert, wirkt sich das auf die IPv6 EUI64-Adresse beginnend mit fe80::/12 aus.
# Man kann sich eine zufällige MAC-Adresse [[https://www.miniwebtool.com/mac-address-generator/ MAC Address Generator]] (lowercase und ":"-Notation) errechnen lassen.
post-up ip link set dev br-ff address bc:75:33:6a:bf:cf
# Die Bridge soll allen Traffic annehmen.
post-up ip link set dev br-ff promisc on

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.

/etc/default/openvpn:
#AUTOSTART="all" ->
AUTOSTART="all"
oder
#AUTOSTART="all" ->
AUTOSTART="funkfeuer"

Somit erwartet OpenVPN seine Konfiguration in /etc/openvpn/funkfeuer.conf.

/etc/openvpn/funkfeuer.conf:
dev tap0
proto udp
remote 78.41.118.150
# Die Portnummer XXXX wird Dir zugewiesen
port XXXX
daemon tap0
persist-tun
up-delay
down-pre
up-restart
comp-lzo
script-security 2
nobind
ping 10
ping-restart 60
ping-timer-rem
fast-io
sndbuf 524288
rcvbuf 524288
mute 2
verb 0
up /etc/openvpn/funkfeuer-updown.sh
down /etc/openvpn/funkfeuer-updown.sh
secret /etc/openvpn/funkfeuer.secret
auth SHA256
cipher none

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:

/etc/openvpn/funkfeuer-updown.sh:
#!/bin/bash
# br-ff ist die Bridge aus /etc/network/interfaces
# $dev ist ein Parameter, den Openvpn übergibt. Hier zumeist „tap0“.
br="br-ff"
dev=$1
logger "openvpn: $(echo $@)"
logger "openvpn: $script_type"
case $script_type in
"down")
/sbin/brctl delif $br $dev
/sbin/ip link set link dev $dev down
;;
"route-up")
;;
"up")
/sbin/brctl addif $br $dev
/sbin/ip link set dev $br promisc on
/sbin/ip link set link dev $dev up
/sbin/ip link set link dev $br up
;;
esac
echo $(date) $script_type $br.$dev $script_type>> /tmp/br-vpn.log
exit 0

Das Skript muss ausführbar gemacht werden. chmod +x /etc/openvpn/funkfeuer-updown.sh

chmod +x /etc/openvpn/funkfeuer-updown.sh

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):

/etc/openvpn/funkfeuer.secret:
#
# 2048 bit OpenVPN static key
#
-----BEGIN OpenVPN Static key V1-----
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
-----END OpenVPN Static key V1-----

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.)

/etc/default/olsrd:
START_OLSRD="YES"
DEBUGLEVEL=0
DAEMON_OPTS="-f /etc/olsrd/olsrd.conf -d $DEBUGLEVEL"

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.) -

/etc/olsrd/olsrd.conf:
AllowNoInt yes
ClearScreen yes
DebugLevel 0
FIBMetric "flat"
IpVersion 4
LinkQualityAlgorithm "etx_ff"
LinkQualityFishEye 1
LinkQualityLevel 2
MainIp [DIE MAIN-IP BEKOMMT IHR AUS DEM FUNKFEUER PORTAL, WENN IHR EIN GERÄT (DEVICE) ANLEGT]
MprCoverage 1
Pollrate 0.1
TcRedundancy 2
TosValue 16
UseHysteresis no
Willingness 3
InterfaceDefaults
{
AutoDetectChanges yes
HelloInterval 5.0
HelloValidityTime 100.0
TcInterval 2.0
TcValidityTime 300.0
MidInterval 50.0
MidValidityTime 300.0
HnaInterval 50.0
HnaValidityTime 300.0
Ip4Broadcast 255.255.255.255
Mode "mesh"
LinkQualityMult default 0.15
Weight 99
}
Interface "br-ff"
{
AutoDetectChanges yes
LinkQualityMult default 1.0
Weight 0
}
Hna4
{
[SERVER-IP FALLS VORHANDEN - ZUWEISUNG VIA PORTAL] 255.255.255.255
}
LoadPlugin "olsrd_httpinfo.so.0.1"
{
PlParam "Port" "81"
PlParam "Net" "0.0.0.0 0.0.0.0"
PlParam "resolve" "false"
}
LoadPlugin "olsrd_txtinfo.so.1.1"
{
PlParam "port" "2006"
PlParam "accept" "127.0.0.1"
}
LoadPlugin "olsrd_jsoninfo.so.1.1"
{
PlParam "port" "9090"
PlParam "accept" "0.0.0.0"
PlParam "UUIDFile" "/etc/olsrd/olsrd.uuid"
}

Damit ist eigentlich die Arbeit getan.

=== 'the quick and dirty hack' für IPv6 ===

Für OLSR mit IPv6 gibt es noch ein paar Tricks zu wissen und noch etwas mehr Handarbeit.
Kopiere:

* /etc/default/olsrd nach /etc/default/olsrd6
** Ersetz jedes Vorkommen von olsr(d) durch olsr(d)6.

mit vim wäre das so: vom input modus in den command modus wechseln (ESC) und in der command line folgendes eingeben:

%s/olsrd/olsrd6/g

12 ersetzungen sollten stattfinden.

%s/OLSRD/OLSRD6/g

selbiges gilt für die folgenden weiteren Dateien

* /etc/init.d/olsrd nach /etc/init.d/olsrd6
** Ersetz jedes Vorkommen von olsr(d) durch olsr(d)6. Ersetze /usr/sbin/olsrd durch /etc/alternatives/olsrd6
* Setz einen Link von /usr/sbin/olsrd nach /etc/alternatives/olsrd6.

ln -s /usr/sbin/olsrd /etc/alternatives/olsrd6

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.
* Leg /etc/olsrd/olsrd6.conf an - nachfolgend ein Beispiel.

AllowNoInt yes
ClearScreen yes
DebugLevel 0
FIBMetric "flat"
IpVersion 6
LinkQualityAlgorithm "etx_ff"
LinkQualityFishEye 1
LinkQualityLevel 2
MprCoverage 1
Pollrate 0.1
TcRedundancy 2
TosValue 16
UseHysteresis no
UseNiit yes
Willingness 3
InterfaceDefaults
{
#Ip6MulticastGlobal ff0e::1
#Ip6MulticastSite ff05::11
IPv6Multicast ff02::6d
Weight 99
AutoDetectChanges yes
HelloInterval 50.0
HelloValidityTime 100.0
HnaInterval 50.0
HnaValidityTime 300.0
LinkQualityMult default 0.33
MidInterval 50.0
MidValidityTime 300.0
Mode "mesh"
TcInterval 2.0
TcValidityTime 300.0
Weight 99
}
Hna6
{
}
LoadPlugin "olsrd_httpinfo.so.0.1"
{
PlParam "Net" "0::/0 2000::/3"
PlParam "port" "82"
}
LoadPlugin "olsrd_jsoninfo.so.1.1"
{
PlParam "port" "9090"
PlParam "accept" "::"
PlParam "UUIDFile" "/etc/olsrd/olsrd6.uuid"
PlParam "ipv6only" "true"
}
Interface "br-ff"
{
AutoDetectChanges yes
LinkQualityMult default 0.25
Mode "ether"
Weight 1
IPv6Multicast ff02::6d
}

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.

Es ist auch möglich die plugin sektion ganz wegzulassen, damit eliminiert man evtl ein weiteres Problem.
diese können ja schrittweise bei funktionierender config nachträglich wieder eingefügt werden.

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.

Das war's. Dual-Stack OLSRv1 mit Tunnel läuft, sowie Du es gestartet hast.

OpenVPN mit Debian/Ubuntu

2018-05-25T11:17:29Z

Franzlax: /* 'the quick and dirty hack' für IPv6 */

Unter Debian installierst Du die Pakete für Openvpn und olsr.

Voraussetzungen:
* Aktuelles Debian Stable oder Ubuntu LTS
* Pakete für OpenVPN, OLSR (und OLSRv2), bridge-utils
* Funkfeuer-Login
* Funkfeuer-IPv4-Adresse für das Tunneldevice respektive die Bridge aus [[https://portal.funkfeuer.at/wien REDEEMER/FRONTEND/PORTAL]]
* Einen Taschenrechner, der Dezimalzahlen in Hexadezimalzahlen umrechnen kann („programmiertechnischer Modus“)
* 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:
** „&id=9999“ oder so
** „id_nodes=9999“.
Diese Zahl umgewandelt in „Hex“ brauchst Du später für Deine IPv6-Adresse.

* apt-get install openvpn openvpn-blacklist olsrd olsrd-plugins bridge-utils

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.

/etc/network/interfaces:
iface eth0 inet static
...
up /sbin/ip r a 78.41.118.150/32 dev eth0 via 192.168.1.1 metric 0
up /etc/init.d/openvpn restart

iface br-ff inet static
bridge_fd 0
bridge_maxwait 0
bridge_waitport 0
bridge_stp no
bridge_ports none
address [REDEEMER-IP v4]
netmask 255.255.255.255
# 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]
# Nachfolgend für 9999 NodeID 9999(10) = 270F(16); Router 1, Interface 1 mit Adresse „feed“:
post-up /sbin/ip -6 a a 2a02:60:1'''27''':'''0f'''''11''::feed/64 dev br-ff
# Wenn man die MAC-Adresse der Bridge definiert, wirkt sich das auf die IPv6 EUI64-Adresse beginnend mit fe80::/12 aus.
# Man kann sich eine zufällige MAC-Adresse [[https://www.miniwebtool.com/mac-address-generator/ MAC Address Generator]] (lowercase und ":"-Notation) errechnen lassen.
post-up ip link set dev br-ff address bc:75:33:6a:bf:cf
# Die Bridge soll allen Traffic annehmen.
post-up ip link set dev br-ff promisc on

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.

/etc/default/openvpn:
#AUTOSTART="all" ->
AUTOSTART="all"
oder
#AUTOSTART="all" ->
AUTOSTART="funkfeuer"

Somit erwartet OpenVPN seine Konfiguration in /etc/openvpn/funkfeuer.conf.

/etc/openvpn/funkfeuer.conf:
dev tap0
proto udp
remote 78.41.118.150
# Die Portnummer XXXX wird Dir zugewiesen
port XXXX
daemon tap0
persist-tun
up-delay
down-pre
up-restart
comp-lzo
script-security 2
nobind
ping 10
ping-restart 60
ping-timer-rem
fast-io
sndbuf 524288
rcvbuf 524288
mute 2
verb 0
up /etc/openvpn/funkfeuer-updown.sh
down /etc/openvpn/funkfeuer-updown.sh
secret /etc/openvpn/funkfeuer.secret
auth SHA256
cipher none

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:

/etc/openvpn/funkfeuer-updown.sh:
#!/bin/bash
# br-ff ist die Bridge aus /etc/network/interfaces
# $dev ist ein Parameter, den Openvpn übergibt. Hier zumeist „tap0“.
br="br-ff"
dev=$1
logger "openvpn: $(echo $@)"
logger "openvpn: $script_type"
case $script_type in
"down")
/sbin/brctl delif $br $dev
/sbin/ip link set link dev $dev down
;;
"route-up")
;;
"up")
/sbin/brctl addif $br $dev
/sbin/ip link set dev $br promisc on
/sbin/ip link set link dev $dev up
/sbin/ip link set link dev $br up
;;
esac
echo $(date) $script_type $br.$dev $script_type>> /tmp/br-vpn.log
exit 0

Das Skript muss ausführbar gemacht werden. chmod +x /etc/openvpn/funkfeuer-updown.sh

chmod +x /etc/openvpn/funkfeuer-updown.sh

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):

/etc/openvpn/funkfeuer.secret:
#
# 2048 bit OpenVPN static key
#
-----BEGIN OpenVPN Static key V1-----
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
-----END OpenVPN Static key V1-----

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.)

/etc/default/olsrd:
START_OLSRD="YES"
DEBUGLEVEL=0
DAEMON_OPTS="-f /etc/olsrd/olsrd.conf -d $DEBUGLEVEL"

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.) -

/etc/olsrd/olsrd.conf:
AllowNoInt yes
ClearScreen yes
DebugLevel 0
FIBMetric "flat"
IpVersion 4
LinkQualityAlgorithm "etx_ff"
LinkQualityFishEye 1
LinkQualityLevel 2
MainIp [DIE MAIN-IP BEKOMMT IHR AUS DEM FUNKFEUER PORTAL, WENN IHR EIN GERÄT (DEVICE) ANLEGT]
MprCoverage 1
Pollrate 0.1
TcRedundancy 2
TosValue 16
UseHysteresis no
Willingness 3
InterfaceDefaults
{
AutoDetectChanges yes
HelloInterval 5.0
HelloValidityTime 100.0
TcInterval 2.0
TcValidityTime 300.0
MidInterval 50.0
MidValidityTime 300.0
HnaInterval 50.0
HnaValidityTime 300.0
Ip4Broadcast 255.255.255.255
Mode "mesh"
LinkQualityMult default 0.15
Weight 99
}
Interface "br-ff"
{
AutoDetectChanges yes
LinkQualityMult default 1.0
Weight 0
}
Hna4
{
[SERVER-IP FALLS VORHANDEN - ZUWEISUNG VIA PORTAL] 255.255.255.255
}
LoadPlugin "olsrd_httpinfo.so.0.1"
{
PlParam "Port" "81"
PlParam "Net" "0.0.0.0 0.0.0.0"
PlParam "resolve" "false"
}
LoadPlugin "olsrd_txtinfo.so.1.1"
{
PlParam "port" "2006"
PlParam "accept" "127.0.0.1"
}
LoadPlugin "olsrd_jsoninfo.so.1.1"
{
PlParam "port" "9090"
PlParam "accept" "0.0.0.0"
PlParam "UUIDFile" "/etc/olsrd/olsrd.uuid"
}

Damit ist eigentlich die Arbeit getan.

=== 'the quick and dirty hack' für IPv6 ===

Für OLSR mit IPv6 gibt es noch ein paar Tricks zu wissen und noch etwas mehr Handarbeit.
Kopiere:

* /etc/default/olsrd nach /etc/default/olsrd6
** Ersetz jedes Vorkommen von olsr(d) durch olsr(d)6.

mit vim wäre das so: vom input modus in den command modus wechseln (ESC) und in der command line folgendes eingeben:

%s/olsrd/olsrd6/g

12 ersetzungen sollten stattfinden.

%s/OLSRD/OLSRD6/g

selbiges gilt für die folgenden weiteren Dateien

* /etc/init.d/olsrd nach /etc/init.d/olsrd6
** Ersetz jedes Vorkommen von olsr(d) durch olsr(d)6. Ersetze /usr/sbin/olsrd durch /etc/alternatives/olsrd6
* Setz einen Link von /usr/sbin/olsrd nach /etc/alternatives/olsrd6. 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.
* Leg /etc/olsrd/olsrd6.conf an - nachfolgend ein Beispiel.

AllowNoInt yes
ClearScreen yes
DebugLevel 0
FIBMetric "flat"
IpVersion 6
LinkQualityAlgorithm "etx_ff"
LinkQualityFishEye 1
LinkQualityLevel 2
MprCoverage 1
Pollrate 0.1
TcRedundancy 2
TosValue 16
UseHysteresis no
UseNiit yes
Willingness 3
InterfaceDefaults
{
#Ip6MulticastGlobal ff0e::1
#Ip6MulticastSite ff05::11
IPv6Multicast ff02::6d
Weight 99
AutoDetectChanges yes
HelloInterval 50.0
HelloValidityTime 100.0
HnaInterval 50.0
HnaValidityTime 300.0
LinkQualityMult default 0.33
MidInterval 50.0
MidValidityTime 300.0
Mode "mesh"
TcInterval 2.0
TcValidityTime 300.0
Weight 99
}
Hna6
{
}
LoadPlugin "olsrd_httpinfo.so.0.1"
{
PlParam "Net" "0::/0 2000::/3"
PlParam "port" "82"
}
LoadPlugin "olsrd_jsoninfo.so.1.1"
{
PlParam "port" "9090"
PlParam "accept" "::"
PlParam "UUIDFile" "/etc/olsrd/olsrd6.uuid"
PlParam "ipv6only" "true"
}
Interface "br-ff"
{
AutoDetectChanges yes
LinkQualityMult default 0.25
Mode "ether"
Weight 1
IPv6Multicast ff02::6d
}

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.

Es ist auch möglich die plugin sektion ganz wegzulassen, damit eliminiert man evtl ein weiteres Problem.
diese können ja schrittweise bei funktionierender config nachträglich wieder eingefügt werden.

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.

Das war's. Dual-Stack OLSRv1 mit Tunnel läuft, sowie Du es gestartet hast.

OpenVPN mit Debian/Ubuntu

2018-05-25T11:12:31Z

Franzlax:

Unter Debian installierst Du die Pakete für Openvpn und olsr.

Voraussetzungen:
* Aktuelles Debian Stable oder Ubuntu LTS
* Pakete für OpenVPN, OLSR (und OLSRv2), bridge-utils
* Funkfeuer-Login
* Funkfeuer-IPv4-Adresse für das Tunneldevice respektive die Bridge aus [[https://portal.funkfeuer.at/wien REDEEMER/FRONTEND/PORTAL]]
* Einen Taschenrechner, der Dezimalzahlen in Hexadezimalzahlen umrechnen kann („programmiertechnischer Modus“)
* 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:
** „&id=9999“ oder so
** „id_nodes=9999“.
Diese Zahl umgewandelt in „Hex“ brauchst Du später für Deine IPv6-Adresse.

* apt-get install openvpn openvpn-blacklist olsrd olsrd-plugins bridge-utils

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.

/etc/network/interfaces:
iface eth0 inet static
...
up /sbin/ip r a 78.41.118.150/32 dev eth0 via 192.168.1.1 metric 0
up /etc/init.d/openvpn restart

iface br-ff inet static
bridge_fd 0
bridge_maxwait 0
bridge_waitport 0
bridge_stp no
bridge_ports none
address [REDEEMER-IP v4]
netmask 255.255.255.255
# 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]
# Nachfolgend für 9999 NodeID 9999(10) = 270F(16); Router 1, Interface 1 mit Adresse „feed“:
post-up /sbin/ip -6 a a 2a02:60:1'''27''':'''0f'''''11''::feed/64 dev br-ff
# Wenn man die MAC-Adresse der Bridge definiert, wirkt sich das auf die IPv6 EUI64-Adresse beginnend mit fe80::/12 aus.
# Man kann sich eine zufällige MAC-Adresse [[https://www.miniwebtool.com/mac-address-generator/ MAC Address Generator]] (lowercase und ":"-Notation) errechnen lassen.
post-up ip link set dev br-ff address bc:75:33:6a:bf:cf
# Die Bridge soll allen Traffic annehmen.
post-up ip link set dev br-ff promisc on

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.

/etc/default/openvpn:
#AUTOSTART="all" ->
AUTOSTART="all"
oder
#AUTOSTART="all" ->
AUTOSTART="funkfeuer"

Somit erwartet OpenVPN seine Konfiguration in /etc/openvpn/funkfeuer.conf.

/etc/openvpn/funkfeuer.conf:
dev tap0
proto udp
remote 78.41.118.150
# Die Portnummer XXXX wird Dir zugewiesen
port XXXX
daemon tap0
persist-tun
up-delay
down-pre
up-restart
comp-lzo
script-security 2
nobind
ping 10
ping-restart 60
ping-timer-rem
fast-io
sndbuf 524288
rcvbuf 524288
mute 2
verb 0
up /etc/openvpn/funkfeuer-updown.sh
down /etc/openvpn/funkfeuer-updown.sh
secret /etc/openvpn/funkfeuer.secret
auth SHA256
cipher none

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:

/etc/openvpn/funkfeuer-updown.sh:
#!/bin/bash
# br-ff ist die Bridge aus /etc/network/interfaces
# $dev ist ein Parameter, den Openvpn übergibt. Hier zumeist „tap0“.
br="br-ff"
dev=$1
logger "openvpn: $(echo $@)"
logger "openvpn: $script_type"
case $script_type in
"down")
/sbin/brctl delif $br $dev
/sbin/ip link set link dev $dev down
;;
"route-up")
;;
"up")
/sbin/brctl addif $br $dev
/sbin/ip link set dev $br promisc on
/sbin/ip link set link dev $dev up
/sbin/ip link set link dev $br up
;;
esac
echo $(date) $script_type $br.$dev $script_type>> /tmp/br-vpn.log
exit 0

Das Skript muss ausführbar gemacht werden. chmod +x /etc/openvpn/funkfeuer-updown.sh

chmod +x /etc/openvpn/funkfeuer-updown.sh

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):

/etc/openvpn/funkfeuer.secret:
#
# 2048 bit OpenVPN static key
#
-----BEGIN OpenVPN Static key V1-----
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
-----END OpenVPN Static key V1-----

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.)

/etc/default/olsrd:
START_OLSRD="YES"
DEBUGLEVEL=0
DAEMON_OPTS="-f /etc/olsrd/olsrd.conf -d $DEBUGLEVEL"

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.) -

/etc/olsrd/olsrd.conf:
AllowNoInt yes
ClearScreen yes
DebugLevel 0
FIBMetric "flat"
IpVersion 4
LinkQualityAlgorithm "etx_ff"
LinkQualityFishEye 1
LinkQualityLevel 2
MainIp [DIE MAIN-IP BEKOMMT IHR AUS DEM FUNKFEUER PORTAL, WENN IHR EIN GERÄT (DEVICE) ANLEGT]
MprCoverage 1
Pollrate 0.1
TcRedundancy 2
TosValue 16
UseHysteresis no
Willingness 3
InterfaceDefaults
{
AutoDetectChanges yes
HelloInterval 5.0
HelloValidityTime 100.0
TcInterval 2.0
TcValidityTime 300.0
MidInterval 50.0
MidValidityTime 300.0
HnaInterval 50.0
HnaValidityTime 300.0
Ip4Broadcast 255.255.255.255
Mode "mesh"
LinkQualityMult default 0.15
Weight 99
}
Interface "br-ff"
{
AutoDetectChanges yes
LinkQualityMult default 1.0
Weight 0
}
Hna4
{
[SERVER-IP FALLS VORHANDEN - ZUWEISUNG VIA PORTAL] 255.255.255.255
}
LoadPlugin "olsrd_httpinfo.so.0.1"
{
PlParam "Port" "81"
PlParam "Net" "0.0.0.0 0.0.0.0"
PlParam "resolve" "false"
}
LoadPlugin "olsrd_txtinfo.so.1.1"
{
PlParam "port" "2006"
PlParam "accept" "127.0.0.1"
}
LoadPlugin "olsrd_jsoninfo.so.1.1"
{
PlParam "port" "9090"
PlParam "accept" "0.0.0.0"
PlParam "UUIDFile" "/etc/olsrd/olsrd.uuid"
}

Damit ist eigentlich die Arbeit getan.

=== 'the quick and dirty hack' für IPv6 ===

Für OLSR mit IPv6 gibt es noch ein paar Tricks zu wissen und noch etwas mehr Handarbeit.
Kopiere:

* /etc/default/olsrd nach /etc/default/olsrd6
** Ersetz jedes Vorkommen von olsr(d) durch olsr(d)6.

mit vim wäre das so: vom input modus in den command modus wechseln (ESC) und in der command line folgendes eingeben: %s/olsrd/olsrd6/g
12 ersetzungen sollten stattfinden. selbiges gilt für die folgenden weiteren Dateien

* /etc/init.d/olsrd nach /etc/init.d/olsrd6
** Ersetz jedes Vorkommen von olsr(d) durch olsr(d)6. Ersetze /usr/sbin/olsrd durch /etc/alternatives/olsrd6
* Setz einen Link von /usr/sbin/olsrd nach /etc/alternatives/olsrd6. 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.
* Leg /etc/olsrd/olsrd6.conf an - nachfolgend ein Beispiel.

AllowNoInt yes
ClearScreen yes
DebugLevel 0
FIBMetric "flat"
IpVersion 6
LinkQualityAlgorithm "etx_ff"
LinkQualityFishEye 1
LinkQualityLevel 2
MprCoverage 1
Pollrate 0.1
TcRedundancy 2
TosValue 16
UseHysteresis no
UseNiit yes
Willingness 3
InterfaceDefaults
{
#Ip6MulticastGlobal ff0e::1
#Ip6MulticastSite ff05::11
IPv6Multicast ff02::6d
Weight 99
AutoDetectChanges yes
HelloInterval 50.0
HelloValidityTime 100.0
HnaInterval 50.0
HnaValidityTime 300.0
LinkQualityMult default 0.33
MidInterval 50.0
MidValidityTime 300.0
Mode "mesh"
TcInterval 2.0
TcValidityTime 300.0
Weight 99
}
Hna6
{
}
LoadPlugin "olsrd_httpinfo.so.0.1"
{
PlParam "Net" "0::/0 2000::/3"
PlParam "port" "82"
}
LoadPlugin "olsrd_jsoninfo.so.1.1"
{
PlParam "port" "9090"
PlParam "accept" "::"
PlParam "UUIDFile" "/etc/olsrd/olsrd6.uuid"
PlParam "ipv6only" "true"
}
Interface "br-ff"
{
AutoDetectChanges yes
LinkQualityMult default 0.25
Mode "ether"
Weight 1
IPv6Multicast ff02::6d
}

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.
Es ist auch möglich die plugin sektion ganz wegzulassen, damit eliminiert man evtl ein weiteres Problem.
diese können ja schrittweise bei funktionierender config nachträglich wieder eingefügt werden.

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.

Das war's. Dual-Stack OLSRv1 mit Tunnel läuft, sowie Du es gestartet hast.

Knowledge Base

2014-10-27T21:33:14Z

Franzlax: /* Basiswissen zur Risikobewertung hochfrequenter elektromagnetischer Felder */

Du befindest dich jetzt in der Wissensdatenbank von Funkfeuer.at

== IANA Private Enterprise Number ==
Funkfeuer Wien hat für seine SNMP-Entwicklung seitens der [http://www.iana.org Internet Assigned Numbers Authority (IANA)] die '''Nummer 42893''' zugeteilt bekommen.

Der Eintrag kann [http://www.iana.org/assignments/enterprise-numbers bei www.iana.org] abgefragt werden.
Änderungen sind [http://pen.iana.org/pen/PenModification.page über diesen Link] möglich.

== High Efficiency WLAN Study Group (HEW) ==
http://www.ieee802.org/11/Reports/hew_update.htm

== In-Band Simultaneous Transmit and Receive (STR) ==
Durch geschickte Signalverarbeitung kann ein schwaches und spektral schmales 2,4-GHz-Signal gesendet und gleichzeitig auf derselben Frequenz empfangen werden.
Normalerweise übertönt eine Antenne im Sendebetrieb ein eingehendes Signal derart stark, dass es der Empfänger nicht mehr "hören" kann. Denn der Pegel des eingehenden Signals ist wegen der Streckendämpfung beim Empfänger um etliche Größenordnungen schwächer als der Pegel des eigenen Sendesignals. Dennoch setzen manche Funkverfahren Vollduplex-Techniken ein – aber eben über zwei Frequenzen (Frequency Division Full Duplex). Weil dafür zusätzliche aufwendige Analoghardware erforderlich ist, begnügt man sich oft mit der billigeren Version und nutzt nur einen Kanal im Halbduplex-Verfahren, bei dem immer nur einer von zwei Teilnehmern sendet. Das halbiert jedoch die Kapazität des Kanals, weil ein Teilnehmer nur die Hälfte der Zeit senden kann.

Wenn man aber separate Antennen zum Senden und Empfangen einsetzt und die Empfangsantenne dort aufstellt, wo die selbstgesendeten Daten am schwächsten eintreffen, empfangene Signale aber normal, dann lässt sich eine Frequenz dennoch zum gleichzeitigen Senden und Empfangen nutzen.

Verwendet man aber drei Antennen, zwei zum Senden eines identischen Signals und eine zum Empfangen. Der Kniff besteht in der exakten Konstellation der drei Antennen: Die Sendeantennen sind in einer Entfernung aufgestellt, in der sich Wellenberg der einen und Wellental der anderen am Scheitelpunkt treffen – dort treten Interferenzeffekte auf, bei denen sich die beiden Sendesignale im Idealfall gegenseitig auslöschen (Nullpunkt) und ebendort ist die beste Position für die Empfangsantenne. Die Technik wird als als Antenna Cancellation bezeichnet.

[http://www.stanford.edu/~dineshb/comm292-bharadia.pdf Dual Band Radios]

[https://mentor.ieee.org/802.11/dcn/13/11-13-1122-01-0hew-considerations-for-in-band-simultaneous-transmit-and-receive-str-feature-in-hew.pdf In-Band Simultaneous Transmit and Receive (STR)]

== Basiswissen zur Risikobewertung hochfrequenter elektromagnetischer Felder ==

INHALTE:

• Einführung in die umweltmedizinische Thematik

• Technische und physikalische Grundlagen

• Biologische Wirkungen von HF-Feldern–Stand des Wissens

• Risikobewertung aus ärztlicher Sicht

• Fallbeispiel aus der umweltmedizinischen Praxis

• Behandlungsstrategien bei subjektiv empfundener Elektrosensibilität

http://www.izmf.de/sites/default/files/download/IZMF_CME-Fortbildung_2014.pdf

bzw.

http://lax.priv.at/0xff/Risikobewertung_HF_Felder.pdf

Knowledge Base

2014-10-27T21:32:00Z

Franzlax:

Du befindest dich jetzt in der Wissensdatenbank von Funkfeuer.at

== IANA Private Enterprise Number ==
Funkfeuer Wien hat für seine SNMP-Entwicklung seitens der [http://www.iana.org Internet Assigned Numbers Authority (IANA)] die '''Nummer 42893''' zugeteilt bekommen.

Der Eintrag kann [http://www.iana.org/assignments/enterprise-numbers bei www.iana.org] abgefragt werden.
Änderungen sind [http://pen.iana.org/pen/PenModification.page über diesen Link] möglich.

== High Efficiency WLAN Study Group (HEW) ==
http://www.ieee802.org/11/Reports/hew_update.htm

== In-Band Simultaneous Transmit and Receive (STR) ==
Durch geschickte Signalverarbeitung kann ein schwaches und spektral schmales 2,4-GHz-Signal gesendet und gleichzeitig auf derselben Frequenz empfangen werden.
Normalerweise übertönt eine Antenne im Sendebetrieb ein eingehendes Signal derart stark, dass es der Empfänger nicht mehr "hören" kann. Denn der Pegel des eingehenden Signals ist wegen der Streckendämpfung beim Empfänger um etliche Größenordnungen schwächer als der Pegel des eigenen Sendesignals. Dennoch setzen manche Funkverfahren Vollduplex-Techniken ein – aber eben über zwei Frequenzen (Frequency Division Full Duplex). Weil dafür zusätzliche aufwendige Analoghardware erforderlich ist, begnügt man sich oft mit der billigeren Version und nutzt nur einen Kanal im Halbduplex-Verfahren, bei dem immer nur einer von zwei Teilnehmern sendet. Das halbiert jedoch die Kapazität des Kanals, weil ein Teilnehmer nur die Hälfte der Zeit senden kann.

Wenn man aber separate Antennen zum Senden und Empfangen einsetzt und die Empfangsantenne dort aufstellt, wo die selbstgesendeten Daten am schwächsten eintreffen, empfangene Signale aber normal, dann lässt sich eine Frequenz dennoch zum gleichzeitigen Senden und Empfangen nutzen.

Verwendet man aber drei Antennen, zwei zum Senden eines identischen Signals und eine zum Empfangen. Der Kniff besteht in der exakten Konstellation der drei Antennen: Die Sendeantennen sind in einer Entfernung aufgestellt, in der sich Wellenberg der einen und Wellental der anderen am Scheitelpunkt treffen – dort treten Interferenzeffekte auf, bei denen sich die beiden Sendesignale im Idealfall gegenseitig auslöschen (Nullpunkt) und ebendort ist die beste Position für die Empfangsantenne. Die Technik wird als als Antenna Cancellation bezeichnet.

[http://www.stanford.edu/~dineshb/comm292-bharadia.pdf Dual Band Radios]

[https://mentor.ieee.org/802.11/dcn/13/11-13-1122-01-0hew-considerations-for-in-band-simultaneous-transmit-and-receive-str-feature-in-hew.pdf In-Band Simultaneous Transmit and Receive (STR)]

== Basiswissen zur Risikobewertung hochfrequenter elektromagnetischer Felder ==
Inhalte

• Einführung in die umweltmedizinische Thematik

• Technische und physikalische Grundlagen

• Biologische Wirkungen von HF-Feldern–Stand des Wissens

• Risikobewertung aus ärztlicher Sicht

• Fallbeispiel aus der umweltmedizinischen Praxis

• Behandlungsstrategien bei subjektiv empfundener Elektrosensibilität

http://www.izmf.de/sites/default/files/download/IZMF_CME-Fortbildung_2014.pdf
bzw.
http://lax.priv.at/0xff/Risikobewertung_HF_Felder.pdf

Knowledge Base

2014-10-27T21:29:14Z

Franzlax:

Du befindest dich jetzt in der Wissensdatenbank von Funkfeuer.at

== IANA Private Enterprise Number ==
Funkfeuer Wien hat für seine SNMP-Entwicklung seitens der [http://www.iana.org Internet Assigned Numbers Authority (IANA)] die '''Nummer 42893''' zugeteilt bekommen.

Der Eintrag kann [http://www.iana.org/assignments/enterprise-numbers bei www.iana.org] abgefragt werden.
Änderungen sind [http://pen.iana.org/pen/PenModification.page über diesen Link] möglich.

== High Efficiency WLAN Study Group (HEW) ==
http://www.ieee802.org/11/Reports/hew_update.htm

== In-Band Simultaneous Transmit and Receive (STR) ==
Durch geschickte Signalverarbeitung kann ein schwaches und spektral schmales 2,4-GHz-Signal gesendet und gleichzeitig auf derselben Frequenz empfangen werden.
Normalerweise übertönt eine Antenne im Sendebetrieb ein eingehendes Signal derart stark, dass es der Empfänger nicht mehr "hören" kann. Denn der Pegel des eingehenden Signals ist wegen der Streckendämpfung beim Empfänger um etliche Größenordnungen schwächer als der Pegel des eigenen Sendesignals. Dennoch setzen manche Funkverfahren Vollduplex-Techniken ein – aber eben über zwei Frequenzen (Frequency Division Full Duplex). Weil dafür zusätzliche aufwendige Analoghardware erforderlich ist, begnügt man sich oft mit der billigeren Version und nutzt nur einen Kanal im Halbduplex-Verfahren, bei dem immer nur einer von zwei Teilnehmern sendet. Das halbiert jedoch die Kapazität des Kanals, weil ein Teilnehmer nur die Hälfte der Zeit senden kann.

Wenn man aber separate Antennen zum Senden und Empfangen einsetzt und die Empfangsantenne dort aufstellt, wo die selbstgesendeten Daten am schwächsten eintreffen, empfangene Signale aber normal, dann lässt sich eine Frequenz dennoch zum gleichzeitigen Senden und Empfangen nutzen.

Verwendet man aber drei Antennen, zwei zum Senden eines identischen Signals und eine zum Empfangen. Der Kniff besteht in der exakten Konstellation der drei Antennen: Die Sendeantennen sind in einer Entfernung aufgestellt, in der sich Wellenberg der einen und Wellental der anderen am Scheitelpunkt treffen – dort treten Interferenzeffekte auf, bei denen sich die beiden Sendesignale im Idealfall gegenseitig auslöschen (Nullpunkt) und ebendort ist die beste Position für die Empfangsantenne. Die Technik wird als als Antenna Cancellation bezeichnet.

[http://www.stanford.edu/~dineshb/comm292-bharadia.pdf Dual Band Radios]

[https://mentor.ieee.org/802.11/dcn/13/11-13-1122-01-0hew-considerations-for-in-band-simultaneous-transmit-and-receive-str-feature-in-hew.pdf In-Band Simultaneous Transmit and Receive (STR)]

== Basiswissen zur Risikobewertung hochfrequenter elektromagnetischer Felder ==
Inhalte
• Einführung in die umweltmedizinische Thematik
• TechnischeundphysikalischeGrundlagen
• BiologischeWirkungenvonHF-Feldern–StanddesWissens
• RisikobewertungausärztlicherSicht
• FallbeispielausderumweltmedizinischenPraxis
• BehandlungsstrategienbeisubjektivempfundenerElektrosensibilität

http://www.izmf.de/sites/default/files/download/IZMF_CME-Fortbildung_2014.pdf
bzw.
http://lax.priv.at/0xff/Risikobewertung_HF_Felder.pdf

Services

2014-03-23T22:50:13Z

Franzlax:

Hier entsteht unsere Liste aller Services
--[[Benutzer:JoeSemler|JoeSemler]] ([[Benutzer Diskussion:JoeSemler|Diskussion]]) 09:29, 20. Mär. 2013 (CET)

*'''[https://marvin.funkfeuer.at/frontend_wien/ IP-Adressverwaltung]'''

*'''[https://193.238.157.16/~markus/ipstat/ IP-Nutzungsstatistik]'''

*'''[http://tunnel.tunnel.wien.funkfeuer.at/openvpn.php openVPN-StatusInfo]'''
:''Status aller openVPN-Tunnel Clients im Netz von Funkfeuer-Wien''

*'''[http://tunnel6.funkfeuer.at/tunnel6.php 6in4-StatusInfo]'''
:''Status aller 6in4-Clients im Netz von Funkfeuer-Wien''

*'''[http://zorro.kunstlabor.at/voip VOIP Telefonie]'''
:''VOIP im Netz von Funkfeuer-Wien''

Services

2014-03-23T22:48:41Z

Franzlax: