Hamburg/Gateway

Aus wiki.freifunk.net
Zur Navigation springenZur Suche springen

Freifunk Hamburg

Anforderungen

Grundsätzlich kann man keine idealen Mindestanforderungen vorgeben. Um einen kleinen Überblick darüber zu bieten was aber in etwa notwendig ist, haben wir eine kleine Zusammenfassung gebastelt.


Übersicht

Netze

Netzwerk IP-Bereich ASN
ICVPN 10.112.0.0/18 65112
ULA fd51:2bb2:fd0d::/64 65112
Förderverein 2001:bf7:180::/44
Rheinland 2a03:2267::/32 49009
Richtfunk 10.112.62.1 – 10.112.63.255 n/a

IPv4

Hamburg ist das Netz 10.112.0.0/16 zugeteilt. Daraus nutzen wir im Mesh das Netz 10.112.0.0/18. (Temporär für das Kampnagel-GW: 10.112.64.0/18)

IPv6

Uns sind in Hamburg folgende Netze zugeteilt (siehe hier und hier):

  • Unique Local Unicast Netz: fd51:2bb2:fd0d::/48
  • Öffentliche Netze 2001:bf7:180::/44, 2001:bf7:190::/44, 2001:bf7:200::/44, 2001:bf7:210::/44, 2001:bf7:220::/44 und 2001:bf7:230::/44

Im Mesh werden davon fd51:2bb2:fd0d::/64 und 2001:bf7:180::/64 genutzt, wobei letzteres auch ins Internet geroutet wird. Dadurch ist Internetzugang per IPv6 ohne VPN ins Ausland möglich. Gleichzeitig ist das gesamte Freifunk Netz aus dem Internet erreichbar.

(Temporär für das Kampnagel-GW benutzen wir das jeweils nächste /64, also: fd51:2bb2:fd0d:a0b::/64 und 2001:bf7:180:a0b::/64)

Infrastruktur

Element IPv6 ULA RFC1918 DHCP ICVPN-Transit B.A.T.M.A.N.-adv. MAC(s) Dienste Standort Betreuer Internet-Gateway
srv01 2a03:2267::101 fd51:2bb2:fd0d::101 10.112.1.1 n/a de:ad:be:ef:08:15 Primary DNS: hamburg.freifunk.net., ffhh.
postmaster, mail, smtp, imap
meta.
www.
formular.
graph.
git.
media.
1.ntp.services.ffhh
1.updates.services.ffhh 		VM auf worker NOC n/a
srv02 2a03:2267::102 fd51:2bb2:fd0d::102 10.112.1.2 n/a de:ad:be:ef:08:16 2.ntp.services.ffhh
2.updates.services.ffhh
media. 		NOC n/a
gw01 2a03:2267::202 fd51:2bb2:fd0d::202 10.112.1.11 10.112.2.2 – 10.112.9.254 n/a de:ad:be:ef:01:01 n/a artfiles NOC IPv4: Rheinland
IPv6: peering
gw02 2a03:2267::201 fd51:2bb2:fd0d::201 10.112.42.1 10.112.10.2 – 10.112.17.254 n/a de:ad:be:ef:05:05 n/a n@work NOC IPv4: Rheinland
IPv6: peering
gw03 2a03:2267::301 fd51:2bb2:fd0d::301 10.112.1.3 10.112.18.2 – 10.112.25.254 n/a de:ad:be:ef:03:03 n/a IPHH NOC IPv4: Rheinland
IPv6: peering
gw05 2a03:2267::d01 10.112.1.5 10.112.34.2 – 10.112.41.254 de:ad:be:ef:22:22
de:ad:be:ef:22:23 		n/a VM auf priv. Host bei Hetzner leo IPv4: Rheinland
gw08 2a03:2267::b01 fd51:2bb2:fd0d::b01 10.112.1.8 10.112.50.2 – 10.112.53.254 n/a de:ad:be:ef:88:88
de:ad:be:ef:88:89 		n/a VM auf priv. Host bei Hetzner, RZ20 peter Mullvad 2
gw09 2a03:2267::901
2a01:4f8:120:438c::2 		fd51:2bb2:fd0d::901 10.112.1.9 10.112.54.2 – 10.112.57.254 n/a de:ad:be:ef:66:66
de:ad:be:ef:66:67 		n/a Dedizierter Server bei Hetzner thomas Mullvad 2
gw12 2a03:2267::501 fd51:2bb2:fd0d::501 10.112.1.12 10.112.58.2 – 10.112.61.254 n/a de:ad:be:ef:01:14
de:ad:be:ef:01:15 		n/a VM bei netcup martin Mullvad 2
wandale0 2a00:ea8:100:8::2 eBGP n@work NOC
wende0 2001:868:100:d00::10 eBGP IPHH NOC
suede0 2a00:1f78:c:e::e eBGP artfiles NOC

Benutzerverwaltung

Zunächst sollte die Benutzer eingerichtet werden, die Zugriff auf das gateway haben sollen. Nehmen wir an, ein Nutzer soll sudo-Rechte bekommen wird er wie folgt angelegt 

useradd -m -G sudo **BENUTZERNAME**

Zunächst wird ein dummy-Kennwort vergeben, dass dem Benutzer mitgeteilt wird: 

passwd **BENUTZERNAME**

Das Kennwort wird auf abgelaufen gesetzt, damit er sich bei der ersten Anmeldung gleich selbst ein neues geben muss: 

chage -d0 **BENUTZERNAME**

Die öffentlichen ssh-Schlüssel der freifunker liegen auf github. Der Schlüssel wird für einen Benutzer autorisiert: 

mkdir /home/**BENUTZERNAME**/.ssh
touch /home/**BENUTZERNAME**/.ssh/authorized_keys
vi /home/**BENUTZERNAME**/.ssh/authorized_keys

Dann den Schlüssel einfügen. Auf die Datei darf nur die vom jeweiligen Benutzer zugegriffen werden: 

chown **BENUTZERNAME**:**BENUTZERNAME** /home/**BENUTZERNAME**/.ssh -R

Sind die wichtigen Benutzer angelegt und sind alle Anmeldungen erfolgreich getestet, sollte aus Sicherheitsgründen verhindert werden, dass sich root direkt anmelden kann und dass Benutzer sich über ihr Kennwort anmelden können. Sie sollen sich also nur noch über ihren ssh-Schlüssel anmelden: 

vi /etc/ssh/sshd_config

Das geschieht, indem die folgenden drei Parameter gesetzt werden. 

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes

Einwahlknoten

Im ersten Schritt der gateway-Konfiguration wird zunächst nur sicher gestellt, dass er die Knoten untereinander vernetzt, ohne das bereits ein Internetzugang bereitgestellt wird. Dazu werden folgende Tätigkeiten durchgeführt:

  • Quell-Listen für fastd und B.A.T.M.A.N. definieren
  • Installation von fastd, B.A.T.M.A.N. und bridge-utils
  • Konfiguration der Netzwerkschnittstellen
  • Installation von git
  • Clonenen des Schlüssel-repos
  • Automatisches importieren der fastd-Schlüssel der Knoten
  • Hochfahren


Quell-Listen definieren

$ vim /etc/apt/sources.list 

deb http://security.debian.org/ wheezy/updates main contrib non-free
deb-src http://security.debian.org/ wheezy/updates main contrib non-free
 
# fastd
deb http://ftp.de.debian.org/debian wheezy-backports main
deb https://repo.universe-factory.net/debian/ sid main

Schlüssel für repo importieren:

gpg --keyserver pgpkeys.mit.edu --recv-key 16EF3F64CB201D9C
gpg -a --export 16EF3F64CB201D9C | apt-key add -
sudo apt-key adv --recv-keys --keyserver keys.gnupg.net 16EF3F64CB201D9C

Installation von fastd, B.A.T.M.A.N. und bridge-utils

Packetmanager aktualisieren:

# apt-get update

Installieren:

# apt-get install batctl batman-adv-dkms fastd bridge-utils

Neue Datei, Autostart des B.A.T.M.A.N.-Moduls

# vim /etc/modules 

batman-adv

Konfiguration der Netzwerkschnittstellen

fastd

$ mkdir /etc/fastd/ffhh-mesh-vpn

Neue Datei anlegen und eine ausgedachte MAC einsetzen (mit : als Trennzeichen). Die MAC-Adressen sollten dem de:ad:be:ef Schema folgen und sollte hier vermerkt werden. Sie muss der gateway-AG mitgeteilt werden, damit sie die in die Schlüsseldatei des neuen gateways in fastd-Schlüsselrepo eintragen.
$ vim /etc/fastd/ffhh-mesh-vpn/fastd.conf 

log to syslog level debug;
interface "ffhh-mesh-vpn";
method "salsa2012+gmac"; # new method, between gateways for the moment (faster)
method "xsalsa20-poly1305"; # old method
bind 0.0.0.0:10000;
hide ip addresses yes;
hide mac addresses yes;
include "secret.conf";
mtu 1426; # 1492 - IPv4 Header - fastd Header...
include peers from "peers";
on up "
 ifup bat0
 ip link set address **HIER AUSGEDACHTE MAC EINSETZEN** up dev $INTERFACE
";

Einen fastd Schlüsselpaar erzeugen kann man über:

$ fastd --generate-key

ABER, dies ist bei der Einrichtung eines neuen gateways idR. nicht notwendig(!). Damit nicht bei jedem hinzukommenden gateway eine Aktualisierung der firmware über alle router gefahren werden muss, wurden Schlüsselpaare für 20 gateways vorgeneriert und die öffentl. Schlüssel bereits in die firmware integriert. Es gilt also den passenden privaten Schlüssel für das aufzusetzende gateway von der gateway AG zu bekommen (Freifunk_Hamburg/FastdKeys). Dieser geheime Schlüssel wird dann in eine neue Datei eingetragen (Anführungszeichen & Semikolon nicht vergessen). Der dazugehörige öffentliche Schlüssel muss wie die MAC ebenfalls Sie von der gateway-AG in die Schlüsseldatei des neuen gateways in fastd-Schlüsselrepo eintragen werden.

$ vim /etc/fastd/ffhh-mesh-vpn/secret.conf 

secret "**HIER GEHEIMEN SCHLUESSEL EINSETZEN**";

Pubkey kann anschliessend mit $ fastd -c /etc/fastd/ffhh-mesh-vpn/fastd.conf --show-key angezeigt werden.

SSH-Schlüsselpaar erzeugen zur Verbindung des gateways mit dem geschlossenen git repo, welches die fastd Schlüssel der nodes enthält:

Damit das neue gateway das fastd-Schlüsselrepo lesen kann, muss es sich identifizieren. Dafür wird ein ssh-Schlüssel erzeugt:

$ ssh-keygen

Den öffentlichen Schlüssel an gateway-AG senden. Der nächste Schritt (Klonen des repos) funktioniert erst, wenn der Schlüssel von der gateways AG eingetragen wurde.

Brückenschnittstelle

Brückenschnittstelle anlegen. Verwendete IP Adressen (v4 & v6) müssen dokumentiert werden. An die Datei interfaces wird angehängt:

$ vim /etc/network/interfaces 

auto br-ffhh        
iface br-ffhh inet6 static
 bridge-ports none
 address **STATISCHE IPv6 DES GATEWAYS EINSETZEN; BEISPIEL FÜR GW03 fd51:2bb2:fd0d:0::c01**
 netmask 64 
iface br-ffhh inet static
 address **STATISCHE IPv4 DES GATEWAYS EINSETZEN; BEISPIEL FÜR GW02 10.112.12.1**
 netmask 255.255.192.0 

allow-hotplug bat0
iface bat0 inet6 manual
 pre-up modprobe batman-adv
 pre-up batctl if add ffhh-mesh-vpn
 up ip link set $IFACE up
 post-up brctl addif br-ffhh $IFACE
 post-up batctl it 10000
 post-up /sbin/ip rule add from all fwmark 0x1 table 42
 pre-down brctl delif br-ffhh $IFACE || true 
 down ip link set $IFACE down

git installieren

$ apt-get install git

Klonen des Schlüssel-repos

$ cd /etc/fastd/ffhh-mesh-vpn/

$ git clone git@git.hamburg.freifunk.net:fastdkeys peers

Automatisches Shell Skripte

Automatisches importieren der fastd-Schlüssel der Knoten

autoupdate_fastd_keys.sh erstellen, welches sich die fastd-Schlüssel von github holt. (Quelle: http://freifunk.in-kiel.de/debian/fastd-update)

$ mkdir /root/bin

Neues shell-Skript erzeugen:
$ vim /root/bin/autoupdate_fastd_keys.sh 

#!/bin/bash             
# Simple script to update fastd peers from git upstream
# and only send HUP to fastd when changes happend.
  
# CONFIGURE THIS TO YOUR PEER DIRECTORY
FASTD_PEERS=/etc/fastd/ffhh-mesh-vpn/peers

function getCurrentVersion() {
 # Get hash from latest revision
 git log --format=format:%H -1
}

cd $FASTD_PEERS          
      
# Get current version hash
GIT_REVISION=$(getCurrentVersion)                

# Automagically commit local changes
# This preserves local changes
git commit -m "CRON: auto commit"
 
# Pull latest changes from upstream
git fetch                                                                
git merge origin/master -m "Auto Merge"

# Get new version hash
GIT_NEW_REVISION=$(getCurrentVersion)                

if [ $GIT_REVISION != $GIT_NEW_REVISION ]
then                                                              
 # Version has changed we need to update
 echo "Reload fastd peers"
 kill -HUP $(pidof fastd)
fi

Ausführbar machen:
$ chmod +x /root/bin/autoupdate_fastd_keys.sh

Automatisches Prüfen, ob das gateway (noch) ein gateway in das Internet ist

cd /usr/local/bin
wget https://raw.githubusercontent.com/freifunkhamburg/puppet-ff_gw/master/files/usr/local/bin/check_gateway

Ausführbar machen:
chmod +x check_gateway

cronjob

cronjob erstellen, der autoupdate_fastd_keys.sh alle 5min ausführt, sowie check_gateway hinzufügen. Dazu folgende zwei Zeilen hinzufügen

$ crontab -e 

*/5 * * * *   /root/bin/autoupdate_fastd_keys.sh > /dev/null 2>&1
* * * * *   /usr/local/bin/check_gateway > /dev/null 2>&1

Hochfahren

bridge-Schnittstelle hochfahren

$ brctl addbr br-ffhh

$ ifup br-ffhh

B.A.T.M.A.N. kernel-Modul laden

$ modprobe batman-adv

fastd starten

$ service fastd start


Exit Node Gateway

Im zweiten Schritt wird das gateway auch zum gateway ins Internet und zum DHCP-server.

Benötigte software:

  • IPv4: dhcpd
  • rooting daemon für IPv6: radvd
  • VPN: openvpn
  • firewall: IPtables
  • DNS: dnsmasq

Konfigurationsdateien:

  • dhcp.conf
  • radvd.conf
  • openvpn.conf
  • iptables (NAT 44)


Installieren

$ apt-get install isc-dhcp-server radvd openvpn iptables-persistent dnsmasq

IPv4 DHCP konfigurieren

Dabei wird pro gateway ein /18er-Netz in der ffhh-IP-range 10.112.x.x vergeben. Die bereits vergebenen Subnetze sind unter https://wiki.freifunk.net/Freifunk_Hamburg/%C3%9Cber#Subnetze aufgeführt.

dhcpd.conf Inhalt ersetzen:
$ vim /etc/dhcp/dhcpd.conf 

# The ddns-updates-style parameter controls whether or not the server will
# attempt to do a DNS update when a lease is confirmed. We default to the
# behavior of the version 2 packages ('none', since DHCP v2 didn't
# have support for DDNS.)
ddns-update-style none;

# option definitions common to all supported networks...
option domain-name ".ffhh";

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

log-facility local7;

subnet 10.112.0.0 netmask 255.255.192.0 {
    authoritative;
    range 10.112.**START-IP-BEREICH** 10.112.**ENDE-IP-BEREICH**;
    
    # DNS: srv01 (10.112.1.1) & gw01 (10.112.14.1)
    option domain-name-servers **EIGENE IPv4 DES GATEWAYS im FF-NETZ**, 10.112.1.1;
    option routers **EIGENE IPv4 DES GATEWAYS im FF-NETZ**;
}

include "/etc/dhcp/static.conf";

Für die Vergabe der statischen IPs gibt's ein https://github.com/freifunkhamburg/dhcp-static. Um die Konfiguration aus dem repo zu bekommen wird der Benutzer dhcpstatic angelegt: 

useradd -m -s /bin/bash dhcpstatic

Dann wird in seinem Heimverzeichnis das git repo geconet. 

cd /home/dhcpstatic
git clone https://github.com/freifunkhamburg/dhcp-static
chown dhcpstatic:dhcpstatic dhcp-static -R
/home/dhcpstatic/dhcp-static/updateStatics.sh

Ein cronjob soll die Konfiguration aus dem repo übernehmen. 

crontab -e

*/5 * * * * /home/dhcpstatic/dhcp-static/updateStatics.sh > /dev/null 2>&1

Das Logging des dhcpd wird nun konfiguriert. Die Datei /etc/rsyslog.d/dhcpd.conf anlegen mit dem Inhalt 

local7.warn /var/log/dhcpd.log

Danach die Logdatei anlegen 

touch /var/log/dhcpd.log
chown root:adm /var/log/dhcpd.log
chmod 600 /var/log/dhcpd.log

Nun in der Datei /etc/rsyslog.conf die Zeile 

mail,news.none;              -/var/log/messages

in 

mail,news.none;local7.none              -/var/log/messages

ändern. Und die Zeile 

*.*;auth,authpriv.none;              -/var/log/syslog

in 

*.*;auth,authpriv.none;local7.none              -/var/log/syslog

ändern.

Nun rsyslog neustarten 

service rsyslog restart

Der DHCP-Dienst wird gestartet. 

service isc-dhcp-server restart

DNS per dnsmasq konfigurieren

Für die Konfiguration der DNS Auflösung gibt es ein git [1]. Um die Konfiguration aus dem repo zu bekommen wird der Benutzer ffdnsmasq angelegt: 

useradd -m -s /bin/bash ffdnsmasq

Dann wird in seinem Heimverzeichnis das git repo gecloned. 

cd /home/ffdnsmasq
git clone https://github.com/freifunkhamburg/dnsmasq
chown ffdnsmasq:ffdnsmasq dnsmasq -R
/home/ffdnsmasq/dnsmasq/updateDnsmasq.sh

Ein cronjob soll die Konfiguration aus dem repo übernehmen. 

crontab -e

*/5 * * * * /home/ffdnsmasq/dnsmasq/updateDnsmasq.sh > /dev/null 2>&1

Nun dnsmasq startet über 

service dnsmasq restart

IPv6 radvd konfigurieren

radvd.conf neu anlegen:
$ vim /etc/radvd.conf 

interface br-ffhh
{    
 AdvSendAdvert on;

 MaxRtrAdvInterval 200;

 prefix fd51:2bb2:fd0d::/64 {
 };

 RDNSS **STATISCHE IPv6 DES GATEWAYS; BEISPIEL FÜR GW03 fd51:2bb2:fd0d::c01** {
 };
};

# vim: noai:ts=4:sw=4:ff=unix:ft=text:fdm=marker

IPv4 & IPv6 forwarding aktivieren. Dazu folgende Zeilen in der sysctl.conf einkommentieren

$ vim /etc/sysctl.conf 

# Uncomment the next line to enable packet forwarding for IPv4
net.ipv4.ip_forward=1
                                                                                         
# Uncomment the next line to enable packet forwarding for IPv6
#  Enabling this option disables Stateless Address Autoconfiguration
#  based on Router Advertisements for this host
net.ipv6.conf.all.forwarding = 1

VPN konfigurieren

Vorsicht! Bei Hetzernrechnern muss vorher eine Konfigurationsdatei entfernt werden: 

mv /etc/sysctl.d/99-hetzner.conf /root

Als VPN-Dienste ins Internet werden Mullvad oder hide.me oder IPredator genutzt.

Wenn OpenVPN gestartet wird, öffnet es standardmäßig alle Tunnel, die unter /etc/openvpn konfiguriert sind. In unserem Fall brauchen wir natürlich nur einen Tunnel zum Internet, selbst wenn sowohl mullvad als auch hide.me hinterlegt sein sollten. Welcher der beiden Tunnel gestartet wird, wird eingestellt unter: 

vi /etc/default/openvpn

Mullvad

mullvad Dateien bekommt man von Andre. Diese kopieren nach

cp -r **KUNDENNUMMER** /etc/openvpn/mullvad

Dann mullvad up skript editieren

vim /etc/openvpn/mullvad/mullvad-up 

#!/bin/bash
/sbin/ip route replace 0.0.0.0/1 via $5 table 42
/sbin/ip route replace 128.0.0.0/1 via $5 table 42

/usr/sbin/service dnsmasq restart
exit 0

Es gibt Berichte, wonach mit bestimmten OpenVPN Versionen hier jeweils $4 anstatt $5 stehen muss, dass konnten wir aber bisher nicht verifizieren. Wir nutzen OpenVPN aus den Debian Backports. Ausführbar machen:
chmod +x /etc/openvpn/mullvad/mullvad-up

OpenVPN Konfigurationsdatei schreiben

vim /etc/openvpn/mullvad.conf 

client 

dev-type tun
dev mullvad

proto udp
#proto tcp

#remote openvpn.mullvad.net 1194
#remote openvpn.mullvad.net 443
#remote openvpn.mullvad.net 53
#remote se.mullvad.net # Servers in Sweden
remote nl.mullvad.net # Servers in the Netherlands

# Keep trying indefinitely to resolve the
# host name of the OpenVPN server.  Very useful
# on machines which are not permanently connected
# to the internet such as laptops.
resolv-retry infinite

# Most clients don't need to bind to
# a specific local port number.
nobind 
  
# Try to preserve some state across restarts.
persist-key 
persist-tun 

# Enable compression on the VPN link.
comp-lzo 

# Set log file verbosity.
verb 3

remote-cert-tls server

ping-restart 60

# Allow calling of built-in executables and user-defined scripts.
script-security 2

# Parses DHCP options from openvpn to update resolv.conf
route-noexec
up    /etc/openvpn/mullvad/mullvad-up

ping 10

ca /etc/openvpn/mullvad/master.mullvad.net.crt
cert /etc/openvpn/mullvad/mullvad.crt
key /etc/openvpn/mullvad/mullvad.key

hide.me

hide.me Dateien bekommt man von Andre. Diese kopieren nach

cp -r /etc/openvpn/hideme

Dann hideme up skript editieren

vim /etc/openvpn/hideme/hideme-up 

#!/bin/bash
/sbin/ip route replace 0.0.0.0/1 via $4 table 42
/sbin/ip route replace 128.0.0.0/1 via $4 table 42

/usr/sbin/service dnsmasq restart
exit 0

Ausführbar machen:
chmod +x /etc/openvpn/hideme/hideme-up

OpenVPN Konfigurationsdatei schreiben

vim /etc/openvpn/hideme.conf 

client
dev-type tun
proto udp
remote nl.hide.me 3478
cipher AES-128-CBC
resolv-retry infinite
nobind
persist-key
persist-tun
mute-replay-warnings
ca /etc/openvpn/hideme/TrustedRoot.pem
verb 3
auth-user-pass /etc/openvpn/hideme/auth.txt
reneg-sec 0
# ping 5 # this is pushed by hideme
# ping-restart 15 # this is pushed by hideme


## the following options originate from mullvad.conf
dev mullvad # this is important because other scripts rely on this device name
# Allow calling of built-in executables and user-defined scripts.
script-security 3 system
# Parses DHCP options from openvpn to update resolv.conf
route-noexec # use our script (next option)
up    /etc/openvpn/hideme/hideme-up # this sets the default route for freifunk traffic, is the same for hideme and mullvad

IPredator

Die IPredator Dateien kopieren nach

cp -r /etc/openvpn/ipredator

Dann das ipredator-up Script editieren

vim /etc/openvpn/ipredator/ipredator-up 

  #!/bin/sh

 IP=$4
 
 BASE="$(echo $IP | cut -d. -f1-3)"
 LSV="$(echo $IP | cut -d. -f4)"
 
 if test $LSV -gt 128; then
         LSV=128
 else
         LSV=0
 fi
 
 echo $LSV
 
 GW=$BASE.$((LSV+1))
 SERVER=$BASE.$((LSV+2))
 
 ip route add $SERVER/32 via 212.12.51.129
 
 ip route del 0.0.0.0/1 table 42
 ip route del 128.0.0.0/1 table 42
 
 ip route add 0.0.0.0/1 via $GW table 42
 ip route add 128.0.0.0/1 via $GW table 42
 exit 0

Ausführbar machen:
chmod +x /etc/openvpn/ipredator/ipredator-up

OpenVPN Konfigurationsdatei schreiben und die entsprechenden Zertifikate einsetzen.

vim /etc/openvpn/ipredator.conf 

 client
 dev mullvad
 dev-type tun
 proto udp
 remote pw.openvpn.ipredator.se 1194
 remote pw.openvpn.ipredator.me 1194
 remote pw.openvpn.ipredator.es 1194
 resolv-retry infinite
 nobind
 auth-user-pass /etc/openvpn/ipredator/IPredator.auth
 auth-retry nointeract
 ca [inline]
 tls-client
 tls-auth [inline]
 ns-cert-type server
 keepalive 10 30
 cipher AES-256-CBC
 persist-key
 persist-tun
 comp-lzo
 tun-mtu 1500
 mssfix 1200
 passtos
 verb 3
 route-noexec
 script-security 2
 up    /etc/openvpn/ipredator/ipredator-up
 <ca>
 -----BEGIN CERTIFICATE-----
 ...
 -----END CERTIFICATE-----
 </ca>
 <tls-auth>
 -----BEGIN OpenVPN Static key V1-----
 ...
 -----END OpenVPN Static key V1-----
 </tls-auth>

In der Datei /etc/openvpn/ipredator/IPredator.auth Username (in der ersten Zeile) und Passwort (in der zweiten Zeile) hinterlegen.

IPtables anpassen

$ vim /etc/iptables/rules.v4 

# Generated by iptables-save v1.4.14 on Sun Mar 24 14:14:50 2013
*filter
:INPUT ACCEPT [273:40363]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [194:28568]
COMMIT
# Completed on Mon Mar 25 19:41:40 2013
# Generated by iptables-save v1.4.14 on Mon Mar 25 19:41:40 2013
*mangle
:PREROUTING ACCEPT [286:41734]
:INPUT ACCEPT [273:40363]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [194:28568]
:POSTROUTING ACCEPT [194:28568]
-A PREROUTING -i br-ffhh -j MARK --set-xmark 0x1/0xffffffff
COMMIT
# Completed on Mon Mar 25 19:41:40 2013
# Generated by iptables-save v1.4.14 on Mon Mar 25 19:41:40 2013
*nat
:PREROUTING ACCEPT [15:1459]
:INPUT ACCEPT [2:88]
:OUTPUT ACCEPT [1:74]
:POSTROUTING ACCEPT [1:74]
-A POSTROUTING -o mullvad -j MASQUERADE
COMMIT
# Completed on Mon Mar 25 19:41:40 2013

rc.local editieren. Alle 0x1 makierten Pakete nach Regel 42 behandeln $ vim /etc/rc.local 

#!/bin/sh -e
# 
# rc.local
# 
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
# 
# In order to enable or disable this script just change the execution
# bits.
# 
# By default this script does nothing.

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

IPtables starten 

/etc/init.d/iptables-persistent start

Peering

Diese Anleitung ermöglicht es den gateways über ICPVN mit anderen Städten Verbindung auf zu bauen. ICVPN nutzt tinc als VPN. bird6 dient zum Routenaustausch zwischen den gateways. Alle folgenden Beispiele beziehen sich auf das gateway03. Die Einträge müssen bei neuen gateways entsprechend angepasst werden.

Tinc ist ein VPN client, der die Städte untereinander verbindet. Er muss also nur installiert werden, wenn das gateway externes peering zu anderen Städten machen soll. Internes peering geht ohne tinc über die bestehenden fastd Tunnel. In beiden fällen erfolgt der Routenaustausch über BGP. In der Regel recht es, wenn zwei gateways extern peeren. Denn für jede Änderung der Konfiguration müssen alle teilnehmenden Städte ihre Konfiguration anpassen.

Installieren:
$ aptitude install tinc bird bird6

tinc

Im freifunk-Wiki unter Intercity VPN im Abschnitt BGP einrichten freie IPv4 10.207.0.x wählen und eintragen. Letzten 32bit der IPv6 (also alles nach fec0::) ist die IPv4-Adresse übersetzt in Hex. Viele der anderen IC-VPN-Teilnehmer nutzen übrigens quagga als BGP-Dienst anstatt bird. Deshalb steht im IC-VPN die quagga-Konfiguration: 

neighbor **IPv4 WÄHLEN** remote-as 65112                       # Beispiel für gw03: 10.207.0.61
neighbor **IPv4 WÄHLEN** description **NAME WÄHLEN**  #Beispiel für gw03 IP: 10.207.0.61 und Name: Hamburg03
neighbor **IPv4 WÄHLEN** peer-group icvpn4                    #Beispiel für gw03: 10.207.0.61

neighbor **IPv6 WÄHLEN** remote-as 65112                     # Beispiel für gw03: fec0::a:cf:0:3d
neighbor **IPv6 WÄHLEN** description **NAME WÄHLEN** #Beispiel für gw03 IP: fec0::a:cf:0:3d und Name: Hamburg03
neighbor **IPv6 WÄHLEN** peer-group icvpn6                    # Beispiel für gw03: fec0::a:cf:0:3d

Im Abschnitt Netzübersicht das Netzwerk eintragen. Hier wieder die Beispiele für gw03 - bitte entsprechend anpassen. 

Hamburg03	 65112	 10.207.0.61	 fec0::a:cf:0:3d/96	 gw03.hamburg.freifunk.net	 kontakt at hamburg.freifunk.net	 10.112.0.0/16, fd51:2bb2:fd0d::/48

Testen, ob tinc läuft.

Der erzeugte öffentliche Schlüssel wird auf ein anderes gateway, welches bereits im ICVPN ist, nach /etc/tinc/icvpn/hosts/ kopiert. Auf dem eigenen host wird geschaut, ob die Netzwerkschnittstelle da ist:
$ ip a

Beispiel: 

icvpn: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 500
link/ether 36:35:c8:9b:be:5d brd ff:ff:ff:ff:ff:ff
inet6 fec0::a:cf:0:3d/96 scope site deprecated 
valid_lft forever preferred_lft forever
inet6 fe80::3435:c8ff:fe9b:be5d/64 scope link 
valid_lft forever preferred_lft forever

Zum Test Kiel anpingen (Adresse aus der Netzwerkübersicht):
$ ping6 fec0::a:cf:0:3a

bird6 routing daemon

Jetzt ist die VPN-Verbindung fertig und das IPv6 routing kann erstellt werden. Dabei muss jedes gateway die anderen gateways eingetragen haben. Für die anderen gateways und server muss die gateway-AG dies also nachholen. Die internen gateways werden unter # iBGP peerings eingetragen, die der anderen Städte unter # eBGP peerings.
$ vim /etc/bird6.conf 

# the ff ip of the gateway
router id 10.112.10.1;  # edit for new gateway

# routing tables
table ffhh;

# filter to check ulas
function is_ula() {
 return (net ~ [ fc00::/7{48,64} ]);
}

function is_self() {
    return (proto = "static_ffhh");
}

filter ffhh_internal_export {
        if (proto = "local_ffhh") then accept;
        if (source != RTS_BGP) then reject; 
        if (is_ula() && proto != "static_ffhh") then accept;
        else reject;
}

# don't use kernel's routes for bird, but export bird's routes to kernel
protocol kernel {
 scan time 20;  # Scan kernel routing table every 20 seconds
 import none;  # Default is import all
 export all;
}

# This pseudo-protocol watches all interface up/down events.
protocol device {
 scan time 10;  # Scan interfaces every 10 seconds
}

# define our routes
protocol static static_ffhh {
 table ffhh;

    # reject route if announced from external
 route fd51:2bb2:fd0d::/48 reject;
};

protocol static local_ffhh {
    table ffhh;
    route fd51:2bb2:fd0d::/64 via "br-ffhh";
};


protocol pipe pipe_ffhh {
 peer table ffhh;
 import all;
    export none;
};

# template for internal routing
template bgp bgp_ibgp {
    table ffhh;
 local as 65112;
 source address fd51:2bb2:fd0d::c01;  # edit: own ip of gateway
    import all;
    export where source = RTS_BGP;
    gateway direct;
    next hop self;
};
 
# icvpn template for hamburg03
template bgp bgp_icvpn {
 local as 65112;
 source address fec0::a:cf:0:3d; # edit for new gateway
 table ffhh;
 import where is_ula();
 export where is_self() || (source = RTS_BGP);
};

# iBGP peerings
protocol bgp srv01 from bgp_ibgp {
    neighbor fd51:2bb2:fd0d::101 as 65112; # edit: ip of remote gateway
};

protocol bgp hamburg01 from bgp_ibgp {
 neighbor fd51:2bb2:fd0d::e01 as 65112; # edit: ip of remote gateway
};

protocol bgp hamburg04 from bgp_ibgp {
 neighbor fd51:2bb2:fd0d::801 as 65112; # edit: ip of remote gateway
};

protocol bgp hamburg05 from bgp_ibgp {
 neighbor fd51:2bb2:fd0d::d01 as 65112; # edit: ip of remote gateway
};

protocol bgp hamburg06 from bgp_ibgp {
 neighbor fd51:2bb2:fd0d::f01 as 65112; # edit: ip of remote gateway
};

protocol bgp hamburg07 from bgp_ibgp {
 neighbor fd51:2bb2:fd0d::a01 as 65112; # edit: ip of remote gateway
};

protocol bgp hamburg08 from bgp_ibgp {
 neighbor fd51:2bb2:fd0d::b01 as 65112; # edit: ip of remote gateway
};

# eBGP peerings

protocol bgp Augsburg1 from bgp_icvpn {
 neighbor fec0::a:cf:0:a as 65050;
};

protocol bgp Bayreuth from bgp_icvpn {
 neighbor fec0::a:cf:0:19 as 65025;
};

protocol bgp Berlin1 from bgp_icvpn {
 neighbor fec0::a:cf:0:5 as 44194;
};

protocol bgp Bielefeld1 from bgp_icvpn {
    neighbor fec0::a:cf:0:59 as 65529;
};

protocol bgp Bielefeld2 from bgp_icvpn {
    neighbor fec0::a:cf:0:60 as 65529;
};

protocol bgp diac24 from bgp_icvpn {
    neighbor fec0::a:cf:ac:16 as 64600;
};

protocol bgp Franken1 from bgp_icvpn {
    neighbor fec0::a:cf:0:17 as 65024;
};

protocol bgp Franken2 from bgp_icvpn {
    neighbor fec0::a:cf:0:18 as 65024;
};

protocol bgp Freiburg1 from bgp_icvpn {
    neighbor fec0::a:cf:0:21 as 65060;
};

protocol bgp Gronau1 from bgp_icvpn {
    neighbor fec0::a:cf:0:50 as 65526;
};

protocol bgp Gronau2 from bgp_icvpn {
    neighbor fec0::a:cf:0:51 as 65526;
};

protocol bgp Kiel1 from bgp_icvpn {
 neighbor fec0::a:cf:0:35 as 65525;
};

protocol bgp Kiel3 from bgp_icvpn {
 neighbor fec0::a:cf:0:36 as 65525;
};

protocol bgp Kiel4 from bgp_icvpn {
 neighbor fec0::a:cf:0:3a as 65525;
};

protocol bgp Koeln from bgp_icvpn {
 neighbor fec0::a:cf:0:57 as 65528;
};

protocol bgp Ljubljana1 from bgp_icvpn {
 neighbor fec0::a:cf:3:23 as 65023;
};

protocol bgp Ljubljana2 from bgp_icvpn {
 neighbor fec0::a:cf:3:30 as 64768;
};

protocol bgp Luebeck1 from bgp_icvpn {
 neighbor fec0::a:cf:0:82 as 65052;
};

protocol bgp Luebeck2 from bgp_icvpn {
 neighbor fec0::a:cf:0:83 as 65052;
};

protocol bgp Schwarzach from bgp_icvpn {
 neighbor fec0::a:cf:0:56 as 65527;
};

protocol bgp Weimar1 from bgp_icvpn {
 neighbor fec0::a:cf:0:3 as 65042;
};

protocol bgp Wermelskirchen1 from bgp_icvpn {
 neighbor fec0::a:cf:0:7 as 65530;
};

Das Hamburger gateway muss nun auch auf gateways der zu peer-enden Städte eingetragen werden (in deren bird6.conf).

bird6 starten:
$ service bird6 start

bird6 testen

Gucken ob's läuft:
$ birdc6 show protocols

Routen anzeigen:
$ birdc6 show route

Konfiguration neu laden:
$ birdc6 configure

bird4 routing daemon

$ vim /etc/bird.conf 

router id 10.112.10.1;

table ffhh; # BGP Peerings
table ibgp;
table icvpn; # BGP Peerings (ICVPN)
table freifunk; # Kernel table 42 (Routing from Freifunk networks)

function is_freifunk_dn42() {
        return (net ~ [
            10.0.0.0/8{12,32},
            10.100.0.0/14,
            172.22.0.0/15+,
            172.31.0.0/16
            ]);
}

function is_freifunk() {
    return (net ~ [10.0.0.0/8+]);
}

function is_chaosvpn() {
    return (net ~ [172.31.0.0/16+]);
}

function is_self_net() {
    return (net ~ [10.112.0.0/16+]);
}

function is_self() {
    return (proto = "static_ffhh");
}

function is_dn42_aggregate() {
    return (net ~ [172.22.0.0/15{16,32}]);
}

filter ffhh_internal_export {
    if (proto = "dn42_aggregate_ffhh" || proto = "local_ffhh") then accept;
    if (source != RTS_BGP && proto != "pipe_icvpn") then reject; 
    if (proto ~ "bgp_ibgp_*") then reject;
    if (is_dn42_aggregate()) then reject;
    accept;
}


protocol pipe pipe_ffhh {
    peer table ffhh;
    import all;
    export none;
};

protocol pipe pipe_icvpn {
    table ffhh;
    peer table icvpn;
    export where is_self();
    import all;
    mode opaque;
};

protocol pipe pipe_freifunk {
    peer table freifunk;
    import none;
    export all;
};

protocol pipe pipe_ibgp {
    peer table ibgp;
    import all;
    export where !is_self_net();
    mode opaque;
};

protocol kernel kernel_master {
    scan time 20;
    import none;
    export filter {
        krt_prefsrc = 10.112.10.1;
        accept;
    };
};

protocol kernel kernel_freifunk {
    scan time 20;
    import none;
    export filter {
        krt_prefsrc = 10.112.10.1;
        accept;
    };
    table freifunk;
    device routes;
    kernel table 42;
};

# This pseudo-protocol watches all interface up/down events.
protocol device {
    scan time 10;       # Scan interfaces every 10 seconds
};

protocol static unreachable_default {
    table freifunk;
    route 0.0.0.0/0 reject;
};

protocol static static_ffhh {
    table ffhh;
    route 10.112.0.0/16 reject;
};

protocol static local_ffhh {
    table ffhh;
    route 10.112.0.0/18 via "freifunk";
};

protocol static dn42_aggregate_ffhh {
    table ffhh;
    route 172.22.0.0/15 reject;
};


template bgp bgp_ibgp {
    local as 65112;
    table ibgp;
    import filter {
        preference = 99;
        accept;
    };
    export all;
    gateway direct;
    next hop self;
};

template bgp bgp_icvpn {
    local as 65112;
    table icvpn;
    import where (is_freifunk_dn42() && !is_self_net());
    export all;
};

# iBGP (siehe IPv6; ggf. eigenen Eintrag entfernen, falls von anderem gateway übernommen, bzw. neuen gateway )

protocol bgp srv01 from bgp_ibgp {
    neighbor 10.112.1.1 as 65112;
};

protocol bgp hamburg01 from bgp_ibgp {
    neighbor 10.112.14.1 as 65112;
};

protocol bgp hamburg04 from bgp_ibgp {
    neighbor 10.112.8.1 as 65112;
};

protocol bgp hamburg05 from bgp_ibgp {
    neighbor 10.112.18.1 as 65112;
};

protocol bgp hamburg06 from bgp_ibgp {
    neighbor 10.112.20.1 as 65112;
};

protocol bgp hamburg07 from bgp_ibgp {
    neighbor 10.112.16.1 as 65112;
};

protocol bgp hamburg08 from bgp_ibgp {
    neighbor 10.112.22.1 as 65112;
};

# eBGP (siehe IPv6)

protocol bgp Augsburg1 from bgp_icvpn {
    neighbor 10.207.0.17 as 65050;
};

protocol bgp Augsburg2 from bgp_icvpn {
    neighbor 10.207.0.177 as 65070;
};

protocol bgp Aurich1 from bgp_icvpn {
    neighbor 10.207.0.15 as 65047;
};

protocol bgp BadZwischenahn1 from bgp_icvpn {
    neighbor 10.207.0.26 as 65512;
};

protocol bgp Bayreuth1 from bgp_icvpn {
    neighbor 10.207.0.28 as 65025;
};

protocol bgp Berlin1 from bgp_icvpn {
    neighbor 10.207.0.5 as 44194;
};

protocol bgp Bielefeld1 from bgp_icvpn {
    neighbor 10.207.0.59 as 65529;
};

protocol bgp Bielefeld2 from bgp_icvpn {
    neighbor 10.207.0.67 as 65529;
};

protocol bgp Chemnitz1 from bgp_icvpn {
    neighbor 10.207.0.36 as 65053;
};

protocol bgp diac24_net from bgp_icvpn {
    neighbor 10.207.2.0 as 64600;
};

protocol bgp Dresden1 from bgp_icvpn {
    neighbor 10.207.0.19 as 65051;
};

protocol bgp Franken1 from bgp_icvpn {
    neighbor 10.207.0.23 as 65024;
};

protocol bgp Franken2 from bgp_icvpn {
    neighbor 10.207.0.24 as 65024;
};

protocol bgp Franken3 from bgp_icvpn {
    neighbor 10.207.0.31 as 65024;
};

protocol bgp Frankfurt1 from bgp_icvpn {
    neighbor 10.207.0.35 as 65026;
};

protocol bgp Freiburg1 from bgp_icvpn {
    neighbor 10.207.0.21 as 65026;
};

protocol bgp Gronau1 from bgp_icvpn {
    neighbor 10.207.0.55 as 65526;
};

protocol bgp Gronau2 from bgp_icvpn {
    neighbor 10.207.0.60 as 65526;
};

protocol bgp Grossdraxdorf from bgp_icvpn {
    neighbor 10.207.0.25 as 65025;
};

protocol bgp Halle1 from bgp_icvpn {
    neighbor 10.207.0.13 as 65046;
};

protocol bgp Halle2 from bgp_icvpn {
    neighbor 10.207.0.14 as 65046;
};

protocol bgp Hannover1 from bgp_icvpn {
    neighbor 10.207.0.22 as 65511;
};

protocol bgp Jena1 from bgp_icvpn {
    neighbor 10.207.0.33 as 65055;
};

protocol bgp Jena2 from bgp_icvpn {
    neighbor 10.207.0.66 as 65055;
};

protocol bgp Kiel4 from bgp_icvpn {
    neighbor 10.207.0.58 as 65525;
};

protocol bgp Koblenz from bgp_icvpn {
    neighbor 10.207.0.32 as 65032;
};

protocol bgp Koeln1 from bgp_icvpn {
    neighbor 10.207.0.57 as 65528;
};

protocol bgp Leipzig1 from bgp_icvpn {
    neighbor 10.207.0.1 as 65041;
};

protocol bgp Leipzig2 from bgp_icvpn {
    neighbor 10.207.0.2 as 65041;
};

protocol bgp Ljubljana1 from bgp_icvpn {
    neighbor 10.207.3.23 as 65023;
};

protocol bgp Ljubljana2 from bgp_icvpn {
    neighbor 10.207.3.30 as 64768;
};

protocol bgp Luebeck1 from bgp_icvpn {
    neighbor 10.207.0.130 as 65052;
};

protocol bgp Luebeck2 from bgp_icvpn {
    neighbor 10.207.0.131 as 65052;
};

protocol bgp Mainz1 from bgp_icvpn {
    neighbor 10.207.0.37 as 65037;
};

protocol bgp Oldenburg1 from bgp_icvpn {
    neighbor 10.207.0.27 as 65513;
};

protocol bgp Schwarzach1 from bgp_icvpn {
    neighbor 10.207.0.56 as 65527;
};

protocol bgp Treuenbrietzen from bgp_icvpn {
    neighbor 10.207.0.18 as 65045;
};

protocol bgp Weimar1 from bgp_icvpn {
    neighbor 10.207.0.3 as 65042;
};

protocol bgp Weimar2 from bgp_icvpn {
    neighbor 10.207.0.4 as 65042;
};

protocol bgp Wermelskirchen1 from bgp_icvpn {
    neighbor 10.207.0.7 as 65530;
};

Monitoring

Um den Gesundheitszustand der gateways zu überwachen wird der Dienst munin eingerichtet. 

apt-get install munin-node vnstat

Konfigurieren: 

vim /etc/munin/munin-node.conf

host_name gw**NUMMER DES GATEWAYS EINSETZEN**.hamburg.freifunk.net
cidr_allow 78.47.49.236/32
host **IPv4 DES GATEWAYS IM INTERNET EINSETZEN**

Welche Parameter genau von munin überwacht werden, wir über plugins gesteuert. Zunächst wird das plugin für vnstat nachgeladen und ausführbar gemacht: 

cd /usr/share/munin/plugins
wget https://raw.github.com/bram85/munin-plugins/master/vnstat/vnstat_         
chmod +x vnstat_

Das gleiche erfolgt für udp-statistics 

wget https://raw.github.com/munin-monitoring/contrib/master/plugins/network/udp-statistics
chmod +x udp-statistics

Ausgeführt werden die plugins, die einen softlink im Verzeichnis 

cd /etc/munin/plugins

haben. Also müssen wir dort für die beiden nachgeladenen plugins jeweils einen anlegen. 

ln -s /usr/share/munin/plugins/udp-statistics udp-statistics

Mit Unterstrich können manchen Plugins Parameter übergeben werden. Hier wird vnstat gesagt, den monatlichen eingehenden und ausgehenden Verkehr der Schnittstelle eth0 anzuzeigen. 

ln -s /usr/share/munin/plugins/vnstat_ vnstat_eth0_monthly_rxtx

In dem Verzeichnis können alle Plugins ausser die folgenden gelöscht werden: 

cpu
df
df_inode
diskstats
entropy
forks
fw_conntrack
fw_forwarded_local
fw_packets
if_bat0
if_br-ffhh
if_err_bat0
if_err_br-ffhh
if_err_eth0
if_err_ffhh-mesh-vpn
if_err_mullvad
if_eth0
if_ffhh-mesh-vpn
if_mullvad
interrupts
irqstats
load
memory
open_files
open_inodes
processes
swap
threads
udp-statistics
vmstat
vnstat_eth0_monthly_rxtx

Zum Schluss wird noch das vnstat Plugin konfiguriert 

vim /etc/munin/plugin-conf.d/vnstat

indem man folgende Zeilen einträgt: 

[vnstat_eth0_monthly_rxtx]
env.estimate 1

Jetzt wird munin neu gestartet: 

service munin-node restart

Nun Leo bitte, das Gateway in das Monitoring aufzunehmen. Das Monitoring kann unter http://www.ohrensessel.net/mstats begutachtet werden.

Aufgaben der gateway AG

DNS-Einträge

Auf srv01: 

cd /etc/bind/master
rndc freeze
vi db.ffhh

Änderungen machen (Zähler hoch zählen nicht vergessen). 

vi db.net.freifunk.hamburg

Änderungen machen (Zähler hoch zählen nicht vergessen). 

rndc thaw
rndc reload

MAC der ffhh-mesh-vpn Schnittstelle im fastd Schlüsselrepo

Für die neue MAC muss ein Eintrag im fastd Schlüsselrepo erstellt werden. Der zugehörige öffentliche fastd Schlüssel findet sich auf gw01 unter /home/freifunker/fastd-keys/backup.

Gatewaybetreiben den privaten gateway-Schlüssel zur Verfügung stellen

Die privaten fastd Schlüssel befinden sich auf gw01 unter /home/freifunker/fastd-keys/backup.

Öffentlicher ssh Schlüssel des gatways eintragen

Der öffentliche ssh Schlüssel des gateways muss zu den berechtigen Zugängen des fastd-Schlüsselrepos eingetragen werden, damit das neue gateway das repo clonen darf.

Gatway auf srv01 anmelden

Damit srv01 sich mit dem neuen gateway verbinden kann (und umgekehrt), muss der öffentliche fastd-Schlüssel des gateways unter /etc/fastd/ffhh-mesh-vpn/backbones angelegt werden.

Freifunk Hamburg

Abgerufen von „https://wiki.freifunk.net/index.php?title=Hamburg/Gateway&oldid=49569“