Vpn03 Admin Howto

Aus wiki.freifunk.net
Wechseln zu: Navigation, Suche

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

Neue Konfig

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

Jedenfalls brauchst du einen Tunnelnamen (muss eindeutig sein, Länge etwa 10-30 Zeichen, keine Leerzeichen, keine Sonderzeichen). Aus dem Bauch heraus würde ich darauf achten, dass die Zeichenkette später mal als Hostname für DNS Verwendung finden könnte. Ort und Gelegenheit wären jedenfalls schön, z.B. schalander-kneipe-in-bad-schandau wär' ein guter Tunnelname. Dann brauchst du noch eine E-Mail-Adresse. Am besten von der Person die sich um den Router kümmert. Also nicht info@stadt-schandau.de sondern jana.lustig@coldmail.com. Jetzt kann eine Konfiguration erzeugt werden:
sudo bash
openvpn-build-key schalander-kneipe-in-bad-schandau jana.lustig@coldmail.com
cd /etc
git add --all
git commit
Der letzte Befehl führt zu einem Editor-Fester, wo ein Kommentar für das /etc-Commit eingegeben wird. Drücke [i] für Einfügemodus des VI-Editors, tippe etwas ähnliches wie "Sven-Ola: neuer Schlüssel für Bad Schandau" und schieße das ganze mit [Esc]:wq ab. Eine automatische E-Mail-Sendefunktion steht auf der Todo-Liste. Bis dahin muss die Konfigurationsdatei manuell gesendet werden. Rufe auf
cp /etc/openvpn/clients/freifunk_schalander-kneipe-in-bad-schandau.tgz ~/

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

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

Schlüssel sperren

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

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

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

Hinweis2: Es werden auch Schlüssel akzeptiert, die auf dem früher in Slovenien betriebenen Server generiert wurden. Ein CRL für diese Schlüssel kann nicht so ohne weiteres erzeugt werden. Nötigenfalls mich (Sven-Ola) fragen.

Systempflege

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

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

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

Die SNAT-Mechanik sieht etwa so aus. Beim Start des OpenVPN-Daemons wird ein Script ausgeführt, das folgendes enthält:
sven-ola@vpn03:~$ grep -- -A /etc/openvpn/mark-and-change-snat-ip 
  iptables -t mangle -A PREROUTING -i ${dev} -j IPMARK --addr src --and-mask 0x3f --or-mask 0x1000
Da könnte man später auch mal ein "xor $RANDOM" einbauen, dass einmal die Woche wechselt. Jedenfalls gibt es eine IPTables-Regel, die die so markierten hereinkommenden Pakete dann auf die offiziellen IPv4-Adressen des Servers umsetzt:
sven-ola@vpn03:~$ sed -n 24,29p /etc/rc.local 
iptables -t nat -F POSTROUTING
for net in 104.0.0.0/8 10.0.0.0/8 172.16.0.0/12;do
  for ip in $(seq 0 1 63);do
    iptables -t nat -A POSTROUTING -o ${INET_DEV} -s ${net} -m mark \
      --mark $(( 0x1000 + ${ip} )) -j SNAT --to 77.87.49.${ip}
  done
done

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

Note: Bitte darauf achten, dass /etc/rc.local jederzeit nochmals ausgeführt werden kann. Also z.B. die Firewall-Regeln erst löschen, dann neue anlegen.

Automatische Wartung mit Cron

Auf dem Server existieren zwei zusätzliche Cron-Einträge, die die regelmäßige Wartung ausführen. Dies betrifft in erster Linie die Handhabung von IPv4-Adressen.

/etc/cron.daily/roulette

Dieses täglich ausgeführte Script ändert den Zufallswert für das Intern-zu-Extern IPv4-Adress-Mapping. Der täglich geänderte Wert steht in /var/run/roulette-xor.txt. Diese Datei wird von /etc/openvpn/openvpn-updown-mark-snat und freifunk-zapp ausgewertet.

/etc/cron.weekly/openvpn

Dieses wöchentlich ausgeführte Script stoppt den OpenVpn-Dienst und löscht alle in /var/run/*pool* vorhandenen Tunnel-IP-Adress-Zuordnungen (172.31.x.x und 2002:4d57:300a:fffe::). Danach wird der OpenVpn-Dienst neu gestartet. Zweck ist die Neuzuordnung von Tunnel-IP-Adressen, damit sich niemand auf statische Tunnel-IP-Zuordnungen verlässt und das System somit ein bisschen mehr Anonymität für die Gateway-Betreiber zulässt.

Hinweis1: Damit fährt der OpenVpn-Dienst jeden Sonntag morgen kurz mal herunter. Damit wird auch ein Neuverbinden sämtlicher OpenVpn-Clients erzwungen. Es gab zumindest sporadisch Fälle, in denen OpenVpn-Clients nach wochenlangen Betrieb seltsam langsam wurden. Die Neustart-Mechanik sollte helfen, dies verhindern.

Hinweis2: Diese Mechanik ist nur für die von OpenVpn verwalteten Tunnel-Adressen aktiv. Die über Map66 erzeugten externen IPv6-Zuordnungen sind derzeit über die Zeit stabil (siehe /var/run/openvpn-pool-map66.txt)

Die Sache mit dem ZAPP

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

Eine weitere Mechanik des ZAPP-Skripts sollte jetzt funktionieren. Wenn gerade ein Bittorrent o.ä. aktiv ist, dann kommen jede Menge unbestellte Verbindungsanfragen von irgendwo draußen herein. Das sind die "bekomme ich auch was" Anfragen der Torrent-Wolke. In diesem Zeitfenster kann man die Empfindlichkeit / den Schwellwert für das Blockieren heruntersetzen. Das ist mit der MARK-and-SNAT-Mechanik (siehe oben) und der eingebauten XOR $Random verknüpft (über die Datei /var/run/roulette-xor.txt).

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

Quelle für Download-IPK

Wie auf der Benutzerseite Vpn03 erwähnt gibt es ein IPK-Paket zur vereinfachten Installation ("opkg install http://download.berlin.freifunk.net/sven-ola/vpn03/vpn03-install-to-ramdisk_all.ipk"). Die Datei /home/download/Makefile erzeugt das *.ipk. Alles unter /home/download/all wird in das *.ipk eingepackt. Upload allerdings nur mit Schreibzugriff auf den "Download-Master".

Liste verwendeter IP-Adressen

Die folgende Tabelle zeigt interne und externe IP-Adressen/Bereiche, wie sie auf dem VPN03-Server eingerichtet sind. Im Zweifelsfall ist natürlich die jeweilige Konfigurationsdatei die bessere Quelle für diese Info, aber einen ordentlichen Überblick bekommt hier schon.

Adresse Erläuterung Konfig-Datei
77.87.48.1/28 IPv4 Gateway, zugewiesen / gekonft von Daniel. Auch: DNS-Resolver für VPN03 network/interfaces
77.87.48.10/28 Offizielle Server-IPv4, OpenVPN-Incoming, verknüpft mit DNS: vpn03.berlin.freifunk.net; zudem: 6to4 Basis-IP für tun64a, erster IPv6-Adressbereich. network/interfaces, openvpn/clients/template-(udp/tcp).ovpn, rc.local, ipsec-tools.d/l2tp.conf, racoon/racoon.conf
77.87.49.0/26 IPv4 Adressbereich bis 77.87.49.63, OpenVPN-Outgoing, zugewiesen / gekonft von Daniel. Die darüber liegenden IPs müssten frei sein, falls wir mehr brauchen also Daniel fragen. network/interfaces
6.0.0.0/8 Dynamic-Iroute-IPv4 und NAT-to-ExternIP; siehe IP-Netze und IP-Bereich_6 (Vergabe derzeit ungeregelt, evt. IP-Bereich_6 nutzen); Bereich ist "gekapert" zur Verwendung in Freifunk-Mesh-Netzen rc.local, openvpn/server-melle.conf, openvpn/server-tcp.conf, openvpn/server-udp.conf
10.0.0.0/8 Dynamic-Iroute-IPv4 und NAT-to-ExternIP; siehe IP-Netze (Vergabe machen die jeweiligen örtlichen Gruppen); Offizieller Private-IP-Bereich, zur Verwendung in Freifunk-Mesh-Netzen rc.local, openvpn/server-melle.conf, openvpn/server-tcp.conf, openvpn/server-udp.conf
104.0.0.0/8 Dynamic-Iroute-IPv4 und NAT-to-ExternIP; siehe Berliner IP-Vergabe http://ip.berlin.freifunk.net/; Bereich ist "gekapert" zur Verwendung in Freifunk-Mesh-Netzen rc.local, openvpn/server-melle.conf, openvpn/server-tcp.conf, openvpn/server-udp.conf
172.16.0.0/12 Dynamic-Iroute-IPv4 und NAT-to-ExternIP; Offizieller Private-IP-Bereich, zur spontanen bzw. temporären Verwendung in Freifunk-Mesh-Netzen (bis 172.31.223.255, der 172.31.224.0/19 ist reserviert für IPv4-OpenVPN-Pools) rc.local, openvpn/server-melle.conf, openvpn/server-tcp.conf, openvpn/server-udp.conf, openvpn/server-test.ovpn
172.31.237.1/24 IPv4-Adresse tun-test, IPv4-Pool für Test-VPN openvpn/server-test.ovpn
172.31.238.1/24 IPv4-Adresse tun-melle, IPv4-Pool für FF-Potsdam-Migrations-VPN openvpn/server-melle.conf
172.31.239.1/24 IPv4-Adresse tun-tcp, IPv4-Pool für TCP-VPN openvpn/server-tcp.conf
172.31.240.1/20 IPv4-Adresse tun-udp, IPv4-Pool für UDP-VPN (bis 172.31.255.255) openvpn/server-tcp.conf
192.168.0.0/16 Diese privaten IPv4-Adressen haben kein NAT und werden nicht weitergeleitet (zur Sicherheit...) rc.local
2002:4d57:300a::/48 tun64: 6to4 IPv6-Adressbereich, MAP66 auf alle im Mesh verwendete IPv6 aus 2002::/16 und fc00::/7 rc.local, network/interfaces, openvpn/openvpn-learn-address
2002:4d57:300a:fffb::/64 IPv6-Pool für Test-VPN openvpn/server-test.ovpn
2002:4d57:300a:fffc::/64 IPv6-Pool für FF-Potsdam-Migrations-VPN openvpn/server-melle.conf
2002:4d57:300a:fffd::/64 IPv6-Pool für TCP-VPN openvpn/server-tcp.conf
2002:4d57:300a:fffe::/64 IPv6-Pool für UDP-VPN openvpn/server-udp.conf
2002:4d57:300a:ffff::1/64 tun64: Interface IPv6-Adresse, verknüpft mit IPv6-DNS-AAAA vpn03.berlin.freifunk.net network/interfaces, openvpn/clients/template-(udp/tcp).ovpn
2002::/16 Dynamic-Iroute-IPv6 mit /64-Routen, außerdem mit MAP66 übersetzte alte Freifunk-ULA IPv6-Adresse rc.local, openvpn/server-melle.conf, openvpn/server-tcp.conf, openvpn/server-udp.conf, openvpn/openvpn-learn-address
fc00::/7 Dynamic-Iroute-IPv6 mit /64-Routen, außerdem mit MAP66 übersetzte aktuelle Freifunk-ULA IPv6-Adresse rc.local, openvpn/server-melle.conf, openvpn/server-tcp.conf, openvpn/server-udp.conf, openvpn/openvpn-learn-address
fdca:ffee:babe:0000::/64 Dynamic-Iroute-IPv6 mit /128-Routen, außerdem mit MAP66 übersetzte sehr alte Freifunk-ULA IPv6-Adresse rc.local, openvpn/server-melle.conf, openvpn/server-tcp.conf, openvpn/server-udp.conf, openvpn/openvpn-learn-address
78.41.116.65/32 IPv4-Adresse des vpn03-backup.berlin.freifunk.net (im DNS verknüpft), Server-VM wird von http://www.funkfeuer.at/ zur Verfügung gestellt. hosts
2a02:60:1:1::43/64 Native IPv6-Adresse des vpn03-backup.berlin.freifunk.net (im DNS verknüpft) hosts
2a02:60:4:4300::1/56 Zusätzlicher nativer IPv6-Adressbereich für vpn03-backup

Info über IPv6

Hey,

damit ihr informiert bleibt: ich habe auf dem VPN03-Tunnelendpunkt-Server die IPv6-Konfiguration geändert. Hintergrund: die aktuellen PBerg-Firmwares verwenden jetzt andere (interne) IPv6-Adressen. Das sind:

  • Uralt-FW (WRT, kamikaze): fdca:ffee:babe:0000:x:x:x:x:/128
  • Sehr-Alt-FW (bis Backfire): 2002:[ipv4-von-WAN]:xxxx::/64
  • Vorige-FW (ab Backfire): fdca:ffee:babe:xxxx::/64
  • Aktuelle-FW (Attitude): f(c|d)xx:xxxx:xxxx:xxxx::/64

Bei der Uralt-FW wurde x:x:x:x aus der MAC-Adresse generiert. Es wird genau eine IPv6 verwendet, also /128. Bei allen anderen wird das per radvd/ipv6-autoconf an angeschlossene Clients verteilt, daher pro Interface ein /64 verwendet. Die xxxx kommen hier aus einem Zufallsgenerator, erzeugt mit dem Freifunk-Assistenten.

Die im Mesh verwendeten IPv6-Adressen sind ULA's, die im Internet nicht weitergeroutet werden. Darum war auf VPN03 immer eine IPv6-Adressumsetzung aktiv, die ich vor längerer Zeit mal zusammengefummelt hatte (nennt sich MAP66, siehe http://map66.sourceforge.net/). Die aktuelle Firmware weitet nun den verwendeten ULA-Adressbereich erheblich aus: je ein /64 aus fc00::/7. Das lässt sich nicht mehr in /48 abbilden (sowas haben wir extern, derzeit über 6-to-4), daher gibt es jetzt eine temporäre Zuordnung die ein paar Wochen gültig bleibt.

Erwartete Auswirkung: IPv6 geht wieder (Browser, Telefonie). Heads Up: IPv6 ist nicht gefirewalled. Watch your logs.

Tipp: Wer seine externe IPv6 kennt, kann auch ohne Portforwarding an interne Router / Geräte von Extern aus dran.

Noch eine Anmerkung: in vielen Fällen ist das gar nicht aktiviert. Bei den LuCI-basierten Firmwares kann man das so testen:

Vorige LuCI-Firmwares:

 uci show autoipv6 -> autoipv6.olsr_node.enable=1

Aktuelle LuCI-Firmware:

 uci show auto_ipv6_node -> auto_ipv6_node.olsr_node.enable=1

Und noch'n Hinweis: bei vielen Routern-mit-DSL wird evt. auch noch die automatische 6to4-Mechanik aktiv sein. "uci show autoipv6" zeigt dann "autoipv6.tunnel.enable=1". Wenn die Kiste über pppoe angebunden ist funktioniert das sogar. Wenn die Kiste über WAN(dhcp mit 192.168.x.x) angebunden ist wird das nicht laufen und stört damit den IPv6-Abwurf über VPN03. In diesem Fall einfach 6to4 ausmachen.

VPN03 verteilt schon länger IPv6 über IPv4-OpenVPN-Tunnel. Es geht aber auch IPv4 über IPv6-OpenVPN-Tunnel und sogar IPv6-über-IPv6. Die erwähnte MAP66-Mechanik spart uns den Aufwand, wechselnde IPv6-Präfixe im Netz zu verteilen, wofür irgendwie noch niemand eine ordentliche Technik durchgesetzt hat.

Das ist im Übrigen auch auf "vpn03-backup.berlin.freifunk.net" eingerichtet, das ist der freundlicherweise von Funkfeuer bereitgestellte Backup-VPN, der demnächst in den offiziellen Betrieb gehen wird.

Gruß // Sven-Ola

...To be continued...