Richtiger Eintrag iptables für Routing mit Tailscale

  • 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.

  • Ich würde eben nicht alle Kundenanschlüsse in ein großes 100.x.y.z/10 Netz verfrachten.


    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.

    Laut How Tailscale assigns IP addresses · Tailscale scheint jedes Gerät sein eigenes IP Netz maßgeschneidert zu bekommen, das Beispiel 100.108.38.123/32 auf der verlinkten Seite lässt genau eine einzige IP Adresse zu: 100.108.38.123.


    Ein Tailnet ist eine abgeschlossene Einheit, die nur Clients miteinander kommunizieren lässt, die im gleichen Tailnet sind. Die Verbindungen zwischen den Geräten sind controllervermittelte Mesh Wireguard Tunnel, die Clients haben private Encrytion Keys, die nötig sind, damit die Partner miteinander reden können. Hat eine "benachbarte" IP, die nicht im gleichen Tailnet ist, deswegen diese Keys nicht, kann sie nichts machen. In einem Tailnet kann die Kommunikation von Clients untereinander noch weiter durch ACLs ( Terminology and concepts · Tailscale ) eingeschränkt werden.


    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.

    Das korrekte Funktionieren dieses Stacks ist die Geschäftsgrundlage von Tailscale. Wieso zweifelst Du generell an, dass die Firma ihr Kerngeschäft drauf hat? Willst Du damit sagen, dass Wireguard unzuverlässig ist? 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? Was wäre der Unterschied zwischen dem 100.X.X.X Bereich und den privaten Adressbereichen?


    Ob es nun sinnvoll ist, den CG-NAT Adressbereich zu verwenden, oder die komplett privaten Adressbereiche, darüber können wir gerne reden. Aber alles andere ist doch Käse.

    Ich würde eben nicht alle Kundenanschlüsse in ein großes 100.x.y.z/10 Netz verfrachten.

    Sondern?

    RS Fast Rabbit OST21 (~RS 8000 G9) | RS Ostern L OST22 (~RS "3000" G9.5)

    Like 2
  • 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.

  • 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.


    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.

    Dude, dann darfst Du keinerlei Software, ja noch nicht einmal einen Computer verwenden, denn all das könnte Fehler haben (hats ja auch). Die Logik ist doch in diesem Zusammenhang komplett sinnfrei und kann gegen jegliche Software, im Prinzip gegen ALLES verwendet werden. Als Softwareentwickler solltest Du es besser wissen. Und Softwareentwickler müssen nicht unbedingt Ahnung von Networking haben. QED.

    Nein, aber die Konfiguration kann fehlerhaft 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/newsticke…lich-mitsurft-153559.html

    Exakt davon rede ich.

    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?


    Etwas noch älteres und unwahrscheinlicheres hast Du nicht mehr gefunden? Was hat denn bitte das mit Tailscales Technik zu tun? Exakt GAR NICHTS.


    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.

    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? Alles andere was ich geschrieben habe, hast Du übrigens einfach ignoriert.


    Nebenbei ist es nicht "ein großes privates Netz", sondern viele viele kleine, individuelle OHNE überlappende Adressen und mit keybasiertem Routing. Du solltest Dich dringend mit der Funktionsweise von Wireguard auseinandersetzen, insbesondere mit dessen https://www.wireguard.com/#cryptokey-routing .

    RS Fast Rabbit OST21 (~RS 8000 G9) | RS Ostern L OST22 (~RS "3000" G9.5)

    Like 2
  • 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/newsticke…lich-mitsurft-153559.html

    Exakt davon rede ich.

    Genau so funktioniert Layer 2 - wenn ich mein Gerät mit der L2 Infrastruktur des Providers verbinde, bin ich für andere Teilnehmer der L2 Domain sichtbar. So funktioniert halt Internet, dafür habe ich ein L3 Gerät (Firewall)...


    Dir sagen jetzt zwei Leute, dass du hier falsche Infos verbreitest...

  • 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.

  • Dass sie nur 1x vergeben wird ist ja das Problem. Denn nur dadurch wird es unsicherer.

    Nein!



    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.

    Warum muss eigentlich derjenige, der eine Aussage widerlegt, Beweis erbringen?

    Warum beweist du deine Aussage nicht selbst, sondern beziehst diese auf deine Tätigkeit als Softwareentwickler (Argumentum ad hominem)


    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.

    Ist ja nicht so, als wäre diese Disziplin physikalisch sauber definiert, eher philosophisch.

    Aber deswegen ins Esoterische abdriften?



    Natürlich. Wenn die Argumente ausgehen, wird es persönlich.

    Was ist denn daran persönlich? Alles hier nimmt Bezug auf das, was du schreibst.

    Und was TBT schreibt, ist richtig: Softwareentwickler und Netzwerktechniker sind zwei unterschiedliche Berufe und Disziplinen.


    Das wäre in etwa so, als würde ich in einem Forum behaupten, ich kenne mich mit Weinanbau aus, weil ich die letzten 25 Jahre Kartoffeln angepflanzt habe.

    Hat zwar beides mit Landwirtschaft zu tun aber da hören die Gemeinsamkeiten auch auf.

    Gibt ja nicht umsonst die unterschiedlichen Ausbildungsberufe des Fachinformatikers für Anwendungsentwicklung, Fachinformatiker für Systemintegration und den IT Systemelektroniker.


    Bleibt nur noch die Frage, in wie weit das jetzt dem TE weiterhilft bei seinem Problem mit Tailscale.

  • 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.

    Quote

    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.

  • 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.

    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?


    Wo ist denn der Schaden, wenn es kein Hacker wäre, sondern wirklich ein Versehen?

    Hast du für deine internen Dienste keine Authentifizierung oder gar Verschlüsselung? Bei mir jedenfalls ist maximal der Drucker sperrangelweit offen.

  • 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.

  • Natürlich. Wenn die Argumente ausgehen, wird es persönlich. Das hatten wir heute schon mal.

    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. Als Begründung kommen Allgemeinsätze (alle Software hat Fehler), Du belegst Deine Aussagen nicht, ignorierst Belege und Links die Dir gebracht werden und pickst Dir Aussagen selektiv raus. Da kann man schon mal fuchsig werden...


    Dass sie nur 1x vergeben wird ist ja das Problem. Denn nur dadurch wird es unsicherer.

    Beispiel für Allgemeinsatz ohne jeglichen Beleg oder technische Grundlage.


    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.

    Du stellst die Behauptung auf, dass Tailscale inhärent unsicher ist. Diesen "Beweis" musst also erst mal Du führen. Wir müssen hier gar nichts beweisen. Ich habe Dich bereits auf die Zertifikatsarchitektur und Funktionsweise von Wireguard hingewiesen und Du hast sie ignoriert.


    Nur um das hier auch mal einzustreuen: ich nutze Tailscale nicht, da mir die kostenfreie Variante zu restriktiv ist, sondern verwende Zerotier und Netbird, die vom Prinzip her aber Ähnlichkeiten haben (controllerbasierte VPN Lösungen).

    RS Fast Rabbit OST21 (~RS 8000 G9) | RS Ostern L OST22 (~RS "3000" G9.5)

    Edited 2 times, last by TBT ().

    Like 1
  • 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?

  • 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").

    ...

    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).

    Du kennst nicht die Technologie von Tailscale, sondern Du nimmst an, dass sie den von Dir verwendeten Techniken (die Du nicht näher spezifiziert hast) ähnlich sind. Das kann sein, oder halt auch nicht. Können wir von außen natürlich nicht nachvollziehen.


    Du beschreibst auch den wesentlichen Unterschied, dass Ihr Euch nicht auf eine Cloud verlassen könnt - Tailscale kann das halt schon, das ist ja der Witz an einem controllerbasierten VPN. Da ist der Controller die einzige Autorität für die IP Vergabe und die Berechtigungen. Bei Euch scheint das ein verteilter Ansatz zu sein, ergo schon mal keine ähnliche Architektur.


    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.

    Ich seh noch nichts überzeugendes. Du hast Deine - andere - Netzwerkanwendung geschildert und dann gemeint, dass Tailscale das ja so ähnlich machen müsste. Das ist alles.


    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.

    True. Aber wieso sollte dieser Sachverhalt generell gegen Tailscale sprechen?


    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?

    Und wieso stellst Du den Service unter Generalverdacht, dass genau das "aufgrund der IP Zuordnung im 100.X.X.X Netz" passieren müsse? 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.

    RS Fast Rabbit OST21 (~RS 8000 G9) | RS Ostern L OST22 (~RS "3000" G9.5)

    Like 1
  • 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.

  • 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.

    Und WARUM sollte das so sein? Ich habe noch nicht ein sinnvolles technisches Argument gehört aber schon viele Begründungen geliefert wieso das nicht so ist. Stell doch die ständig angesprochenen aber nie belegten Schwachpunkte des verwandten Systems der Adressverteilung dar.

    Wie ich schon mal sagte, offenbar habt ihr eine vollkommen falsche Auffassung von der Problemstellung.

    Du hast das Problem niemals technisch begründet und nachvollziehbar dargestellt. Nur immer mit Allgemeinpositionen im Nebel rumgewabert.

    RS Fast Rabbit OST21 (~RS 8000 G9) | RS Ostern L OST22 (~RS "3000" G9.5)

    Like 1
  • 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.

  • Die

    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.

    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.


    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.


    Die IP Ebene ist doch bei verschlüsselten Wireguard Tunneln nahezu egal. Hat man die Schlüssel nicht, kommt man nicht rein, egal ob man nun die IP sieht oder nicht.

    Siehe How Tailscale works · Tailscale .

    Zitate:

    Quote

    the coordination server (key drop box) protects nodes by giving each node the public keys of only the nodes that are supposed to connect to it. Other Internet computers are unable to even request a connection, because without the right public key in the list, their encrypted packets cannot be decoded. It’s like the unauthorized machines don’t even exist. This is a very powerful protection model; it prevents virtually any kind of protocol-level attack. As a result, Tailscale is especially good at protecting legacy, non-web based services that are no longer maintained or receiving updates.

    Man könnte sogar sagen, dass Services wie TS die Sicherheit erhöhen, denn es erstellt

    Quote

    point-to-point fully encrypted connections (no unencrypted traffic carried over any LAN)

    d.h. TS ist sogar sicherer, als wenn sich Client und Server im LAN unterhalten, bzw. kann sogar die Sicherheit im LAN erhöhen.

    RS Fast Rabbit OST21 (~RS 8000 G9) | RS Ostern L OST22 (~RS "3000" G9.5)

    Like 1
  • 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.

  • 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.

  • Ok, also immer noch Allgemeinpositionen und "Du bist zu dumm um den riesigen Fehler zu sehen" Kommentare. Kein einziger echter technischer Hinweis in diesem ganzen Thread.


    Ich hab schon lange keine Lust mehr auf eine solche Gummidiskussion, aber habe immer noch gehofft, dass da mal was substantielles kommt. Aber ist nicht.


    Ich bin raus.

    RS Fast Rabbit OST21 (~RS 8000 G9) | RS Ostern L OST22 (~RS "3000" G9.5)