Bisher ist dein Server über genau einen Eingang erreichbar: Port 22 für SSH, öffentlich im Internet sichtbar. Durch Key-Authentifizierung sind Brute-Force-Angriffe chancenlos – aber sichtbar ist sichtbar. Sobald in späteren Artikeln Admin-Werkzeuge wie Komodo dazukommen, brauchen wir einen anderen Ansatz: ein privates Netzwerk, in dem ausschließlich deine eigenen Geräte den Server erreichen.

Genau das macht ein VPN (Virtual Private Network): Es legt einen verschlüsselten Tunnel zwischen deinen Geräten – dein Laptop und der VPS verhalten sich, als hingen sie im selben lokalen Netz, obwohl tausende Kilometer dazwischen liegen. Aus dem Rest des Internets ist der Server über diesen Tunnel nicht erreichbar.

Genau das machen wir in diesem Artikel. Wir installieren Tailscale, verifizieren die VPN-Verbindung – und schließen anschließend Port 22 im öffentlichen Internet. SSH funktioniert natürlich weiterhin, aber für alle außer dir bleibt es unsichtbar.

In diesem Artikel öffnen wir keine zusätzlichen Ports am Server. Im Gegenteil: am Ende ist ein Port weniger offen als vorher.

Am Ende hast du

  • Tailscale installiert auf dem Server und auf deinem Rechner
  • Beide Geräte im selben privaten VPN-Netz
  • SSH funktioniert nur noch über das Tailscale-Netzwerk
  • Port 22 ist im öffentlichen Internet geschlossen
  • Server bleibt dauerhaft im Tailnet (Anmeldung läuft nicht ab)
  • Provider-Konsole als Notfallzugang getestet
  • Optional: MagicDNS aktiviert, du sprichst deine Geräte bei Namen an

Voraussetzungen

  • Debian 13 mit SSH-Key-Login (aus Artikel 02)
  • UFW aktiv mit OpenSSH-Regel (aus Artikel 02)
  • Account-Möglichkeit bei Tailscale (kostenlos, z. B. mit GitHub, Google oder Microsoft)
  • Lokaler Rechner griffbereit – wir installieren auch dort

1. Warum jetzt – bevor die Admin-Tools kommen?

Admin-Oberflächen sind etwas anderes als normale Web-Anwendungen. Ein Blog darf gelesen werden. Eine Verwaltungsoberfläche, mit der jemand Container starten, stoppen oder löschen kann, darf das nicht – auch nicht hinter einem Login.

Der Grund: Jedes Login-Formular im öffentlichen Internet wird permanent automatisiert getestet – mit Listen geleakter Passwörter, mit Brute-Force, mit ausgenutzten Bugs im Login-Mechanismus selbst. Bei einem öffentlichen Blog ist das egal. Bei einem Tool, das Container starten und löschen kann, ist es das Risiko nicht wert.

Die Lösung: Admin-Werkzeuge sollen gar nicht erst im öffentlichen Internet erscheinen. Sie laufen ausschließlich in einem privaten Netzwerk, das nur deine eigenen Geräte sehen.

Genau dieses Netzwerk bauen wir jetzt – bevor das erste Admin-Werkzeug überhaupt installiert ist. So entsteht kein Zeitraum, in dem etwas ungeschützt online steht.

Hinweis zu den Zugriffsebenen

Welche Apps später über VPN, welche öffentlich mit 2FA und welche frei zugänglich laufen, ist in Artikel 01 im Detail beschrieben (die drei Zugriffsebenen 🔒 / 🔐 / 🌐). Dieser Artikel kümmert sich nur um die Grundlage: das VPN selbst.

2. Warum Tailscale?

Ein klassisches VPN selbst aufzusetzen ist möglich – mit WireGuard und etwas Konfiguration sogar relativ schlank. Was bei einem Einzelserver schnell mühsam wird, ist die Geräteverwaltung: jedes Mal Schlüssel verteilen, Port öffnen, Endpunkte konfigurieren, mit NAT umgehen.

Tailscale nutzt unter der Haube WireGuard, nimmt dir aber genau diesen Verwaltungsaufwand ab:

  • Geräte authentifizieren sich über deinen Account (z. B. GitHub), nicht über manuell verteilte Schlüssel
  • NAT-Traversal funktioniert automatisch – kein Portforwarding nötig
  • Neue Geräte sind in wenigen Klicks Teil des Netzes

Die kostenlose Variante deckt bis zu 100 Geräte und 3 Nutzer ab – für Self-Hosting deutlich mehr als nötig. Die Verschlüsselung läuft Ende-zu-Ende; Tailscale selbst kann den Datenverkehr nicht mitlesen.

Wenn du später lieber alles auf eigener Infrastruktur hosten willst (ohne den Tailscale-Koordinationsdienst): in Reihe 2 (NAS Edition) zeigt eine Bonus-Anleitung den Umstieg auf Netbird.

3. Tailscale-Account anlegen

Bevor Geräte sich verbinden können, brauchst du ein Konto.

  • Öffne im Browser: https://tailscale.com
  • Klicke auf Get Started
  • Melde dich mit einem bestehenden Konto an (z. B. GitHub oder Google)

Das Konto dient ausschließlich der Zuordnung deiner Geräte. Der eigentliche VPN-Datenverkehr läuft direkt zwischen ihnen, nicht über Tailscale.

Nach der Anmeldung siehst du die Admin Console mit einer leeren Geräteliste. Hier tauchen gleich Server und Rechner auf.

⚠️ Dein VPN ist nur so sicher wie dein Login beim Identity Provider

Tailscale hat kein eigenes Passwort – die Anmeldung läuft komplett über deinen Identity Provider (IDP), also den Dienst, mit dem du dich oben angemeldet hast: GitHub, Google, Apple oder Microsoft. Wer diesen Account übernimmt, kommt auch in dein Tailscale-Netz und damit auf jedes Gerät darin.

Falls noch nicht geschehen: 2FA beim IDP aktivieren. Konkrete Empfehlung: 2FAS Auth – eine Open-Source-TOTP-App (iOS + Android, EU-Entwickler, kein Account-Zwang). Aegis (Android) oder Bitwarden Authenticator sind ebenfalls solide.

[Screenshot-Platzhalter: Tailscale Admin Console nach Login – leere Machines-Liste]

4. Tailscale auf dem Server installieren

Verbinde dich per SSH mit deinem VPS:

ssh martin@DEINE-SERVER-IP

Installiere Tailscale:

curl -fsSL https://tailscale.com/install.sh | sh

Das Skript erkennt Debian 13 automatisch, fügt das Tailscale-Repository hinzu und installiert das Paket. Der Dienst tailscaled startet automatisch. Der Output zeigt dir die einzelnen Schritte:

Installing Tailscale for debian trixie, using method apt
+ apt-get update
+ apt-get install -y tailscale
Created symlink /etc/systemd/system/multi-user.target.wants/tailscaled.service
Installation complete! Log in to start using Tailscale by running:

sudo tailscale up

Verbindung zum Tailscale-Netz aufbauen:

sudo tailscale up

Im Terminal erscheint eine Anmelde-URL. Öffne sie in deinem Browser, melde dich mit deinem Tailscale-Account an und bestätige, dass dieses Gerät dem Netzwerk beitreten darf.

[Screenshot-Platzhalter: Browser-Bestätigung „Connect device" – Server tritt dem Tailnet bei]

Nach wenigen Sekunden meldet das Terminal Erfolg. Die VPN-IP des Servers anzeigen:

tailscale ip -4

Erwartung: Eine Adresse aus dem Bereich 100.x.x.x – das ist Tailscales privater Adressraum (CGNAT). Diese IP ist nur innerhalb deines Tailscale-Netzes erreichbar. Notiere sie, du brauchst sie gleich mehrfach.

5. Tailscale auf deinem eigenen Rechner installieren

Damit du deinen Server über das VPN erreichen kannst, braucht auch dein Computer Tailscale.

macOS oder Windows

  1. Lade die App von https://tailscale.com/download
  2. Installiere und starte sie
  3. Klicke auf Connect und melde dich mit demselben Account an

Linux

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up

Wie beim Server bekommst du eine Anmelde-URL.

Verbindung prüfen:

tailscale status

Erwartung: Beide Geräte erscheinen in der Liste – dein Server und dein Rechner. Hinter beiden steht jeweils ihre 100.x.x.x-Adresse.

[Screenshot-Platzhalter: Tailscale Admin Console → Machines-Liste mit zwei Geräten (Server + Rechner), beide „Connected"]

6. VPN-Verbindung testen

Vom lokalen Rechner aus den Server anpingen:

ping <TAILSCALE-IP-DES-SERVERS>

Erwartung: Antworten kommen zurück.

SSH über das VPN testen:

ssh martin@<TAILSCALE-IP-DES-SERVERS>

Beim ersten Mal erscheint die bekannte Host-Key-Abfrage – derselbe Server, aber neue Adresse. Mit yes bestätigen.

Wenn der Login klappt, ist die VPN-Verbindung einsatzbereit. Jetzt fehlen noch zwei Schritte, damit der Server dauerhaft erreichbar bleibt – und Port 22 endgültig aus dem öffentlichen Internet verschwindet.

7. Tailscale-Anmeldung des Servers dauerhaft gültig machen

Wenn sich ein Gerät bei Tailscale anmeldet, bekommt es einen geräteeigenen Schlüssel – das ist Tailscales interne Anmeldung an deinem Tailnet (technisch ein WireGuard-Schlüssel). Wichtig: Das hat nichts mit deinen SSH-Keys aus Artikel 02 zu tun. Die SSH-Keys verschlüsseln den SSH-Login; der Tailscale-Schlüssel ist die VPN-Anmeldung des Geräts.

Diese Tailscale-Anmeldung läuft standardmäßig nach 180 Tagen ab. Für einen Laptop ist das sinnvoll – ein verlorenes Gerät fällt automatisch aus dem Netz. Für einen Server, der dauerhaft erreichbar bleiben soll, ist es genau falsch herum: nach 180 Tagen wäre dein VPS plötzlich offline und müsste manuell neu angemeldet werden (über die Provider-Konsole).

Für den Server schalten wir den Ablauf deshalb ab. In der Admin Console (https://login.tailscale.com/admin/machines):

  1. Wähle deinen Server aus der Geräteliste
  2. Klicke rechts auf das Drei-Punkte-Menü (…)
  3. Wähle Disable key expiry

[Screenshot-Platzhalter: Drei-Punkte-Menü eines Geräts mit hervorgehobenem Eintrag „Disable key expiry"]

In der Übersicht steht jetzt Expiry disabled neben dem Server. Für den lokalen Rechner lässt du den Ablauf an – wenn der Laptop mal verloren geht, soll er sich nicht ewig im Netz aufhalten.

Hinweis

Diese Einstellung wirkt nur für das ausgewählte Gerät. Für jeden weiteren Server, den du später hinzufügst, machst du den gleichen Schritt.

8. SSH auf das Tailscale-Netzwerk beschränken

Jetzt der entscheidende Sicherheitsschritt: Port 22 verlässt das öffentliche Internet. SSH ist danach nur noch über die Tailscale-IP erreichbar.

⚠️ Erst testen, dann scharf schalten

Bevor du die alte UFW-Regel entfernst, halte unbedingt eine funktionierende SSH-Session über die Tailscale-IP in einem zweiten Terminal offen. Wenn etwas schiefgeht, hast du dort noch Zugang zum Server.

Zweites Terminal öffnen, dort:

ssh martin@<TAILSCALE-IP>

Login klappt? Dann weiter – die folgenden Befehle führst du am besten direkt in dieser neuen Session aus:

# SSH (und alles andere) über Tailscale erlauben
sudo ufw allow in on tailscale0

# Alte öffentliche SSH-Regel entfernen
sudo ufw delete allow OpenSSH

# Status prüfen
sudo ufw status verbose

Erwartung:

Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                          Action      From
--                          ------      ----
Anywhere on tailscale0      ALLOW IN    Anywhere
Anywhere (v6) on tailscale0 ALLOW IN    Anywhere (v6)

Kein OpenSSH ALLOW IN Anywhere mehr.

Was bedeutet allow in on tailscale0?

Tailscale legt beim Start ein eigenes Netzwerk-Interface namens tailscale0 an. Die UFW-Regel erlaubt eingehenden Verkehr ausschließlich auf diesem Interface – also nur, wenn er aus dem VPN kommt. Über die öffentliche IP ist der Server jetzt aus UFWs Sicht stumm.

Das wird in den nächsten Artikeln nützlich: Wenn Komodo (Artikel 06) auf Port 9120 lauscht oder Uptime Kuma später auf Port 3001, ist das automatisch nur über Tailscale erreichbar. Wir müssen nicht für jeden Dienst eine eigene Regel anlegen.

9. Plan B: Provider-Konsole als Notfallzugang

Port 22 ist geschlossen, SSH läuft ausschließlich über Tailscale. Berechtigte Folgefrage: Was, wenn Tailscale ausfällt oder das lokale Setup kaputt geht?

Zwei Punkte zur Entspannung:

1. Bestehende Verbindungen laufen direkt zwischen den Geräten. Tailscale koordiniert nur den Verbindungsaufbau – der eigentliche Datenverkehr läuft P2P über WireGuard. Ein Tailscale-Outage (Koordinationsserver weg) trennt also keine laufenden Sessions. Was scheitern würde, sind neue Anmeldungen.

2. Die Provider-Konsole bleibt immer erreichbar. Jeder seriöse VPS-Anbieter bietet eine Web-Konsole (VNC oder KVM), die direkten Bildschirm-Zugriff gibt – komplett unabhängig vom Netzwerk-Setup auf dem Server. Das ist dein echter Notfallzugang.

  • Netcup: SCP → Server auswählen → VNC-Konsole
  • Hetzner: Cloud Console → Server → „Console"

Teste die Konsole einmal, bevor du sie wirklich brauchst. Login funktioniert mit dem Root-Passwort, das dir der Provider beim Anlegen des Servers gegeben hat. Falls vergessen: Jeder Provider bietet ein Rescue-System, mit dem sich das Root-Passwort zurücksetzen lässt – aber die fünf Minuten Vorbereitung sparen dir später Stress.

Zugangsdaten an einem zweiten Ort ablegen

Speichere die URL zur Provider-Konsole und die Zugangsdaten nicht nur auf dem Server, der gerade nicht erreichbar ist. Vor dem ersten Vaultwarden tut es auch ein verschlüsselter Notizen-Speicher auf deinem lokalen Rechner.

10. Optional: MagicDNS – Geräte beim Namen ansprechen

Statt ssh martin@100.64.12.5 kannst du auch ssh martin@homelab schreiben – wenn MagicDNS aktiv ist.

Für Accounts ab Oktober 2022 ist MagicDNS standardmäßig eingeschaltet. Dann zeigt Tailscale dir direkt nach dem Verbinden eine Zeile wie:

This machine is accessible as `homelab` using MagicDNS.

Falls MagicDNS bei dir nicht aktiv ist:

  1. Admin Console öffnen → DNS
  2. Bei MagicDNS auf Enable klicken

[Screenshot-Platzhalter: Tailscale Admin Console → DNS-Bereich mit aktiviertem MagicDNS]

Den Gerätenamen vergibt Tailscale automatisch anhand des Hostnamens deines Servers. Ändern kannst du ihn in der Admin Console oder beim Verbinden:

sudo tailscale up --hostname=homelab

Danach erreichst du den Server unter homelab (der vollständige Name homelab.<tailnet-name>.ts.net funktioniert ebenfalls, brauchst du im Alltag aber nicht).

Verträglichkeit mit Artikel 04

Falls du in Artikel 04 (optional) den systemd-resolved-Stub-Listener deaktiviert hast: MagicDNS funktioniert trotzdem. Wir haben dort nur den Stub-Listener auf Port 53 abgeschaltet – der Dienst systemd-resolved selbst läuft weiter, und genau über ihn integriert sich Tailscale (per D-Bus). Der Stub-Listener wird für MagicDNS nicht gebraucht.

11. Optional: Smartphone-Zugriff

Tailscale gibt es als App für iOS und Android. Aus dem App Store installieren, mit demselben Account anmelden – fertig. Das Smartphone ist Teil deines Tailnets.

Was du damit machen kannst:

  • Im mobilen Browser Admin-Interfaces öffnen (http://homelab:9120 für Komodo, sobald installiert)
  • Mit SSH-Apps wie Termius (iOS/Android) auf den Server zugreifen
  • Dienste von unterwegs verwalten, als wärst du zuhause

Achte darauf, dass dein Smartphone selbst gut geschützt ist (PIN/Biometrie, aktuelle Updates). Die VPN-Verbindung ist nur so sicher wie das schwächste Gerät im Netz.

Und jetzt?

Du hast jetzt ein privates Netzwerk zwischen deinen Geräten und dem Server. SSH läuft nur noch darüber, Port 22 ist im öffentlichen Internet geschlossen. Damit ist das Versprechen aus Artikel 02 eingelöst – und gleichzeitig die Grundlage für alle Admin-Werkzeuge gelegt, die jetzt folgen.

Im nächsten Artikel installieren wir Komodo – eine Web-Oberfläche für Docker, mit der du Stacks, Container und Konfigurationen bequem im Browser verwaltest, statt jedes Mal docker compose ... zu tippen. Komodo wird ausschließlich über das gerade eingerichtete Tailscale-Netz erreichbar sein. Kein offener Port, kein öffentliches Login-Formular.

👉 Nächster Artikel: 06. Komodo – Docker-Management per Web-UI