staging.inyokaproject.org

2024 Woche 12

23. März 2024

Bei KDE wurde kürzlich eine Sicherheitslücke bekannt, die wohl erstmal offen bleiben wird. Komponenten aus dem KDE-Store, der sich an verschiedenen Stellen hinter der Schaltfläche „Neue holen…“ in verschiedenen KDE-Komponenten verbirgt, können Schadcode enthalten und in den Benutzerdaten wüten.

Im konkreten Fall handelte es sich nicht um einen absichtlichen Angriff. Es handelte sich lediglich um einen Fehler. Die Ursache liegt in einer KDE-Funktionalität. Benutzer von Plasma können über den KDE-Store Themes, Widgets und Miniprogramme beziehen. Diese werden zwar nur mit Benutzerrechten installiert, können aber funktionsbedingt ziemlich uneingeschränkt Skripte etc. im jeweiligen Home-Verzeichnis ausführen. KDE benötigt dies, da nicht alle Themes und Miniprogramme über die Distributionen paketiert werden können.

Der Vorfall zeigt einmal mehr, dass Linux auf dem Desktop ein ziemlicher Ponyhof ist. Wenn man es schonungslos auf den Punkt bringt, sieht es so aus: Die KDE-Entwickler bauen eine Sideload-Option für bösartigen Code ein, es fällt jahrelang niemandem auf und nachdem es dann doch auffällt, ist die erste Reaktion im Tenor: „Da kann man nichts machen, ohne die Funktionalität einzuschränken“. Die Nutzer müssen einfach aufpassen und vielleicht kann es eine Warnung geben. Eine Kuratierung wäre wünschenswert, ist aber nicht so schnell umsetzbar und bindet Ressourcen.

Die Nachlässigkeit bei KDE ist die eine Seite der Medaille. Sie ist vermutlich auch deshalb nicht so schlimm, weil diese KDE-Funktion nie besonders exzessiv genutzt wurde und die meisten Anwender mit dem arbeiten, was standardmäßig mitgeleifert wird, weil das bei KDE schon sehr viel ist. Kombiniert wird diese Nachlässigkeit bei KDE mit der immer noch völlig unterschätzten Gefahr fehlender Rechtebeschränkungen innerhalb des Benutzerverzeichnisses. Immer noch geben sich zu viele Linux-Anwender der Illusion hin, dass Schadcode nur dann gefährlich ist, wenn er mit Administratorrechten ausgeführt wird. Ein massiver Datenverlust im Home-Verzeichnis reicht bei nachlässigen Backups aus (und die meisten Anwender sind nachlässig bei Backups). Programme werden unter Linux traditionell kaum eingehegt, sondern können im Home-Verzeichnis nach Belieben schalten und walten.

Machen wir uns nichts vor. Im Falle eines größeren Malware-Drucks wären solche Funktionen fatal und würden massiv ausgenutzt.

22. März 2024

In den letzten Blogposts habe ich gezeigt, wie ich mein privates VPN mit openVPN aufsetze. In diesem Post wiederhole ich das - nur eben mit Wireguard.

OpenVPN und Wireguard können auch problemlos nebeneinander laufen, wenn sie verschiedene Netzmasken benutzen. So hat man jeweils ein Fall-Back-Netz, mit dem man die Clients noch erreichen kann.

Auf dem Handy verbraucht openVPN mehr Strom, weil die Kryptosachen stärker sind. Wireguard ist da schlanker bei ausreichender Verschlüsselung.

VPN

Mein Wireguard-VPN soll unter den Netzen 10.3.3.0/24 und fd04:bab0:3::/64 laufen. Alle Clients sollen sich gegenseitig sehen und anpingen können. Auf Wunsch soll der gesamte Traffic über das VPN geroutet werden.

Installation

Unter Ubuntu lässt sich Wireguard auf Server und Clients wie folgt installieren:

#Ubuntu
apt install wireguard
 
#Arch, btw
pacman -S wireguard-tools

Schlüssel erzeugen

Auf meiner Zertifikationsinstanz (oder auf jedem anderen Rechner) erstelle ich mir einen neuen Ordner und erzeuge für den Server sowie für jeden Client ein Paar aus privatem und öffentlichem Schlüssel.

sudo bash
umask 077 && wg genkey | tee server-private.key | wg pubkey > server-public.key
umask 077 && wg genkey | tee client1-private.key | wg pubkey > client1-public.key
umask 077 && wg genkey | tee client2-private.key | wg pubkey > client2-public.key
umask 077 && wg genkey | tee client3-private.key | wg pubkey > client3-public.key

Die Inhalte der Schlüsseldateien werden gleich plaintext in die Configdateien geschrieben.

Server aufsetzen

Nach der Installation existiert das Verzeichnis /etc/wireguard. In diesem Verzeichnis liegen die .conf-Dateien der VPNs, egal ob Server oder Client. Der Name der .conf-Datei entscheidet über den Namen der Interfaceschnittstelle. Benenne ich die Datei foobar.conf, so wird ein Tunneldevice mit dem Namen foobar erzeugt. Die Datei tun0.conf erzeugt ein Interface mit dem Namen tun0. Standardmäßig (also in den Manuals im Netz) werden für Wireguard wg0-Interfaces erzeugt.

Wir erzeugen also die Datei wg0.conf und geben ihr folgenden Inhalt:

# ---------- Server Config ----------
[Interface]
## welche IP4-Adresse hat der Server im Tunnel?
Address = 10.3.3.1/24

## welche IPv6-Adresse hat der Server im Tunnel?
Address = fd04:bab0:3::1/64 

# Wenn ihr iptables nutzt, dann wird hier das NAT zum Internet klargemacht
# Mein Device heisst eth0, eures auch? ansonsten ändern!
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -s 10.3.3.0/24 -o eth0 -j MASQUERADE; ip6tables -A FORWARD -i wg0 -j ACCEPT; ip6tables -t nat -A POSTROUTING -s fd04:bab0:3::/64 -o eth0 -j MASQUERADE 
# Sobald der VPN beendet wird, werden die iptables Regeln rückgängig gemacht
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -s 10.3.3.0/24 -o eth0 -j MASQUERADE; ip6tables -D FORWARD -i wg0 -j ACCEPT; ip6tables -t nat -D POSTROUTING -s fd04:bab0:3::/64 -o eth0 -j MASQUERADE

# Hier kommt der private Key des Servers hin, in Plaintext
PrivateKey = OHUJätschibätschifasfdeg92wz4CvFqlWWUW74dfgM5+zPfuEU=
# Auf welchem Port soll der Server lauschen?
# Diesen Port in der Firewall freigeben!
ListenPort = 45881 

## Für jeden Client kommt hier eine eigene Identifikation
[Peer] # Client1
# Schreibe hier den öffentlichen Schlüssel des Client1 hinein
PublicKey = AfuckAfDfejoqfooobaaarmHILbtoxReB6ZjzNuMtyYNxlM= 
# Mit welchen IP4 und IPv6-Adressen soll sich der Client verbinden?
# Hier müssen ein /32  und /128 verwendet werden (= genau 1 IP-Adresse erlaubt)
AllowedIPs = 10.3.3.2/32, fd04:bab0:3::2/128 


# Hier wiederholt sich das Ganze für Client2
[Peer] # CLient2
# Client public key
PublicKey = 1xejE9Z2OnkqkuckuckFcOsoLA623M1yRr+7/v7SmAtP36UmG8=  
# IPs client can connect as (IPv4 /32  and IPv6 /128)
AllowedIPs = 10.3.3.3/32, fd04:bab0:3::3/128 

[Peer] # Client3
# Client public key
PublicKey = sCid523sdfXwQHoErOyXyIk8UNEz36aff7+R9MIU8Xm4wc=  
# IPs client can connect as (IPv4 /32  and IPv6 /128)
AllowedIPs = 10.3.3.4/32, fd04:bab0:3::4/128 
  • Der Server lauscht unter IP4 und IPv6 auf Port 45881. Ihr könnt auch irgendeinen anderen Port auswählen.
  • Der Server wird unter den Adressen 10.3.3.1/24 und fd04:bab0:3::1/64 über den Tunnel ereichbar sein. Ebenso haben derzeit 3 Clients Zugriff, wobei jeder Client eine fixe IP4 und IPv6 im Tunnelnetz erhält.
  • Bei den AllowedIPs ist euch sicherlich aufgefallen, dass bei IP4 ein /32 und bei IPv6 ein /128 hinter die Adresse geschrieben werden muss.
    • Auf dem Server fungiert AllowedIPs ähnlich wie ein Router und gibt an, wohin der Datenverkehr geroutet werden soll. Daher genügt die Angabe von /32 oder eben /128 (genau eine IP-Adresse).
    • In der gleich folgenden Client-Config fungiert AllowedIPs wie eine Access-Controll-List. Daher muss in der Client-Config ein /24 bzw. /64 definiert werden, um alles von 10.3.3.* bzw. fd04:bab0:3:: zu akzeptieren.
  • Soll ein weiterer Client hinzugefügt werden, muss in der Server-Config ein neuer [Peer]-Block mit dem puplic key des neuen Clients hinzugefügt werden.

Server starten

Ähnlich wie bei openVPN liest systemd das Verzeichnis /etc/wireguard aus und macht alle dort befindlichen MY-VPN.conf-Dateien verfügbar über den Service wg-quick@MY-VPN.service.

Wir können unseren wg0-Server starten mittels:

# Starten
systemctl start wg-quick@wg0.service
# Logs ansehen
journalctl -u wg-quick@wg0.service -f

Firewall anpassen

Falls ihr eine Firewall benutzt (und ich hoffe doch sehr, dass dies der Fall ist), muss diese für Wireguard angepasst werden. Einerseits muss der Server-Port freigegeben werden (ich habe da ja 45881), anderseits müssen wir intern NAT einrichten, wenn der Internetverkehr über den Tunnel geroutet werden soll.

iptables

Die iptables-Firewall muss auf dem Server und auf den Clients angepasst werden, damit openVPN funktioniert:

## Akzeptiere Pakete von den wg+ Interfaces
iptables -A INPUT -i wg+ -j ACCEPT
iptables -A FORWARD -i wg+ -j ACCEPT

## auf dem Server muss Port 45881 tcp/udp geöffnet werden
iptables -A INPUT -i eth0 -p tcp --dport 45881 -j ACCEPT
iptables -A INPUT -i eth0 -p udp --dport 45881 -j ACCEPT

Wenn euer Device nicht eth0 heisst, müsst ihr den Befehl entsprechend anpassen.

ufw

Die ufw-Firewall muss auf dem Server angepasst werden, damit Wireguard funktioniert. Zunächst muss der Serverport freigegeben werden:

sudo ufw allow 45881

Anschließend müssen drei weitere Dateien editiert werden, damit das Netz funktioniert.

  1. /etc/default/ufw
nano /etc/default/ufw 

DEFAULT_FORWARD_POLICY="ACCEPT"

2a. /etc/ufw/before.rules, füge die folgenden Zeilen vor der *filter-Sektion ein, um das NAT für IPv4 zu aktivieren:

nano /etc/ufw/before.rules

# NAT-Tabelle hinzufügen
*nat
:POSTROUTING ACCEPT [0:0]
# OpenVPN-Regeln hinzufügen
-A POSTROUTING -s 10.3.3.0/24 -o eth0 -j MASQUERADE
COMMIT

2b. /etc/ufw/before6.rules, füge die folgenden Zeilen vor der *filter-Sektion ein, um das NAT für IPv6 zu aktivieren:

nano /etc/ufw/before6.rules

# NAT-Tabelle hinzufügen
*nat
:POSTROUTING ACCEPT [0:0]
# OpenVPN-Regeln hinzufügen
-A POSTROUTING -s fd04:bab0:3::/64 -o eth0 -j MASQUERADE
COMMIT

Wenn euer Device nicht eth0 heisst, müsst ihr den Befehl entsprechend anpassen. Und falls ihr diese Einstellung gerade getroffen habt, könnt ihr in der wg0.conf des Servers die Parameter PostUp und PostUp wieder auskommentieren.

  1. /etc/ufw/sysctl.conf
nano /etc/ufw/sysctl.conf

net/ipv4/ip_forward=1
net/ipv6/conf/default/forwarding=1
net/ipv6/conf/all/forwarding=1

Client einrichten

Auf den Clients erzeugen wir ebenfalls die Datei /etc/wireguard/wg0.conf und geben ihr diesen Inhalt:

# -------- Client Config ------------------
[Interface]
# IP4 Adresse des Clients, so wie in der Server-Config angegeben (/32!)
# Dieser Client bekommt 10.3.3.2
Address = 10.3.3.2/32 
# IPv6 Adresse des Clients (use /128!)
# Dieser Client bekommt fd04:bab0:3::2
Address = fd04:bab0:3::2/128 
# Der Private Key von Client1 im Plaintext
PrivateKey = GNJJAJT0MQnxRHga8Rzp/hLGoCtsefljhelahDks6EMD8Vw= 


[Peer]
# Wie ist der Server erreichbar? Adresse und Port
#Endpoint = [2a02:08:15:4500:fckafd:4]:45881
#Endpoint = 192.168.0.1:45881
Endpoint = vpn.myserver.org:45881

# Der öffentliche Schlüssel des Servers im Plaintext
PublicKey = emV/wFCKAFD4WIyakB/JEi7jp9wH7zBCi81W+qjuMkWc= 

# Sende alle x Sekunden einen Ping an das Netz 
# um den Tunnel aufrecht zu erhalten. 
# Sollte NIE auf dem Server gesetzt werden, 
# sondern nur dort, wo auch "Endpoint" definiert ist. 
# Also hier im Client...
PersistentKeepalive = 5

# Was soll durch den Tunnel geroutet werden?
## Option 1: nur Tunnelkrams durch den Tunnel routen
AllowedIPs = 10.3.3.0/24, fd04:3::/64 
## Option 2: ALLES durch den Tunnel routen
#AllowedIPs = 0.0.0.0/0, ::/0 
  • Diese Datei muss ich nun bei jedem Client nach dem selben Muster anlegen.
  • Der Client erhält seine fest IP4 und IPv6 über den Tunnel
  • Dieses Mal müssen unter Address jeweils ein /32 bzw /128 vergeben werden (= 1 IP Adresse).
    • Der Parameter AllowedIPs fungiert im Clientmodus wie eine Access-Controll-List. Daher wird an dieser Stelle wieder ein /24 bzw. /64 definiert, um alles von 10.3.3.* bzw. fd04:bab0:3:: über den Tunnel zu routen.
  • Soll der gesamte Datenverkehr über den VPN-Tunnel geroutet werden, muss die zweite AllowedIPs-Zeile aktiviert (und die darüberstehende auskommentiert) werden.

Android

Für mein Handy erstelle mich mir wie oben beschrieben ein Schlüsselpaar und generiere mir eine Clientconfig wie oben, wobei ich die zweite AllowedIPs-Option wähle (alles übers VPN routen). Diese wg0.conf übertrage ich per KDE Connect auf mein Handy.

Als App installiere ich mittels F-Droid WG Tunnel von Zane Schepke, da die Original-Wireguard-App Ende 2023 aus dem F-Droid-Repository geflogen ist (weil sie einen integrierten Aktualisierer bekommen hat, der standardmäßig aktiviert ist und nicht transparent angibt, von wo aus er Aktualisierungen herunterlädt; noch fragt er um Zustimmung).

Jetzt kann ich einfach die übertragene wg0.conf-Datei in der App importieren, und alles funktioniert bestens. Ok, in den App-Einstellungen musste ich noch “Tunnel on untrusted wifi” und “Tunnel on mobile data” aktivieren, dann hat es aber sofort funktioniert.

“Tunnel on untrusted wifi” und “Tunnel on mobile data” aktivieren

Weblinks



 

Mozilla hat Firefox 124.0.1 veröffentlicht und behebt damit zwei kritische Sicherheitslücken, welche im Rahmen des Hacking-Wettbewerbs Pwn2Own demonstriert worden sind.

Download Mozilla Firefox 124.0.1

Wieder einmal fand ein Pwn2Own-Wettbewerb im Rahmen der CanSecWest Sicherheitskonferenz in Vancouver statt. Und wie bereits im Vorfeld erwartet, hat Mozilla in Form eines schnellen Updates (weniger als 24 Stunden) auf die Firefox betreffenden Ergebnisse reagiert. Firefox 124.0.1 behebt zwei Sicherheitslücken, welche Mozilla beide als kritisch einstuft. Ebenfalls in diesem Zusammenhang veröffentlicht wurde Firefox ESR 115.9.1.

Der Beitrag Sicherheits-Update Firefox 124.0.1 veröffentlicht erschien zuerst auf soeren-hentzschel.at.

20. März 2024

Mozilla hat Firefox 124 für Windows, Apple macOS und Linux veröffentlicht. Dieser Artikel fasst die wichtigsten Neuerungen zusammen – wie immer auf diesem Blog weit ausführlicher als auf anderen Websites.

Download Mozilla Firefox für Microsoft Windows, Apple macOS und Linux

Offene Tabs in Firefox View sortieren

Die mit Firefox 106 eingeführte und mit Firefox 119 stark verbesserte Funktion Firefox View hatte mit Firefox 123 eine Suchfunktion sowie verbesserte Performance erhalten. Firefox 124 bringt eine weitere Verbesserung: Im Reiter der offenen Tabs ist es ab sofort möglich, diese wahlweise nach der neuesten Aktivität oder nach der Tab-Reihenfolge zu sortieren.

Plattform-Verbesserungen auf Apple macOS

Firefox auf macOS nutzt nun endlich auch die native Vollbild-Schnittstelle des Apple-Betriebssystems, womit sich Firefox in bestimmten Aspekten mehr so verhält, wie man es unter macOS erwartet.

Seit macOS 14 zeigt das Apple-Betriebssystem ein Kamera-Symbol in der Menüleiste an, wenn der Kamera-Zugriff für eine Website aktiviert ist. Firefox selbst zeigt ebenfalls ein Kamera-Symbol in der Menüleiste an. Über die neue Option privacy.webrtc.showIndicatorsOnMacos14AndAbove in about:config auf false kann der Indikator, der von Firefox kommt, auf macOS 14 und höher deaktiviert werden.

Die Schriftgröße in Dialogen auf macOS war bisher sehr klein. Hier verwendet Firefox ab sofort eine etwas größere Schrift.

Sonstige Endnutzer-Neuerungen von Firefox 124

Die Textcursor-Steuerung, welche durch Drücken der Taste F7 aktiviert werden kann, funktioniert jetzt auch in PDF-Dateien.

Die Suchmaschine Qwant steht nicht mehr nur bei Verwendung der französischen Sprache, sondern ab sofort auch für Nutzer anderer Sprachen in Frankreich sowie für Nutzer in der Schweiz, Belgien, Italien, den Niederlanden sowie Spanien standardmäßig zur Verfügung.

Für Nutzer, welche die separate Suchleiste aktiviert, aber seit mindestens 120 Tagen nicht genutzt haben, wird diese automatisch aus der Oberfläche entfernt.

Firefox geht jetzt besser mit Änderungen der Netzverbindung um, zum Beispiel bei Aktivierung respektive Deaktivierung eines VPNs oder DNS-over-HTTPS, sodass Firefox bei einem Wechsel nicht mehr erst einmal eine Zeit lang benötigt, um wieder erfolgreich Verbindungen zu Websites aufbauen zu können.

Die Jump List in der Taskleiste von Windows wird nun effizienter befüllt, was die Performance verbessern sollte.

Für Nutzer in den USA gibt es, sofern gesponserte Vorschläge in der Adressleiste aktiviert sind, jetzt auch Suchvorschläge von Yelp.

Mehr Sicherheit für Firefox-Nutzer

Auch in Firefox 124 wurden wieder mehrere Sicherheitslücken geschlossen. Alleine aus Gründen der Sicherheit ist ein Update auf Firefox 124 daher für alle Nutzer dringend empfohlen.

Verbesserungen der Entwicklerwerkzeuge

Mit Firefox 122 hatte Mozilla die Tastatur-Steuerung des Regeln-Panels im Inspektor-Werkzeug überarbeitet. Diese Änderung wurde in Firefox 122.0.1 aufgrund von Nutzer-Feedback standardmäßig wieder rückgängig gemacht und eine Option in about:config implementiert, über welche man das gewünschte Verhalten steuern kann. Firefox 124 ergänzt eine sichtbare Option in den Einstellungen der Entwicklerwerkzeuge.

Das Netzwerkanalyse-Werkzeug zeigt jetzt auch Ressourcen an, welche über das file://-Protokoll geladen werden.

Performance-Verbesserungen gab es für das Regeln-Panel des Inspektors bei vielen zutreffenden CSS-Regeln sowie für die Darstellung von Objekten in der Konsole.

Verbesserungen der Webplattform

Auf CSS-Seite neu ist die Unterstützung von text-wrap: wrap und text-wrap: nowrap. Die Pseudo-Elemente ::first-letter und ::first-line können außerdem jetzt auch für das <text>-Element in SVG-Grafiken verwendet werden.

Firefox unterstützt jetzt AbortSignal.any. Außerdem können jetzt HTTP(S) sowie relative URLs für die Erstellung von WebSockets genutzt werden.

Für Entwickler von Firefox-Erweiterungen wurde ein neues WebExtension-Event hinzugefügt, worüber Erweiterungen Informationen erhalten können, wenn eine Performance-Warnung ausgegeben wird.

Weitere Neuerungen für Entwickler von Websites lassen sich in den MDN Web Docs nachlesen.

Der Beitrag Mozilla veröffentlicht Firefox 124 erschien zuerst auf soeren-hentzschel.at.

19. März 2024

Die MZLA Technologies Corporation hat mit Thunderbird 115.9 ein planmäßiges Update für seinen Open Source E-Mail-Client veröffentlicht.

Neuerungen von Thunderbird 115.9

Mit dem Update auf Thunderbird 115.9 hat die MZLA Technologies Corporation ein planmäßiges Update für seinen Open Source E-Mail-Client veröffentlicht. Das Update bringt diverse Fehlerbehebungen und Verbesserungen unter der Haube, welche sich in den Release Notes (engl.) nachlesen lassen. Auch wurden diverse Sicherheitslücken geschlossen.

Der Beitrag Thunderbird 115.9 veröffentlicht erschien zuerst auf soeren-hentzschel.at.

Im letzten Blogpost habe ich beschrieben, wie ich mein privates Netz mit openVPN aufbaue. In diesem Post möchte ich zeigen, wie man Android-Geräte dem Netz hinzufügen kann, und was ich tun musste, damit der Server korrekt auf IPv4 und IPv6-Anfragen lauscht.

IPv6

Mein Heimserver, der die VPNs aufbaut, ist sowohl per IPv4 als auch per IPv6 erreichbar. Da das Mobilnetz an Handy und Tablet fast ausschließlich IPv6 nutzt, ist es eine gute Idee, auf beiden Netzen zu lauschen. Damit der openVPN-Server sowohl per IPv4 als auch per IPv6 auf Anfragen antwortet, ändere ich in der Server-Config die Stelle

proto udp

auf

proto udp6

UDP6 antwortet mit anderer Adresse

Bei mir gab es das Problem, dass udp6 nicht mit der IP-Adresse auf Anfragen antwortet, an welche die Anfrage abgeschickt wurde. Mein Server hat beispielsweise die feste IPv6 2002:bla:fasel::4/64. Mein Handy sendet nun aus dem Mobilnetz (da gibt es nur IPv6) an diese Adresse seine Anfrage, aber der Server antwortet mit einer neuen IPv6, z.B. 2002:bla:fasel:ätschi:bätsch:4/64. In diesem Falle kommt keine Verbindung zu Stande (das scheint schon länger und immer wieder ein Problem mit UDP zu sein).

Die Lösung besteht darin, in der Server-Config die Zeile multihome zu ergänzen.

proto udp6
multihome

Die Option stellt sicher, dass die UDP-Antwortpakete immer von der Adresse gesendet werden, an welche der Client seine Anfragen gestellt hat.

IPv6-ULA einrichten.

Bislang bekommen alle Clients eine IP4 aus dem 10.5.5.0/24 Bereich, wobei ich über das ccd-Verzeichnis jedem Client eine feste IP gegeben habe. Da ich den Server nun auch aus dem IPv6-Netz heraus erreichbar gemacht habe, verteile ich über mein VPN zusätzlich IPv6-ULA-Adressen aus dem Bereich fd04:bab0::/64, so dass alle Clients auch per IPv6 ansprechbar sind.

Hierfür ergänze ich die Server-Config um folgende Zeilen:

server-ipv6 fd04:bab0::/64        # ULA IPv6 Subnetz für OpenVPN-Clients
push "route-ipv6 fd04:bab0::/64"  # ULA IPv6 Subnetz an die Clients weitergeben

Ebenfalls ergänze ich im ccd-Verzeichnis die Dateien aller Clients um folgende Zeile:

ifconfig-ipv6-push fd04:bab0::xyz/64

wobei ich für xyz jeweils die selbe Ziffer nehme wie im IPv4 Netz.

Nach einem Neustart des VPN-Servers erhalten alle Clients automatisch eine 10.5.5.0/24 sowie eine fd04:bab0::/64-Adresse und können sich gegenseitig über IPv4 oder IPv6 anpingen. An den Client-Configs muss nichts geändert werden.

IPv6 Internet durch den Tunnel routen

Damit auch das globale IPv6-Internet durch den Tunnel geroutet werden kann, müssen die Firewallregeln angepasst werden.

iptables

# iptables
ip6tables -t nat -D POSTROUTING -s fd04:bab0::/64 -o eth0 -j MASQUERADE

ufw

Für IPv6 muss die Datei /etc/ufw/before6.rules angepasst werden. Füge die folgenden Zeilen vor der *filter-Sektion ein, um das NAT für IPv6 zu aktivieren:

nano /etc/ufw/before6.rules

# NAT-Tabelle hinzufügen
*nat
:POSTROUTING ACCEPT [0:0]
# OpenVPN-Regeln hinzufügen
-A POSTROUTING -s fd04:bab0::/64 -o eth0 -j MASQUERADE
COMMIT

Zertifikate erstellen

Damit Handy und Tablet das VPN nutzen können, benötigen sie wieder gültige Zertifikate und den ta.key des VPNs (siehe letzter Blogpost).

Dazu wechsle ich auf meine Zertifikationsinstanz und erstelle wie gewohnt Zertifiakte für Handy und Tablet, z.B. so:

sudo bash
cd /etc/easy-rsa
easyrsa gen-req handy nopass
easyrsa sign-req client handy

easyrsa gen-req tablet nopass
easyrsa sign-req client tablet

Zertifikat für Android umwandeln

Wir können Androids Zertifikateverwaltung nutzen, um die Zertifikate halbwegs “sicher” auf den Geräten zu verwalten. Hierfür bündeln wir

  • /etc/easy-rsa/pki/private/handy.key
  • /etc/easy-rsa/pki/issued/handy.crt
  • /etc/easy-rsa/pki/ca.crt

in einer PKCS-Datei mit dem Namen handy.p12, die wir dann später am Handy importieren können. Der dazugeöhrige Befehl lautet:

openssl pkcs12 -export -in CERT -inkey KEY -certfile CA -name CLIENTNAME -out OUTPUT.p12

In meinem Fall also

openssl pkcs12 -export -in pki/issued/handy.crt -inkey pki/private/handy.key -certfile pki/ca.crt -name handy -out handy.p12

Ihr werdet nach einem Export-Passwort gefragt. Denkt euch irgendetwas halbwegs sicheres aus. Am Handy muss später dieses Passwort beim Import eingegeben werden.

Die erzeugte PKCS-Datei handy.p12 sowie der ta.key des VPN müssen nun auf das Handy kopiert werden. Ich nutze hierfür meine Nextcloud, KDE Connect oder eine E-Mail an mich selbst.

  • Ist die Datei handy.p12 auf das Handy kopiert, klicke ich am Handy auf eben diese Datei, um die Zertifikate in den Android-Zertifikatespeicher aufzunehmen. Hierbei muss das oben erwähnte Passwort eingegeben werden.
  • Die Datei ta.key kopiere ich an eine Stelle meines Handys, die ich mir merken kann, z.B. “Dokumente/OpenVPN”

openVPN for Android

Für Android steht z.B. über F-Droid das Paket von blinkt zur Verfügung, siehe https://f-droid.org/packages/de.blinkt.openvpn/

  • In der Client-App erstelle ich ein neues Profil mit dem Namen “test” (Name ist ja egal).
  • Im Reiter “Basic” klicke ich bei “Client Certificate” auf den Select-Button. So kann ich das eben in Android importierte Zertifikat auswählen.

importierte Zertifikate im Androidspeicher
  • Im Reiter “Server List” trage ich meinen Server ein und wähle unter “Protocol” UDP.

Serveradresse und Protocol “UDP”
  • Unter dem Reiter “Authentication/Encryption” müssen folgende Einstellungen getroffen werden:
    • bei TLS-Settings entferne ich den Haken bei “Certificate Hostname Check”

kein “Certificate Hostname Check”
  • dafür setze ich den Haken bei “Use Control Channel Authentication/Encryption”
    • als “TLS Auth/TLS Encrpytion File” wähle ich den auf das Handy kopierten ta.key
    • als “Authentication/encryption method” wähle ich Encryption (--tls-crypt)

TLS Auth/TLS Encrpytion File ist ta.key und Encryption --tls-crypt
  • bei “Encryption ciphers” trage ich (gemäß meiner Server-Config) AES-256-CBC:AES-256-GCM ein.

Encryption ciphers auf AES-256-CBC:AES-256-GCM

Das funktioniert wunderbar, und mein Handy kann sich mit meinem VPN verbinden.

erfolgreich verbunden

Jetzt können sich alle Clients (auch die Mobilgeräte über IPv6) mit dem Server verbinden und sich gegenseitig anpingen.

gesamten Verkehr der Mobilgeräte über das VPN routen

Im Reiter “Routing” können bei Bedarf die Haken bei “Use default Route” für IPv4 und IPv6 gesetzt werden. Dann wird der gesamte Datenverkehr des Handys über das VPN geroutet. Die Server-Config muss dafür nicht angefasst werden.

alles übers VPN routen

Das ist sehr vorteilhaft, z.B. wenn man in einem ranzigen WLAN unterwegs ist (McDoof, Bahn, etc.) oder im Ausland dennoch “Sportschau” übers Netz schauen möchte. Auch funktioniert KDE Connect bestens über das VPN, was für meinen Büro-PC sehr gut ist.

Möchtet ihr auch bei anderen Clients (z.B. beim Laptop) den gesamten Datenverkehr durch das VPN routen, müsst ihr in dessen Client-Config folgende Zeile ergänzen:

redirect-gateway def1 # leitet gesamten Datenverkehr über das VPN

Das def1 steht für “default route” und muss nicht weiter angepasst werden. Nun läuft auch am Laptop alles über das VPN.

Weblinks



 

Nutzer von Firefox auf openSUSE sehen derzeit sämtliche Erweiterungen deaktiviert. Schuld ist eine Änderung seitens der Linux-Distribution.

Firefox-Nutzer, welche die Linux-Distribution openSUSE nutzen, können derzeit nicht ihre Firefox-Erweiterungen verwenden. Die Ursache hierfür ist eine Änderung des crypto-policies-Paketes, welche openSUSE ausgerollt hat und nicht kompatibel mit Firefox ist. Betroffene Nutzer sollten auf ein Update warten, welche diese Änderung wieder rückgängig macht. Vom Entfernen und erneuten Installieren der Firefox-Erweiterungen wird abgeraten, da hierdurch die Konfigurationen der jeweiligen Erweiterungen verloren gehen.

Update 14.50 Uhr: Mittlerweile hat openSUSE auf das Problem reagiert und das betroffene Paket erneut aktualisiert. Damit tritt das Problem nicht länger auf.

Der Beitrag openSUSE-Update sorgt für deaktivierte Erweiterungen in Firefox erschien zuerst auf soeren-hentzschel.at.

18. März 2024

Wenn ich über Rolling-Release-Distributionen und den Wartungsaufwand von Linux schreibe, kommen zuverlässig Kommentare, dass das alles kein Problem sei und man selbst seit x Jahren mit der Distribution y ohne Neuinstallation arbeitet. Kann sein. Muss es nicht. Vor allem aber fehlt es an Planbarkeit.

Ende Februar hat KDE das lange angekündigte Mega Release veröffentlicht. Dabei handelt es sich um die gleichzeitige Aktualisierung des Plasma-Desktops auf Version 6 und der nun auf Qt 6 basierenden Applikationssammlung. Im Gegensatz zu früheren Versionssprüngen ist KDE hier ein grundsolides Release gelungen. Es gibt sinnvolle Verbesserungen, keine großen Brüche, keine signifikanten Funktionseinbußen und vor allem keine riesigen Buglisten. Hier hat KDE definitiv dazugelernt.

Für ein paar Tage war dann Ruhe. Schließlich mussten die Entwickler erst testen, dann bauen und die QA musste auch noch drüber laufen. Aber letzte Woche wurde Plasma 6 und alles was dazu gehört in openSUSE Tumbleweed verteilt. Das geschah ohne Zeitplan und ohne große Ankündigung. Wem das gerade nicht in den Kram passte, weil er das System gerade dringend für einen Arbeitsprozess oder ähnliches benötigte, der konnte ab diesem Tag nur noch das Aktualisieren und Neuinstallieren von Paketen einstellen. Sicherheitsupdates kommen dann natürlich auch nicht mehr. Rolling Release heißt eben auch unweigerlich mitrollen.

Das Update selbst ruckelte sehr stark. Das berichten viele Nutzer. Die Probleme – das möchte ich ausdrücklich betonen – lagen nicht bei KDE, sondern bei der Update-Routine von openSUSE. Der eigentliche Vorgang über zypper brach bei Anwendern mit laufender Wayland-Session mittendrin ab. Wer dann nicht auf TTY wechselte und dort das Update beendete, hatte ein inkonsistentes System und landete bestenfalls nach einem Neustart wieder bei Plasma 5. Größere Probleme waren dann noch fehlende Übergänge bei SDDM, weshalb hier entweder die Konfigurationsmöglichkeit verloren ging oder gleich alle Pakete. Die automatische Entsperrung von KWallet über PAM funktionierte nicht mehr und die Desktopsuche Baloo hing in einem Mix aus 5 und 6 fest. Hinzu kamen kleinere und größere Probleme mit einzelnen Programmen. Je nach Einschätzung des Aufwandes konnte man sich dann entweder einzeln auf Fehlersuche begeben (wobei ein Unfallauto immer ein Unfallauto bleibt) oder neu installieren. Das Zurückspringen über Snapper und ein erneuter Versuch brachte letztlich meist ein ähnliches Ergebnis, ist also nicht die Lösung.

Jetzt wird natürlich wieder jemand schreiben, mit der Distribution xyz wäre das nicht passiert, man hätte nur dies und jenes beachten müssen usw. usf.

Aber meiner Ansicht nach zeigt diese fehlerhaften Aktualisierung wieder verschiedene Punkte:

  • RR-Verteilungen sind nur für den unkritischen privaten Gebrauch geeignet. Solche Großupdates sind nicht planbar, nicht vorhersehbar und nicht verschiebbar. Das macht RR-Distributionen für den produktiven Einsatz ungeeignet.
  • Die klassische Paketverwaltung mit ihren systemimmanenten Problemen ist am Ende ihres Entwicklungszyklus angelangt. Bessere Übergänge bei openSUSE hätten manches verhindert, aber das System aus tausenden Paketen mit fein definierten Abhängigkeiten und Überleitungen ist ein fehleranfälliges Konstrukt. Ein festes Image aus Basissystem und Desktop plus Anwendungsprogrammen hätte diese Probleme beim Update nicht verursacht.
  • Linux ist und bleibt wartungsintensiver als vergleichbare Systeme.