Kürzlich kursierte im Internet ein Gerücht, dass YouTube in Albanien keine Werbung spielen dürfe. Das stimmt in der Tat nicht, es gibt kein Gesetz in Albanien, welches Werbung per se verbieten würde. Vielmehr sieht Google derzeit Albanien nicht als interessanten Markt für sein Partnerprogramm, was das Ausmaß an Werbung drastisch reduziert.
Während man an einem vollwertigen Computer durchaus Adblock oder andere Tools nutzen kann, ist diese Option z. B. an Fernsehgeräten nicht direkt gegeben. Hier kann man Werbung nur schwer und manchmal gar nicht blockieren.
Abhilfe kann hier das Routing via albanisches VPN schaffen. Da die meisten Geräte wie z. B. von Samsung heftig in ihren Möglichkeiten, ein VPN direkt zu nutzen, eingeschränkt sind, empfiehlt es sich ein völlig unabhängiges Gateway mit einem alten Computer, Home-Server oder einfach einem ganz einfachen RaspberryPi aufzusetzen. Im Testaufbau nutze ich schlicht meinen Home-Server, welcher für solche Zwecke ohnehin konzipiert ist.
Vorbereitung
Wir brauchen also:
- ein albanisches VPN
- oder einen albanischen virtuellen Server (VPS)
- einen Kleinstcomputer oder ähnliches mit Linux
Ferner muss unser TV-Gerät folgendes können:
- IP-Adressdaten DNS und Gateway müssen frei wählbar sein (wenn nicht auch nicht schlimm, aber viel komplizierter und von diesem Beitrag nicht abgedeckt)
Bei meinem Gerät aus diesem Testaufbau (Samsung QN85C) ist das mit Einschränkungen gegeben, dazu mehr im Fazit.
Umsetzung
Virtual Server bestellen (wenn fertiges VPN gewünscht, diesen Teil überspringen)
Meinen Testserver bestellte ich bei AVS ISP, einen albanischen, günstigen Anbieter von virtuellen Servern und VPN. Der günstigste virtuelle Server beginnt hier bei 2,50€ im Monat. Ich wählte aufgrund der geringen Bandbreite von 50 Mbit/s hier den nächstgrößeren für 5,00€ im Monat mit einer Bandbreitenbeschränkung von 100 Mbit/s.
AVS ISP fand ich in diesem Fall über lowendbox.com, eine Plattform für meist sehr günstige, kleine Virtual Server.
Virtual Server einrichten
Ist der Virtual Server bestellt, erhält man zügig die nötigen Zugangsdaten. Mit diesen erfolgt ein Login via SSH und ein grundlegendes Setup:
- WireGuard
- IPv4-Forwarding
- NAT
WireGuard (Server)
apt update
apt install wireguard
wg genkey | tee privatekey-server | wg pubkey > publickey-server
wg genkey | tee privatekey-client | wg pubkey > publickey-client
nano /etc/netplan/50-cloud-init.yaml
# Inhalt unten anfügen in /etc/netplan/50-cloud-init.yaml
tunnels:
wg0:
mode: wireguard
key: <Inhalt von privatekey-server>
port: 51823
addresses: [ 10.80.81.3/24 ]
peers:
- allowed-ips: [ 10.80.81.4/32 ]
keepalive: 4
keys:
public: <Inhalt von publickey-client>
Anschließend alles neustarten:
netplan apply
systemctl restart systemd-networkd
WireGuard (Client)
Nun zum Client wechseln und WireGuard konfigurieren.
nano /etc/netplan/50-cloud-init.yaml
# Inhalt unten anfügen in /etc/netplan/50-cloud-init.yaml
tunnels:
wg0:
mode: wireguard
key: <Inhalt von privatekey-client>
port: 51822
addresses: [ 10.80.81.4/24 ]
peers:
- allowed-ips: [ 0.0.0.0/0 ]
endpoint: <Server-IP vom VPS>
keepalive: 4
keys:
public: <Inhalt von publickey-server>
routing-policy:
- from: 192.168.188.37/32
table: 200
- from: 192.168.188.40/32
table: 200
routes:
- to: 0.0.0.0/0
via: 10.80.81.3
table: 200
on-link: true
Anzupassen sind dabei die Subnetze oder via „/32“-Suffix die einzlnen IPs der zu routenden Endgeräte aus dem eigenen Netz. In meinem Fall wären das .37 – TV, .-40 – mein Heimcomputer.
Wieder alles neustarten:
netplan apply
systemctl restart systemd-networkd
Mittels „wg“ Kommando sollte nun zu sehen sein, dass eine grundlegende Verbindung besteht:
root@s01:~# wg
interface: wg0
public key: <hier steht der publickey-client>
private key: (hidden)
listening port: 51822
peer: <hier steht der publickey-server>
endpoint: <Server-IP vom VPS>:51823
allowed ips: 0.0.0.0/0
latest handshake: 1 minute, 47 seconds ago
transfer: 2.78 GiB received, 157.68 MiB sent
persistent keepalive: every 5 seconds
Ferner sollte ein „ping“ zum Server klappen:
root@s01:~# ping 10.80.81.3
PING 10.80.81.3 (10.80.81.3) 56(84) bytes of data.
64 bytes from 10.80.81.3: icmp_seq=1 ttl=64 time=78.0 ms
Netzwerkeinrichtung
Am Server
Wir realisieren in das Internet ein NAT und maskerieren den Traffic, da unser VPN-internes 10.80.81.0/24 Netz im Internet nicht zu uns geroutet wird und wir eine Adressumsetzung an dieser Stelle zwingend benötigen.
# IP Forwarding aktivieren
echo "net.ipv4.ip_forward=1" > /etc/sysctl.d/98-ipforward.conf && sysctl --system
apt install iptables-persistent
# zweimal "Nein" -> wir speichern die aktuellen Regeln nicht
nano /etc/iptables/rules.v4
# Inhalt /etc/iptables/rules.v4
*filter
-A FORWARD -i eth0 -o wg0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i wg0 -o eth0 -j ACCEPT
COMMIT
*nat
-A POSTROUTING -s 10.80.81.0/24 -o eth0 -j MASQUERADE
COMMIT
Am Client (Gateway)
Wir realisieren mit iptables ein NAT und maskerieren den Traffic, da wir ein dem virtuellen Server unbekanntes Netz nutzen. Alternativ könnten wir eine statische Route in unser Netz setzen, müssten dann aber dafür sorgen, dass weder unser Serverprovider, noch ein anderer seiner Kunden unser VPS als Gateway in unser persönliches Heimnetz nutzt (Firewall-Regeln).
Für den Zweck des Adblockings reicht ein NAT-Setup vollständig.
# IP Forwarding aktivieren
echo "net.ipv4.ip_forward=1" > /etc/sysctl.d/98-ipforward.conf && sysctl --system
apt install iptables-persistent
# zweimal "Nein" -> wir speichern die aktuellen Regeln nicht
nano /etc/iptables/rules.v4
# Inhalt /etc/iptables/rules.v4
*filter
-A FORWARD -i wg0 -o enp5s0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i enp5s0 -o wg0 -j ACCEPT
COMMIT
*nat
-A POSTROUTING -o wg0 -j MASQUERADE
COMMIT
Am Router
Die nachfolgende Einrichtung am TV-Gerät ist sehr unterschiedlich. Manche Geräte sind sehr flexibel und erlauben zahlreiche Einstellungen. Manche Geräte, insbesondere neuere Geräte von Samsung mit Tizen OS sind bei der Betrachtung der Flexibilität bei Konfigurationen katastrophal. Mein Gerät unterstützt zwar die Konfiguration von IPv4 (manuell) und lässt auch zu ein alternatives Gateway zu setzen, jedoch lässt sich IPv6 nicht deaktivieren. Ist IPv6 im Netzwerk mit einem RADVD (Router Advertisement Daemon) aktiv, lässt mein Gerät die Deaktivierung von IPv6 nicht zu. Es lässt jedoch auch nicht zu, manuelle IPv6-Einstellungen zu treffen. Da die meisten Apps, insbesondere der großen Tech-Unternehmen wie Google, wozu bekanntermaßen YouTube gehört, meist für ihren Traffic IPv6 nutzen, würde das den gesamten Testaufbau ad absurdum führen.
IPv6 muss daher in meiner FRITZ!Box deaktiviert werden. Das gilt so auch für jeden Router, welcher IPv6-Advertisements verschickt. Leider lässt die FRITZ!Box wiederum es nicht zu IPv6 per Gerät zu deaktivieren. Nur eine ganzheitliche Deaktivierung hilft.
Alternativ ist es noch möglich einen zweiten RADVD im Netzwerk zu starten und die Prioritäten der Advertisement-Daemons, also der Software, welche die lokale IPv6-Zuweisung analog zu DHCP, übernimmt, so anzupassen, dass das TV-Gerät ein besonderes durch mich konfigurierbares IPv6-Setup erhält bevor die FRITZ!Box die Einstellungen zuweist. Das sprengt jedoch wieder den Rahmen dieses Beitrags.
Am TV-Gerät
In meinem Fall am QN85C sind folgende Einstellungen unter „Einstellungen“ -> „Connection“ -> „Network“ zu treffen:
Wobei alles Standardwerte sind, außer das Gateway, welches die IP meines lokalen Gateways darstellt.
Abschluss
Zum Abschluss sollte nun ein grundlegender Test durchgeführt werden. Funktioniert alles? -> Gut. Nein? -> Gerne in die Kommentare, ich werde versuchen nach meinen Möglichkeiten zu unterstützen.
Fazit
Der Aufbau birgt ein paar Risiken und Nachteile, auf die ich hier gesammelt eingehen möchte:
- Je nach TV-Gerät muss IPv6 im gesamten Netzwerk deaktiviert und auf seine Vorteile verzichtet werden. Alternativ muss ein lokaler Router Advertisement Daemon gestartet werden.
- Der gesamte Traffic des TV-Gerätes wird bei diesem Aufbau über das VPN und den virtuellen Server geleitet. Das kann nützlich sein, manchmal aber auch zu Nachteilen führen (z. B. bei der Netflix-Standort-Kontrolle).
- Dieser Testaufbau deckt nicht alle Möglichkeiten (Single-NAT statt Double-NAT, Policy-based Routing anhand der Zieladressen. etc.) ab. Netzwerktechnik ist hochflexibel, aber auch komplex. Viele alternative Anwendungsszenarien sind möglich.
- Im Testaufbau nutze ich für WireGuard ausschließlich netplan und systemd-networkd. Die Konfiguration mittels wg-quick oder ähnlichen Tools ist gleichermaßen möglich und vereinfacht einige Schritte unter Umständen.
- In einigen Fällen fiel die Verbindung zum VPS oder die Verbindung vom VPS ins Internet aus. Das wiederum führte bei meinem Samsung TV zu Verbindungsproblemen in der Spotify-App, welche sich nur durch einen vollständigen Neustart (auf der Fernbedienung lange den Einschaltknopf drücken) beheben ließen.
- In Anbetracht der Abstriche und der unpraktischen Verwaltung dieses Setups, werde ich dieses mittelfristig wahrscheinlich nicht beibehalten und alternative Lösungen prüfen.