jpasewalck.org

Category: Uncategorized

  • Wireguarding my Homelab and Overcoming Androids Limitations

    It’s been over a year now since I started getting into homelabbing more seriously. One of the biggest questions I faced from day one was how I would access my homelab remotely. I had considered something like Tailscale, which basically does everything for you. And to be honest, for most people, they probably provide one of the best options at the time of writing this; the connections between your Tailscale nodes (e.g., home and laptop) are end-to-end encrypted (though the key distribution does go through their coordination servers), they use WireGuard, and well, a lot of people use them. However, if you are like me, you will probably be bugged by Tailscale being a big enterprise, parts of their server code being closed source, and those coordination servers playing a crucial role. You will probably not like being dependent on their infrastructure. You will want to instead build your own infrastructure. Infrastructure that you will also be dependent on. Infrastructure that you will also have to maintain now, of course. But at least now you are not dependent on that enterprise.

    So I got started on solving the remote access problem with a more custom solution. Simply speaking, one of the main issues with a homelab is that it is, well, at home, meaning that it is generally not reachable via the internet. One solution is to port forward and expose your home network to the internet that way. However, for me that was off the table due to security concerns. An often suggested alternative is to use a remote server (a VPS) as a relay or hub. That is what I settled on.

    I opted for WireGuard, which allows you to easily create a virtual network. WireGuard, in case you didn’t know, is a VPN protocol/implementation. Below you can see a simple illustration of how WireGuard can be used. Essentially the laptop (could be any device) and homelab each initiate a connection to the VPS that runs a WireGuard server. Two WireGuard tunnels are created. This then enables the laptop to send traffic to the homelab (via the VPS).

    This will work great for most people. All major operating systems support a WireGuard connection. Great! You can now access your homelab from anywhere, from a laptop or a phone.

    However, this brings along a caveat. The VPS can read all the unencrypted traffic in transit (of course TLS/SSL is uneffected). Essentially with WireGuard, the traffic is only encrypted within a WireGuard tunnel, but of course there is no direct tunnel between the homelab and the laptop (as the diagram shows). An obvious solution is to instead directly connect from the laptop to the homelab; however, this would again require port forwarding on your home network, as that requires your homelab to be accessible via the internet. (A WireGuard connection requires initialization from one end, and that requires the other end to be accessible.) A workaround would be to use the VPS as a simple relay server. Below you can see a simple illustration. Basically the Homelab initiates a connection to the VPS and creates a tunnel: the “Outer Tunnel.” There now is a virtual network that allows the VPS to reach the Homelab. Further using some firewall rules, the VPS forwards any WireGuard traffic coming in. A direct tunnel to the homelab is created: the “Data Tunnel.” (to distinguish between the outer and inner/data WireGuard traffic, we can simply have them operate on different ports)

    This would then allow the laptop to reach the homelab. Below are the commands to activate this forwarding using iptables. Basically all traffic coming in on port 51821 is forwarded to 10.200.200.2, which is the IP of the Homelab within the “outer” WireGuard network.

    sudo iptables -t nat -A PREROUTING -p udp --dport 51821 -j DNAT --to-destination 10.200.200.2:51821
sudo iptables -t nat -A POSTROUTING -s -d 10.200.200.2 -p udp --dport 51821 -j MASQUERADE

    However, that way literally all traffic on that port is blindly forwarded to the homelab. The VPS has no way of checking if the incoming WireGuard traffic is legitimate or not – it just forwards it all. Which also comes with risks; basically, it exposes your homelab similarly to how port forwarding does.

    Nevertheless, a solution is actually quite straightforward. With one WireGuard network initiated via a VPS the way described initially, so with both the Laptop and Homelab initiating a connection to the VPS, you can (on non-phone operating systems) simply create a WireGuard tunnel within this network. Meaning a connection from the laptop to the homelab. Essentially laying a single “inner” tunnel through the existing two “outer” tunnels.

    The beauty of this is that your homelab is inaccessible via the internet – there is no port open leading directly to the homelab. No blind forwarding. And at the same time your entire traffic is end-to-end encrypted with the VPS only ever seeing the encrypted inner WireGuard traffic.

    But I soon ran into a new problem. The concept of layering WireGuard tunnels doesn’t work with Android, at least not with non-rooted Android. (For iOS, I am unsure how this is.) Let’s get a bit more technical here. In WireGuard terms, every remote endpoint you connect to is a peer. You can configure several peers on one system, and it will hold a separate connection to each. Now Android generally only lets you run one active VPN at a time. WireGuard makes the most of this: a single one can be connected to multiple peers, meaning Android does actually also support multiple tunnels. But the way routing is handled in Android does not allow the layering of these tunnels. Damn checkmate, I thought.

    Nevertheless, I soon came across an at least temporary solution. I figured I could actually use the relay concept described earlier. However, instead of blindly forwarding all traffic, I would just forward specific traffic that comes from a whitelisted IP. That would then allow Android to connect to the homelab directly as long as its IP is whitelisted. In case it wasn’t totally clear, there still is an outer tunnel between the homelab and VPS that is initiated via the homelab. The forwarded traffic coming from the laptop, or in this case phone, is then forwarded via this tunnel to reach the homelab. I found out about the concept of port knocking. Essentially, port knocking allows a certain sequence of UDP or TCP requests to different ports to act as a means of authorization that then triggers a certain action. In my case the action is to forward traffic to my homelab for a specific time period. I set up knockd, a daemon enabling port knocking on a server, and actually used it for some time. But soon I was annoyed by always having to initiate the port knocking once the IP address on my Android phone changed. Automation of this would be possible, but I didn’t find any open-source automation apps for Android I was happy with. Also, port knocking is not the safest, especially when using a static sequence. That static sequence can easily be snooped by some basic network analysis, allowing an attacker to then simply replay it.

    I figure it was primarily the annoyance that led me to have a novel idea for solving this: What if I just use a WireGuard connection to replace port knocking as a means of authorization? That connection being established could trigger the traffic forwarding on the VPS. As mentioned, Android does support simultaneous connections to multiple peers, just not layering. So I could just initiate one connection to the VPS and have the VPS then allow forwarding a second connection to the homelab — both of which come from Android. So basically replacing port knocking with a WireGuard connection – so basically “WireGuard knocking”. Below you can see a simple illustration. The “Signal Tunnel” is the initial WireGuard connection Android initiates to the VPS. The “Data Tunnel” is the second WireGuard connection (forwarded via the VPS) — also from Android, but addressed to the homelab. With the VPS only allowing the forwarding once it sees the established “Signal Tunnel”.

    Via the “Data Tunnel” all communication between the homelab and android can happen, and that data is now end-to-end encrypted. This is actually quite secure as WireGuard is a pretty strong means of authorization in this context, especially compared to port knocking. I soon implemented my idea with some simple Go code, feel free to check it out!

    Now, this is not perfect. I realize that this is somewhat hacky. And also, it’s important to mention that you are often not the only person with a specific IP. In some cases, thousands of people share one IP address. But in the end the worst they can do is try to establish a WireGuard connection — and it’ll fail without the right key. WireGuard also drops these unauthenticated packets (no reply, no error), so people will not even know if they hit the correct port. And that, I consider a lower-risk issue; however, I am happy to someday find a better solution to also overcome it. But for now, this fares well enough.

  • Gedanken zur Unausweichlichkeit von KI

    Es war letzte Woche; ich redete mit einem Lehrenden an der Uni; irgendetwas zwischen Austausch und Smalltalk. Das Thema von der KI kommt auf, konkret ging es um LLMs bzw. generative KI. Ich frage ihn, eher beiläufig, ob er „die KI“ eher als positive oder negative Entwicklung sieht. Wohl wissend, dass dies eine offene Frage ist – aber seine Antwort interessiert mich. Wie er mir dann aber antwortet, überrascht mich etwas. Er hinterfragt meine Frage indirekt, er macht den Punkt, dass „die KI“ ja so oder so kommen würde, es also keinen Sinn ergeben würde, diese Entwicklung zu bewerten. Wir müssten halt einen Umgang finden, sagt er. Er schiebt zwar dann noch eine tatsächliche Antwort auf meine Frage hinterher: dass es ambivalent sei. Er hebt positiv hervor, dass „die KI“ ihm viel erleichtern würde; und gleichzeitig sagt er auch, dass er um seinen Job fürchte. Aber bei mir bleibt vor allem sein erster Kommentar im Kopf. Ich fühle mich ein bisschen bloßgestellt, als wäre meine Frage nicht gut gestellt bzw. als wäre es die falsche Frage, als würde sie eine Prämisse, jene der Unaufhaltsamkeit von sogenannter KI, verkennen. Ein paar Stunden nach dem Gespräch denke ich noch über seine Antwort nach. Ich merke, ich bin der Auffassung, dass meine Frage genau die richtige ist und ich die Ablehnung der Frage nicht richtig finden kann. Ich fange an, diesen Text zu schreiben.

    Jetzt muss ich an dieser Stelle fairerweise sagen, dass das ein kurzes Gespräch war und ich nicht wirklich weiß, was der Lehrende wirklich denkt. Dennoch denke ich, dass diese Situation eine größere und weitverbreitete Einstellung widerspiegelt, nämlich die Einstellung, dass die Weiterentwicklung und Weiterverbreitung der sogenannten KI unaufhaltsam sei. Ich nenne das im Weiteren den KI-Vormarsch-Standpunkt. Dieser umfasst sowohl die technische Verbesserung der sogenannten KI, sowie die Weiterentwicklung, und die Integration der sogenannten KI in immer mehr Lebensbereiche, also die Weiterverbreitung.

    Dass der Begriff KI eigentlich immer etwas am­bi­gu­os ist, gehört meiner Meinung nach dazu, was diesen Standpunkt ausmacht. Die Ambiguität ist neben einer Euphorisierung und einer Anthropomorphisierung Teil einer oft angebrachten und validen Kritik an dem Begriff „KI“. Ich denke, die Anthropomorphisierung und Euphorisierung sind in diesem Fall jedoch nicht so relevant. Also zur Ambiguität: Diese bedeutet, dass es eigentlich gar nicht so klar ist, was eigentlich eine oder die KI ist. Und das passt gut, denn der KI-Vormarsch-Standpunkt sagt nicht voraus, dass eine bestimmte Form der KI, also z. B. dass LLMs diese KI sind und dass exakt diese LLMs unaufhaltsam sind und uns allen die Jobs wegnehmen werden. Es wird keine bestimmte Zukunft vorhergesagt, es wird eine Richtung vorhergesagt.

    Ich denke, viele würden den KI-Vormarsch-Standpunkt als eine berechtigte und zutreffende Prognose bezeichnen und ihn damit verteidigen, dass die aktuellen Entwicklungen und bestehenden Machtverhältnisse dafür sprechen würden. Und es stimmt, die Ausgaben im Sinne von Geld und weiteren Ressourcen in diesem Bereich sind rekordhaft – komplett absurd eigentlich, wie hoch die wirklich sind. Und auch die technischen Fähigkeiten und der breite Einsatz von KI sind nicht von der Hand zu weisen. Ob es der volle Rewrite von Bun in Rust durch eine KI von Anthropic¹ ist oder dass OpenAI vor wenigen Wochen die Lösung der Navier-Stokes-Gleichungen für sich reklamiert hat². In beiden Fällen gibt es berechtigte Kritik und Einwände, aber es ist dennoch nicht von der Hand zu weisen, dass die Entwicklungen beeindruckend sind. Es ist immer leicht, die Dinge hervorzuheben, die noch nicht perfekt sind.

    Und trotz dieser überzeugenden Argumente habe ich da so einen Verdacht. Und zwar, dass diese Argumente oft, keineswegs immer, aber oft, eigentlich eher eine Rationalisierung von einem Glauben sind statt eine die tatsächlichen Argumente eines Wissens oder einer Vorhersage die unfehlbar sei. Stattdessen, so mein Verdacht, ist es eben ein Glaube. Und zwar der Glauben an ein Narrativ. An das Narrativ. Das Narrativ des KI-Vormarsch-Standpunkts. Wenn ich Nachrichten höre, höre ich kaum die Frage, ob die KI auszuhalten ist oder nicht. Sowohl im praktischen als auch normativen Sinne. Stattdessen höre ich Fragen, danach, was es bedeutet, dass die KI kommt, die Frage, wie schnell die KI kommt, oder die Frage des Umgangs damit. Es ist einfach als Prämisse gesetzt, dass die KI kommt. Ein Glauben der als Wissen verpackt wird, aber dann eigentlich nichts anders ist als ein Glauben. Keine Vorhersage. Denn eine Vorhersage könnte falsch liegen, aber das wird nicht mal als Option angenommen.

    Und besonders im Kontext von menschlichem Handeln, ein Kontext, in dem der KI-Vormarsch-Standpunkt explizit verankert ist. Beim Klimawandel so in etwa, sagen die Klimaforscher nicht voraus, dass wir die 3-Grad-Grenze überschreiten werden, sondern sie sagen es voraus im Kontext von verschiedenen Handlungsmöglichkeiten, sie benennen explizit unsere Handlungsspielräume und die Folgen dieser, einschließlich der Unsicherheitsfaktoren dieser Prognosen. Natürlich gibt es dann noch diese Kipppunkte beim Klimawandel, aber das sind dann Punkte, nach denen wir Menschen explizit keine Handhabung mehr haben und wir den physikalischen Prozessen unserer Erde dann voll und ganz ausgeliefert sind. Bei dem KI-Vormarsch-Standpunkt bzw. dessen Vorhersage geht es einfach durch die Natur der Art vom Vorhersage um menschliche Entscheidungen und nicht um konkrete „abgeschlossene“ Prozesse. Die Entwicklung von Prozessen, die Menschen, besonders viele Menschen, inkludieren, sind notorisch schlecht vorherzusagen. Eine Vorhersage in so einer Sache, seien die Argumente noch so stark, wie einen Glaubenssatz zu behandeln, befremdet mich deutlich.

    Oft kommt es mir so vor, als würden wir die noch kommende Entwicklung von KI so behandeln, als wäre sie schon passiert. Also, als wäre sie in der Vergangenheit. Dinge, die schon passiert sind, lassen sich bekanntlich nicht mehr ändern. Und klar, wenn man diese noch kommenden Entwicklungen als Prämisse betrachtet, die nicht anders kommen kann, als Prämisse auf der andere Dinge bloß aufbauen können, so passt das gut; es gibt dann eigentlich keinen Unterschied zur echten Vergangenheit.

    Die ganzen bereits sehr konkreten und messbaren Folgen von der Entwicklung von KI, die schon sind, sowie jene, die noch kommen werden, werden kaum benannt; Datenzweckentfremdung, Zerstörung von Ökosystemen, Ressourcenraub und -verbrauch; mal ganz abgesehen von den tollen „tollen Anwendungen“ von KI: Krieg, Massenüberwachung oder AI Slop um ein paar Beispiele zu nennen. Und auch noch komplett unbekannte Gefahren, wie jene durch das AI Alignment Problem, werden nur angegangen unter der Prämisse und mit der Einstellung, dass die KI Entwicklung und die Geschwindigkeit der KI Entwicklung nicht aufzuhalten sei. Als wären all diese Probleme und Gefahren nicht die Konsequenzen von aktuellen Entscheidungen; Entscheidungen die jetzt gerade relevant sein sollten; Entscheidungen die jetzt gerade und in der Zukunft getroffen werden. Als wären sie eben schon passiert.

    Aber es ergibt Sinn, dass dem so ist; denn wenn man all diese Dinge benennen würde und korrekterweise den Zusammenhang herstellt, so würde man erkennen müssen, dass die „KI“ vielleicht eben doch noch nicht passiert ist; wir ihren Vormarsch, wie er aktuell vorangetrieben wird, kritisieren können und müssen. Und dass wir ihn auch noch stoppen können. Und ganz vielleicht sogar stoppen sollten.

    P.S. Ich schreibe diese Zeilen, während auf meinem Zu-Lesen-Stapel „Hoffnung in der Dunkelheit“ von Rebecca Solnit liegt. Obwohl ich das Buch noch nicht gelesen habe, muss ich Solnit hier erwähnen. Ich habe ihren Exkurs zur „Hoffnung in der Dunkelheit“ in „Wenn Männer mir die Welt erklären“ vor kurzem wahrgenommen, sie hat mich zusätzlich bestätigt und mir nochmal neue Worte gegeben, so auf die Zukunft und Vergangenheit zu blicken, wie ich es hier tue.

    1: Sumner, J. (2026, 8. Juli). Rewriting Bun in rust. Bun. https://bun.com/blog/bun-in-rust

    2: Howlett, J. (2026, 22. September). Did OpenAI solve the wrong Navier-Stokes problem? Scientific American. https://www.scientificamerican.com/article/did-openai-solve-the-wrong-navier-stokes-problem/