Projekte Tech-Blogging by Thomas Winkler 2019-07-25T12:04:00+00:00 Thomas Winkler https://prismplex.tech/blog Wireguard VPN via Docker https://prismplex.tech/de/blog/wireguard-server-docker 2019-07-25T12:04:00+00:00 2019-07-25T12:04:00+00:00

Einleitung

VPNs werden immer beliebter, um die Privatsphäre zu schützen. Ich möchte hier ein kurzes Tutorial zu einem VPN auf wireguard-Basis in einem Docker-Contaier geben.

Kernel Modules

Bevor man Wireguard in einem Docker Container laufen lassen kann, muss man zuerst die Kernel Header und das Kernel Modul installieren. Unter Manjaro geht das so:

$ sudo pacman -S linux-headers

Anmerkung: Es wird nun gefragt, welchen Header er installieren soll, man wählt hier den Header für die Version des installieren Linux Kernels aus. Wenn man gerade nicht weiß, welche Version man installiert hat, kann man das über diesen Befehl herausfinden: uname -r

Als nächstes installiert man das Kernel Modul über diesen Befehl:

sudo pacman -S dkms wireguard-dkms wireguard-tools

Wireguard im Docker Container

Als erstes sucht man sich einen Ordner und erstellt in diesem als Beispielkonfiguration folgende docker-compose.yml:

version: "2"
services:
 vpn:
  image: cmulk/wireguard-docker
  #network_mode: host
  volumes:
   - ./etc-wireguard:/etc/wireguard
  networks:
   - net
  ports:
   - 7777:7777/udp
  restart: unless-stopped
  cap_add:
   - NET_ADMIN
   - SYS_MODULE

networks:
  net:

Als nächstes erstellt man über mkdir etc-wireguard den entsprechenden Ordner für die Konfiguarationsdateien. server.conf

[Interface]
Address = 192.168.20.1/24
PrivateKey = <server-private-key>
ListenPort = 7777

[Peer]
PublicKey = <client-public-key>
AllowedIPs = 192.168.20.2

*client.config

[Interface]
Address = 192.168.20.2/24
PrivateKey = <client-private-key>
ListenPort = 0 #needed for some clients to accept the config

[Peer]
PublicKey = <server-public-key>
Endpoint = 24.134.225.237:7777
AllowedIPs = 0.0.0.0/0,::/0 #makes sure ALL traffic routed through VPN
PersistentKeepalive = 25

Die entsprechenden "private-keys" und "public-keys" lassen sich zum Beispiel über die Android-App oder die iOS-App. Jeweils zwei Konfigurationen anfangen zu erstellen und dort die entsprechenden Schlüssel generieren. Das ganze macht man zweimal, einmal für den Server und einmal für den Client und modifiziert dann die jeweiligen Konfiguarationsdateien. Die fertige Client-Konfiguration lässt sich dann einfach importieren. Zum Schluss wechselt man wieder in den Oder der "docker-compose.yml" und startet den Conatainer per sudo docker-compose up -d

Quellen

]]>
DNSCrypt und Pi-hole auf einem Raspberry Pi 3 mit Autoupdate https://prismplex.tech/de/blog/dnscrypt-pihole-raspberry 2019-07-24T16:50:00+00:00 2019-07-24T16:50:00+00:00

Einleitung

Vor einiger Zeit stieß ich auf einen Artikel zu DNS-Abfragen und die Rolle des Providers. Ich möchte diesen Artikel nur kurz aufs Wesentliche herunterbrechen: Jede Adresse, die man in die Adresszeile seines Browsers eingibt, landet bei einem sogenannten DNS-Server, der zur eingegebenen Webadresse die jeweilig zugehörige IP-Adresse abfragt und den Nutzer dann entsprechend auf den Zielserver weiterleitet. Nun ergibt sich bei genauerer Überlegung folgende Problematik: Heutzutage verwendet fast jede Webseite, die etwas von sich hält "https" also Webkommunikation über TLS-Verschlüsselung (zum Glück immer seltener SSL-Verschlüsselung). Die Anfragen an den DNS-Server sind jedoch unverschlüsselt, d.h. theoretisch könnte es jemanden mit entsprechendem Wissen gelingen, Anfragen, die an den DNS-Sender gesendet werden, entsprechend zu manipulieren und dann bei einem Aufruf von z.B. duckduckgo.com eine andere Adresse anzuzeigen. Freilich wird das dann schwieriger das "https"-Zertifikat zu fälschen, hierzu bräuchte der Angreifer Zugriff auf die DNS-Einstellungen der jeweiligen Domain. Aber eine "http"-Seite, ohne entsprechende Verschlüsselung, ließe sich damit theoreitsch relativ leicht, ohne Wissen den Nutzers umleiten, sogenanntes "DNS spoofing". Neben dem "DNS spoofing" muss man sich noch einer Tatsache bewusst werden. Standardmäßig surft man immer über den DNS-Server des eigenen Internetproviders. Im Klartext heißt das, dass dieser theoretisch jede Abfrage mitloggen kann und so jederzeit nachvollziehen kann, welcher Benutzer mit welcher IP zu welchen Zeiten auf welchen Webseiten war. Was den Datenschutz angeht, ist das höchst fragwürdig...

Um sich dagegen zu schützen, gibt es zwei Möglichkeiten:

  1. Eine Verschlüsselte zum DNS-Server über "https" (DoH)
  2. DNSCrypt mithilfe von verschiednen "private keys" und "public keys"

Hypriot OS

Als erstes installiert man sich Hypriot OS. Flashen der heruntergeladenen .zip Datei gelingt am besten mit balena Etcher. Nach erneutem mounten der SD-Karte sollte eine Partition namens "Hypriot OS" erscheinen. Hier sucht man die Datei user-data und bearbeitet diese nach Wünschen. Eine Beispielkonfiguration:

#cloud-config
# vim: syntax=yaml
#

# The current version of cloud-init in the Hypriot rpi-64 is 0.7.6
# When dealing with cloud-init, it is SUPER important to know the version
# I have wasted many hours creating servers to find out the module I was trying to use wasn't in the cloud-init version I had
# Documentation: http://cloudinit.readthedocs.io/en/0.7.9/index.html

# Set your hostname here, the manage_etc_hosts will update the hosts file entries as well
hostname: prismplex.hole
manage_etc_hosts: true

# You could modify this for your own user information
users:
  - name: username
    gecos: "Prismplex Hole"
    sudo: ALL=(ALL) NOPASSWD:ALL
    shell: /bin/bash
    groups: users,docker,video,input
    plain_text_passwd: hypriot
    lock_passwd: false
    ssh_pwauth: true
    chpasswd: { expire: false }

# # Set the locale of the system
# locale: "en_GB.UTF-8"

# # Set the timezone
# # Value of 'timezone' must exist in /usr/share/zoneinfo
timezone: "Europa/Berlin"

# # Update apt packages on first boot
package_update: true
package_upgrade: true
# package_reboot_if_required: true

# # Install any additional apt packages you need here
# packages:
#  - ntp
#  - dnscrypt-proxy

# Static IP address
write_files:
  - content: |
      persistent
      # Generate Stable Private IPv6 Addresses instead of hardware based ones
      slaac private
      # static IP configuration:
      interface eth0
      static ip_address=#ip-address/24
      static ip6_address=#ip-address/64
      static...
]]>
Cloud Gaming auf dem heimischen Linux Server https://prismplex.tech/de/blog/cloud-gaming-selbstgebaut 2019-06-16T14:28:00+00:00 2019-06-16T14:28:00+00:00

Hintergrund

Immer mehr Anbieter stellen Cloud Gaming Server bereit, auf denen Kunden, die zuhause keine gute Grafikkarte (am Prozessor liegt es ja meistens nicht) im PC bzw. Laptop verbaut haben, ihre Spiele spielen und auf das heimische Gerät streamen können. Voraussetzung dafür ist natürlich eine entsprechend schnelle Internetverbindung. In die Details der Technik, die dahintersteckt möchte ich jetzt nicht eingehen, hier eine wirklich kurze Zusammenfassung: Der Client verfügt über eine Software, die alle Tastaturbefehle und Mauseingaben an einen Server weiterleitet auf dem das jeweilige Spiel läuft und wieder an den Client zurückgestreamt wird.

Ich habe mich gefragt, ob man sowas auch auf dem heimischen Server zum laufen bekommen könnte. Der Gedanke war recht simpel, die Umsetzung leider weniger. Zuallererst musste ein neues Gehäuse her, denn im alten Mini-ITX Gehäuse war neben den vielen Festplatten wenig Platz für eine ensprechend potente Grafikkarte. Auf meinem heimischen Server läuft ein Linux auf Arch Linux Basis (Manjaro), das natürlich nicht wirklich zum Gaming geeignet ist. Leider verstehe ich bis heute nicht, warum man die ganzen Verkaufsschlager nicht auch für Linux entwickeln kann, aber zum Glück gibt es im Open-Source Sektor potente Virtualiserungssoftware, nämlich KVM bzw. Qemu.

Voraussetzungen

Erstmal ist sicherzustellen, dass die Hardware passt:

Grafikkarte

  • Eine NVIDIA Grafikkarte (NVIDIA Shield in Kombination mit dem Open Source Client Moonlight ist die Software, die zumindest ich zum Game-Streamen verwende und die meiner Meinung nach neben Parsec die beste ist)

Prozessor und Mainboard

  • Virtualisierung (VT-d bei Intel bzw. AMD-V bei AMD)
  • IOMMU Unterstützung (aktuelle Mainboards und Prozessoren siehe hier: Wikipedia, eine weitere Liste siehe hier: passthroughpo.st. Grob gesagt sind aktuelle Mainboards mit dem Chipsatz Z370 keine schlechte Wahl. Soweit ich das verstanden habe, sollten diese (zumindest von der Firma Asrock) alle IOMMU unterstützen.)
  • Grafikkarte mit UEFI-Unterstützung (bei den aktuellen Modellen der Hersteller eher weniger das Problem)

RAM

  • Zu empfehlen sind 16GB oder mehr

Eine einfache Überprüfung, ob die Hardware so passt, liefert (zumindest unter Arch Linux (Derivaten) folgender Befehl: dmesg|grep -e DMAR -e IOMMU, der in diese Antwort hervorbringen solle: DMAR: IOMMU enabled

Umsetzung

  1. Als Erstes ein komplettes Systemupdate mit sudo pacman -Syu oder analog pikaur (sehr zu empfehlen, falls jemand Pakete aus dem AUR installiert hat)
  2. sudo pacman -S nano, falls nano noch nicht installiert ist. Anschließend sudo nano /etc/default/grub. In der Zeile GRUB_CMDLINE_LINUX_DEFAULT folgendes hinzufügen intel_iommu=on (oder analog für AMD-Prozessoren amd_iommu=on) und daneben in der gleichen Zeile pcie_acs_override=downstream.
    Im nächsten Schritt ein Befehl zum updaten vom GRUB-Bootmenü: sudo update-grub.
  3. Nächster Befehl: lspci -nn. Ergebnis des Ganzen wird eine Liste an allen aktuell angeschlossenen PCI-Geräten sein mit entsprechender Hardware ID. In der Liste muss nun die Grafikkarte gefunden werden; fällt dies schwer, kann man zur Vereinfachung der List auch diesen Befehl wählen, der dann hoffentlich nur die Grafikkarte ausgibt: lspci -nn|grep -iP "NVIDIA|Radeon".
  4. Ist die Adresse der GPU herausgefunden, notiert/kopiert man nun die Hardware ID, diese brauchen wir später.
  5. Der Knackpunkt:

    #!/bin/bash
    shopt -s nullglob
    for d in /sys/kernel/iommu_groups/*/devices/*; do 
        n=${d#*/iommu_groups/*}; n=${n%%/*}
        printf 'IOMMU...
]]>
Neue Webseite https://prismplex.tech/de/blog/neue-webseite 2017-08-23T13:07:00+00:00 2017-08-23T13:07:00+00:00

Neue Webseite prismplex.tech

Nach langer Arbeit habe ich meine Hauptseite aktualisiert. Im Hintergrund arbeiten GRAV, CSS-Bibliotheken (Pure CSS) und diverse Skripte (AOS.js, lightslider.js).

]]>