Zudem unterstellst Du Tailscale ständig, "bei Fehlern wegen der Netzwerkwahl Daten zu leaken". Als Softwareentwickler kannst Du Dir ja gerne https://github.com/tailscale/tailscale (ist open source) ansehen und uns Fehler aufzeigen
Kurz als Nachtrag dazu: Der Fehler, alle Kunden mit einer unique Adresse aus einem großen Pool zu versorgen, ist ein Fehler im Design, nicht in der Implementierung. Ein Codereview hilft da nicht.
Die beiden Posts sind eben solche Allgemeinsätze ohne wirklich Nennung des Problems mit dem 100 Netz oder wie man es, Deiner Meinung nach, hätte besser machen sollen (einer Lösung) oder welche Netzwerkbereiche mit welcher Begründung man statt dessen hätte verwenden sollen.
Wenn wir jetzt auch noch Grundlagen IP-Networking durchgehen müssen, wird es sehr lange dauern. Es geht ums Prinzip, die technischen Details kann man sich herleiten. Wenn du aus der Beschreibung nicht aufs Problem zurückschließen kannst oder es nicht abstrahiert bekommst, kann ich dir auch nicht helfen. Und die Verbesserung hab ich auch bereits beschrieben, ich spare mir den erneuten Hinweis aufs Lesen der Beiträge.
Die IP Ebene ist doch bei verschlüsselten Wireguard Tunneln nahezu egal.
Nein, eine funktionierende IP-Konfiguration und Routen braucht man auch da noch. Und da ist eben die Frage, ob man dafür was tun muss, oder ob es sich von allein ergibt.
Ansonsten vergeht mir so langsam die Lust, immer und immer wieder den gleichen Sachverhalt zu erklären. Ich weiß nicht, ob du es nicht verstehen kannst oder nicht willst, ist mir aber auch egal. Wichtig ist, das andere für das Problem sensibilisiert wurden und das in ihre Bewertung einfließen lassen können.
Du hast das Problem niemals technisch begründet und nachvollziehbar dargestellt.
Bereits in #14 und noch mehr in #16 ist das Problem präzise beschrieben. Ich mache zum wiederholten Male darauf aufmerksam, dass ihr Beiträge lesen solltet, bevor ihr Statements abgebt.
Ich habe noch nicht ein sinnvolles technisches Argument gehört aber schon viele Begründungen geliefert wieso das nicht so ist.
Die in den meisten Fällen gar nicht zum Problem passten (auch darauf habe ich wiederholt hingewiesen) oder leicht zu widerlegen waren.
Leute, wo holt ihr eure Phanatasie her?
Und wieso stellst Du den Service unter Generalverdacht, dass genau das "aufgrund der IP Zuordnung im 100.X.X.X Netz" passieren müsse?
Das hab ich nie gesagt. Lies es noch mal nach. Die falsche Zuordnung von Endpunkten passiert nicht aufgrund der IP Verteilung.
Also: Ich habe nie generell was gegen Tailscale gesagt, noch den Service unter Generalverdacht gestellt. Ich habe lediglich gesagt, dass es ein Risiko für eine missbräuchliche oder irrtümliche Verschaltung von Endpunkten gibt, und wenn das passiert (aus was für Gründen auch immer), dann sorgt das System der Adressverteilung für ein erhöhtes Risiko für einen unerwünschten Datenfluss. Nicht mehr und nicht weniger.
Wenn der Controller auch nur einmal Käse macht, dann wird das 1. sofort auffallen und 2. kann Tailscale dann zusperren. So einfach ist das.
Richtig. Die Frage ist, was zwischen dem Käse und Punkt 1 oder 2 passiert. Da können die Kunden noch auf der Suche nach anderen Adressen und Kommunikationspartnern im Netz sein, oder sie tauschen schon fleißig Daten aus, weil die Adressen und Routen das Out of the Box erlauben.
Wie ich schon mal sagte, offenbar habt ihr eine vollkommen falsche Auffassung von der Problemstellung. Ich wiederhole die Empfehlung, die Beiträge aufmerksam zu lesen, zu verstehen und dann eine entsprechende Stellungnahme abzugeben. Ansonsten manövriert man sich wiederholt ins Nirwana. Wenn dann aufgrund der falschen Auffassung auch noch persönliche Vorwürfe formuliert werden, ist das nicht gerade ein Zeichen von Professionalität.
Du posaunst hier im Brustton der Überzeugung raus, dass Tailscale wegen seiner Netzwerkarchitektur gar nicht sicher sein kann ohne sie im Detail zu kennen oder ein Experte dafür zu sein.
Ich denke, dass ich die Technologie von Tailscale recht gut kenne, da wir mit ähnlichen Verfahren arbeiten.
Wir entwickeln industrielle Bedienlösungen für mobile Arbeitsmaschinen. Dazu gehören neben den Bediengeräten (robuste Linux Tablets) auch verschiedene Kommunikationsmodule für die Cloudanbindung und die Infield-Kommunikation. Die Herausforderung ist, dass diese Maschinen dynamisch für einen Auftrag in einem Netz zusammenarbeiten müssen, ohne dass sich die Netze untereinander gegenseitig beeinflussen können (wir nennen das "Fence"). Das Netz existiert immer nur für den einen Auftrag (der zwischen Stunden und Monaten dauern kann) und eine Maschine kann mehrfach am Tag das Netz wechseln. Erschwerend kommt hinzu, dass nicht überall Internetempfang ist und die Geräte auch adhoc ein lokales Netz bilden können müssen. Die Teilnehmer sind dynamisch und können jederzeit das Netz betreten und verlassen. Das ganze natürlich Zeroconf und Plug-and-Play. Es gibt dann Einsatz-Netze, das haben alle Geräte Internetzugang, manchmal aber auch nur einige (die mit Satellitenmodem) und auch mal keiner. Für den Anwender darf das praktisch keinen Unterschied machen, wenn nicht alle Geräte Internetzugang haben, nutzen sie den der anderen mit. Wenn es gar keinen Internetzugang gibt, müssen die Geräte auch ohne Cloud zurechtkommen.
Im Grunde arbeiten wir also wie Tailscale, nur haben wir keine Kunden-Netze, sondern Einsatz-Netze. Wir haben zusätzlich das Problem, dass die Netze jederzeit dynamisch generiert, verändert und terminiert werden und trotzdem gekapselt sein müssen, während die Tailscale Kunden-Netze ja relativ statisch sind. Nicht zuletzt können wir uns nicht auf eine Cloud verlassen für die Netzkonfiguration. Dabei kann natürlich der Internetzugang in einem Einsatz-Netz mal verfügbar sein und mal nicht (in Abhängigkeit der teilnehmenden Maschinen).
Von daher glaube ich, ganz gut beurteilen zu können, mit welchen Herausforderungen Tailscale so zu kämpfen hat und was die Folgen ihrer Addresszusweisung sind.
Du stellst die Behauptung auf, dass Tailscale inhärent unsicher ist. Diesen "Beweis" musst also erst mal Du führen.
Nein, muss ich nicht. Selbst Tailscale hat nie behauptet, dass ihr Netz 100% sicher ist, und auch ihr bestreitet nicht, dass die üblichen IT Risiken hier greifen. Ein Netz ist solange unsicher, bis die Sicherheit bewiesen ist, nicht umgekehrt.
Ich habe Dich bereits auf die Zertifikatsarchitektur und Funktionsweise von Wireguard hingewiesen und Du hast sie ignoriert.
Ich habe sie nicht ignoriert, lese es noch mal nach. Ich habe geantwortet: Nicht die Verfahren von Wireguard sind das Problem, sondern die Konfiguration. Was nützt dir die beste Zertifikatsarchitektur, wenn ein Controller-Algorithmus die Zertifikate an die falschen Endgeräte verteilt?
Also möchtest du mir wirklich verklickern, dass ein Hacker es schafft, zwei VPN miteinander zu verbinden - dann aber daran scheitert eine Verbindung zu anderen Teilnehmern aufzubauen, weil das andere Netz eine andere IP Adresse verwendet?
Wenn es ein Hacker-Angriff ist, dann wird der an die Daten kommen, da werden ihn andere Adressen nicht aufhalten. Aber es gibt ja auch den Fehlerfall, sprich ein Konfigurationsfehler oder sowas, wo die Betroffenen erst mal nicht aktiv versuchen, Daten abzusaugen: Sie nehmen keine Konfigurationsänderung vor, um Datenflüsse zu ermöglichen. Damit es trotzdem klappt, müssen die Voraussetzungen vor allem in Bezug auf die Adressverteilung bereits vom System her geschaffen werden: Oops.
Wo ist denn der Schaden, wenn es kein Hacker wäre, sondern wirklich ein Versehen?
Du kannst mir nicht erzählen, dass du in deinem Heimnetz jeden Server-Dienst, jedes IOT Gerät und jede Kamera mit Verschlüsselung und Zugriffsschutz ausgerüstet hast. Bei vielen dieser Geräte geht das gar nicht.
Ist aber für den vorliegenden Fall auch irrelevant. Es geht wie gesagt ums Prinzip. Und da du ja jetzt von der Kernfrage abweichst und dich mit den Auswirkungen befasst, können wir das ganze jetzt wohl als gegeben ansehen. Die Adressverteilung bei Tailscale erhöht das Risiko für unerwünschte Datenflüsse im Fehlerfall. Vermutlich hat die interne TARA bei Tailscale ergeben, dass sie das Risiko akzeptieren, weil sie durch die Art der Adressverteilung den Kunden einen Mehrwert bieten können oder es ihre internen Kosten senkt (z.B. durch reduzierte Komplexität). Ändert aber nichts an der Tatsache an sich.
Für den Kunden bedeutet das, dass er sich des Risikos bewusst sein sollte, wie bei allen anderen Risiken dieser SDN Anbieter auch. Wie gesagt, es ist denkbar, dass man zu dem Ergebnis kommt, dass das Risiko für einen selber akzeptabel ist. Kein Problem. Man sollte es halt nur auf dem Schirm haben.
Warum muss eigentlich derjenige, der eine Aussage widerlegt, Beweis erbringen?
Ihr habt die Aussage ja nicht widerlegt.
Selbst wenn ich es beweisen würde, kämen wir dabei zu einem Universalbeweis, der andere VPN Technologien nicht ausschließt, wobei wir hier von Eventualitäten reden, deren Eintritt extrem Unwahrscheinlich ist, und irgendwie alle Informationstechnik beträfe, von RAM über Betriebssystemen bis hin zu Compilern.
Womit du zugibst, dass die theoretische Möglichkeit einer unerwünschten Verbindung besteht. Klar, es ist unwahrscheinlich, aber nicht ausgeschlossen.
Und jetzt nehmen wir mal kurz an, es hat zwei Geräte zusammengespült, die nicht zusammengehören. Aber von der irrtümlichen Zusammenschaltung bis zum tatsächlichen unerwünschten Datenfluss ist es ja noch ein großer Schritt. Aber was macht diesen Schritt wahrscheinlicher: wenn die Geräte in zufällig verteilten Netzen aus allen RFC 1918 Bereichen mit möglichen Überschneidungen und Adresskonflikten unterwegs sind, oder wenn alle Geräte systematisch aus einem Pool mit einer eindeutigen IP aus einem Adressbereich versorgt werden? Eben.
QED.
Bleibt nur noch die Frage, in wie weit das jetzt dem TE weiterhilft bei seinem Problem mit Tailscale
Der TE hat seine Lösungen ja schon, die nötigen iptables Regeln und die Hinweise zur Anwendung hab ich ja oben schon beschtieben.
Dude, dann darfst Du keinerlei Software, ja noch nicht einmal einen Computer verwenden, denn all das könnte Fehler haben (hats ja auch)
Eben. Es ist eine Frage der Risikoabwägung. Aber wie du schon sagst: alles hat Fehler. QED.
Und Softwareentwickler müssen nicht unbedingt Ahnung von Networking haben. QED.
Natürlich. Wenn die Argumente ausgehen, wird es persönlich. Das hatten wir heute schon mal.
Einen Fall des Zusammentreffens von Fehlkonfiguration des DSL Anbieters und das direkte Betreiben eines PCs an einem Modem (der PC bekommt die öffentliche IP, MACHT ABSOLUT NIEMAND) aus 2007 kombiniert mit passwortlosen Freigaben vergleichst Du mit controllerbasiertem Wireguard VPN?
Ja. Vom Prinzip gibt es da nämlich keinen Unterschied. Und auch heute gibt es Glasfaseranbieter deren CGNAT Adressen sich uneingeschränkt gegenseitig erreichen können.
Tailscale sagt, dass jede(r) eine "unique" IP Adresse bekommt. Also nehme ich an, dass jede IP aus diesem 100.X.X.X Netz nur genau 1x vergeben wird. Wo ist dabei Dein Problem?
Dass sie nur 1x vergeben wird ist ja das Problem. Denn nur dadurch wird es unsicherer.
Wenn ihr euch so sicher seid, dann beweist mir doch bitte mal, dass es theoretisch unmöglich ist, dass sich zwei Tailscale Geräte unerwünscht erreichen können, sei es aufgrund eines Fehlers, einer Lücke oder warum auch immer.
Reiche im Rahmen der KI-Woche ein Community Tutorial ein.
Also da wäre das mit dem "Ampeln labeln" einfacher gewesen.
Ein Tailnet ist eine abgeschlossene Einheit, die nur Clients miteinander kommunizieren lässt, die im gleichen Tailnet sind.
Das ist mir schon klar. So soll es sein, und im Normalfall wird es auch so sein. Ich rede aber nicht vom Normalfall, ich rede vom Fehlerfall.
Das korrekte Funktionieren dieses Stacks ist die Geschäftsgrundlage von Tailscale. Wieso zweifelst Du generell an, dass die Firma ihr Kerngeschäft drauf hat?
Weil ich selber Softwareentwickler bin. IT Security ist im Grunde eine einzige große Risikoanalyse. Welches Risiko bin ich bereit, in Kauf zu nehmen? Welche Rolle spielen die kommerziellen Aspekte dabei? Wenn ihr mir jetzt erzählen wollt, dass das Risiko in diesem Fall 0 ist, dann kann ich nur sagen: träumt weiter. Ob das Risiko akzeptabel ist? Für euch mag es das sein, und das werfe ich euch auch gar nicht vor. Für mich ist es das nicht.
Willst Du damit sagen, dass Wireguard unzuverlässig ist?
Nein, aber die Konfiguration kann fehlerhaft sein.
Jede(r) hat irgendeine IP Adresse für den öffentlichen Internetzugang. Wieso sollte die Versorgung mit unique IP Adressen "aus einem großen Pool" bei Tailscale etwas anderes sein?
Vielen Dank, sehr gutes Beispiel. Genau da gibt es je mehrere Beispiele, wo Konfigurationsfehler bei den Internetprovidern dazu führten, dass plötzlich Kunden des gleichen Providers die Netzwerkumgebung anderer Kunden sehen konnten.
https://www.heise.de/newsticker/meldung/Wenn-der-Nachbar-heimlich-mitsurft-153559.html
Exakt davon rede ich.
Was wäre der Unterschied zwischen dem 100.X.X.X Bereich und den privaten Adressbereichen?
Wenn es am Ende nur ein großes privates Netz ist, keiner. Wenn es viele kleine mit überlappenden Adressen sind, ist es ein gewaltiger Unterschied, weil es genau den Risikovektor, den ich anspreche, ausschaltet.
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.
Nein, das hab ich nie behauptet, davon habe ich nicht mal im Entferntesten gesprochen. Wenn du das wirklich glaubst, dann lies meine Beiträge noch mal in Ruhe durch, denn das hab ich nie erwähnt.
Ich weiß nicht, warum du plötzlich diesen aggressiven Ton an den Tag legst, aber ich kann dir nur raten, dich mit deinen Analysen diesbezüglich zurückzuhalten. Wie sich jetzt herausstellt, hast du nicht mal im Ansatz verstanden, wovon ich überhaupt rede, folglich hast du dich mit deiner Einschätzung gerade ziemlich ins Nirwana manövriert.
Wenn eine Firewall versagt, ist die letzte Bastion dahinter Netzsegmentierung
Genau. Da sind wir einer Meinung.
Wie würdest du so ein System denn gestalten, dass der Schaden bei gehackter Firewall möglichst gering ist?
Ich würde eben nicht alle Kundenanschlüsse in ein großes 100.x.y.z/10 Netz verfrachten.
Wer sagt denn, dass das bei Tailscale nicht der Fall ist?
Die Beschreibung auf der Tailscale Seite und die Art der Adressverteilung lässt diesen Schluss zu. Offenbar werden alle Kundengeräte nach welchem Algorithmus auch immer aus einem großen 100.x/10 Netz mit Adressen versorgt und dann in kundenspezifischen Gruppen zusammengefasst. Wer sagt, dass das unter allen Umständen reibungslos funktioniert? Dass nicht plötzlich mal Adressen eines anderen Kunden in meinem Netz auftauchen? Vielleicht sogar provoziert? Es ist Software, es ist menschengemacht, es ist damit prinzipiell fehleranfällig. Und erst der Umstand, dass alle Geräte mit Unique Adressen aus einem großen Pool versorgt werden, öffnet diesen Vektor. Grundlagen TARA.
Nochmal: die verwendeten IP Adressen für das Tunnel-innere haben nichts mit dem Tunnel-äußeren zu tun
Das hab ich auch nie behauptet. Ich weiß nicht, wo dieses verquere Verständnis herkommt.
Im Moment macht es keinen Sinn, auf dieser Basis weiterzudiskutieren, da du offenbar nicht über das gleiche Problem redest, wie ich. Wie gesagt, lies dir die Beiträge im Thread noch mal mit ein bisschen Abstand in Ruhe durch. Vielleicht finden wir dann noch ein einheitliches Verständnis.
So funktioniert der Layer 2 bzw. Broadcast Domains aber nicht.
Ja? Wie denn dann? Was daran hat Einfluss auf das hier diskutierte Problem?
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?
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.
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.
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.
Ich weiß, wie Tailscale und drumherum funktionieren. Aber zum Beispiel:
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.
Danke für die Links. Aber diese sagen alle auch nur aus, das man das ndppd braucht.
Nein, die beschreiben auch die Probleme, die es trotz ndppd noch gibt und was alles versucht wurde, um sie zu umgehen. In Kürze: Eine zuverlässige Lösung gibt es nicht, soll es stabil und ohne Paketverluste laufen, brauchst du ein 2. routebares IPv6 Netz.
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.
Du brauchst für die IPv6 Adressen der Container einen Neighbor Discovery Proxy.
Das allein reicht nicht.
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.
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.
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?
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):
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:8080Die Regeln müssen natürlich an der richtigen Stelle in der Chain eingefügt werden.
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.
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).
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.
Wie ist bei euch eigentlich der Download/Upload Speed? Bei mir ist es im durchschnitt ca. 300 Mbit/s (daily average).
Läufst du da in die Limits? Wenn mehr als 60 Minuten am Stück mehr als 1 GBit/s erzeugt wird, wird auf 200 MBit/s gedrosselt, wenn ich mich recht erinnere. Damit könnte man die 300 MBit/s im Tagesmittel gut erklären.
Ich erreiche zu ausgesuchten ookla-Gegenstellen locker über 2 GBit/s. Kommt natürlich immer auf die Gegenstelle an.
