Ein Artikel über Meta, den ich im Internet gelesen habe, und die Aufgabe eines Trainees bei uns in der Firma hat mich dazu gebracht mir das Thema AI Agent’s anzuschauen. Vorweg möchte ich alle die das lesen dazu motivieren, sich aktiv mit dem Thema AI auseinanderzusetzen. Ich befürchte das alle, die jetzt nicht auf den Zug aufspringen, über kurz oder lang unter die Räder ebenjenes kommen. Die Tragweite meiner Aussage ist mir durchaus bewusst. Die aktuelle Entwicklung ist menschlich keine gute wie ich finde, aber die großen Player haben die Büchse der Pandora aufgemacht, und diese werden wir alle nicht mehr schließen können. Deshalb heißt es, mitschwimmen, den Kopf über Wasser halten, sonst säuft man ab. Das zeigt das Beispiel Meta. Hier ersetzen gerade KI Agent’s 8000 Mitarbeiter und Führungskräfte. Und das innerhalb von 4 Monaten Entwicklungszeit. Ob ich mit meinen Gedanken richtig liege wird die Zeit zeigen.

Solange schwimmen wir mal los … Die Funktionalität welche die großen Firmen gerade nutzen, kann man auch selbst als DIY Bastler hervorragend verwenden. Ich will das folgend an einem Beispiel zeigen und für Anregung sorgen. Ich weiß das ihr auf allerhand großartige Ideen und pfiffige Lösungen kommt, und freue mich schon darauf mich mit euch über eure Anwendungsfälle zu Unterhalten.

Für ein Projekt an dem ich gerade arbeite benötige ich Informationen die auf kleine Karten gedruckt sind. Diese sollen ausgelesen und als JSON zur Verfügung gestellt werden. Dazu habe ich einen Agent gebaut, was recht simpel war. Zunächst einmal die Ordnerstruktur und die Dateien anlegen.

In der Datei agent.py ist das Python Script für den Agent. In .env ist der API-Key gespeichert. Diesen kann man sich unter aistudio.google.com holen.

Sobald man einen API-Key hat, kann man prüfen welche Modelle einem zur Verfügung stehen

Python:
# Test-Script zum Auflisten der Modelle
for model in client.models.list():
    print(f"Name: {model.name}, Supported Methods: {model.supported_actions}")

Für Gemini 1.5 Flash beispielsweise sind die kostenlosen Limits folgendermaßen:
Rate Limit: Bis zu 15 Anfragen pro Minute (RPM).
Tageslimit: Bis zu 1.500 Anfragen pro Tag (RPD).
Token-Limit: 1 Million Token Kontextfenster.

Jetzt schreibt man einen Prompt für die Aufgabe die der Agent ausführen soll:

Prompt:
Du bist ein spezialisierter Assistent zur Datenextraktion aus Bilddateien. Deine Aufgabe ist es, Informationen von einer Rezeptkarte in ein präzises JSON-Format zu überführen.
Analyse der Bildbereiche:
Rezeptname: Befindet sich oben links in der weißen Box.
Rezeptgruppe: Befindet sich oben rechts in der weißen Box.
QR-Code: Befindet sich unten in der Mitte.
Zutaten: Liste auf der rechten Seite unter der Überschrift "Zutaten".
Optionale Zutaten: Falls vorhanden, unter der Überschrift "Optional".
Gewürze: Falls vorhanden, unter der entsprechenden Überschrift.
JSON-Strukturvorgaben:
Verwende exakt die folgende Struktur. Wenn eine Kategorie fehlt, setze null oder [].
Achte darauf, Menge und Einheit korrekt zu trennen. Falls keine Einheit angegeben ist, verwende null.
Wichtig: Gib als Antwort ausschließlich den reinen JSON-Code zurück. Keine Erklärungen, kein Markdown-Code-Block.
{
  "rezeptname": "String oder null",
  "rezeptgruppe": "String oder null",
  "qr_code": "String oder null",
  "zutaten": [],
  "optional": [],
  "gewuerze": []
}

Zuguterletzt fehlt noch das Python Script, wofür zusätzliche Pakete benötigt werden.

Bash:
pip install -U google-generativeai
pip install python-dotenv
pip install Pillow

Das Script schaut im Ordner img_new ob es dort Bilder gibt. Die Bilder werden geladen und an das Model übergeben. Das Ergebnis wird als JSON File gespeichert und das Bild entweder als erledigt in den vorgesehenen Ordner geschoben oder in den Error Ordner.

Das Sahnehäubchen bildet inotify welches in jedem Linux Kernel integriert ist. Um es zu nutzen verwenden wir inotify-tools

Bash:
sudo apt update
sudo apt install inotify-tools

Hiermit können wir den Agent automatisieren.

#!/bin/bash
MONITOR_DIR="/ai_agent/img_new"
inotifywait -m "$MONITOR_DIR" -e create |
    while read path action file; do
        echo "Neue Datei erkannt: $file"
        python /ai_agent/agent.py "$path$file"
    done

Sobald man eine neue Datei in den Ordner schiebt, registriert es das System und führt agent.py aus. Als Resultat erhalten wir unser JSON File.

JSON:
{
  "rezeptname": "POMMES MIT QUARK-DIP",
  "rezeptgruppe": "SMARTE SPAR-REZEPTE",
  "qr_code": "https://scanned.page/heNp4I",
  "zutaten": [
    {
      "menge": 1,
      "einheit": "kg",
      "name": "festkochende Kartoffeln"
    },
    {
      "menge": 600,
      "einheit": "g",
      "name": "Quark"
    },
    {
      "menge": null,
      "einheit": null,
      "name": "Zitronensaft nach Geschmack"
    }
  ],
  "optional": [
    {
      "menge": 2.5,
      "einheit": "EL",
      "name": "neutrales Öl"
    },
    {
      "menge": 2,
      "einheit": "EL",
      "name": "Tomatenmark"
    }
  ],
  "gewuerze": [
    "Salz",
    "Pfeffer",
    "Paprika edelsüß",
    "Kräuter der Provence",
    "Knoblauchpulver"
  ]
}

Ergänzung 06.05.2026: Nachdem Gemini 1.5 nicht mehr zur Verfügung steht, kann man 2.5 Flash Lite mit den gleichen Limits als „Workhorse“ nutzen.

Vor ein paar Tagen habe ich mir für meinen Energieüberschuss auf Empfehlung von bis dahin zwei Kollegen eine Zendure 1600 AC+ gekauft. Eigentlich wollte ich mir meinen Speicher selbst bauen, aber man muss ja nicht für alles das Rad neu erfinden. Nun ist es leider so, das man die Kiste nur mit dem in der Firmware hinterlegten MQTT Broker verbinden kann. Meine Meinung zu Home-Automation ist strikt. Das Wort steckt schon im Begriff, nämlich „Home“. In diesem Zusammenhang kann ich mit dem ganzen IoT und Cloud Wahn überhaupt nichts anfangen. Es ist ja schließlich auch noch niemand auf die Idee gekommen, das eigene Stromkabel zu Hubel-Heiner-Butzenbach den ich mal Bernd nenne und der zwei Straßen weiter wohnt zu legen, dort in einen Schaltkasten, und von dort wieder zurück. Um den eigenen Treppenhausautomaten dort unterzubringen, damit Bernd immer schauen kann wann ich in den Keller gehe und das zu protokollieren. Der Clou an Bernd und anderen Anbietern wie Shelly, Bosch, Zendure uvm. ist, das man sich seine live Daten anschauen kann (Ahhh das Licht ist an!) die Historischen Daten aber in Bernds Tresor landen, und mir diese nicht frei zur Verfügung stehen. Wie wenn das Bernds und nicht meine Kellergänge gewesen wären. Und wenn der Bernd glaubt, nicht genug dran zu verdienen, oder keine Lust mehr hat, schaltet er einfach meinen Treppenhausautomaten ab. Bernd argumentiert dann: Trotz aller Bemühungen und des innovativen Konzepts wurde nicht die für einen wirtschaftlichen Weiterbetrieb erforderliche Marktakzeptanz erreicht!

Wo war ich stehen geblieben? Ah ja, wer sagt denn, das ich meinem Server in meinem lokalen Netzwerk nicht den alias mqtt-eu.zen-iot.de geben kann und somit die Zendure 1600 AC+ mit meinem MQTT spricht?! Das eine nennt man Spoofing und das andere Hijacking was garnichtmal so trivial ist.

Da ich das nicht über meinen Linux Server lösen, dort Sicherheitslöcher aufreißen und etliche vorhandene, funktionierende Sachen verbiegen wollte, habe ich mich für einen anderen Weg entschieden. In meiner Bastelbox liegen seit ein paar Tagen zwei brandneue ESP32 S3 DevKit1 R16N8. Mit 16MB Flash und 8MB PSRAM haben die um einiges mehr Ressourcen als meine bisherigen. Sollte also für eine TCP-Bridge reichen.

Also erst mal schauen was alles von Zendure erwartet wird. HTTP Token (TCP), MQTT (TCP), NTP (UDP) oha. Ohne Uhrzeit lässt sich die 1600 AC+ nicht regeln.

Erst mal mit dem Programmieren anfangen. Zunächst einmal einen Accesspoint mit WPA aufspannen. Zum Testen auf 192.168.4.1 (default) und über das Webinterface auf Port 8080 konfigurierbar machen. Dann nach SSIDs scannen und das Zielnetzwerk einstellbar machen. Zudem die Target IP also mein persönlicher Server einstellbar machen. Zum Testen wird die 192.168.1.10 verwendet. Zur Sicherheit habe ich eine Whitelist eingebaut. Nur erlaubte Domains dürfen auf meinen Server. Um das zu prüfen musste noch ein Log ins Interface. Dann noch DNS und TCP einbauen.

Was passiert nun? Der Client meldet sich am ESP32 Accesspoint an, bekommt den Gateway und den DNS 192.168.4.1 sowie eine freie IP in diesem Netzwerksegment. Wenn der Client nun beim DNS nach der IP von Beispielsweise google.com fragt, bekommt er die 192.168.4.1 zurück insofern die Domain in der Whitelist ist. Intern werden die Pakete über die TCP-Bridge welche die WIFI Klasse mitbringt an die Target-IP weitergeleitet, und von da die Antwort zurück.

Funktioniert astrein.

Bei NTP schaut die Sache nun anders aus. Das User Datagram Protocol (UDP) hat zwar einen Header, aber dieser beinhaltet keine Quell und Zieladressen. Die werden eine Schicht darüber im IP-Header geführt. Das ist in meinem Fall ein Problem. Der Client schickt die Anfrage zur .4.1 wo es ausgepackt wird. Hier sieht mein Proxy das es eine NTP Anfrage auf Port 123 ist. Dieses kann ich nehmen, und auf der anderen Seite wieder als UDP an meinen Server, den Router oder einen anderen NTP-Server schicken welcher mit der Uhrzeit antwortet. Da aber der ESP32 vergessen hat von wem die Anfrage gekommen ist, endet der Rückweg hier. Es muss ein simuliertes abgespecktes Network Address Translation (NAT) her. Also habe ich eine Funktion für NAT-light eingebaut. Das hat soweit geklappt, benötigt aber viele Ressourcen und bremst den Proxy aus. Zudem ist das System unzuverlässig sobald zwei Clients UDP anfragen stellen, da der eine den anderen im schlechten Fall überschreibet. Also habe ich rumgekämpft, die NAT-Funktion weiter aufgeblasen um das System noch langsamer zu machen. Hat mir alles nicht gefallen. Beim drüber schlafen habe ich mir die Sache nochmal durch den Kopf gehen lassen. Wenn doch der Client eh nur die .4.1 sieht, dann kann er doch von da auch die Urzeit bekommen. Und so läufts. Der ESP32 holt sich beim Boot und in regelmäßigen Abständen die Uhrzeit bei de.pool.ntp.org und stellt sie selbst als NTP zur Verfügung.

• Bernd, wenn du dich persönlich angegriffen fühlst, möchte ich mich dafür entschuldigen. Der Name ist Rainer Zufall! Äh nein Rainer, nicht ganz. Welches international agierende Unternehmen mit dem Hang zur Verlagerung beginnt nochmal mit dem gleichen Buchstaben?

• Warum nicht direkt NAT verwenden. Weil die Klasse gekapselt ist, und Eingriffe wie ich sie benötige nicht hergibt ohne diese umzuschreiben.

• NTP beinhaltet nicht nur die Uhrzeit. Uhrzeit war aber einfacher zu schreiben.

• Es ist zu erwähnen das google.com für meine ersten Tests die schlechtmöglichste Wahl war. Aber man lernt nie aus. Moderne Browser sind sogenannte HSTS Browser. Beim Aufruf einer Website kann diese dem Browser mitteilen, das zukünftig oder für eine gewisse Zeit der Verbindungsaufruf auf eine andere Adresse umgeändert wird. Es ist gar nicht so einfach dem Browser zu sagen das er bei google.com nicht https://www.google.com/?hl=de aufrufen soll.

Vorwort

Eigentlich ist dies ein Beitrag, den ich nie schreiben wollte.

Ich hatte eine einfache Grundregel: Auf diesem Blog erkläre ich keine Systeme oder Werkzeuge, die — unabhängig von ihrer technischen Legitimität — auch gezielt von Kriminellen eingesetzt werden, um Straftaten zu verschleiern. Nicht, weil ich diese Werkzeuge ablehne, sondern weil mir bewusst ist, dass Wissen Verantwortung bedeutet.

Und dennoch schreibe ich heute über die Einrichtung von Mullvad VPN.

Der Grund dafür ist kein technischer, sondern ein politischer.

Was für mich das Fass zum überlaufen gebracht hat, war vor ein paar Tagen die Aussage von Bundeskanzler Friedrich Merz auf einer Konferenz in Trier, in der er das Internet ausdrücklich als politischen Debattenraum bezeichnete und daraus die Notwendigkeit einer Klarnamenspflicht ableitete. Spätestens an diesem Punkt wurde mir klar, dass sich ein grundlegendes Missverständnis festgesetzt hat: Das Internet wird von Teilen der Politik offenbar nicht als Infrastruktur verstanden, sondern als eine Art öffentlicher Marktplatz.

Doch das World Wide Web ist kein Marktplatz.

Es ist der größte, offenste und zugleich gefährlichste Kommunikationsraum, den es gibt. Dort bewegen sich Staaten, Unternehmen, Nachrichtendienste, Betrüger, Datensammler und organisierte Kriminalität zugleich. Wer sich verbindet, exponiert sich technisch. Diese Realität verschwindet nicht dadurch, dass man sie politisch anders bezeichnet.

Deshalb bin ich der Meinung nicht die Nutzung von Schutzmaßnahmen ist erklärungsbedürftig, sondern ihre Nichtnutzung.

• Die Entwicklung der letzten Jahre

(EU) 2016/679 – Ein Teil dieser Entwicklung begann mit der Datenschutz-Grundverordnung. Die DSGVO hatte ein legitimes Ziel: Bürgern bewusst zu machen, dass ihre personenbezogenen Daten nicht herrenlos sind und dass sie ein einklagbares Recht darauf haben, dass Daten gelöscht werden können. Dieser Gedanke ist richtig. Gleichzeitig waren die wirtschaftlichen Folgen erheblich. Zurückhaltende Schätzungen gehen davon aus, dass allein die Umstellung die deutsche Wirtschaft 50 Milliarden Euro gekostet hat, ohne die laufenden Kosten zu betrachten. Kosten, die letztlich über die Preise beim Bürger landen. Man muss festhalten: Die DSGVO hat nicht das grundlegende Problem gelöst, nämlich den technischen Selbstschutz des Einzelnen im Netz.

§ 188 StGB – Parallel dazu wurde § 188 erweitert, der besondere Ehrschutz für Personen des politischen Lebens. Kritiker sehen darin eine Ungleichbehandlung im strafrechtlichen Schutz persönlicher Ehre. In der Praxis hat sich zudem ein neues Phänomen entwickelt: automatisierte Auswertung öffentlicher Äußerungen im Internet und daraus resultierende juristische Verfahren. Unabhängig von der Bewertung zeigt das vor allem eines — Äußerungen im Internet sind längst kein flüchtiges Gespräch mehr, sondern dauerhaft verwertbare Information.

§ 113 TKG – Schon heute müssen alle Telekommunikationsanbieter Verbindungs- und Metadaten für 14 Tage speichern. Über Jahre wurde politisch über die anlasslose Speicherung gestritten – offiziell aus Gründen der Strafverfolgung und Gefahrenabwehr, faktisch aber ein Generalverdacht gegenüber allen Nutzern. Geplant ist nun eine Ausweitung auf drei Monate, was nicht nur zusätzliche Kosten für die Verbraucher bedeutet, sondern den praktischen Nutzen infrage stellt: Überlastete Gerichte können die Daten kaum zeitnah auswerten. Gleichzeitig steigt das Risiko, dass sich auch hier eine Klageindustrie entwickelt, die automatisiert auf kleinste Verstöße reagiert, da die geplanten Änderungen neue Angriffspunkte schaffen.

Aus den beschriebenen Entwicklungen ergibt sich ein grundlegender Widerspruch: Während Bürger zunehmend verpflichtet werden, identifizierbarer zu werden, wächst gleichzeitig die Bedrohungslage im Netz gerade in Zeiten von KI enorm. Daten und Identitätsdiebstahl, Social-Engineering-Angriffe und automatisierte Betrugssysteme sind Alltag.

• Verhältnismäßigkeit und Realität

Wenn ich das Internet mit einem physischen Ort vergleichen müsste, dann wäre es kein offener Marktplatz — sondern eher eine dunkle, unübersichtliche Gasse sichtbarer und unsichtbarer Akteure. In einer solchen Umgebung dürfte niemand ernsthaft fordern, das ein Kind ein Schild tragen muss auf dem steht: „Ich bin Susi, 12 Jahre alt“

In der analogen Welt existierten schon vor dem Internet Schutzprinzipien:

• das Briefgeheimnis (Art.10 GG),
• die Vertraulichkeit der Telekommunikation (TKG §88-91),
• das Recht sich frei zu versammeln (Art.8 GG),
• das Recht auf Anonymität abgeleitet aus (Art.2 Abs.1 Grundgesetz)

Niemand verlangt, dass auf jedem Brief außen der vollständige Lebenslauf steht. Niemand würde akzeptieren, dass jede Postverbindung pauschal protokolliert wird. Und doch bewegen wir uns im Internet zunehmend in genau diese Richtung.

Die eigentliche Fehleinschätzung ist daher nicht technischer, sondern struktureller Natur: Das Internet ist keine Debattenplattform — es ist Infrastruktur. Und Infrastruktur benötigt Sicherheit.

• Warum dieser Artikel existiert

Ich breche mit meiner eigenen Regel, weil sich die Rolle verschoben hat.

Früher bedeutete die Erklärung von Anonymisierungs- oder Schutztechniken jemandem beim Verbergen zu helfen. Heute bedeutet das Weglassen dieser Informationen zunehmend, Menschen ungeschützt zu lassen. Zwischen Verschleierung und Selbstschutz besteht ein entscheidender Unterschied.

Meine persönliche Schlussfolgerung ist daher einfach:

Sobald ich eine Verbindung mit dem World Wide Web herstelle, öffne ich eine Tür zu einem potenziell gefährlichen Raum. Das muss jedem bewusst sein — auch politischen Entscheidungsträgern. In diesem Raum geht es um Sicherheit und vor allem um Eigenschutz. Und wenn staatliche Maßnahmen diesen Schutz nicht gewährleisten oder ihn sogar verringern, dann bleibt nur eine Konsequenz:

Ich muss mich und meine Familie selbst schützen.

Vorbereitung

Im folgenden erkläre ich unabhängig meines eigenen VPN-Gateways die Einrichtung von Mullvad VPN auf einem Raspberry PI mit nur einem Netzwerkadapter.

Voraussetzungen:
• Router 192.168.100.1
• Raspberry PI 192.168.250.250, 192.168.100.250
• Raspberry PI OS (Debian) vorinstalliert
• A klitzeklois bissle Ahnong vo Linux du Dackel

Zunächst muss die Möglichkeit geschaffen werden, dem Client den Raspberry PI als Gateway vorzugeben. Eine Möglichkeit ist es, IP Adresse, Gateway sowie DNS am Client fest einzustellen. Ich möchte eine flexiblere Lösung aufzeigen. Der D-Link DAP2695 beispielsweise bietet dafür eine Ausgezeichnete Möglichkeit. Zunächst legt man eine Zusätzliche SSID an, in meinem Fall sycotec-secvpn. Danach ein virtuelles logisches Teilnetzwerk, hier VLAN10. Diesem weist man über SSID-to-VLAN Mapping die neue SSID zu. Danach muss noch der DHCP konfiguriert werden.

Bei dieser Konfiguration ist es nun so, das der WLAN-Client bei der default SSID die Netzwerksettings vom DHCP des Routers bekommt. Verbindet man sich über die SSID sycotec-secvpn erhält man die Netzwerksettings vom DHCP des Accesspoints, landet im Segment 192.168.250.0 und bekommt den Raspberry Pi als Gateway.

Einrichtung des VPN Gateways

Idealerweise macht man zunächst ein Update der Paketliste und des Betriebssystems

sudo apt update
sudo apt upgrade -y

um danach die neusten Pakete von wireguard, nftables, dnsmasq und curl zu installieren, falls noch nicht vorhanden.

sudo apt install wireguard dnsmasq iptables-persistent curl -y

Folgend muss der Pi in die beiden Netze IN (192.168.250.250) und OUT (192.168.100.250). Dazu wird /etc/network/interfaces wie folgt geändert:

auto eth0
iface eth0 inet static
    address 192.168.100.250
    netmask 255.255.255.0
    gateway 192.168.100.1      # IP des Routers
    dns-nameservers 192.168.100.1

# Virtuelles Interface für secvpn Subnetz
auto eth0:1
iface eth0:1 inet static
    address 192.168.250.250
    netmask 255.255.255.0

Der DNS Server spielt an dieser Stelle für den VPN keine Rolle. Damit Linux Routen kann, muss IP Forwarding unter /etc/sysctl.conf aktiviert werden.

net.ipv4.ip_forward=1

Danach meldet man sich mit seinen Zugangsdaten unter https://mullvad.net/ an, und wählt dort „WireGuard configuration“. Ich habe mich für einen Ausgang in Island entschieden da diese eine Hervorragende Infrastruktur haben, und dort die Privatsphäre sehr hoch aufgehängt ist. Dafür wählt man

• Server location: Iceland
• Device: Linux
• Tunnel: WireGuard

aus und startet den Download. Den Inhalt der mullvad.conf kopiert man nun in die Datei /etc/wireguard/wg0.conf welche dann folgende Struktur hat:

[Interface]
PrivateKey = XXXXX
Address = 10.x.x.x/32
DNS = 10.64.0.1

[Peer]
PublicKey = XXXXX
AllowedIPs = 0.0.0.0/0
Endpoint = xx-is.mullvad.net:51820
PersistentKeepalive = 25

Wichtig ist hier das AllowedIPs auf 0.0.0.0/0 steht, damit sämtliche Packete durch den Tunnel gezwungen werden. Nun können wir WireGuard probehalber schonmal starten und schauen ob der Tunnel funktioniert.

sudo wg-quick up wg0
curl https://am.i.mullvad.net/ip

Hier sollte nun Country: Iceland stehen. Wenn der VPN nicht läuft bekommt man lediglich die aktuelle Internet IP angezeigt. Wenn’s nicht geht, gehe zurück zum Start, gehe nicht über Los und ziehe nicht 200 Mark ein. Alles Punkt für Punkt überprüfen und schauen ob alle Dienste laufen. Ansonsten … weiter geht’s. Da wir nicht wollen, das uns der DNS verrät zwingen wir diesen auch durch den Tunnel und nehmen den DNS von Mullvad. Dazu editieren wir die Datei /etc/dnsmasq.conf

interface=eth0
listen-address=192.168.250.250
server=10.64.0.1
no-resolv

Nun kommt die Konfiguration von nftables NAT und Forward

sudo iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE
sudo iptables -A FORWARD -i eth0 -s 192.168.250.0/24 -o wg0 -j ACCEPT
sudo iptables -A FORWARD -i wg0 -d 192.168.250.0/24 -m state --state RELATED,ESTABLISHED -j ACCEPT

Das sollte selbsterklärend sein. Nun bauen wir noch einen Killswitch ein, damit nichts durchrutscht.

sudo iptables -A OUTPUT ! -o wg0 -m addrtype ! --dst-type LOCAL -j REJECT

Alle Pakete die nicht an wg0 also den VPN Tunnel gehen und die nicht im lokalen Netz adressiert sind, werden zurückgewiesen.

Nun fehlt nur noch der Härtetest: https://dnsleaktest.com/

Epilog

Wichtig bei der Nutzung eines VPN Gateways als „Router“ ist es sich vorher genau zu überlegen welche Endgeräte man durch den Tunnel schicken will und welche nicht. Darauf aufbauend muss man sich das Konzept überlegen.
Hier gibt es für fast alles eine Lösung. Aber Achtung, Streaming Anbieter sind bei „Geo Blocking“ sehr empfindlich und auch die VPN Tunnel von Arbeitgebern mögen es zuweilen überhaupt nicht ihrerseits getunnelt zu werden. Ganz paranoide haben noch die Möglichkeit ihre DNS Abfragen mit dnscrypt-proxy über DoH (DNS over HTTPS) laufen zu lassen. Über diesen Vorschlag gab es bei ein paar Bierchen einen angeregten Austausch. Danke dafür.

Noch ein paar wichtige Tips:
Wenn an den config-files von laufenden Diensten etwas geändert wird, müssen die Dienste zumeist neu gestartet werden.
Die Regeln von iptables-persistent und netfilter-persistent müssen gespeichert werden um sie nach einem reboot noch zur Verfügung zu haben.

Nachdem bei mir viel Interesse am Thema AI bekundet wurde, habe ich die Fragen gesammelt. Dabei wurde mir klar, das die meisten noch keine Berührungspunkte mit LLM’s (Chatbots) also der Basis der häufigsten KI Anwendungen hatten.

Aus diesem Grund habe ich meinen Post Howto AI als Grundlage genommen und ein Tutorial für die Nutzung von ChatGPT erstellt. Da sich bis zur Fertigstellung des Tutorials nicht mehr viel zu diesem Thema in meinem Posteingang getan hat, lag das Teil nun eine ganze Weile ganz weit unten in meiner Schublade.

Kürzlich hatte ich dann eine interessante Unterhaltung mit einem Kollegen zu diesem Thema. Während dieser Unterhaltung kam raus, das die „Hemmschwelle“ sich bei OpenAI anzumelden das größte Hindernis für „Neulinge“ darstellt.

Also habe ich das Tutorial nochmal überarbeitet und Gemini als LLM verwendet, da man diesen direkt über die Google Startseite aufrufen kann.

Hier findet ihr das Tutorial HowtoAI.pdf und hier noch Arbeitsmaterial für die Beispiele

Viel Spaß beim rumprobieren!

Vor ein paar Tagen hatte ich eine Unterhaltung mit einem Freund bei der es um Add-Blocking ging. Ich habe ihm von DNS4EU aus meinem letzten Beitrag erzählt, und das diese je nach gewähltem DNS-Server schon Add-Blocking machen.

Er hat mir im Gegenzug von einem (bereits über ein paar Jahre gereiften) Tool namens PI-Hole erzählt welches er nutzt. Hört sich interessant an dachte ich mir, und muss ich dann mal testen.

Also habe ich das Tool installiert. Heidewitzka… Der Core lief auf Anhieb. Auf das Webinterface konnte ich nicht zugreifen. Als Tipp Vorweg, wer sich zum Testen Ärger ersparen will macht RasperryOS aka Debian 12 auf den PI und installiert direkt pihole.

Es hat mich geärgert und wenn mich was ärgert will ich das gelöst haben. Der übliche Chatbot konnte mir nicht helfen, weil er fest davon überzeugt war, das lighttpd als Webserver verwendet wird. Ok, dachte ich mir. Ich hab Apache2 also wofür benötige ich noch einen Webserver. Wie sich herausstellte war lighttpd auch nicht installiert. So konnten sich auch keine Ports gegenseitig blockieren. Und ich konnte 80 und 443 auch nicht auf 8080 und 4443 verschieben wie empfohlen. Also das Webinterface neu installiert und geschaut was da passiert. Er holt sich die Files aus nem Git und kopiert sie nach var/www/html/admin. Dort lagen dann die Files als *.lp „Lua Pages“ ab. Gut dachte ich, installiere ich halt die Apache Erweiterung für Lua Pages. Pustekuchen „Dieses Modul steht für ihr System nicht zur Verfügung oder ist Abgelaufen. Ahhhhhh….

Nach längerem Suchen habe ich dann herausgefunden das pihole ab v6.2 einen integrierten Webserver Namens CivetWeb verwendet. Also von vorn, Apache2 stoppen, /admin aus dem DocumetRoot löschen, pihole Installationsscript erneut aufrufen. pihole-FTL stoppen. Nun kann man in der pihole.toml den Port ändern. Die richtige Syntax ist

port = "8080o,4443os,[::]:8080o,[::]:4443os"

Apache2 wieder starten, pihole-FTL wieder starten, und einloggen!

Es ist verrückt. 22% geblockte Inhalte. Aber nicht nur das. Selbst beim Streaming *kann* größtenteils die Werbung entfernt werden. Der ultimative Test ist hier die Website heise.de Hier kann man optisch prima sehen, das es zwischen DNS4EU – Ad Blocking und Pi-Hole noch merkliche Unterschiede gibt.

Aktueller Stand 17.12.2025:

Inzwischen hat wieder jedes Subnet seine eigene „DNS Konfiguration“.

Bekannte Geräte Zone
Bekannte Geräte Kinder Zone
Bekannte Geräte IoT Geräte Zone
Unbekannte Gast Geräte

Realisieren kann man das über die Gruppenfunktion in der GUI und der Clientzuordnung. Alle DNS anfragen von Clients die Internetfreigabe haben, werden zum PI-Hole gezwungen und von da direkt über DoH zu DNS4EU TYP2. Fehlt nur noch das Script das die MAC Adressen aus der dhcpd.conf ausliest und in die gravity.db von Pi-Hole einträgt.

Domains oder Subdomains lassen sich im Menüpunkt Domains white oder blacklisten. Ich finde es allerdings einfacher das über die verwendeten Blocklisten zu machen.

Ergänzend:

Da es doch einige Fragen zu diesem Post gab: Um mich hier nicht angreifbar zu machen habe ich die Formulierung in meinem Post an einer Stelle leicht geändert. Des weiteren würde ich natürlich nie Werbung von Streaming-Diensten blockieren.

Ein klitze kleines bisschen Sarkasmus ist zu spüren ja, aber nichts desto trotz gibt es bei mir keine Anleitung um Werbung beim Streaming zu blockieren.

Gerne verweise ich auf die Website https://firebog.net wenn es um Blocklists geht. Hier ist mit Sicherheit für jeden was dabei. Und der erste Teil des Domain Namens ist reiner Zufall 😉

Bei einer Abteilungsfeier zu der ich eingeladen war hat mir ein Arbeitskollege von einem neuen großen DNS-Resolver für Europa „aus Europa“ erzählt. Das hat sich alles sehr Interessant angehört, und mir sind da gleich allerhand Schandtaten dazu eingefallen.
Zuhause angekommen habe ich mich dann direkt mit DNS4EU beschäftigt. Details gibt es auf deren Website.

Für mich waren folgende Eckpunkte wichtig:

• Unabhängig von Google, Cloudflare usw.
• Verschiedene Filtertypen
  • TYP 1: Unfiltered Resolution
  • TYP 2: Protective Resolution
  • TYP 3: Protective Resolution with Child Protection
  • TYP 4: Protective Resolution with Ad blocking
  • TYP 5: Protective Resolution with Child Protection & Ad blocking

Das hat sich prima mit drei laufenden Aktivitäten ergänzt. Zum einen war ich dabei meine Infrastruktur für den kommenden Glasfaserausbau zu optimieren/erweitern. Zum anderen wollte ich meinen Raspberry-Pi mit Home Assistant rauswerfen und durch eine DIY Plattform ersetzen, da dieser mir schon 4 SD-Karten ruiniert hat. In diese Plattform wollte ich die Informationen meiner Homematic Zentrale mit einfließen lassen wo wir beim Punkt drei sind. Die CCU2 durch Raspberrymatic ersetzen.
Also habe ich zuerst zwei Gehäuse für die PI’s gedruckt.

Diese eingebaut und in Betrieb genommen.

Der erste ist für Raspberrymatic zuständig.

Hier werden alle Homematic Komponenten gesteuert, und über eine API zur Verfügung gestellt. Das neu Anlernen, Verknüpfen und Einstellen der 2 Millionen Aktoren und Sensoren war nervig und zeitraubend aber ist kein Hexenwerk.

Als nächstes habe ich Debian auf den zweiten Pi installiert. Dazu kamen dann einige Pakete, welche ich zur Verfügung haben wollte. Standard sozusagen ist SSH und Samba. Dazu wollte ich einen Apache2 Webserver inklusive php Lib, mySQL und phpMyAdmin zum lokalen Testen von Code. Als MQTT Broker läuft nun Mosquitto um den bereits überlasteten Broker auf meinem ESP32 zu ersetzen, und Node Red um die fertige Schnittstelle zur Raspberrymatic API zu nutzen.

Das war bis dahin nicht der Rede Wert und auch keinen Beitrag wert da im Prinzip alles fertiges Zeug war oder nur Polygone schupsen im Node Red.
Nun wollte ich die neuen Infos zu DNS4EU für mich nutzen und meine Ideen umsetzen.
Also habe ich zunächst die config meiner alten iptables Firewall aus ISDN Zeiten rausgesucht die Basti damals mit mir erstellt hat. Danach habe ich mir IP-Bereiche (Subnets) überlegt:

Bekannte Geräte Zone
Dürfen ins LAN und ins Internet und erhalten den DNS4EU: TYP 4
Bekannte Geräte Kinder Zone
Dürfen ins LAN und ins Internet und erhalten den DNS4EU: TYP 5
Bekannte Geräte Proxy Zone
Bspl. Onion Routing gegen Geoblocking und zum Anonymisieren
Bekannte Geräte IoT Geräte Zone
Dürfen nur ins IoT Zonen LAN
Unbekannte Gast Geräte
Dürfen nur ins Internet und erhalten den DNS4EU: TYP 2

Zunächst habe ich also die Zonen und alle MAC Adressen meiner Geräte in die dhcpd.conf eingetragen. In erster Linie wollte ich dafür sorgen das erstens die IoT Geräte in einer eigenen Zone sind, in der ich bestimme wer nach draußen darf. Zum anderen wollte ich für die Zukunft vorsorgen und eingrenzen, wo später die Kinder rumsurfen können. Dann habe ich mir überlegt was ich so als Jüngling getrieben habe, und dem wollte ich dann auch einen Riegel vorschieben. So bekommen Beispielsweise nur IP-Adressen die vom DHCP Server vergeben wurden einen accept-Flag. Das nennt sich Dynamic IP Hook.
Dann ging es ans Eingemachte. Die Konfiguration von nftables welches iptables ablöst. Hier muss man zuallererst beachten, das die Ports 67 und 68 zum Linux Router frei sind und der Loopback (localhost) auf accept steht, sonst kommen die Clients beim connect nicht zum DHCP und somit bekommen sie keine IP und kein Lease. Es müssen die erlaubten (dynamic hook) DHCP-Clients eingebunden werden. Dann erst kommt der Forward-Chain (Packete von einer in eine andere Zone Leiten) und folgend die NAT-Tabelle (Network Address Translation) zum WAN. Hier ist an mancher Stelle einiges an Ausprobieren nötig bis alles funktioniert. Als Tüpfelchen auf dem i kommt noch ein Logging hinzu welches alle gedroppten Packete aufführt. Das geht nicht direkt. Die logs landen im Syslog (var/log/kern.log) und müssen mit rsyslog abgefangen und in die gewünschte Datei umgeleitet werden. Es ist erstaunlich wie viele ungewünschte Pakete an der Firewall verbrennen. Das war damals schon so, und ist heute nicht besser.

Anders als jetzt wäre ich mit meinem damaligen Wissen nicht an meiner heutigen Absicherung vorbei und mit eigenem DNS Server ins Internet gekommen, um nicht vom Jugendschutz ausgebremst zu werden. Wer mir Face2Face eine Möglichkeit aufzeigt, bekommt von mir ein Bier bezahlt 😉

Ein paar Anmerkungen noch:

• By Default ist das syslog bei dem von mir gewählten Raspbeery OS (Debian) ausgeschaltet um nicht auf der SD-Karte rumzuschreiben wenn es nicht nötig ist. Beim Einschalten sollte man dafür sorgen das die Logs über eine Harte Verknüpfung auf einem USB-Stick landen.
• Alle Files sind anonymisiert und nicht meine IP-Bereiche.
• Alle Messwerte laufen nun über den neuen MQTT Broker und werden in meine IONOS SQL Datenbank geschrieben. Nun kann ich an meinem Backend mit Dashboards arbeiten.
• der Datendurchsatz vom Pi und der Firewall liegt bei 260Mbit
• die Stromaufnahme beider Pi`s zusammen liegt in Schnitt bei 5,6W
• Von Fragen zu TOR, Mullvad oder redsocks ist Abstand zu nehmen!

Nachdem immer wieder mal Fragen zu Heartbleed auftauchen, hier eine kurze Info!
Das Geotrust SSL Zertifikat dieser Website war und ist nicht betroffen.
Auf folgender Seite könnt ihr eure Webserver testen: https://filippo.io/
Diese Seite ist vertrauenswürdig und wurde mir von Geotrust empfolen.
Unter http://mashable.com/ könnt ihr nachschauen, bei welchen Diensten ihr eure Passwörter ändern, und bei welchen ihr mit der Änderung noch warten solltet.