Tailscale - so einfach doch nicht?

Support
,
1

Hallo ihr Lieben.
Das Prinzip von Tailscale ist soweit klar, jedoch gibt es Verständnisprobleme, dass offenbar mit großer Wahrscheinlichkeit mit meinem Netzwerk-Setup zusammenhängt.

Der IST-Zustand:
WWW → FritzBox (DS-Lite) → Hardware-Firewall (DHCP+DNS) → Switch → LAN-Geräte (Laptop, Server, etc.)

Nun soll von außen auf dem im LAN befindlichen Server zugegriffen werden und aufgrund der obigen Probleme mit DS-Lite, soll Tailscale da ja ideal für sein.

Auf dem Server sind mehrere Docker-Dienste, einer davon ist Caddy um u.a. HTTPS zu ermöglichen.
Um nicht immer via IP+PORT auf entsprechende Docker-Dienste zuzugreifen und um die Warnmeldungen im Browser zu eliminieren, wurde lokal eine Domain eingerichtet (*.server.home) und ein Self-Signed Zertifikat mit mkcert erstellt und Caddy entsprechend damit konfiguriert.

Die IP des Servers lautet 192.168.100.2

Auf der Hardware-Firewall, die ja auch für DNS zuständig ist, wurden ebenfalls alle Einträge zur Auflösung der Domains eingetragen, speziell für Mobilgeräte:
192.168.100.2 immich.server.home
192.168.100.2 it-tools.server.home
usw.

Auf dem Laptop wurde unter Linux die /etc/hosts bearbeitet mit den gleichen Einträgen wie in der Hardware-Firewall. Warum?
Es läuft dort ein kommerzieller VPN um IP-Tracking zu reduzieren und dabei wird ja der DNS des VPN’s genutzt.

So, nun zu Tailscale.
Sobald auf dem Laptop und dem Server Tailscale installiert ist bekommen diese ja eine eigene Tailnet-IP und die Tailnet DNS name z.b. tail7f50c3.ts.net

Wie kann man nun vom Laptop via Tailscale auf den Server zugreifen? Nur die Tailnet-IP ergibt kein HTTPS, Warnmeldungen im Browser sind wieder vorhanden und einige Docker-Dienste erfordern HTTPS und via Tailnet DNS name würde ebenfalls kein HTTPS greifen weil es dafür noch kein Zertifikat gibt.

Nach mehrtägigen Lesens von TUT’s und Videos gäbe es wohl 2 Optionen:

Option 1 - Server als Subnet Router:
Dabei wird allerdings das gesamte Heimnetz zur Verfügung gestellt → sinnvoll?
Allerdings wäre so der DNS-Server (Hardware-Firewall) ebenfalls erreichbar zwecks Namensauflösung und die jetzige Netzwerkstruktur wäre wohl ohne weitere Konfiguration nutzbar.

Option 2 - Tailscale alles machen lassen:
In Tailscale HTTPS aktivieren und so das von Let’s Encrypt signierte Zertifikat für die
*.ts.net-Adresse erstellen.
Allerdings muss dazu wohl Caddy bzw. das Caddyfile umkonfiguriert werden und wahrscheinlich noch „/var/run/tailscale/tailscaled.sock:/var/run/tailscale/tailscaled.sock“ im Docker-stack hinzugefügt werden?

Anmerkung:
Das obige Szenario wurde als Gedankenkonstrukt behandelt. Soll heißen das es praktisch so noch nicht getestet wurde.
Lediglich 2 VM’s wurden damit getestet.

Desweiteren gibt es Ungereimtheiten was die Installation auf dem Server betrifft.
Eingentlich ist es nur ein Befehl:
curl -fsSL https://tailscale.com/install.sh | sh
Aber im Admin-Bereich von Tailscale gibt es unter „Add device“ noch die Option „Linux server“.
Damit wird dann ein anderer Befehl generiert inkl. eines AUTH-Keys.
Was wäre nun richtig?

Ich bitte vorab um Entschuldigung für diesen langen Text. Aber ich denke, je mehr Infos ihr habt desto besser könnt ihr darauf eingehen.

2

Es ist sehr interessant, an einem konkret und detailliert erklärten Problem lernen zu dürfen. Danke für deinen langen Text!

3

Warum macht man es sich nicht einfach: VPN Tunnel mit Wireguard?

4

Soweit ich mich informiert habe funktioniert ein einfacher WG-Tunnel nicht wenn DS-Lite im Spiel ist.

5

Hast du bei deinem ISP angefragt, ob du Dual Stack haben kannst? Bei Vodafone und Telekom sollte es beispielsweise gehen.

6

Negativ. Wird allerdings im Hinterkopf behalten, danke für die Info, sofern der ISP (Vodafone) dies tatsächlich noch macht.
Dennoch müsste, wenn reines DS aktiv, wieder mit Port-Forwarding gespielt werden zusammen mit einem DynDNS-Dienst richtig?

Falls noch wichtig:
Die FritzBox ist eine 7430 mit FRITZ!OS: 07.31 (gemietet). D.h. WG ist dort nicht implementiert.
Also entweder WG auf der Hardware-Firewall (ipfire) oder direkt auf dem Server installieren.

Und:
Sowohl die FritzBox als auch die ipfire laufen eingenständig. Nichts wurde exposed.

7

Ich habe hier auch DS-Lite aber greife per ipv6 von außen zu. Habe dafür noch ein ipv6-fähiges DynDNS vorgeschalten. VPN ist hier allerdings keins.

8

Wenn nun aber im Hotel oder in einer FeWo oder Mobilfunk? kein ipv6 sondern nur ipv4 genutzt werden kann → Keine Verbindung zum Heimnetz.

9

Doch. Du musst es nur deine IPFire machen lassen. Die Verbindung wird dann von innen nach aussen initiiert und offen gehalten.

https://www.ipfire.org/docs/configuration/services/wireguard

10

Ja ipfire hat seit längerem WG integriert, ABER fehlt es wohl immernoch an ipv6-Unterstützung, die wohl erst aber Version 3 kommen soll → ergo sollte damit DS-Lite trotzdem nicht funktionieren oder?

Ich möchte euch dennoch über die „Testergebnisse“ der letzten Tage berichten, die leider ziemlich ernüchternd sind:

Als Testobjekt, stellvertretend für den Server, wurde ein R-Pi4 genommen mit Debian 12 und einem Docker-Dienst (IT-Tools), dazu natürlich Tailscale mit dem vereinfachten Befehl für Linux.

Test #1
Mit tailscale up den Dienst gestartet und im Admin-Panel von Tailscale freigegeben.
Der Zugriff über’s Tailnet auf diesen R-Pi erfolgte zunächst von einer VM aus, einmal via Tailnet-IP:PORT und Tailnet-DNS-Name:PORT → beides erfolgreich.
ABER:
In den Stacks von Docker auf dem richtigen Server wurden die Ports auskommentiert → alles läuft über Caddy.

Test #2
Aufgrund meines Netzwerk-Setups im Startpost bringen mir also weder Tailnet-IP:PORT noch Tailnet-DNS-Name:PORT etwas.
Mit tailscale set --advertise-routes=192.168.100.3/32 auf dem R-Pi wurde versucht NUR diesen im Tailnet zur Verfügung zu stellen und nicht das gesamte Heimnetz.
Zusätzlich wurde im Admin-Panel von Tailscale unter „DNS“ noch folgendes eingetragen:
Add nameserver → 192.168.100.1 (ipfire als DNS) → Split-DNS → server.home

Ergebnis:
it-tools.server.home (so in der ipfire hinterlegt) kann nicht aufgerufen werden.
Ist eigentlich auch logisch → Denn das Tailnet weis nichts von der ipfire trotz Eingabe als Nameserver.

Test #3
Nun wurde mit tailscale set --advertise-routes=192.168.100.0/24 das gesamte Netzwerk eingebunden.
Die DNS-einstellungen im Admin-Panel von Tailscale wurden beibehalten.
Ergebnis:
Leider funktionierte das so wie es soll, auch vom Smartphone im Mobilnetz.

Ob ich mich damit zufrieden geben kann weis ich noch nicht so richtig.
In der Community von ipfire gibt es ein Plugin welches womit man Tailscale darauf nutzen kann.

Trotzdem ist mir Tailscale irgendwie umheimlich. Immerhin wird damit (nach meinem laienhaften Verständnis) sowohl die FritzBox als die Hardware-Firewall „umgangen“.

11

Wie soll die von innen nach außen imitiert werden? Dazu bräuchte sie als Peer einen Wireguard-Server mit offenem Port, um zu verbinden.

12

oder im Supermarkt oder oder, das WLAN nur ein Gastnetz zur Verfügung stellt. In dem ist normalerweise „alles außer Surfen und E-Mail“ gesperrt. Dann guckst du eh in die Röhre. BTDT. Mobilfunk geht immer.

13

Hallo Kooper

Hast du auf deinem Server einen lokalen DNS-Server Dienst (z.B. Pi-hole) laufen? Dann einfach auch Tailscale auf deinem Server installieren und in der Tailscale Admin Console (login.tailscale.com/admin/dns) unter Nameservers → Add nameserver → Custom → die Tailscale IP des Servers eintragen (z.B. 100.100.100.2) und «Override DNS servers» aktivieren.

Dann «local DNS records» im lokalen DNS-Server (z.B. Pi-hole) setzen, z.B.

dockerservice1.example.com 100.100.100.2

dockerservice2.example.com 100.100.100.2

usw.

Dann ist es am einfachsten wenn du ein Let’s Encrypt wildcard Zertifikat (*.example.com) erstellst. Du könntest aber auch für jeden Service eine eigene Subdomain erstellen, z.B. dockerservice1.example.com, dann musst du aber das Zertifikat jeweils neu ersellen, wenn du einen neuen Service hinzufügst.

Pi-hole funktioniert da super als lokaler DNS-Dienst, deine DNS Anfragen profitieren vom Werbeblocker und werden für lokale Services mit «local DNS records» auch sauber aufgelöst (DNS-Splitting).

Kann sein, dass ich die eine oder andere Kleinigkeit vergessen habe zu erwähnen, aber im groben funktioniert es so mit Tailscale sehr gut, um deine Services von überall her über https zu erreichen. Sonst einfach nochmal nachfragen.

14

Hallo Kimi.
Nein auf dem Server läuft kein DNS-Server Dienst. Alles was mit DNS zutun hat hier im Heimetz erledigt die ipfire.

Leider habe ich hier keinen Dienst der Zertifikate von z.b. Let’s Encrypt bereitstellt, auch weil es eigentlich nicht geplant war von außerhalb auf’s Heimnetz zuzugreifen und wegen dem DS-Lite somit eh verworfen wurde, naja, bis ich mich eben mit Tailscale beschäftigt habe.

Tailscale bietet zwar Let’s Encrypt an, dafür müsste ich allerdings die gesamte Heimnetz-Konfiguration umstellen.

Da ich mein anliegen auch mal durch einige „KI’s“ erörtern lies, wären 2 Lösungen möglich:

Lösung 1
Auf dem Server mit dem Befehl
tailscale set --advertise-routes=192.168.100.1/32,192.168.100.2/32
wird nur der Server und die ipfire ins Tailnet gelassen und nicht das komplette Heimnetz.
Via ACL in Tailscale kann man es so einrichten das nur der DNS der ipfire genutzt werden soll.

Lösung 2
Auf dem Server ein Mini-DNS Dienst wie CoreDNS oder dnsmasq installieren und dieser soll nur dafür zuständig sein Anfragen aus dem Tailnet zum Server aufzulösen, bspw.:
dienst1.server.home → 100.x.x.x
Ob das „besser“ ist vermag ich nicht zu sagen …

Zur Zeit habe ich Lösung 1 getestet und via ACL es etwas eingeschränkt und es funktioniert zumindest aus einer VM heraus.
Weitere Tests werden folgen.

15

Genau das will man ja nicht. Jemanden den Generalschlüssel für ein Wohnhaus mit 101 Stockwerken zu geben, damit er überall im Gebäude zu jeder Wohnung die Tür aufschließen kann.

Genau deshalb gibt es ja Tailscale und Netbird.

16

Und NGINX?