Gateways

Mesh VPN einrichten

Juhu, die Zugangsdaten für meinen virtuellen Sever sind da! Damit sind die Weichen für ein unabhängiges Freifunk-Netz in Weil am Rhein gestellt. Um einzelne Knoten außer Funkreichweite miteinander verbinden zu können bedarf es eines Kunstrukts, welches ich als Mesh VPN bezeichne (nicht zu verwechseln mit dem InterCity VPN, welches die verschiedenen Freifunknetze miteinander verbindet). Das Konstrukt is relativ simpel: Mit dem Internet verbundende Knoten in den einzelnen Funkmaschen erstellen eine Tunnelverbindung zu einem oder mehreren zentralen Severn. Diese Server leiten eingehenden Netzwerkverkehr dann in die außer Reichweite befindlichen Funkmaschen weiter. Das Routing übernimmt wie in den Funkmaschen batman-adv.

Der folgende Artikel beschreibt die Einrichtung eines solchen zentralen Servers. Der gleiche Server wird zu einem späteren Zeitpunkt als Gateway ins Internet und zu anderen Freifunk-Netzen via InterCity VPN konfiguriert werden. Die zentralen Elemente sind das batman-adv Kernelmodul und der fastd VPN-Server. Als Betriebssystem wird von Debian Wheezy mit ein Linux-Kernel in der Version 3.2.41 ausgegangen. Das Vorgehen für andere Linux-Distributionen sollte ähnlich sein. Allerdings wird man in diesen Fällen um das Kompilieren von fastd und batman-adv/batctl vermutlich nicht herumkommen. Weiterhin wird von einer Einrichtung als Benutzer root ausgegangen. Falls dem nicht so ist, muss den Befehlen welche Superuser-Rechte benötigen ein sudo vorangestellt werden (Also, sudoer sollte man schon sein, sonst wird es nichts mit der Server-Einrichtung).

Noch einmal tief Atem geholt, in die Hände gespuckt und los geht es… Etckeeper

Um Änderungen an der Konfiguration des Servers besser verfolgen zu können, installieren wir als erstes das Paket etckeeper mit den folgenden Commandos:

$ apt-get update $ apt-get install etckeeper

Das ‘$’-Zeichen bezeichnet hierbei die Eingabeaufforderung (“Prompt”) und ist nicht mit einzugeben. Im Anschluss aktivieren wir die Versionierung des Konfigurationsverzeichnisses “/etc”:

$ etckeeper init /etc

In seiner Standardkonfiguration verwendet etckeeper git zur Versionierung. Um lästige Warnungen während der Installation weiterer Pakete zu vermeiden, vervollständigen wir die git-Konfiguration mit den zwei folgenden Kommandos. Falls git bereits vollständig konfiguriert wurde, kann dieser Schritt übersprungen werden.

$ git config --global user.name "Your Name" $ git config --global user.email you@example.com

Die Platzhalter Your Name und you@example.com sind selbstverständlich durch den eigenen Namen und die eigene e-Mailadresse zu ersetzen. batman-adv

Im nächsten Schritt installieren wir das batman-adv Kernelmodul und das zugehörige Konfigurationswerkzeug batctl. Diese sind nicht Teil der Debian-Distribution (zumindest nicht in einer aktuellen Version), sondern müssen über ein externes Depot (“Repository”) bezogen werden. Hierfür fügen wir der Datei /etc/apt/sources.list die folgende Zeile hinzu:

deb http://repo.universe-factory.net/debian/ sid main

Im Anschluss importieren wir die öffentlichen Schlüssel, mit welchen die Identität der importierten Pakete überprüft wird:

$ gpg --keyserver pgpkeys.mit.edu --recv-key AB7A88C5B89033D8 $ gpg --keyserver pgpkeys.mit.edu --recv-key 16EF3F64CB201D9C $ gpg -a --export AB7A88C5B89033D8 | sudo apt-key add - $ gpg -a --export 16EF3F64CB201D9C | sudo apt-key add -

Jetzt sind wir soweit, dass wir die benötigten Pakete mittels der folgenden Befehle bequem installieren können:

$ apt-get update $ apt-get install batman-adv-dkms $ apt-get install batcl

Im Anschluss müssen wir noch das batman-adv Modul in den Kernel laden:

$ modprobe batman-adv

Damit es Zukunft automatisch während des Boot-Vorgangs geladen wird fügen wir noch die folgende Zeile der Datei /etc/modules hinzu:

batman-adv

fastd

Nachdem wir batman-adv erfolgreich installiert haben (zumindest hoffe ich das), wenden wir uns in nächstem Schritt dem VPN-Server fastd zu. Glücklicherweise kann dieser über das gleiche Software-Depot wie batman-adv bezogen werden. Für die Installation genügt es, das folgende Kommando auszuführen:

$ apt-get install fastd

Nach erfolgter Installation muss der fastd-Server noch konfiguriert werden. Das Standardkonfigurationsverzeichnis /etc/fastd ist zum aktuellen Zeitpunkt noch leer. Zuerst erzeugen wir ein Unterverzeichnis, in dem die Konfigruationsdateien für unser Netzwerk abgelegt werden sollen:

mkdir /etc/fastd/freifunk mkdir /etc/fastd/freifunk/peers

Der Name des Verzeichnisses freifunk kann hierbei beliebig geändert werden. Falls ein anderer Name verwendet wurde, sind die Pfadangaben im Folgenden anzupassen. Als nächstes generieren wir ein Schlüsselpaar und speichern es in der Dateil keys:

$ fastd --generate-key >> keys

Die Ausgabe der Datei sollte dem folgenden Beispiel ähneln:

$ cat keys 2014-04-26 21:15:27 +0200 --- Info: Reading 32 bytes from /dev/random... Secret: 90722f73f2c23b672ad419f66191420444a3e7a9a69c9fa139e0da096570b857 Public: a7d7cfbd2d4a463ffd8d6faff71fffbef7761ae95d685913d774e38aa1f31596

Den privaten Schlüssel speichern wir nun in der Datei /etc/fastd/freifunk/secret.conf in Form der folgenden Zeile:

secret "90722f73f2c23b672ad419f66191420444a3e7a9a69c9fa139e0da096570b857";

Der eingetragene Schlüssel muss an dieser Stelle selbstverständlich durch den tatsächlich generierten Schlüssel ersetzt werden. Beide Dateien (keys und secret.conf) schützen wir durch eine Einschränkung der Rechte vor dem Zugriff Dritter:

$ chmod 600 keys $ chmod 600 secret.conf

Der öffentliche Schlüssel wird nicht für die Konfiguration des fastd-Servers benötigt, wohl aber später für die Konfiguration der Clients. Schließlich erzeugen wir die zentrale Konfigurationsdatei /etc/fastd/freifunk/fastd.conf mit folgendem Inhalt:

1. Log warnings and errors to stderr

log level warn;

1. Log everything to syslog

log to syslog level info;

1. Set the interface name

interface "mesh-vpn";

1. Support xsalsa20 and aes128 encryption methods, prefer xsalsa20

method "xsalsa20-poly1305"; method "aes128-gcm";

1. Bind to a fixed port, IPv4 only

bind 0.0.0.0:10000;

1. Secret key generated by `fastd --generate-key`

include "secret.conf";

1. Enforce secure handshakes

secure handshakes yes;

1. Set the interface MTU for TAP mode with xsalsa20/aes128 over IPv4 with a base MTU of 1492 (PPPoE)
2. (see MTU selection documentation)

mtu 1426;

1. Include peers from the directory 'peers'

include peers from "peers";

1. Activate batmand-adv routing in tap interface

on up " ip link set up dev $INTERFACE batctl if add $INTERFACE ";

Wer seine Konfiguration maßschneidern möchte, der findet eine detaillierte Beschreibung der verfügbaren Optionen an dieser Stelle. Im Unterverzeichnis /etc/fastd/freifunk/peers werden wir zu einem späteren Zeitpunkt für jeden Client eine Datei mit dem öffentlichen Schlüssel anlegen:

key "INCOMING_CONNECTION_PARTNER_PUBLIC_KEY";

Der öffentliche Schlüssel wird von Gluon auf den Clients zum Zeitpunkt der Erstkonfiguration angelegt und muss per e-Mail an den Gateway-Administrator übermmittelt werden. Doch davon später mehr. Jetzt müssen wir den fastd-Server nur noch starten. Dies bewerkstelligen wir mit einer einfachen Kommandozeile:

/etc/init.d/fastd start

Da mit dem Installieren des fastd-Pakets gleichzeitig die zugehörigen Links in den /etc/rc.X-Verzeichnissen erstellt wurden, startet der fastd-Server beim nächsten Bootvorgang automatisch. Abschluss

Damit sind wir eigentlich am Ziel. Um die aktuelle Konfiguration noch zu sichern, senden wir eine letzte Kommandozeile an etckeeper:

$ etckeeper commit "Configuration IntraCity VPN server completed."

Jetzt fehlen eigentlich nur noch die Clients. Im nächsten Artikel werde ich darüber berichten, wie sich Gluon konfigurieren und kompilieren lässt. Danach sind wir bereit für den Erstkontakt und es wird spanned!

Der folgende Artikel beschreibt die Einrichtung eines Gluon Internet-Gateways, um Teilnehmern des Freifunknetzes die Verbindung mit dem Internet zu ermöglichen. Die Einrichtung des Mesh-VPN zur Vernetzung von isolierten Funkwolken unterneinander hatten wir in einem vorangehenden Artikel bereits beschrieben. Ein funktionierendes Mesh-VPN ist Voraussetzung für die folgenden Schritte.

Vom Prinzip her wird über das Mesh-VPN eingehender Verkehr, welcher an das Internet (d.h. an Adressen außerhalb des Freifunk-Netzes) gerichtet ist, mittels Routing- und Firewall-Regeln ins Internet weitergeleitet. Zwecks Anonymisierung der Verbindung und Umgehung der in Deutschland geltenden Störerhaftung wird hierbei eine weitere VPN-Verbindung zwischengeschaltet.

Zusätzlich werden wir einen DHCP-Server einrichtigen, um IPv4-Adressen dynamisch an Endgeräte zu vergeben sowie einen DNS-Proxy, der vom Mesh ausgehende DNS-Anfragen bedient. Weiterhin benötigen wir einen Radvd-Dämonen zur Umsetzung des “Neighbour Discovery Protocols”, welches die Autokonfiguration von IPv6-Adressen auf der Basis von Link-Layer-Adressen ermöglicht. Das Routing auf Layer 2 übernimmt batman-adv.

Als Vorlage für die folgenden Beschreibungen dienten die Anleitungen der Freifunk-Gemeinden Hannover und Hamburg. Diese wurden an manchen Stellen modifiziert und um Erläuterungen ergänzt. Als Betriebssystem wird von Debian Wheezy ausgegangen. Die Einrichtung des Gateway erfolgt als Benutzer root. Netzwerkschnittstellen konfigurieren

Für die Konfiguration des Gateways benötigen wir die sogenannten bridge-utils, welche wir mit folgenden Befehlen installieren:

$ apt-get update $ apt-get install bridge-utils

Zusätzlich aktivieren wir die IP-Weiterleitung durch Hinzufügen der folgenden Zeile zur Datei /etc/sysctl.conf:

net.ipv4.ip_forward=1 net.ipv6.conf.all.forwarding = 1

Im Anschluss übernehmen wir die Änderung durch Ausführung des folgenden Kommandos:

$ sysctl -p /etc/sysctl.conf

Netzwerkschnittstellen

Im ersten Schritt richten wir unter /etc/network/interfaces eine Netzwerkbrücke mit dem Namen br-ff3l ein. Die Brücke dient der statischen IPv4- und IPv6-Konfiguration des Gateways. Später wird der Brücke noch die Batman-Schnittstelle bat0 zugewiesen.

Beide IP-Adressen müssen innherhalb des Freifunk-Netzes liegen. Für den Freifunk Dreiländereck haben wir uns im Freifunk-Wiki das IPv4-Netz 10.119.0.0/16 reserviert sowie den IPv6-Präfix fdc7:3c9d:b889:a272. Für das erste Gateway wurde die Adressen 10.119.0.2 bzw. fdc7:3c9d:b889:a272::2 vergeben. Bei der Vergabe der Adressen ist darauf zu achten, die in der Gluon site.conf konfigurierten next_node-Adressen auszusparen (typischerweise erste Adresse im Netz, also in unserem Fall 10.119.0.1 bzw. fdc7:3c9d:b889:a272::1), welche immer auf den Router selbst verweist.

1. Freifunk mesh interfaces

auto br-ff3l iface br-ff3l inet6 static

bridge-ports none
address fdc7:3c9d:b889:a272::2
netmask 64

iface br-ff3l inet static

address 10.119.0.2
netmask 255.255.0.0

Neben der Brücke konfigurieren wir in der selben Datei die Batman-Schnitstelle bat0. Bevor die Schnittstelle aktiviert wird, stellen wir mittels des Kommandos “pre-up modprobe batman-adv” sicher, dass das Kernelmodul batman-adv geladen und aktiv ist. Im Anschluss konfigurieren wir das Gateway mittels “pre-up batctl gw server” als Server, so dass DHCP-Anfragen von Batman zugestellt werden. Mittels “pre-up batctl if add mesh-vpn” ordnen wir die Schnittstelle für das Mesh-VPN der Batman-Schnittstelle zu und aktivieren somit das automatische Routing. Im Anschluss aktivieren wir die Schnittstelle mittels “up ip link set $IFACE up”.

Danach ordnen wir die Batman-Schnittstelle mittels “brctl addif br-ff3l $IFACE” der zuvor angelegten Brück zu, so dass die statische IP-Konfiguration greift. Das Originator-Intervall für Batman setzen wir mit “post-up batctl it 10000″ auf 10000 ms (also 10 s). Als letztes leiten wir mittels “post-up ip rule add from all fwmark 0x1 table 42″ mit der Ziffer 0x1 markierten eingehenden Verkehr gemäß der Routing-Tabelle 42 weiter (siehe Firewall-Konfiguration weiter unten). Vor dem Herunterfahren von bat0 lösen wir die Schnitstelle mit “pre-down brctl delif br-ff3l $IFACE || true” wieder von der Brücke.

iface bat0 inet6 manual

pre-up modprobe batman-adv
pre-up batctl gw server
pre-up batctl if add mesh-vpn
up ip link set $IFACE up
post-up brctl addif br-ff3l $IFACE
post-up batctl it 10000
post-up ip rule add from all fwmark 0x1 table 42
pre-down brctl delif br-ff3l $IFACE || true
down ip link set $IFACE down

Nach der Einrichtung der Brücke müssen wir diese ein einziges Mal von Hand starten. Zusätzlich starten wir den fastd-Dämonen erneut, welcher im Zuge des Neustarts wiederum die Batman-Schnittstelle bat0 aktiviert (siehe “on up”-Answeisung in der fastd-Konfiguration).

$ ifup br-ff3l $ service fastd restart

DHCP-Server

Als nächstes richten wir einen DHCP-Server ein, um mit dem Freifunk-Netz verbundenen Endgeräten dynamisch eine IPv4-Adresse zuzuweisen und ihnen die zugehörige Netzwerkkonfiguration mitzuteilen. Hierfür verwenden wir den ISC-DHCP-Server, welchen wir zuvor installieren müssen:

$ apt-get install isc-dhcp-server

Die Konfiguration des Servers unter /etc/dhcp/dhcpd.conf ändern wir gemäß dem folgenden Absatz. Die Top-Level-Domain (“.ff3l”), Netzadresse (10.119.0.0), Netzmaske (255.255.240.0) sowie die Adresse des DNS-Servers/Routers (10.119.0.2) sind ggf. anzupassen. Die Adresse des DNS-Servers/Routers ist der statischen Adresse des Gateways (Freifunknetz – nicht Internet!) gleichzusetzen. Beim zu vergebenden Adressbereich (hier 10.119.1.1 bis 10.119.255.254) empfiehlt es sich einen kleineren Bereich des Neztes für die statische Vergabge von IPv4-Adressen auszusparen (hier 10.119.0.1 bis 10.119.0.254). Die Adresse des Gateways muss in diesem Bereich liegen.

ddns-update-style none;
option domain-name ".ff3l";
default-lease-time 600;
max-lease-time 3600;
log-facility local7;
subnet 10.119.0.0 netmask 255.255.0.0 {
authoritative;
range 10.119.1.1 10.119.255.254;
option domain-name-servers 10.119.0.2;
option routers 10.119.0.2;
}
include "/etc/dhcp/static.conf";

Vorsorglich legen wir noch die (leere) Datei /etc/dhcp/static.conf für die statische Konfiguration von Klienten an, auch wenn wir diese vorerst nicht nutzen und starten im Anschluss den Dämonen neu:

$ touch /etc/dhcp/static.conf $ service isc-dhcp-server restart

Radvd

Um die Autokonfiguration von IPv6- auf der Basis von Link-Layer-Adressen zu ermöglichen, richten wir einen radvd-Dämonen ein, welcher das “Neighbor Discovery Protocol” implementiert. Zu allererst installieren wir den Dämonen:

$ apt-get install radvd

Danach passen wir die Konfiguration unter /etc/radvd.conf gem. dem folgenden Abschnitt an. Wir aktivieren den Dämonen auf der Brücke br-ff3l und damit der Batman-Schnittstelle, welche automatisch zugewiesen wird (siehe oben). Weiterhin teilen wir dem Dämonen unseren IPv6-Präfix (fdc7:3c9d:b889:a272) mit sowie die statische IPv6-Adresse unseres Gateways (fdc7:3c9d:b889:a272::2) als rekursiven DNS-Server zur Namensauflösung.

interface br-ff3l {

AdvSendAdvert on;
MaxRtrAdvInterval 200;
prefix fdc7:3c9d:b889:a272::/64 {
};
RDNSS fdc7:3c9d:b889:a272::2 {
};

};

Damit die Änderungen wirksam werden, starten wir radvd neu: $ service radvd restart

DNS-Proxy

Zur Auflösung von Hostnamen richten wir auf dem Gateway mittels dnsmasq einen DNS-Proxy ein, der eingehende DNS-Anfragen an von uns definierte DNS-Server weiterleitet. Wie zuvor installieren wir als erstes den Dämonen:

$ apt-get install dnsmasq

Die Konfiguration in /etc/dnsmasq.conf ändern wir wie im folgenden Absatz aufgeführt. Mit “bind-interfaces” und “interface=br-ff3l” zwingen wir dnsmasq lediglich an unsere Brücke br-ff3l zu binden. Das Loopback-Interface schließen wir mit “except-interface=lo” aus, um Konflikte mit einem bereits existierenden DNS-Server (z.B. bind9) zu vermeiden. Zum gleichen Zweck lassen wir dnsmasq mittels der Option “listen-address=127.0.0.2″ auf einer anderen lokalen Adresse lauschen. Die DHCP-Serverfunktion wird mittels “no-dhcp-interface=br-ff3l” deaktiviert. Die Option “domain-needed” bewirkt, dass Hostnamen ohne Domain nicht aufgelöst werden. Die Optionen “no-resolve” und “no-hosts” verhindern die Verwendung der DNS-Konfiguration unter /etc/resolv.conf sowie der Host-Einträge in /etc/hosts. Mit “cache-size=4096″ erhöhen wir die Zahl der im Zwischenspeicher gehaltenen Namenseinträge auf 4096. Log-Einträge leiten wir mittels “log-facility=/var/log/dnsmasq.log” in eine eigene Log-Datei um.

bind-interfaces except-interface=lo interface=br-ff3l listen-address=127.0.0.2 no-dhcp-interface=br-ff3l domain-needed no-resolv no-hosts cache-size=4096 log-facility=/var/log/dnsmasq.log

Um die Konfiguration abzuschließen, tragen wir unter /etc/dnsmasq.d/rules noch die von uns favorisierten DNS-Server ein. Die Wahl erfolgt hierbei nach Gusto. Später werden wir in dieser Datei zusätzlich Einträge auf eigene DNS-Server aufnehmen, um Einträge unter diversen Freifunk-Domains aufzulösen. Für den Moment belassen wir es jedoch dabei, alle Anfragen auf externe DNS-Server über die noch einzurichtende VPN-Schnittstelle tun0 ins Internet weiterzuleiten.

1. Forward DNS requests via wan-vpn

server=85.214.20.141@tun0 # FoeBud server=213.73.91.35@tun0 # dnscache.berlin.ccc.de

Damit die Änderungen wirksam werden, starten wir dnsmasq neu:

$ service dnsmasq restart

OpenVPN-Verbindung

Um ausgehenden Netzverkehr zu anonymisieren (d.h. um die IP-Adresse des Gateways und damit unsere Identität zu verstecken), richten wir eine Tunnelverbindung zu einem VPN-Server ein. Entsprechende Tunnelverbindungen werden von zahlreichen Providern als Dienstleistung angeboten. In unserem Fall haben wir uns für CyberghostVPN entschieden. Nicht unbedingt der billigste Anbieter. Dafür hat man die Wahl zwischen einer Vielzahl von Serven, welche in der Regel recht performant sind. Die Verbindung zu CyberghostVPN-Servern erfolgt (unter anderem) mittels OpenVPN. Hierfür installieren wir als erstes das benötigte Paket:

$ apt-get install openvpn

CyberghostVPN bietet für OpenVPN-Verbindungen monolothische Konfigurationsdateien zum Download an, welche bereits alle Einstellungen und Schlüssel enthalten. Eine solche Konfigurationsdatei kopieren wir in das Verzeichnis /etc/openvpn unter dem Namen cyberghost.conf.

Um zu verhindern, dass sämtlicher ausgehender Verkehr über den VPN-Tunnel umgeleitet wird, entfernen wir in der Konfigurationsdatei den Eintrag

redirect-gateway def1

Aus dem gleichen Grund nehmen wir zusätzlich die folgende Zeile auf:

route-noexec

Um Fehlermeldungen zu vermeiden, sind die folgenden Zeilen zu entfernen:

dhcp-renew dhcp-release

Da CyberghostVPN die Authentifizierung mittels eines Benutzernamens und Passworts verlangt, verweisen wir in der Konfiguration auf eine externe Datei, in welcher wir diese hinterlegen:

auth-user-pass ./cyberghost/cyberghost.secret

Zusätzlich konfigurieren wir ein Start-Skript, welches benötigt wird, um Manipulationen am Routing durchzuführen sobald die Tunnelverbindung steht:

up ./cyberghost/cyberghost-up

Nach Abschluss der beschriebenen Modifikationen sollte der Kopf der Konfigurationsdatei /etc/openvpn/cyberghost.conf in etwa wie folgt aussehen:

client remote se.openvpn.cyberghostvpn.com 9081 dev tun proto udp auth-user-pass ./cyberghost/cyberghost.secret resolv-retry infinite persist-key persist-tun nobind route-noexec cipher AES-256-CBC auth MD5 ping 5 ping-exit 60 ping-timer-rem explicit-exit-notify 2 script-security 2 remote-cert-tls server route-delay 5 tun-mtu 1500 fragment 1300 mssfix 1300 verb 4 comp-lzo up ./cyberghost/cyberghost-up

Wir legen als nächstes das Unterverzeichnis /etc/openvpn/cyberghost an:

$ mkdir /etc/openvpn/cyberghost

In diesem hinterlegen wir unseren CyberghostVPN-Benutzernamen und Schlüssel in der datei /etc/openvpn/cyberghost/cyberghost.secret. Die Dateiu enthält in der ersten Zeile den Benutzernamen und in der zweiten Zeile den Schlüssel. Die Datei sollte in etwa wie folgt aussehen:

CG7043533734 8jDDks,d003dD

Um unberechtigten Zugriff zu verhindern, beschränken wir den Zugriff auf den Besitzer der Datei (root):

$ chmod 600 /etc/openvpn/cyberghost/cyberghost.secret

Jetzt fehlt nur noch das Start-Skript. Dieses platzieren wir in der Datei /etc/openvpn/cyberghost/cyberghost-up. Die Befehle in der 2. und 3. Zeile richten in der Routing-Tabelle 42 eine Standardroute zum VPN-Server ein. Die Routing-Tabelle 42 regelt das Routing des über das Mesh-VPN eingehenden Verkehrs (siehe Konfiguration der bat0-Schnittstelle oben und der Firewall weiter unten). Die Adresse des VPN-Servers wird über den Platzhalter $5 übergeben. Danach starten wir mit “service dnsmasq restart” dnsmasq neu, so dass der Dämon die neue Netzwerkverbindung wahrnimmt und DNS-Server über den Tunnel anspricht.

1. !/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 service dnsmasq restart exit 0

Das Skript machen wir noch mit dem folgenden Befehl ausführbar:

$ chmod +x /etc/openvpn/cyberghost/cyberghost-up

Danach sind wir soweit, dass wir die Tunnelverbindung aufbauenkönnen:

$ service openvpn start

In Zukunft wird die Verbindung automatisch aufgebaut werden, wenn das Gateway hochgefahren wird. Nach kurzer Zeit sollte eine zusätzliche Netzwerkschnittstelle tun0 erscheinen (Abfrage mittels ifconfig). Sollte dies nicht der Fall sein, empfiehlt es sich die Log-Einträge unter /var/log/daemon.log zu überprüfen. OpenVPN-Verbindung automatisch überprüfen

Ein generelles Problem mit VPN-Verbindungen ist, dass diese abreißen können. In diesem Fall würde batman-adv nachwievor versuchen, den ausgehenden Internetverkehr über das Gateway weiterzuleiten. Der Grund hierfür ist, dass wir batman-adv im Zuge der Aktivierung mittels “batctl gw server” in den Server-Modus versetzt haben. Die betroffenen Pakete würden verloren gehen und die verbundenen Klienten wären vom Internet abgeschnitten. Um dies zu verhindern, legen wir in der Datei /usr/local/bin/check-gateway das folgende Skript an:

1. !/bin/bash

INTERFACE=tun0 # Set to name of VPN interface shopt -s nullglob

1. Test whether gateway is connected to the outer world via VPN

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

1. Iterate through network interfaces in sys file system

for MESH in /sys/class/net/*/mesh; do

1. Check whether gateway modus needs to be changed

OLD_STATE="$(cat $MESH/gw_mode)" [ "$OLD_STATE" == "$NEW_STATE" ] && continue

echo $NEW_STATE > $MESH/gw_mode
echo 54MBit/54MBit > $MESH/gw_bandwidth
logger "batman gateway mode changed to $NEW_STATE"

# Check whether gateway modus has been deactivated
if [ "$NEW_STATE" == "off" ]; then
# Shutdown DHCP server to prevent renewal of leases
service isc-dhcp-server stop 
# Shutdown radvd daemon to prevent advertisment of server as gateway
service radvd stop
fi 

# Check whether gateway modus has been activated
if [ "$NEW_STATE" == "server" ]; then
# Restart DHCP server and radvd daemon
service isc-dhcp-server start
service radvd start
fi

done

Das Skript pingt über die OpenVPN-Schnittstelle tun0 den Google DNS-Server 8.8.8.8 an. Ist dieser nicht erreichbar, wird der Gateway-Modus in batman-adv über das Sys-Dateisystem deaktiviert. Zusätzlich deaktivieren wir den DHCP-Server und radvd-Dämonen. Klienten im Freifunknetz haben damit die Möglichkeit, sich einen alternativen Weg ins Internet zu suchen (d.h. über ein anderes Gateway). Umgekehrt wird der Gateway-Modus wieder aktiviert, sobald der DNS-Server erreichbar ist. Mit den folgenden Kommandos stellen wir sicher, dass das Skript allein von root ausgeführt werden kann:

$ chown root.root check-gateway $ chmod ug+x check-gateway

Danach nehmen wir die folgenden Zeilen in die Datei /etc/crontab auf, um das Skript einmal pro Minute auszuführen und damit den Gateway-Status zu überprüfen.

1. Check whether internet still reachable via openvpn tunnel

• * * * * root check-gateway > /dev/null

Die Änderungen übernehmen durch einen Neustart des Cron-Dämonen:

$ service cron restart

Firewall

Endspurt! Jetzt fehlt uns nur noch die Konfiguration der Firewall bevor wir am Ziel sind. Um die Firewall-Konfiguration permanent zu speichern, installiern wir zunächst das folgende Paket:

$ apt-get install iptables-persistent

Im Anschluss ersetzen wir den Inhalt der Datei /etc/iptables/rules.v4 mit dem folgenden Absatz. In der Grund-Konfiguration bleibt die Firewall komplett offen. Die Zahlenwerte in den eckigen Klammern sind Paket- und Byte-Zähler und können an dieser Stelle ignoriert werden. Für die Umleitung des ausgehenden Internetverkehrs über den VPN-Tunnel sind die PREROUTING und POSTROUTING Befehle unter *mangle und *nat entscheidend. Der Eintrag “-A PREROUTING -i br-ff3l -j MARK –set-xmark 0x1/0xffffffff” bewirkt, dass über die Brücke br-ff3l (und damit über das Mesh-VPN) eingehender Verkehr mittels der Ziffer 0x1 markiert wird. Die im Zuge der Kongifuration der bat0-Schnittstelle angelegte Routing-Regel (siehe oben) bewirkt wiederum, dass mit der Ziffer 0x1 markierter Verkehr gemäß der Routing-Tabelle 42 weitergeleitet wird. In dieser hatten wir eine Standardroute über den VPN-Tunnel definiert. Damit alle über den VPN-Tunnel ausgehende Pakete auch eine globale IP-Adresse aufweisen, aktivieren wir mittels “-A POSTROUTING -o tun0 -j MASQUERADE” das IP-Masquerading. Die Firewall ersetzt in der Folge lokale IP-Adressen aus dem Freifunk-Netz mit der globalen IP-Adresse des Gateways. Eingehende Pakete werde analog modifiziert, so dass sie ihren Weg zurück in das Freifunknetz finden. Wer sich durch die Details der Konfiguration arbeiten möchte, dem sei folgendes Howto empfohlen.

1. Generated by iptables-save v1.4.14 on Sat May 10 00:21:44 2014

• filter

INPUT ACCEPT [0:0]

FORWARD ACCEPT [0:0]

OUTPUT ACCEPT [0:0]

COMMIT

• mangle

PREROUTING ACCEPT [0:0]

INPUT ACCEPT [0:0]

FORWARD ACCEPT [0:0]

OUTPUT ACCEPT [0:0]

POSTROUTING ACCEPT [0:0]

-A PREROUTING -i br-ff3l -j MARK --set-xmark 0x1/0xffffffff COMMIT

• nat

PREROUTING ACCEPT [0:0]

INPUT ACCEPT [0:0]

OUTPUT ACCEPT [0:0]

POSTROUTING ACCEPT [0:0]

-A POSTROUTING -o tun0 -j MASQUERADE COMMIT

1. Completed on Sat May 10 00:21:44 2014

Noch eine allerletzte Tat, damit die Regeln für die Umleitung auch greifen: Im Skript /etc/rc.local nehmen wir die Zeilen des folgenden Abschnitts auf, um das Routing für unzustellbare Pakete sowie über die Brücke br-ff3l eingehende Pakete (angezeigt durch die Markierung 0x1) gemäß Routing-Tabelle 42 zu aktivieren:

/sbin/ip route add unreachable default table 42 /sbin/ip rule add from all fwmark 0x1 table 42 exit 0

Nach der ersten Einrichtung starten wir das Skript manuell. In Zukunft wird es beim Hochfahren des Gateway automatisch ausgeführt werden:

$ /etc/rc.local

Abschluss

Sollte alles wie beschrieben funktioniert haben, so seid ihr ab sofort stolzer Betreiber eines Gluon-Internet-Gateways! Ob das Gateway tatsächlich funktioniert, testet man am besten mittels eines Endgeräts, welches über einen Gluon WLAN-Router aufs Internet zugreift. Euer Gateway muss hierfür selbstverständlich vor der Kompilierung des Gluon-Images in der site.conf konfiguriert worden sein (siehe Gluon kompilieren). Sollte der Zugriff vom Endgerät aufs Internet nicht auf Anhieb funktionieren, empfiehlt es sich zuerst zu überprüfen, ob eine Verbindung des Routers über fastd zustande kommt. Im Anschluss sollte man überprüfen, ob der Router mittels DHCP eine IPv4-Adresse beziehen konnte und DNS-Server übermittelt wurden. Sollte dies alles einwandfrei funktionieren, so ist die Firewall-Konfiguration noch einmal gründlich zu überprüfen. Wir wünschen gutes Gelingen!