Infrastruktur

Wie Tailscale all meine VPN-Konfigurationen ersetzt hat

9 min read

Wer Server an mehr als einem Ort betreibt, kennt den Netzwerkärger. Portweiterleitungen, dynamisches DNS, Firewall-Regeln, VPN-Konfigurationen, die jedes Mal brechen, wenn der Provider die IP wechselt. Ich habe mich damit jahrelang herumgeschlagen, bevor ich zu Tailscale gewechselt bin — und ehrlich gesagt hätte ich es früher tun sollen. Es ist das eine Werkzeug, das aus meiner verstreuten Maschinensammlung etwas gemacht hat, das sich tatsächlich wie ein Netzwerk anfühlt.

So setze ich es über den gesamten Aufbau hinweg ein: Homelab, Rechenzentrumsserver, Notebooks, Telefon und alles dazwischen.

Was Tailscale eigentlich ist

Tailscale ist ein Mesh-VPN auf Basis von WireGuard. Jedes Gerät, das deinem Netz beitritt (Tailscale nennt es „Tailnet“), bekommt eine feste IP-Adresse, die unabhängig vom physischen Standort funktioniert. Dein Heimserver, ein VPS im Rechenzentrum, dein Notebook im Café: Sie sehen einander direkt, Ende zu Ende verschlüsselt, ohne dass Verkehr über einen zentralen Server läuft.

Entscheidend ist das „Mesh“. Herkömmliche VPNs leiten alles über ein einziges Gateway, das damit zum Flaschenhals und zur einzelnen Bruchstelle wird. Tailscale baut direkte Punkt-zu-Punkt-Verbindungen zwischen Geräten über WireGuard-Tunnel auf. Können zwei Maschinen einander direkt erreichen, tun sie es. Können sie es nicht — wegen strengem NAT oder Firewalls —, greift Tailscale auf Relais-Server (genannt DERP) zurück. In der Praxis klappt die direkte Verbindung aber meistens.

Wie mein Netz aufgebaut ist

Ich betreibe gemischte Hardware an mehreren Standorten:

  • Zu Hause: ein Proxmox-Host mit VMs und Containern, darunter ein KI-Inferenzserver mit GPU, ein NAS und diverse Dienste.
  • Rechenzentrum: mehrere dedizierte Server mit Proxmox für Webhosting, CI/CD, Datenbanken und Anwendungslasten.
  • Notebooks und Mobilgeräte: meine täglichen Begleiter, die all das erreichen müssen.

Vor Tailscale brauchte es dafür ein Gewirr aus SSH-Tunneln, Portweiterleitungen und einem WireGuard-Server, den ich selbst pflegte. Bei jeder neuen Maschine musste ich Schlüssel erzeugen, die Konfiguration auf jeder Gegenstelle nachziehen, Ports öffnen und hoffen, dass sich die Firewall-Regeln nicht in die Quere kamen. Ein zusätzlicher Container auf Proxmox bedeutete eine weitere Runde Konfigurationsänderungen.

Mit Tailscale installiere ich den Client auf einer neuen Maschine, melde sie an, und sie ist im Netz. Das war’s. Keine Konfigurationsdateien, keine Schlüsselverteilung, keine Portweiterleitung.

Tailscale auf Proxmox: jeder Container bekommt eine Identität

Hier wird es für Homelab-Betreiber richtig nützlich. Ich lasse Tailscale in einzelnen LXC-Containern auf Proxmox laufen. Jeder Container bekommt seine eigene Tailscale-IP und seinen eigenen Namen im Netz. Mein Ollama-Container ist als ollama.tail erreichbar, meine GitLab-Instanz als gitlab.tail, mein Überwachungsstapel als grafana.tail.

Für LXC-Container braucht es einen kleinen Kniff: Der Zugriff auf das TUN-Gerät muss in der Container-Konfiguration freigegeben werden. Trage lxc.cgroup2.devices.allow: c 10:200 rwm und lxc.mount.entry: /dev/net/tun dev/net/tun none bind,create=file in die Konfiguration ein und installiere Tailscale danach ganz normal im Container. Das dauert etwa zwei Minuten pro Container.

Bei VMs ist es noch einfacher: Tailscale installieren wie auf jeder anderen Linux-Maschine. Keine besondere Konfiguration nötig.

MagicDNS: Schluss mit IP-Auswendiglernen

MagicDNS legt automatisch DNS-Einträge für jedes Gerät im Tailnet an. Statt dir zu merken, dass dein Heimserver unter 100.64.x.y liegt, nimmst du einfach den Hostnamen. Das klingt nebensächlich, ändert aber, wie man über die eigene Infrastruktur nachdenkt.

Ich konfiguriere alle meine Dienste so, dass sie einander über den Tailscale-Hostnamen ansprechen. Meine Webanwendungen verbinden sich über den Mesh-Namen mit den Datenbanken. Meine CI-Runner ziehen die Container-Registry über den Namen. Verschiebe ich einen Dienst auf eine andere Maschine, wandert der Name mit. Keine fest verdrahteten IPs, keine DNS-Einträge, die von Hand nachgezogen werden müssen.

Eine Stolperfalle: MagicDNS kann die lokale Namensauflösung überschreiben. Wenn du Geräte im LAN über ihren Hostnamen ansprichst — etwa ein NAS —, fängt Tailscale diese Anfragen womöglich ab. Ich bin am Ende dazu übergegangen, lokale LAN-Geräte über die IP anzusprechen und Tailscale-Namen für alles andere zu verwenden. Eine kleine Unschönheit, die man aber kennen sollte.

ACLs: nicht alles sollte mit allem reden

Ab Werk kann jedes Gerät im Tailnet jedes andere erreichen. Für den Anfang ist das bequem, doch mit wachsendem Netz will man mehr Kontrolle. Mit den Zugriffslisten (ACLs) von Tailscale legst du genau fest, welches Gerät welchen Dienst ansprechen darf.

Meine ACLs gruppieren die Maschinen nach Rolle:

  • KI-Inferenz: Nur bestimmte VPS-Container erreichen den Ollama-Port. Beliebige Geräte im Tailnet nicht.
  • Verwaltung: SSH-Zugriff auf die Proxmox-Hosts ist auf meine persönlichen Geräte beschränkt. Kein Container und kein VPS kommt per SSH an die Hypervisor-Ebene.
  • Überwachung: Der Überwachungsstapel darf überall Messwerte abholen, aber nichts anderes erreicht die Überwachungsports.
  • Öffentliche Dienste: Web-zugewandte Dienste sind voneinander getrennt. Sie erreichen die Datenbank und die KI-Schnittstelle, aber nicht die Verwaltungsoberflächen der jeweils anderen.

Die ACL-Datei ist JSON und liegt in der Tailscale-Verwaltungskonsole. Sie lässt sich versionieren (ich halte eine Kopie in meinem Git-Repository), und Änderungen greifen binnen Sekunden. Keine Firewall-Regeln zu verteilen, keine iptables-Ketten zu debuggen.

Die Paradedisziplin: der VPS ruft für KI zu Hause an

Das ist mein liebster Anwendungsfall und der, der am meisten Geld spart. Zu Hause steht eine RTX 3090 für KI-Inferenz (Ollama für LLMs, ComfyUI für Bilder). Meine VPS-Instanzen im Rechenzentrum brauchen für verschiedene Anwendungen KI-Fähigkeiten: Texterzeugung, Embeddings, Klassifikation, Bildverarbeitung.

Ohne Tailscale würde ich entweder für Cloud-KI-Schnittstellen zahlen (bei Volumen teuer) oder GPU-Instanzen mieten (ebenfalls teuer, und sicher anbinden müsste ich sie trotzdem). Stattdessen ruft jeder VPS schlicht über das Tailscale-Mesh zu Hause an:

curl http://ollama.tail:11434/api/generate -d '{"model": "llama3.1", "prompt": "..."}'

Die Anfrage läuft durch den verschlüsselten WireGuard-Tunnel in mein Heimnetz, trifft die GPU, und die Antwort kommt zurück. Der Netzweg kostet etwa 15 bis 30 ms, dazu kommt die Inferenzzeit. Für Stapelverarbeitung und Hintergrundaufgaben ist das völlig in Ordnung.

Und die Kosten? Strom für die GPU (rund 10 EUR im Monat im Dauerbetrieb) gegen mehrere Hundert im Monat für Cloud-KI-Schnittstellen oder GPU-Instanzen. Der Tailscale-Tarif ist der einzige laufende Posten für die Netzwerkschicht.

SSH ohne offene Ports

Tailscale SSH ist eine weitere Funktion, die ich ständig nutze. Statt SSH auf Port 22 ins offene Internet zu stellen, nehme ich Tailscale als Transportweg. SSH ist nur über das Tailnet erreichbar, und das heißt:

  • Keine SSH-Brute-Force-Versuche. Der Port ist zum Internet hin gar nicht offen.
  • Kein Bedarf an fail2ban oder Port Knocking. Die Angriffsfläche ist weg.
  • Ich komme vom Telefon aus auf jeden Server, ohne irgendetwas einzurichten. Ist das Gerät im Tailnet, erreiche ich es.
  • Die Anmeldung übernimmt die Identitätsschicht von Tailscale. Ich nutze zusätzlich weiterhin SSH-Schlüssel als zweiten Faktor, aber die Zugriffskontrolle auf Netzebene steht bereits.

Bei Proxmox-Hosts wiegt das besonders schwer. Verwaltungsoberflächen von Hypervisoren gehören niemals ins offene Internet. Mit Tailscale sind die Proxmox-Weboberfläche und SSH nur von angemeldeten Geräten aus meinem Tailnet erreichbar.

Subnetz-Routing: Geräte ohne Tailscale erreichen

Nicht alles kann den Tailscale-Client ausführen: Netzwerk-Switches, IPMI-Schnittstellen, alte Geräte. Dafür gibt es Subnetz-Routing. Man bestimmt eine Maschine im lokalen Netz zum Subnetz-Router, und sie macht das lokale Subnetz dem übrigen Tailnet bekannt.

Ich nutze das zu Hause für meine IPMI/BMC-Schnittstellen (die in einem eigenen VLAN liegen) und für ein paar IoT-Geräte, die kein Tailscale können. Ein Proxmox-Host im selben Netz übernimmt die Rolle des Subnetz-Routers. Von meinem Notebook aus, irgendwo auf der Welt, komme ich auf die IPMI-Oberfläche meines Heimservers, als säße ich im lokalen Netz.

Exit Nodes: VPN, wenn man es braucht

Jedes Tailscale-Gerät lässt sich als Exit Node einrichten und leitet dann den gesamten Internetverkehr über sich. Ich nutze das in Netzen, denen ich nicht traue — Cafés, Hotels, Flughäfen. Statt für ein kommerzielles VPN zu zahlen, schicke ich meinen Verkehr über einen meiner eigenen Server.

Ich habe zwei Exit Nodes eingerichtet: einen auf einem Rechenzentrumsserver (fürs Tempo) und einen im Heimnetz (um auf geografisch beschränkte Inhalte zuzugreifen, als wäre ich zu Hause). Der Wechsel ist ein Schalter in der Tailscale-App.

Was ich besser fände

Kein Werkzeug ist perfekt. Ein paar Dinge, über die ich gestolpert bin:

  • MagicDNS-Konflikte. Wie erwähnt kann es sich mit dem lokalen DNS beißen. Wer einen eigenen DNS-Server betreibt (etwa Pi-hole), muss Split-DNS sauber einrichten, sonst gibt es Auflösungsprobleme.
  • Die LXC-Einrichtung läuft nicht automatisch. Jeder neue Container braucht die TUN-Konfiguration von Hand. Ich habe es mir skriptiert, aber ein Proxmox-Plugin von Tailscale wäre schöner.
  • Mesh-Probleme aufspüren. Läuft eine Verbindung über ein Relais statt direkt, ist nicht immer offensichtlich, warum. tailscale status und tailscale netcheck helfen, aber die Fehlersuche-Dokumentation könnte besser sein.
  • Gerätegrenze im kostenlosen Tarif. Wer Tailscale in jedem Container einzeln betreibt, stößt schnell an die Grenze. Die kostenpflichtigen Tarife sind fair, man sollte es nur wissen.

Lohnt sich das?

Für mich ohne Zweifel. Tailscale hat aus einer zerstückelten Maschinensammlung ein zusammenhängendes Netz gemacht. Ich denke über Netzwerk nicht mehr nach. Ich suche keine VPN-Tunnel mehr um elf Uhr abends, weil der Provider meine IP gewechselt hat. Ich pflege keine WireGuard-Konfigurationen über zwanzig Maschinen. Ich füge ein Gerät hinzu, und es läuft.

Wer irgendein Homelab oder einen Aufbau mit mehreren Servern betreibt, bekommt mit Tailscale vermutlich das Werkzeug mit dem besten Verhältnis von Aufwand zu Nutzen. Allein die eingesparte Netzwerkarbeit trägt die Kosten, und Funktionen wie ACLs, Subnetz-Routing und Exit Nodes machen es wirklich mächtig, nicht nur bequem.

Zu einzelnen Aufbauten — Tailscale und Proxmox im Detail, ACL-Muster fürs Homelab, Überwachung quer durchs Tailnet — schreibe ich in kommenden Beiträgen mehr. Bei Fragen dazu: melde dich.