Meskal am 18. März 2019 um 22:02 Uhr

2019-03-18T22:02:06Z

← Nächstältere Version		Version vom 19. März 2019, 00:02 Uhr
Zeile 1:		Zeile 1:

			Die aktuell bevorzugte Möglichkeit den Freifunk-Traffic ins Internet zu leiten, ist das Routing über einen Freifunk Exit-Router in unserem Layer-3 Netzwerk.
			Dafür bietet es sich an, sich um ein direktes (gre-Tunnel)-Peering mit [[Portal:Layer3Peering\|einem der Knoten]] , die auch direktes Ausleiten unterstützen, zu bemühen. Dies hat den Vorteil, dass meist deutsche IP-Adressen verwendet werden und dass die Wege und damit die Latenzen meist kürzer sind.

			Die Nutzung eines eigens gemieteten Anonymisierungs-VPN hat jedoch den Vorteil der Dezentraliät und erhöht die Ausfallsicherheit, ist aber meist nicht so leistungsfähig wie ein GRE-Tunnel zu einem bestehenden Exit-Router und man bekommt meistens ausländische IP-Adressen zugeordnet, was das Nutzen von Diensten mit Geolokalisierung erschwert. Zudem werden meist ineffektive VPN-Protokolle verwendet, die zusätzlichen Mehraufwand und Fragementierung erfordern. Bedenkt das diese Provider nicht unbedingt für große Trafficmassen gemacht sind und ein weiterer Punkt in der Fehlersuche sind. Es macht daher Sinn zu versuchen den Traffic möglichst direkt ins Internet zu tragen.

			== VPN-Anbieter ==
			=== Empfehlenswert ===
			Vorsicht, Bedingungen können sich jederzeit ändern!

			* [https://www.azirevpn.com AzireVPN] (Schweden, UK, Spanien)
			** OpenVPN und '''Wireguard'''
			** Komplettes IPv6 /64 Prefix möglich, siehe [https://www.azirevpn.com/support/guides/router/openwrt/wireguard hier]
			** Wireguard nutzbar (beta ist am 4. Oktober ausgelaufen - nur noch im Abo)

			* [https://mullvad.net/en/ Mullvad] (Schweden, Niederlande)
			** Bis zu 5 gleichzeitige Verbindungen
			** Kann man anonym mit Bitcoin bezahlen
			** Serverauswahl über die ausgelieferte OpenVPN-Konfiguration
			*** Server in den Niederlanden sind abends oft stark ausgelastet

			* [https://integrityvpn.com Integrity VPN] (Schweden, Port80)
			** Drittes Oktett durch Auswahl des normalerweise per round.robin-dns ausgewählten OpenVPN-Servers bestimmbar, das letzte Oktett ist immer gleich. Somit muss man sich keine dynamisch vergebenen IP-Adressen mit anderen teilen. Verbindungen daher durch die Anzahl der OpenVPN-Server (derzeit 3; unterschiedliche Ports nicht ausprobiert) beschränkt.
			**Hat eine überaus seriöse Webseite und eine Ltd. erfunden.™
			**Hat schon mal was von IPv6 gehört. Nutzt es zurzeit jedoch nur für SEO.
			**Blockiert Port 25 derzeit nicht.
			**Ist ein ein neuer Anbieter, der _bisher_ unausgelastet wirkt.
			** sind derzeit noch nicht nicht overselled und haben ihren Krams scheinbar halbwegs sauber konfiguriert

			* [https://ipredator.se/ Ipredator] (Schweden, Niederlande, Deutschland)
			** (Glänzen nicht durch Kompetenz, da sie lange Zeit nur PPTP angeboten haben)
			** Mögen schnelle Reconnects nicht -> manchmal muss man OpenVPN ein paar Stunden deaktivieren, bevor es wieder funktioniert.
			** Möchten bald auch IPv6 anbieten.
			** Angeblich Reseller von relakks

			* Cyberghost
			** blockt alle SMTP Ports!!

			* Perfect Privacy

			=== Ungetestet ===
			* [https://www.anonine.com/en Anonine VPN] (Portlane)
			* [https://privacy.io/ privacy.io] (Portlane)
			* [http://prq.se/?p=tunnel&intl=1 prq.se] (Eigenes Netz, teuer)
			* [http://arethusa.su/vpn.html Arethusa VPN] (Loggen in Frankreich, andere Server angeblich nicht)


	== OpenVPN-Tunnel einrichten ==		== OpenVPN-Tunnel einrichten ==

	Ein Anonymisierungsanbieter wird verwendet um den Traffic anonym los zu werden und keine Probleme mit Störerhaftung zu bekommen. Bedenkt das diese Provider nicht unbedingt für große Trafficmassen gemacht sind und ein weiterer Punkt in der Fehlersuche sind. Es macht daher Sinn zu versuchen den Traffic möglichst direkt ins Internet zu tragen

	Die Einrichtung eines OpenVPN Tunnels kann von Anbieter zu Anbieter variieren.		Die Einrichtung eines OpenVPN Tunnels kann von Anbieter zu Anbieter variieren.

ChristianD am 28. August 2018 um 06:08 Uhr

2018-08-28T06:08:58Z

← Nächstältere Version		Version vom 28. August 2018, 08:08 Uhr
Zeile 1:		Zeile 1:
	== OpenVPN-Tunnel einrichten ==		== OpenVPN-Tunnel einrichten ==

			Ein Anonymisierungsanbieter wird verwendet um den Traffic anonym los zu werden und keine Probleme mit Störerhaftung zu bekommen. Bedenkt das diese Provider nicht unbedingt für große Trafficmassen gemacht sind und ein weiterer Punkt in der Fehlersuche sind. Es macht daher Sinn zu versuchen den Traffic möglichst direkt ins Internet zu tragen

	Die Einrichtung eines OpenVPN Tunnels kann von Anbieter zu Anbieter variieren.		Die Einrichtung eines OpenVPN Tunnels kann von Anbieter zu Anbieter variieren.

ChristianD: muss geprüft werden ob das noch richtig ist, ich verwende es nicht daher keine Prüfung

2018-08-28T06:07:37Z

muss geprüft werden ob das noch richtig ist, ich verwende es nicht daher keine Prüfung

Neue Seite

== OpenVPN-Tunnel einrichten ==

Die Einrichtung eines OpenVPN Tunnels kann von Anbieter zu Anbieter variieren.
Im Laufe der Zeit sollte die Dokumentation so um funktionierende Konfigurationen verschiedener Anbieter erweitert werden.
<br>
=== Mullvad ===

Unter https://mullvad.net/download/config/ Reiter "Other platforms" kann man sich die mullvadconfig_xx.zip runterladen.

Mullvad liefert in dieser Datei, die notwendigen Schlüssel (ca.crt, mullvad.crt, mullvad.key) als auch eine Konfigurationsdatei (mullvad_linux.conf) mit, die später angepasst werden muss.

Man kopiert nun die zip-Datei auf das Gateway, entpackt sié und kopiert das Kundenummern-Verzeichnis mit dem Dateien ca.crt, crl.pem, mullvad.crt, mullvad.key, mullvad_linux.conf nach /etc/openvpn:

Von dem lokalen Rechner kopieren wir die zip Datei per scp für [http://ged.msu.edu/angus/tutorials/using-putty-on-windows.html Windows] oder [http://www.hypexr.org/linux_scp_help.php Linux] auf das Gateway.

Als unverbindliche Richtschnur für Linux:
<code>
scp mullvadconfig.zip root@<ipv4 des Gateways>:/root
</code>

Danach loggen wir uns auf dem Gateway ein und entpacken die Datei (nicht vergessen unzip zu installieren):
<code>
ssh root@<ipv4 des Gateways>

unzip mullvadconfig.zip

cd <Kundennummernverzeichnis>

cp * /etc/openvpn
</code>

''/etc/openvpn/'' sollte mit dem Inhalt des entpackten mullvadconfig.zip Archivs dann so aussehen:
<pre>
ca.crt crl.pem mullvad.crt mullvad.key mullvad_linux.conf mullvad_windows.conf.ovpn update-resolv-conf
</pre>

'''Wichtiger Hinweis''': Wer sich nicht von seinem Gateway aussperren möchte, sollte so lange den Rechner nicht neu starten, wie die openvpn Konfiguration nicht wie unten angepasst wurde. Wenn es doch passiert, ist evtl. noch ein Zugriff auf das Gateway über die hoster-Konsole möglich.

Wir legen ein benutzerspezifisches start-up Script namens mullvad-up an:
<code>
vi /etc/openvpn/mullvad-up
</code>

und füllen sie mit folgendem Inhalt:
<pre>
#!/bin/bash
logger -t OPENVPN VPN Gateway: /sbin/ip route replace default via ${route_vpn_gateway} dev ${dev} proto static table fff
/sbin/ip route replace default via ${route_vpn_gateway} dev ${dev} proto static table fff
iptables -t nat -A POSTROUTING -o ${dev} -j MASQUERADE
</pre>
Das Skript definiert in der fff-Routingtabelle zunächst den VPN Anbieter als Standard-Gateway ("/sbin/ip route add default via ${route_vpn_gateway} dev ${dev} table fff"). D.h. Traffic, der über das Freifunk-Netz hereinkommt (Definiert über die fff IP rules) und für den keine anderweitigen Routinginformationen bekannt sind (z.B. Internet Traffic), wird pauschal in Richtung des VPN Gateways geschickt (IP ${route_vpn_gateway}, Device ${dev}). Das Default-Gateway für Traffic, der nicht freifunkbezogen ist, bleibt unangetastet, um sich nicht selber auszusperren.
Da wir Anfragen vieler Clients (verschiedene IPs) über eine VPN IP schieben, müssen wir darüber hinaus "Network Adress Translation" (NAT) betreiben ("iptables -t nat -A POSTROUTING -o ${dev} -j MASQUERADE"). Dies ist auch erforderlich, da der Freifunk IPv4 Adressbereich 10.0.0.0/8 für lokale Netze reserviert ist und nicht im Internet geroutet wird.

Das Skript mullvad-up muss ferner ausführbar sein:
<code>
chmod +x /etc/openvpn/mullvad-up
</code>

Dieses spezifische Routing muss zwingend in mullvad_linux.conf eingepflegt werden:
<code>
vi /etc/openvpn/mullvad_linux.conf
</code>

und hier die Konfiguration entsprechend geändert werden:
<pre>
.
.
.
# Allow calling of built-in executables and user-defined scripts.
script-security 2

# Parses DHCP options from openvpn to update resolv.conf
#up /etc/openvpn/update-resolv-conf
#down /etc/openvpn/update-resolv-conf

# Enable Freifunk specific Routing
route-noexec
route-delay 3
route-up /etc/openvpn/mullvad-up
.
.
.
</pre>
Script security muss auf "2" stehen, damit benutzerspezifische Skripte ausgeführt werden dürfen. Unser Freifunk spezifisches Routing wird über "route-up /etc/openvpn/mullvad-up" ausgeführt, wobei wir vorher openvpn mit "route-noexec" verbieten, automatisch selber Routen anzulegen. Aus Sicherheitsgründen führen wir einen kleinen Zeitpuffer von 3 Sekunden ein ("route-delay 3"). Vorhandene Start/Stop-Skripte (up/down) sollten auskommentiert werden.

Wer möchte, kann in mullvad_linux.conf auch Länder definieren, über die der VPN Traffic laufen soll (Ein- /Auskommentieren).

Der openvpn Tunnel kann nun testweise gestartet werden:
<code>
cd /etc/openvpn

/usr/sbin/openvpn mullvad_linux.conf &
</code>

und sollte exemplarisch und im Auszug folgendes zurück liefern:
<pre>
Sun Sep 6 12:45:20 2015 OpenVPN 2.3.4 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Dec 1 2014
Sun Sep 6 12:45:20 2015 library versions: OpenSSL 1.0.1k 8 Jan 2015, LZO 2.08
Sun Sep 6 12:45:20 2015 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
.
.
.
Sun Sep 6 12:45:23 2015 /sbin/ip link set dev tun0 up mtu 1500
Sun Sep 6 12:45:23 2015 /sbin/ip addr add dev tun0 10.114.0.45/16 broadcast 10.114.255.255
Sun Sep 6 12:45:23 2015 /sbin/ip -6 addr add fdef:e287:a479:72::102b/112 dev tun0
Sun Sep 6 12:45:23 2015 /etc/openvpn/mullvad-up tun0 1500 1558 10.114.0.45 255.255.0.0 init
Sun Sep 6 12:45:23 2015 Initialization Sequence Completed
</pre>
Wichtig ist hierbei, dass in der vorletztes Zeile unser Freifunk-spezifisches Routing durchgeführt wird.

Das VPN-Gateway sollte nun als Default Route in der fff-Routingtabelle auftauchen:
<code>
ip route show table fff | grep default
</code>

Exemplarisch wäre eine Ausgabe für das Tunnel-Device tun0 und dem VPN-Gateway 10.114.0.1:
<pre>
default via 10.114.0.1 dev tun0
</pre>

Auch ein ifconfig Eintrag für das Tunnel Device...
<code>
ifconfig
</code>

...sollte jetzt existieren (Exemplarisch und im Auszug):
<pre>
.
.
.
tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.114.0.76 P-t-P:10.114.0.76 Mask:255.255.0.0
inet6 addr: fdad:bdef:735d:72::104a/112 Scope:Global
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:1012476 errors:0 dropped:0 overruns:0 frame:0
TX packets:640206 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:1250196616 (1.1 GiB) TX bytes:84979294 (81.0 MiB)
.
.
.
</pre>

Wenn alles geklappt hat, kann man (sofern openvpn nicht korrekt beim Systemstart geladen wird), den openvpn Tunnel in der /etc/rc.local bei jedem Systemstart laden:
<code>
vi /etc/rc.local
</code>

und dort z.B. ein zeitverzögertes Starten nach 5 Sekunden vereinbaren:
<pre>
# launch vpn with 5 seconds delay
(sleep 5; /usr/sbin/openvpn /etc/openvpn/mullvad_linux.conf >> /var/log/mullvad_vpn.log &) &
</pre>
<br>

=== NordVPN ===
NordVPN liefert die Datei config.zip mit, die für jeden verwendbaren VPN-Server eine seperate Konfigurationsdatei enthält.

'''Hinweis:''' Auch hier gilt - Wer sich nicht ungewollt von seinem Gateway aussperren möchte, muss vor dem Starten von OpenVPN und vor einem neuen Reboot die Konfigurationsdatei anpassen.

Von dem lokalen Rechner kopieren wir die zip Datei per scp für [http://ged.msu.edu/angus/tutorials/using-putty-on-windows.html Windows] oder [http://www.hypexr.org/linux_scp_help.php Linux] auf das Gateway.

Als unverbindliche Richtschnur für Linux:
<code>
scp config.zip root@<ipv4 des Gateways>:/root
</code>

Und entpacken diese auf dem Gateway:
<code>
cd ~

mkdir nordvpn-configs

mv config.zip nordvpn-configs

cd nordvpn-configs

unzip config.zip
</code>

Danach wählen wir einen VPN Server aus, z.B. unter dem Gesichtspunkt das er wenige Hops vom Gateway entfernt ist und/oder in einem Land unserer Wahl steht.

Im Beispiel nehmen wir se1.nordvpn.com.udp1194.ovpn und passen Sie zunächst Freifunk-spezifisch an (siehe Aussperr-Hinweis oben):

<code>
vi se1.nordvpn.com.udp1194.ovpn
</code>

Änhlich wie bei Mullvad, bestimmen wir dass wir das Routing mit einem eigenen Skript festlegen wollen (/etc/openvpn/nordvpn-up) und openvpn die Route nicht selber definieren soll. Zusätzlich geben wir eine Datei an, in die wir später Password und Benutzername des NordVPN Zugangs (/etc/openvpn/nordvpn-pw) ablegen:
<pre>
.
.
.
# Provide Username and Password
auth-user-pass /etc/openvpn/nordvpn-pw
.
.
.
# Allow calling of built-in executables and user-defined scripts.
script-security 2

# Enable Freifunk specific Routing
route-noexec
route-delay 3
route-up /etc/openvpn/nordvpn-up
.
.
.
</pre>

Die angepasste Datei (im Beispiel se1.nordvpn.com.udp1194.ovpn) kopieren wir nach /etc/openvpn und spendieren Ihr gleichzeitig die Endung .conf, damit der Autostart Mechanismus die Konfigurationsdatei als solche erkennt:
<code>
cp se1.nordvpn.com.udp1194.ovpn /etc/openvpn/se1.nordvpn.com.udp1194.ovpn.conf
</code>

Hier legen wir noch unser Freifunk Startskript und unsere Password Datei an und machen das Skript ausführbar:
<code>
touch /etc/openvpn/nordvpn-up

touch /etc/openvpn/nordvpn-pw

chmod +x /etc/openvpn/nordvpn-up
</code>

Man öffnet nordvpn-up...
<code>
vi /etc/openvpn/nordvpn-up
</code>

und füllt die Datei mit identischem Inhalt wie mullvad-up. Bei Interesse stehen weitere Hinweise bei mullvad (Network Adress Translation, Default Gateway für Freifunk Traffic):
<pre>
#!/bin/bash
logger -t OPENVPN VPN Gateway: /sbin/ip route replace default via ${route_vpn_gateway} dev ${dev} proto static table fff
/sbin/ip route replace default via ${route_vpn_gateway} dev ${dev} proto static table fff
iptables -t nat -A POSTROUTING -o ${dev} -j MASQUERADE
</pre>

Nun öffnet man nordvpn-pw:
<code>
vi /etc/openvpn/nordvpn-pw
</code>

Und legt in der ersten Zeile der Datei seinen NordVPN Usernamen und in der zweiten Zeile sein NordVPN Passwort ab:
<pre>
(Username bei NordVPN)
(Password bei NordVPN)
</pre>

Der Tunnel kann nun testweise gestartet werden (hier im Beispiel mit der Konfigurationsdatei se1.nordvpn.com.udp1194.ovpn)
<code>
openvpn /etc/openvpn/se1.nordvpn.com.udp1194.ovpn.conf &
</code>

Und sollte aufgebaut werden:
<pre>
Sun Sep 27 09:07:13 2015 OpenVPN 2.3.2 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [eurephia] [MH] [IPv6] built on Dec 1 2014
.
.
.
Sun Sep 27 09:07:15 2015 /sbin/ip link set dev tun0 up mtu 1500
Sun Sep 27 09:07:15 2015 /sbin/ip addr add dev tun0 local 10.8.8.226 peer 10.8.8.225
Sun Sep 27 09:07:18 2015 Initialization Sequence Completed
</pre>

Wenn alles geklappt hat, kann man (sofern openvpn nicht korrekt beim Systemstart geladen wird), den openvpn Tunnel in der /etc/rc.local bei jedem Systemstart laden:
<code>
vi /etc/rc.local
</code>

und dort z.B. ein zeitverzögertes Starten nach 5 Sekunden vereinbaren:
<pre>
# launch vpn with 5 seconds delay
(sleep 5; cd /etc/openvpn ; /usr/sbin/openvpn se1.nordvpn.com.udp1194.ovpn.conf >> /var/log/nordvpn.log &) &
</pre>
Die Beispiel-Konfigurationsdatei (se1.nordvpn.com.udp1194.ovpn.conf) muss entsprechend angepasst werden.
<br>

Freifunk-Gateway aufsetzen/VPN-Exit - Versionsgeschichte

Meskal am 18. März 2019 um 22:02 Uhr

ChristianD am 28. August 2018 um 06:08 Uhr

ChristianD: muss geprüft werden ob das noch richtig ist, ich verwende es nicht daher keine Prüfung