Richtiger Eintrag iptables für Routing mit Tailscale

    Hallo zusammen,


    ich bin ein ziemlicher Linux n00b, habe derzeit einen Vserver mit Debian und zu Hause einen x64 Server, ebenfalls auf Debian laufen.


    Da ich Glasfaser Deutschland habe, komme ich nicht ohne weiteres wie früher per DynDNS an meinen Server zu Hause ran. Aktuell läuft auf beiden Tailscale, so dass ich relativ einfach zugreifen kann. Der Nachteil ist, dass es ab dem zweiten User kostenpflichtig ist und ich meiner Frau ebenfalls Zugriff auf einige Dienste einrichten möchte.


    Nun zu meiner Idee:

    Tailscale läuft ja auf meinem Netcup Vserver. Ich würde gerne eine Weiterleitung eines bestimmten Ports des Vservers (zB 10950) auf einen bestimmten Port des Heimservers einrichten. Wegen Tailscale ist die virtuelle IP Adresse des Heimservers fest nach dem Schema 100.x.x.x.


    So müsste ich meiner Frau nur meine fixe Vserver Adresse plus Port geben und sie könnte drauf zugreifen. Wenn das möglich wäre, könnte ich auf dem Heimserver noch eine weitere Weiterleitung einrichten, zB auf den Homeserver, mit dem wir Heizung und Licht steuern.


    Erste Versuche mit iptables schlugen fehl, was entweder an meiner Syntax oder der Tatsache liegt, dass Tailscale sich selbst auch in die iptables schreibt. Da weiß ich nun auch nicht mehr weiter.


    Also: Ist das prinzipiell so möglich und was wäre der korrekte Befehl ?


    Thx !

    Ich hab dein Setup noch nicht verstanden. Du nutzt Tailscale für den Zugriff von außen, ok. Aber wie sind die Server untereinander verbunden? Wie sieht die IP-Verteilung bei dir exakt aus, also auf dem Server und im Heimnetz und welches Transport-Netz nutzt Tailscale? 100.x ist eine Carrier Grade NAT Adresse, die dürfte kaum für das interne Transportnetz von Tailscale benutzt werden (jedenfalls wäre das ein Grund für mich, da auszusteigen).


    Zitat von docromano

    Da ich Glasfaser Deutschland habe, komme ich nicht ohne weiteres wie früher per DynDNS an meinen Server zu Hause ran.

    Warum nutzt du nicht einfach IPv6? Spart ne Menge Aufwand.

    Bevor Du Verrenkungen unternimmst um Dich mit den Limits von Tailscale zu arrangieren, schau Dir doch lieber ZeroTier – Global Area Networking oder NetBird - Zero configuration VPN for fast-moving teams an. Beide haben auch Node Limits, die aber für Deinen Einsatzzweck mehr als ausreichen sollten, da kannst Du noch viel mehr Geräte aufnehmen.


    Bei ZT kannst Du diesen Limits auch komplett entkommen, wenn Du Deinen eigenen Controller hostest, dann gibts gar keine Nodelimits mehr. Bei Netbird ist das auch möglich, aber noch deutlich aufwändiger als den ZT Controller zu hosten (dafür aber auch flexibler).


    Netbird ist neuer und noch heftig in Entwicklung, aber imho etwas performanter als ZT (da auf Wireguard basierend) und hat einige sehr sehr feine Funktionen, die das Leben erleichtern, wie DNS Namen für die VPN Partner, Zugriffsrechte, mehrere Nutzer für das Controller Webinterface u.v.m.


    Zerotier hat bereits mobile Clients für Android und iOS, bei Netbird existieren diese noch nicht, sollen aber in wenigen Monaten kommen.

    RS Ostern L OST22 (~RS "3000" G9.5) (8C,24GB,960GB) | RS Cyber Quack (1C,2GB,40GB)

    Zitat von frank_m

    Aber wie sind die Server untereinander verbunden? Wie sieht die IP-Verteilung bei dir exakt aus, also auf dem Server und im Heimnetz und welches Transport-Netz nutzt Tailscale?

    Das ist für mich "Tailscale-Magic". Ich habe keine Ahnung wie das funktioniert, wurde irgendwo für die non-dualstack Anschlüsse empfohlen und funktioniert out-of-the-box. Jedes Gerät loggt sich auf Tailscale ein und bekommt eine interne, feste IP zugewiesen.


    Mein Heimnetz ist ne Fritzbox, an der hängen der file- und krimskramsserver und ein odroid mit Home Assistant. Alles normale standard Fritz Adressen 192.168.178.xxx. Auf dem Server läuft tailscale. Ich kann auf jedem via Tailscale registrierten Gerät jedes andere unter seiner 100er IP adressieren. Das klappt ohne jedes Problem. Ja, die Sachen liegen auf nem Tailscale Server aber damit kann ich leben. Ich kann also zB auf meinem Android Phone ohne Probleme auf die Samba Freigabe des Servers unter seiner 100er Adresse zugreifen.

    Nun möchte ich, dass bei Zugriff auf den Vserver unter port xyz dieser via der 100er Adresse auf einen port dort geroutet wird. Die Verbindung klappt einwandfrei, kann zB vom Vserver ebenfalls aufs Samba zu Hause zugreifen.


    ipv6 habe ich mal versucht, bin aber irgendwann frustriert gescheitert. Solche Adressen meiner Frau zu geben wäre auch ehm...kein Zuckerschlecken :)


    So sieht das bei Tailscale aus:


    Clipboard01.jpg

    Cool, danke. ZT schaue ich mir mal an. Clients für alle OSse ist Pflicht, da die Frau iOS, ich Android, Win und Linux nutzen. Tailscale würde auch alles lösen, wenn in der Free Variante mehr als ein User erlaubt wären. Nodes kann das für meine Bedürfnisse genug (20).

    Zitat von docromano

    Cool, danke. ZT schaue ich mir mal an.

    Da geht DNS übrigens auch, ist aber nicht integriert und durchaus etwas kompliziert. Da musst Du also eher mit IPs arbeiten, wenn Du Dir die Arbeit nicht machen willst, oder Du machst es wie ich und verwendest schlicht eine öffentliche Domain mit DNS Server für private ZT IPs (also meinserver.meineztdomain.de -> private ZT IP). Der DNS Name geht dann halt nur bei Mitgliedern im ZT Netz, aber er geht.

    RS Ostern L OST22 (~RS "3000" G9.5) (8C,24GB,960GB) | RS Cyber Quack (1C,2GB,40GB)

    Einmal editiert, zuletzt von TBT ()

    Zitat von TBT

    Da geht DNS übrigens auch, ist aber nicht integriert und durchaus etwas kompliziert. Da musst Du also eher mit IPs arbeiten, wenn Du Dir die Arbeit nicht machen willst, oder Du machst es wie ich und verwendest schlicht eine öffentliche Domain mit DNS Server für private ZT IPs (also meinserver.meineztdomain.de -> private ZT IP). Der DNS Name geht dann halt nur bei Mitgliedern im ZT Netz, aber er geht.

    Ich habs direkt ans Laufen bekommen und fuchse mich da jetzt mal rein...danke dir !

    Ich schätze ZT sehr, es macht so vieles so einfach, den Client kann man überall mit reinpacken, auch in Docker Container etc.


    Wenn Du den Controller selbst hosten willst gibt es 2 Lösungen:

    GitHub - key-networks/ztncui: ZeroTier network controller UI

    GitHub - dec0dOS/zero-ui: ZeroUI - ZeroTier Controller Web UI - is a web user interface for a self-hosted ZeroTier network controller.


    Ich kann nur empfehlen, Dir auch Netbird anzusehen, ich finde es eigentlich cooler und performanter. Da fehlt noch ein bisschen Schliff, aber das Konzept ist in vielen Bereichen sehr gut. Klar, iOS und Android Clients müssen her.

    RS Ostern L OST22 (~RS "3000" G9.5) (8C,24GB,960GB) | RS Cyber Quack (1C,2GB,40GB)

    Einmal editiert, zuletzt von TBT ()

    Netbird sieht auch spannend aus, aber ohne iOS derzeit nichts für mich. Spiele jetzt eine Weile mit ZT, ist relativ lahm. Habe einen Kameraserver laufen, der drei Streams gleichzeitig anzeigt. Via Tailscale kein Problem, kontaktiere ich via ZT unsagbar langsam. Werden die Daten nicht direkt geschickt sondern irgendwie über andere Systeme geroutet ?


    /edit


    reboot des Servers hat das erstmal behoben, lief aber vorher wochenlang ohne solche Mätzchen...beobachte das mal weiter :)

    Zitat von docromano

    Ich kann auf jedem via Tailscale registrierten Gerät jedes andere unter seiner 100er IP adressieren.

    Das würde ja bedeuten, dass sich bei Tailscale prinzipiell alle Clients untereinander erreichen können - auch die anderer Nutzer. Wie verhindern sie das denn, so dass nur ein Nutzer Zugriff hat? Und was, wenn da mal was schief geht? Hast du mal einen Portscan gemacht, was du sonst noch so an Geräten oder Diensten siehst auf anderen 100er Adressen?


    Zitat von docromano

    Nun möchte ich, dass bei Zugriff auf den Vserver unter port xyz dieser via der 100er Adresse auf einen port dort geroutet wird.

    D.h., du möchtest auf die öffentliche IP des VServers zugreifen und er leitet es über Tailscale weiter an deinen internen Server weiterleiten. Wenn die 100er Adressen wirklich erreichbar sind, dann sollte das gehen. Im Grunde brauchst du 3 Sachen:

    - IP Forwarding muss an sein (via sysctl)

    - Forwarding Regel für iptables

    - NAT Regel für iptables


    Die iptables Regeln können in etwa so aussehen (wenn dein Ethernetinterface auf dem VServer eth0 heißt und der Port 8080):

    Code
    iptables -A FORWARD -i eth0 -p tcp --dport 8080 -d 100.x.y.z -j ACCEPT
iptables -t nat -A PREROUTING -i eth0 -d ÖFFENTLICHE_IP -p tcp --dport 8080 -j DNAT --to-destination 100.x.y.z:8080

    Die Regeln müssen natürlich an der richtigen Stelle in der Chain eingefügt werden.


    Zitat von docromano

    ipv6 habe ich mal versucht, bin aber irgendwann frustriert gescheitert. Solche Adressen meiner Frau zu geben wäre auch ehm...kein Zuckerschlecken

    Dafür hat man DNS erfunden. Da der Zugriff von außen erfolgt, musst du eh mit DNS arbeiten. Das ist mit Sicherheit einfacher, als die iptables Regeln, und es ist erheblich sicherer und performanter, als TailScale, Zerotier und wie sie sonst noch so heißen.

    Zitat von frank_m

    Das würde ja bedeuten, dass sich bei Tailscale prinzipiell alle Clients untereinander erreichen können - auch die anderer Nutzer. Wie verhindern sie das denn, so dass nur ein Nutzer Zugriff hat? Und was, wenn da mal was schief geht? Hast du mal einen Portscan gemacht, was du sonst noch so an Geräten oder Diensten siehst auf anderen 100er Adressen?

    Genau, alle Clients können sich sehen und erreichen. Es gibt aber nur einen Nutzer im free-Paket. Ich muss mich auf jedem Gerät einloggen, gibt ein expiry date. Kann zentral auf der Tailscale Seite clients rauskicken. Für mehrere Nutzer muss man bezahlen. Ich finde es super komfortabel, weil ich von jedem Gerät auf meinen Server komme. Sicherheit geht vermutlich besser, ich kann das nicht beurteilen. Es ist ja immer eine Abwägung Ease-of-use vs Sicherheit. Hier steht was zur Funktionsweise:

    https://tailscale.com/kb/1136/tailnet/


    Zerotier läuft bislang ganz passabel, so bräuchte ich später nur noch das interne Routing vom Server auf den homeassistant, das sollte ja einfach sein. Danke auf jeden Fall für die Vorschläge zu iptables.


    Mit DNS mache ich es, wenn das alles scheitert. Da habe ich schonmal viel Frust drin investiert...

    Zitat von docromano

    Genau, alle Clients können sich sehen und erreichen.

    Ich meine, wirklich ALLE Clients. Auch die anderer Tailscale Nutzer, mit denen du gar nichts zu tun hast. Das ist das große Risiko bei dieser Art der Adressverteilung, denn du wirst kaum Interesse daran haben, dass wildfremde Leute auf dein NAS zugreifen können. Ist aber bei dieser Adressverteilung nicht ausgeschlossen.


    Da du je eh schon einen VServer hast, wäre es ebenfalls ein Leichtes, das mit Wireguard selber zu machen. Schön sicher und auch für mehrere Nutzer kostenlos. Und garantiert performanter, als die anderen Lösungen.


    Zitat von docromano

    Mit DNS mache ich es, wenn das alles scheitert. Da habe ich schonmal viel Frust drin investiert...

    Dann musst du aber grundlegend falsch an das Thema gegangen sein. Das ist eigentlich super einfach und bietet je nach Einsatzfall die mit Abstand beste Lösung. Klar sollte man NAS Dienste nicht einfach so ins Internet hängen, aber wenn eh schon ein VPN drauf läuft, ist das geschenkt.

    Zitat von frank_m

    Ich meine, wirklich ALLE Clients. Auch die anderer Tailscale Nutzer, mit denen du gar nichts zu tun hast. Das ist das große Risiko bei dieser Art der Adressverteilung, denn du wirst kaum Interesse daran haben, dass wildfremde Leute auf dein NAS zugreifen können. Ist aber bei dieser Adressverteilung nicht ausgeschlossen

    Was ist denn das für ein Quatsch! Natürlich "sehen" sich in einem Tailscale (oder ZT oder Netbird) Netzwerk nur entsprechend konfigurierte und "approved" Geräte ( Device approval · Tailscale ), nicht die aller Kunden.


    Mit

    Zitat

    Ich kann auf jedem via Tailscale registrierten Gerät jedes andere unter seiner 100er IP adressieren.

    meinte er natürlich NUR SEINE EIGENEN Geräte.

    RS Ostern L OST22 (~RS "3000" G9.5) (8C,24GB,960GB) | RS Cyber Quack (1C,2GB,40GB)

    Einmal editiert, zuletzt von TBT ()

    Zitat von TBT

    Was ist denn das für ein Quatsch! Natürlich "sehen" sich in einem Tailscale (oder ZT oder Netbird) Netzwerk nur entsprechend konfigurierte und "approved" Geräte ( Device approval · Tailscale ), nicht die aller Kunden.

    Das hoffst du. Aber die Auswahl der Adressen erhöht das Risiko, dass es (irrtümlich?) schiefgeht. Bei einer anderen Wahl der Kunden-Adressen könnte man das bereits prinzipiell unterbinden, hier ist man drauf angewiesen, dass die Software, die den Fence realisiert, auch ordnungsgemäß funktioniert, konfiguriert ist, und keine Lücken hat. Da hätte man das System direkt in der Architektur sicherer auslegen können. Deshalb oben schon mein Hinweis: Wenn da wirklich 100er Adressen benutzt werden, wäre das für mich schon ein Grund, auszusteigen.

    Zitat von frank_m

    Das hoffst du. Aber die Auswahl der Adressen erhöht das Risiko, dass es (irrtümlich?) schiefgeht. Bei einer anderen Wahl der Kunden-Adressen könnte man das bereits prinzipiell unterbinden, hier ist man drauf angewiesen, dass die Software, die den Fence realisiert, auch ordnungsgemäß funktioniert, konfiguriert ist, und keine Lücken hat. Da hätte man das System direkt in der Architektur sicherer auslegen können. Deshalb oben schon mein Hinweis: Wenn da wirklich 100er Adressen benutzt werden, wäre das für mich schon ein Grund, auszusteigen.

    Aufgrund welcher technischen Grundlage stellst Du die Verwendung des 100.x.x.x. Netzes in Frage? Wieso sollte die Auswahl eines IP Netzwerkes hier irgend etwas beeinflussen? Welche Kundenadressen sollten denn sonst gewählt werden?

    Wieso sollte etwas "irrtümlich" schief gehen? Das ist das BUSINESS MODELL der Anbieter, dass das korrekt und sicher funktioniert.


    Wieso Tailscale das verwendet wird hier erklärt, es kommt damit weder den privaten noch den öffentlichen Adressranges in die Quere.


    Ein privates Netzwerk ist ein "Tailnet". Was das ist, wird hier erklärt.

    Den Absatz

    Zitat

    Each device gets a private Tailscale IP address in the CGNAT range and every device can talk directly to every other device, wherever they are on the internet.

    mag man evtl falsch verstehen in Deine Richtung. Gemeint ist damit aber, dass jedes Gerät mit jedem anderen IM GLEICHEN TAILNET reden kann, nicht darüber hinaus.

    Zudem wird mit

    Zitat

    Your tailnet is your space. The internet cannot reach it.

    sonnenklar erklärt, was nicht geht.


    Tailscale wie Zerotier und andere sind controllerbasierte VPNs, die die lästige dezentrale Konfiguration der Clients zentralisiert und damit die Handhabung extrem vereinfacht. Quasi jedes Angebot hat logischerweise Einstellungen die beschränken, welche Clients in welchem Netz sind. Bei manchen Angeboten kann man darüber noch hinaus mit ACLs einstellen, welcher Client ggüber anderen Clients was darf.

    RS Ostern L OST22 (~RS "3000" G9.5) (8C,24GB,960GB) | RS Cyber Quack (1C,2GB,40GB)

    Einmal editiert, zuletzt von TBT ()

    Ich weiß, wie Tailscale und drumherum funktionieren. Aber zum Beispiel:

    Zitat

    Your tailnet is your space. The internet cannot reach it.

    Das Internet nicht, aber was ist mit anderen Tailnets? Wie gesagt: Ich bin überzeugt davon, dass sie das verhindern wollen, aber können sie auch? Was ist mit Fehlern, Hacker-Attacken etc.?

    Offensichtlich ist es ja so, dass alle tailscale Clients weltweit mit einer unique Adresse aus dem 100er CGNAT Bereich versorgt werden. D.h. prinzipiell liegen sie alle im gleichen LAN und werden nur durch die Fence in Tailnets aufgeteilt. Was ist, wenn einer einen Weg findet, die Fence zu durchbrechen? Dann sind plötzlich alle virtuellen Nodes untereinander erreichbar. Und genau das hätte man durch eine andere Wahl des IP-Bereichs fürs Transportnetz verhindern können. Um Kollisionen zu vermeiden hätte man es einstellbar machen können, denn heute kann es mit anderen CGNAT Zugängen ja auch Konflikte geben, das ist also kein Argument.


    Ein Sicherheitsrisiko bei Design. Für mich ein NoGo.

    Zitat von frank_m

    D.h. prinzipiell liegen sie alle im gleichen LAN und werden nur durch die Fence in Tailnets aufgeteilt.

    So funktioniert der Layer 2 bzw. Broadcast Domains aber nicht.

    Unabhängig von deren IP Adressen kann L2 komplett anders aussehen - der VPN kann sogar komplett auf L2 verzichten (siehe Wireguard).

    Unabhängig davon, ob das für dich ein NoGo ist, solltest du dich mit den Grundlagen von LAN bzw. L2 beschäftigen.



    Zitat von frank_m

    Was ist, wenn einer einen Weg findet, die Fence zu durchbrechen?

    Das ist halt das gleiche Argument wie: was ist, wenn Hacker meine Firewall hacken.

    Das macht jene Firewall nicht per Design zu einem Sicherheitsrisiko.


    Und jetzt erzähl mir nicht, dass das bei OpenVPN oder Wireguard in irgendeiner Form besser ist... auch hier können "Fehler" oder "Hacker-Angriffe" passieren.


    Was ich allerdings kritikwürdig finde: die Verwendung von IP Adressen außerhalb des RFC1918.

    Bei fehlendem VPN Zugang können hier Datenpakete mit vermeindlich sensiblen Informationen ins Internet gelangen.

    Diesem Fakt sollte man sich bewusst sein.


    Ähnlich wie der Verwendung des 25.0.0.0/8 Netz. Der Bereich gehört dem britischen Geheimdienst.

    Zitat von H6G

    So funktioniert der Layer 2 bzw. Broadcast Domains aber nicht.

    Ja? Wie denn dann? Was daran hat Einfluss auf das hier diskutierte Problem?

    Zitat von H6G

    Unabhängig von deren IP Adressen kann L2 komplett anders aussehen - der VPN kann sogar komplett auf L2 verzichten (siehe Wireguard).

    Ja. Aber nochmal: Was hat das mit dem Problem zu tun?


    Zitat von H6G

    Unabhängig davon, ob das für dich ein NoGo ist, solltest du dich mit den Grundlagen von LAN bzw. L2 beschäftigen.

    Mach ich seit ungefähr 25 Jahren. Aber irgendwie fehlt mir gerade der Ansatz, auf den du hinaus willst.


    Zitat von H6G

    Das ist halt das gleiche Argument wie: was ist, wenn Hacker meine Firewall hacken.

    Das macht jene Firewall nicht per Design zu einem Sicherheitsrisiko.

    Neben der Firewall versuche ich das System dahinter so zu designen, dass auch im Falle einer gehackten Firewall der Schaden so klein wie möglich bleibt. Genau das wurde hier nicht getan.


    Zitat von H6G

    Und jetzt erzähl mir nicht, dass das bei OpenVPN oder Wireguard in irgendeiner Form besser ist... auch hier können "Fehler" oder "Hacker-Angriffe" passieren.

    Mit Wireguard und OpenVPN kann man natürlich die gleichen Fehler machen, wie Tailscale sie gemacht hat. Anstatt für viele Kunden ein einziges großes Netz zu designen, dass ich dann wieder aufwendig aufsplitten muss, würde ich viele kleine unabhängige Netze aufbauen, die dann auch jeder in seinem Sinne konfigurieren kann.

    Zitat von frank_m

    Mach ich seit ungefähr 25 Jahren. Aber irgendwie fehlt mir gerade der Ansatz, auf den du hinaus willst.

    Was du postest, ist einfach nur Bullshit.


    Du behauptest, jeder könne ein Tailscale VPN von außen erreichen - das ist aber reiner Blödsinn und zeigt, dass du nicht weißt, wovon du redest.

    Wenn ich jetzt derjenige sein soll, der dir Dunning Kruger erklärt, dann aber hallo.



    Zitat von frank_m

    Neben der Firewall versuche ich das System dahinter so zu designen, dass auch im Falle einer gehackten Firewall der Schaden so klein wie möglich bleibt.

    Wenn eine Firewall versagt, ist die letzte Bastion dahinter Netzsegmentierung - dafür brauchst du Hardware (lies: Switche). Dazwischen könnte man noch 802.1x / RADIUS schalten. Wie würdest du so ein System denn gestalten, dass der Schaden bei gehackter Firewall möglichst gering ist?



    Zitat von frank_m

    Genau das wurde hier nicht getan.

    Wie ist denn der VPN Service von Tailscale gestaltet, was genau fehlen dir denn da für Maßnahmen?



    Zitat von frank_m

    würde ich viele kleine unabhängige Netze aufbauen, die dann auch jeder in seinem Sinne konfigurieren kann.

    Wer sagt denn, dass das bei Tailscale nicht der Fall ist?

    Nochmal: die verwendeten IP Adressen für das Tunnel-innere haben nichts mit dem Tunnel-äußeren zu tun und sagen absolut nichts darüber aus, wie die VPN Topologie aussieht. Nur weil ich in meinem VPN Netz die Adressen 100.0.0.0/24 verwende, heißt das noch lange nicht, dass Hans Wurst in seinem VPN mit der Adresse 100.0.0.0/24 sich im gleichen VPN Netz befindet.