Gateways
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).
...
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
Inhaltsverzeichnis
Etckeeper
Um Änderungen an der Konfiguration des Servers besser verfolgen zu können, installieren wir als erstes das Paket etckeeper:
$ apt-get install etckeeper
Im Anschluss aktivieren wir die Versionierung des Konfigurationsverzeichnisses /etc:
$ etckeeper init /etc
In seiner Standardkonfiguration verwendet etckeeper die Software git zur Versionierung. Um lästige Warnungen zu vermeiden, vervollständigen wir die git-Konfiguration mit den zwei folgenden Befehlszeilen. Falls git bereits vollständig konfiguriert wurde, kann dieser Schritt übersprungen werden.
$ git config --global user.name "Freifunk 3Laendereck" $ git config --global user.email admin@freifunk-3laendereck.de
batman-adv
Im nächsten Schritt installieren wir das batman-adv Kernel-Modul 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 | apt-key add - $ gpg -a --export 16EF3F64CB201D9C | apt-key add -
Jetzt sind wir soweit, dass wir die benötigten Pakete mittels der folgenden Befehlszeilen bequem installieren können:
$ apt-get update $ apt-get install batman-adv-dkms $ apt-get install batctl
Im Anschluss müssen wir noch das batman-adv Modul in den Kernel laden:
$ modprobe batman-adv
Achtung: Unter Debian Jessie wird das Modul nicht installiert. Es kommt während der Installation die Meldung, dass die installierte Version neuer ist als die zu installierende Version. Lösung: Wir erzwingen die Installation des Moduls von Hand:
$ dkms remove batman-adv/2013.4.0 --all $ dkms install --force batman-adv/2013.4.0
Auch batctl ist zu neu und muss unter Debian Jessie nochmals manuell installiert und fixiert werden.
$ apt-get remove batctl $ wget http://repo.universe-factory.net/debian/pool/main/b/batctl/batctl_2013.4.0-1_amd64.deb $ dpkg -i batctl_2013.4.0-1_amd64.deb $ echo "batctl hold" | dpkg --set-selections
Danach ermitteln wir die installierten Kernel- und Kernel-Header-Module:
$ dpkg --get-selections | grep linux
Schließlich fixieren wir sämtliche Pakete mit dem Präfix "linux-headers" bzw. "linux-image" auf die aktuelle Version. Der Platzhalter <version> ist durch den zuvor angezeigten Versionsbezeichner zu ersetzen:
$ echo "linux-headers-<version>-amd64 hold" | dpkg --set-selections $ echo "linux-headers-<version>-common hold" | dpkg --set-selections $ echo "linux-image-<version>-amd64 hold" | dpkg --set-selections $ echo "linux-headers-amd64 hold" | dpkg --set-selections $ echo "linux-image-amd64 hold" | dpkg --set-selections
Damit das Kenel-Modul in Zukunft automatisch während des Boot-Vorgangs geladen wird, fügen wir noch die folgende Zeile der Datei /etc/modules hinzu:
batman-adv
fastd
Im nächsten Schritt richten wir den VPN-Dämonen fastd ein. Dieser kann ü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 fastd 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/ff3l $ mkdir /etc/fastd/ff3l/peers
Als nächstes generieren wir ein Schlüsselpaar und speichern es in der Dateil keys:
$ cd /etc/fastd/ff3l $ 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 in der Datei /etc/fastd/ff3l/secret.conf in Form der folgenden Zeile:
secret "90722f73f2c23b672ad419f66191420444a3e7a9a69c9fa139e0da096570b857";
Der eingetragene Schlüssel muss 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 von fastd benötigt, wohl aber später für die Konfiguration der Klienten. Abschließend erzeugen wir die zentrale Konfigurationsdatei /etc/fastd/ff3l/fastd.conf mit folgendem Inhalt:
# Log warnings and errors to stderr log level info; # Log everything to syslog log to syslog level info; # Set the interface name interface "ff3l-mesh-vpn"; # Enable encryption methods method "salsa2012+umac"; method "salsa2012+gmac"; method "xsalsa20-poly1305"; method "aes128-gcm"; # Bind to a fixed port, IPv4 only bind 0.0.0.0:10000; # Secret key generated by `fastd --generate-key` include "secret.conf"; # Enforce secure handshakes secure handshakes yes; # Set the interface MTU for TAP mode with xsalsa20/aes128 over IPv4 with a base MTU of 1492 (PPPoE) # (see MTU selection documentation) mtu 1426; # Include peers from the directory 'peers' include peers from "peers"; # Activate batman-adv network interface on up " ifup bat0 ip link set address <MAC address> up dev $INTERFACE "; # Deactivate batman-adv network interface on down " ifdown bat0 ";
Der Platzhalter <MAC address> ist mit einer beliebigen, jedoch für das jeweilige Gateway eindeutigen MAC-Adresse zu ersetzen. Im Unterverzeichnis /etc/fastd/freifunk/peers werden wir zu einem späteren Zeitpunkt für jeden Klienten eine Datei mit dem öffentlichen Schlüssel anlegen. Der öffentliche Schlüssel wird von Gluon auf den Knoten zum Zeitpunkt der Erstkonfiguration angelegt und muss per e-Mail an die Gateway-Administratoren übermmittelt werden. Beispiel für eine Konfigurationsdatei:
# <Name des Klienten> # <Kontaktadresse> key "INCOMING_CONNECTION_PARTNER_PUBLIC_KEY";
Jetzt müssen wir den fastd-Server nur noch starten:
/etc/init.d/fastd start
Da mit der Installation von fastd gleichzeitig die zugehörigen Links in den /etc/rc.X-Verzeichnissen erstellt wurde, startet fastd beim nächsten Bootvorgang automatisch.
Netzwerkschnittstellen
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 Zeilen 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 der folgenden Befehlszeile:
$ sysctl -p /etc/sysctl.conf
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 und für das Gateway eindeutig sein. Die Platzhalter <IPv6 address> und <IPv4 address> sind entsprechend zu ersetzen:
# FF3L mesh interfaces iface br-ff3l inet6 static bridge-ports none address <IPv6 address> netmask 44
iface br-ff3l inet static address <IPv4 address> netmask 255.255.0.0
Neben der Brücke konfigurieren wir in der selben Datei die Batman-Schnitstelle 'bat0':
iface bat0 inet6 manual pre-up modprobe batman-adv pre-up batctl if add ff3l-mesh-vpn pre-up batctl gw server 100mbit/100mbit 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 post-up start-stop-daemon -b --start --exec /usr/sbin/alfred -- -i br-ff3l -b bat0; post-up start-stop-daemon -b --start --exec /usr/sbin/batadv-vis -- -i bat0 -s; pre-down brctl delif br-ff3l $IFACE || true pre-down start-stop-daemon --stop --exec /usr/sbin/batadv-vis pre-down start-stop-daemon --stop --exec /usr/sbin/alfred down ip link set $IFACE down
Bevor die Schnittstelle aktiviert wird, stellen wir mittels des Kommandos “pre-up modprobe batman-adv” sicher, dass das Kernel-Modul batman-adv geladen und aktiv ist. Mittels “pre-up batctl if add ff3l-mesh-vpn” ordnen wir die Schnittstelle für das Mesh-VPN der Batman-Schnittstelle zu und aktivieren somit das automatische Routing. Im Anschluss konfigurieren wir das Gateway mittels “pre-up batctl gw server 100mbit/100mbit” als Server, so dass DHCP-Anfragen von Batman zugestellt werden. Die Bandbreiten (Downlink/Uplink) sind ggf. anzupassen. 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ücke 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 10s). 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 unten). Vor dem Herunterfahren von bat0 lösen wir die Schnitstelle mit “pre-down brctl delif br-ff3l $IFACE || true” wieder aus der Brücke.
Nach der Einrichtung der Brücke müssen wir diese ein einziges Mal von Hand starten. Zusätzlich starten wir fastd erneut, welcher im Zuge des Neustarts wiederum die Batman-Schnittstelle bat0 aktiviert (siehe “on up”-Anweisung 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-Netzwerkkonfiguration zuzuweisen. 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 Adresse des DNS-Servers/Routers ist der statischen Adresse des Gateways gleichzusetzen. Der Platzhalter <IPv4 address> ist entsprechend zu ersetzen. Beim zu vergebenden Adressbereich (hier 10.119.1.1 bis 10.119.255.254) ist für das jeweilige Gateway anzupassen:
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 {
# monitor: 80% 90% Y Freifunk Clients
authoritative;
range 10.119.8.32 10.119.9.255;
option domain-name-servers <IPv4 address>;
option routers <IPv4 address>;
}
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. Im Anschluss starten wir den Dämonen neu:
$ touch /etc/dhcp/static.conf $ service isc-dhcp-server restart
Radvd
Um die Autokonfiguration von IPv6-Adressen auf der Basis von Link-Layer-Adressen zu ermöglichen, richten wir den 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 (f2001:bf7:20::) mit sowie die statische IPv6-Adresse unseres Gateways als rekursiven DNS-Server. Der Platzhalter <IPv6 address> ist entsprechend zu ersetzen:
interface br-ff3l
{
AdvSendAdvert on;
MaxRtrAdvInterval 200;
prefix 2001:bf7:20::/64 { };
RDNSS <IPv6 address> { };
};
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. bind) 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/ff3l noch die von uns favorisierten DNS-Server ein (primär: lokaler DNS-Server, sekundär: Google DNS-Server). Weiterhin leiten wir Anfragen für die TLD .ff3l an den lokalen DNS-Server weiter:
# Forward regular DNS requests server=127.0.0.1 server=8.8.4.4
# FF3L forward lookup server=/ff3l/127.0.0.1 # FF3L reverse lookup server=/119.10.in-addr.arpa/127.0.0.1 server=/2.0.0.7.f.b.0.1.0.0.2.ip6.arpa/127.0.0.1
Damit die Änderungen wirksam werden, starten wir dnsmasq neu:
$ service dnsmasq restart
OpenVPN-Verbindung
Noch nicht aktualisiert! 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.
#!/bin/sh ip route replace 0.0.0.0/1 via $5 dev $1 table 42 ip route replace 128.0.0.0/1 via $5 dev $1 table 42 service dnsmasq restart exit 0
Tipp: Im Fall des hide.me VPN-Anbieters wurde festgestellt, dass keine entfernte IP-Adresse übermittelt wird. In diesem Fall ist das Argument $5 leer und die Befehle "ip route ..." schlagen fehl. Als Lösung lässt sich alternativ die lokale IP-Adresse in $4 verwenden, um die Routen im BDS-Kompatibilitätsmodus zu setzen.
Das Skript machen wir noch mit dem folgenden Befehl ausführbar:
$ chmod +x /etc/openvpn/cyberghost/cyberghost-up
In /etc/default/openvpn:
AUTOSTART="all"
Änderung übernehmen:
sudo systemctl daemon-reload
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
Gateway Check
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:
#!/bin/bash INTERFACE=tun0 # Set to name of VPN interface shopt -s nullglob # 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 # Iterate through network interfaces in sys file system for MESH in /sys/class/net/*/mesh; do # 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.
# 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
Noch nicht aktualisiert! 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.
# 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 # 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
I...
$ service netfilter-persistent restart
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!
...
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!
