Tailscales Vorstellung eines neuen Internets
(tailscale.com)- Tailscale will eine neue OSI-Schicht 3 schaffen, damit Entwickler nicht in unnötigen, auf Skalierbarkeit ausgerichteten Strukturen gefangen bleiben und sich alle Geräte sicher direkt verbinden können
- Viele Programme brauchen in Wirklichkeit keine Skalierung im großen Maßstab, aber weil Kubernetes, Container-Deployments und Cloud-Log-Sammlung zum Standard geworden sind, seien Entwicklung und Betrieb langsamer geworden
- Der Mangel an IPv4-Adressen, NAT, Firewalls, dynamische IPs und die TLS-Zertifikatsstruktur trennen Clients und Server voneinander und machen zentrale Cloud-Anbieter wie AWS zum Mittelpunkt der Konnektivität
- Tailscale will jedem Gerät Zertifikate, IP-Adressen, DNS-Namen, Ende-zu-Ende-Verschlüsselung und eine Identität geben, damit es sich auch hinter Firewalls sicher verbinden kann und alle Geräte zu Peers werden
- Die HTTP-PUT-basierte Dateiübertragung von Taildrop zeigt, dass sich eine zwischengeschaltete Cloud-Schicht reduzieren lässt, aber damit ein solches App-Ökosystem entsteht, braucht es zuerst ausreichende Verbreitung
Ausgangspunkt der Tailscale-Vision
- Tailscale hat öffentlich bisher nicht oft über eine größere Vision jenseits kurzfristiger Funktionen gesprochen, doch einige Unternehmen kaufen Tailscale nicht nur wegen der heutigen Funktionen, sondern wegen der Konnektivität, die künftig möglich wird
- Der ursprüngliche Antrieb war nicht, ein Networking-Unternehmen zu werden, sondern die schlechter werdende Developer Experience, weil Entwickler versuchten, auch Dinge zu skalieren, die gar nicht skaliert werden müssen
- Die Generation, die sich noch an LAN-Erfahrungen der 1990er erinnert, bildet den Kontext der Tailscale-Gründung, und diese Erfahrung dient als Maßstab für den Vergleich mit der heutigen technischen Komplexität
- Computerleistung, Zugänglichkeit des Programmierens, App Stores, Bezahlsysteme und Grafik sind besser geworden, aber viele alltägliche Aufgaben von Entwicklern, die früher einfach waren, seien heute im Gegenteil schwieriger geworden
Entwicklungs-Overhead durch unnötige Skalierbarkeit
- Moderne Entwickler werden schon vor der ersten Zeile Code darauf trainiert, eine Größenordnung von einer Milliarde Nutzern mitzudenken, und auch bei der Wahl von Algorithmen und Architekturen wird Skalierbarkeit oft priorisiert
- Wenn die Big-O-Notation falsch angewendet wird, wirkt es so, als seien Hash-Tabellen immer schneller als Arrays, doch bei etwa 10 Einträgen kann ein Array schneller und einfacher sein
- Wer eine skalierbare Struktur wählt, kann am Ende ein System bauen, das langsamer und schwerer zu erstellen ist, wenn es in der Praxis gar nicht skaliert werden muss
- Das Beispiel, 500.000 Pageviews pro Monat mit Kubernetes zu bedienen, entspreche nur etwa 0,2 Requests pro Sekunde, und selbst langsame Computer der 1990er hätten Perl- oder Python-Programme in Millisekunden starten und mehr Anfragen als das verarbeiten können
- Lange Builds, Docker-Builds, Uploads in Container-Registries, Deployments von mehreren zehn Sekunden bis Minuten und verspätet eintreffende Logs werden als Overhead zusammengefasst, der aus der Annahme entsteht, dass „alles skalieren muss“
- Tailscale positioniert sich als Werkzeug, um die lange Reihe von Aufgaben, die nicht skaliert werden müssen, wie Dashboards oder Meme-Generatoren, leichter zu bauen, obwohl alle Entwickler dafür einen erheblichen Teil ihrer Zeit aufwenden
Wie das heutige Internet Komplexität vergrößert
- Viel Komplexität gilt nicht als inhärent, sondern als Ergebnis davon, dass auf einfach lösbare Probleme komplizierte Lösungen gesetzt wurden
- Ein Log-System streamt letztlich nur Text von einem Ort zum anderen, und trotzdem kann das Ergebnis erst 5 Minuten später sichtbar werden
- Ein Orchestrierungssystem ist ein Programm, das andere Programme ausführt, etwas, das Unix-Kernel seit Jahrzehnten in Millisekunden erledigen
- Networking ist für moderne Software unverzichtbar, aber das heutige Internet macht viele Probleme schwerer
- Tailscale will nicht einfach oben auf dem bestehenden OSI-Stack eine weitere Schicht hinzufügen, um die Probleme zu verstecken, sondern auf anderen Grundannahmen eine neue OSI-Schicht 3 schaffen
Cloud-Zentralisierung und die Maut auf Konnektivität
- Wer in der Tech-Industrie Maut verlangen kann, zeigt, wo die Engpässe liegen, und bei der heutigen Softwarebereitstellung sieht man AWS in genau dieser Position
- Die Cloud stellt skalierbare Rechenressourcen bereit, doch selbst ein Mittelklasse-MacBook könne auf seiner SSD 10- bis 100-mal mehr Transaktionen pro Sekunde verarbeiten als eine lokale Cloud-Disk
- Dass der eigene Computer nur schwer selbst zum Server werden kann, liegt an Standort und Konnektivität
- Es gibt Firewalls, NAT, dynamische IPs und asymmetrische Netzverbindungen
- Port-Forwarding, statische IPs und redundante Internetanbindungen lassen sich zwar selbst einrichten, erfordern aber viel Arbeit und Fachwissen
- Am Ende zahlt man Hosting-Anbietern mit IP-Adressen und Bandbreite Geld, und ein ernsthaftes Unternehmen wählt dabei meist einen großen Anbieter, dem man den Zugang zur Hardware anvertrauen kann
- Die Logik „Niemand wird dafür entlassen, AWS gekauft zu haben“ wird mit der früheren Redewendung über IBM verknüpft
Gatekeeper, die vom Betriebssystem zu HTTPS gewandert sind
- IBM konnte in der Ära zentralisierter Rechenverarbeitung Maut verlangen, und Microsoft erschütterte diese Ordnung mit verteilter, PC-basierter Datenverarbeitung
- Die heutige Welt aus Cloud und Smartphones sei wieder zentralisiert
- Die Geräte auf Schreibtischen und in Hosentaschen haben nach Maßstäben von vor 20 Jahren Supercomputer-Niveau, werden aber zu unbrauchbaren Ziegeln, wenn AWS ausfällt
- Selbst wenn es mehrere Serverinstanzen und verteilte Konsenssysteme gibt, laufen die meisten davon auf zentralen Cloud-Anbietern
- In den 1990ern entschied das Betriebssystem über Kompatibilität und Verbindung zwischen Programmen, nach dem Web wurde jedoch JavaScript und die Konnektivität über HTTPS wichtiger
- HTTPS besitzt im Kern eine zentralisierte Client-Server-Struktur
- Server haben statische IPs, DNS-Namen, TLS-Zertifikate und offene Ports
- Clients haben diese Dinge in der Regel nicht
- Wenn der Server verschwindet, kann der Client nichts tun
- Wegen Sicherheitsproblemen und IPv4-Knappheit kamen Firewalls und NAT hinzu, wodurch Verbindungen zu einer Einbahnstruktur vom Client zum Server wurden
Tailscales New Internet
- Tailscale baut seit fünf Jahren Produkte als Lösung für dieses Problem
- Jedes Gerät erhält Zertifikate, eine IP-Adresse, einen DNS-Namen, Ende-zu-Ende-Verschlüsselung und eine Identität und kann Firewalls sicher umgehen
- Alle Geräte können statt fester Server- und Client-Rollen zu miteinander verbundenen Peers werden
- Tailscale sieht sich in der Lage, dies ohne zusätzliche Latenz oder zusätzlichen Overhead zu leisten
- Tailscale-Nutzer erleben bereits eine Umgebung, in der mehrere Schichten von Komplexität entfernt wurden und das Internet näher an der Weise funktioniert, wie es ursprünglich erwartet wurde
Vereinfachung am Beispiel Taildrop
- Taildrop ist ein kleines Beispiel für die Struktur, die Tailscale möglich macht
- Wenn Tailscale bereits installiert ist, besteht der Kern von Taildrop aus einem einzigen HTTP PUT
- Die sendende Seite schickt eine HTTP-Anfrage an die empfangende Seite
- Sie kündigt an: „Ich sende eine Datei X“
- Dann überträgt sie die Datei
- Im bisherigen Internet musste man die Datei erst in die Cloud hochladen und dann wieder herunterladen, weil das empfangende Gerät hinter einer Firewall sitzt und weder offene Ports noch eine Identität hat
- Der Umweg über die Cloud erzeugt mehrere zusätzliche Schichten
- Es entstehen Kosten für ausgehenden Netzwerkverkehr, Speicher und Server-CPU
- Man muss entscheiden, wann nicht heruntergeladene Dateien gelöscht werden
- Der Server muss auch dann online bleiben, wenn er nicht genutzt wird
- Mitarbeitende des Cloud-Anbieters könnten theoretisch auf die Datei zugreifen, daher ist Verschlüsselung nötig
- Für die Verschlüsselung braucht es einen Schlüsselaustausch zwischen Sender und Empfänger
- Um dem Empfänger mitzuteilen, dass eine Datei wartet, kann ein plattformspezifisches Push-Benachrichtigungssystem nötig sein
- Weil dieser Kosten-Overhead bei Taildrop entfällt, ist kostenlose Dateiübertragung möglich, was im Kontext des kostenlosen Plans von Tailscale steht
Warum Verbreitung nötig ist
- Taildrop ist ein triviales Beispiel, dient aber als Existenzbeweis für eine Kategorie von Programmen, die mit Tailscale zehnmal einfacher werden könnten
- Mangelnde Konnektivität führt zu Zentralisierung, Zentralisierung erzwingt selbst bei kleinen Programmen Maut, und daraus entstehen langsame, komplexe und schwer zu debuggende Strukturen
- Damit Apps entstehen können, die nur auf Tailscale laufen, müssen genügend Menschen Tailscale nutzen
- Wenn die Verbreitung nicht groß genug ist, entsteht das Henne-Ei-Problem, dass niemand solche Apps baut
- Deshalb investiert Tailscale viel in kostenlose Bereitstellung und zugleich in Enterprise-Funktionen, die Einführungen am Arbeitsplatz und unternehmensweite Rollouts in Fortune-500-Unternehmen erleichtern
Ziel und aktueller Stand
- Das Internet ist für alle da, und obwohl es früher mehrere Internetworks gab, habe sich das vielfältigste und inklusivste Internet durchgesetzt
- Auch das New Internet müsse von Entwicklern zu Hause, an Universitäten, von Unternehmensangestellten und letztlich von allen genutzt werden können
- Derzeit nutzt etwa eine von 30.000 Personen weltweit das New Internet, also Tailscale
- Tailscale erklärt, nicht aufzuhören, bis es von allen genutzt wird
- Mit dem Verweis auf die Zeit, als Microsoft für das Ziel verspottet wurde, auf jedem Schreibtisch einen Computer zu platzieren, und als TCP/IP ein optionales Zusatzfeature war, das man von Dritten kaufen musste, wird betont, dass sich die Technikwelt selbst innerhalb von 30 Jahren schnell verändern kann
1 Kommentare
Hacker-News-Kommentare
Das ewige Problem bei Unternehmen wie Tailscale, Cloudflare und Google ist, dass sie Anreize haben, Probleme weiterbestehen zu lassen, die das Internet eigentlich selbst hätte lösen sollen, etwa einfache sichere End-to-End-Verbindungen.
Was das Internet bräuchte, wäre etwas wie IPv6 mit der von DNSSEC bereitgestellten Public-Key-Infrastruktur und automatischer IPsec-Verschlüsselung. Würde so etwas aber breit kompatibel implementiert, würde Tailscales Geschäft zusammenbrechen.
Am Ende hängt ihr Geschäftsmodell davon ab, dass das Problem weiter existiert.
Erneut gepostet: https://news.ycombinator.com/item?id=38570370
IPv6 kam 1998 heraus, und in den 21 Jahren bis zum Start von Tailscale 2019 wurde das beschriebene Modell trotzdem nicht umgesetzt.
Wer hat es damals verhindert, und wer verhindert es heute? Google, Cloudflare und Tailscale haben reale Probleme gelöst und dafür Geld oder Daten erhalten, die Geld gleichkommen.
Dieser umgekehrte Akzelerationismus nach dem Motto, man müsse das Internet für alle erst schlechter machen, damit eine wirklich gute Lösung entsteht, überzeugt mich nicht.
Nicht Tailscale verhindert so eine Lösung, sondern der enorme Arbeitsaufwand, der dafür nötig ist. Ohne WireGuard gäbe es Tailscale wahrscheinlich auch nicht.
Mit Tailscale entstand außerdem Headscale, und das ist ein weiterer Baustein für genau dieses „Irgendetwas“.
Weit ausgeholt, aber im Kern sitzt Tailscale zwischen den Geräten, während sie einander finden.
Es gibt auch andere Ansätze. Dynamisches DNS, das Geräten mit nur temporären IPs einen dauerhaften Namen gibt, gibt es seit Jahrzehnten, es hat aber keinen besonders guten Ruf.
Möglich wäre auch ein Modell mit mehreren einander bekannten Koordinationsknoten und einer öffentlichen Knotenliste. Selbst wenn die Liste veraltet ist, kann man sich über einen einzigen noch lebenden Knoten verbinden und aktualisieren. So arbeiten Kademlia, die Grundlage des Ethereum-Netzwerks und mancher Filesharing-Systeme.
Auch ein Kompromiss zwischen Suche und Übertragung ist möglich. Peertube findet die per HTTP zu streamende Datei auf einem per normaler Websuche gefundenen Server, während die eigentliche Übertragung dezentral erfolgt, indem aktuelle Zuschauer sich die Blöcke gegenseitig schicken. Dadurch skaliert es gut, selbst wenn ein Video viral geht.
Es ist also gut möglich, das so zu bauen, dass niemand in der Mitte jemandem den Sauerstoffschlauch abklemmen kann.
Alte VPN-Protokolle oder Authentifizierungsverfahren wie RADIUS haben gravierende Sicherheitslücken, die sich aus Kompatibilitätsgründen nur schwer beheben lassen, und selbst sie laufen in viel kleinerem Maßstab als das gesamte Internet.
Dass die Branche das Verhärtungsproblem von TCP dadurch löst, dass sie TCP verwirft und alles über UDP neu implementiert, sagt schon eine Menge.
Den Standortdienst kann man auf Wunsch auch selbst hosten; man ist also nicht gezwungen, den Dienst zu nutzen.
Abgesehen von DNSSEC kommt das dem Geforderten ziemlich nahe.
Dieser Wert verschwindet nicht einfach, nur weil es IPsec gibt.
Es beginnt mit einer sehr langen Beschwerde über zentralisierte Kontrolle zur Abschöpfung von Renten, und diese Beschwerde ist für sich genommen berechtigt.
Dann verliert es sich aber in Nebenfragen wie der, ob Client-Server-Computing überhaupt sinnvoll ist oder ob es die Ursache für Rent-Seeking ist, und landet am Ende bei der Schlussfolgerung: „Morgen wird sich die Welt in Leute mit und ohne Tailscale teilen.“
Es hat etwas von „Der König ist tot, lang lebe der König“.
Es ist klein und einfach genug, dass sogar ich als Nicht-Programmierer es reparieren kann.
Da nicht alle im Internet direkt erreichbare, firewallfreie IPs haben, kann man für Peer-to-Peer auch Client-Server einsetzen.
Vielleicht muss man auf einem Server eines Hosters einen „Supernode“ betreiben, aber wenn er nur als Rendezvous-Server dient, läuft dort kein Traffic durch, also bleiben die Kosten gering.
Unternehmen, die mit „kostenlos“ konkurrieren wollen, machen mich grundsätzlich misstrauisch. Nach dem Motto: Hör auf, freie Software zu nutzen, bezahle lieber uns, und dafür packen wir 100 unnötige Funktionen dazu.
So eine Unternehmensstrategie mag kurzfristig erfolgreich sein, wie bei Slack, aber solche Abos sind einfach nicht mein Ding.
Der Kern ist für mich nicht Client-Server gegen Peer-to-Peer, sondern proprietär gegen nicht-proprietär.
Wenn Tailscale nicht innerhalb von zehn Jahren zu einem Schwergewicht auf Microsoft-Niveau wird, dürfte das schwer positiv aufgenommen werden.
Damals war es ein wirklich großartiges und einfaches Werkzeug, um private Netzwerke zu entwerfen und einzurichten. Dateifreigabe, lokales Gaming-LAN, Entwicklungszusammenarbeit und sogar Medien-Streaming waren damit leicht möglich.
Die Zukunft von Peer-to-Peer ist wohl eher nicht Tailscale, sondern eher eine selbstgehostete Hamachi-Variante, die allgemein Knoten über unterschiedliche NATs und ASNs hinweg verbindet und NAT-Traversal-Techniken, STUN/TURN und Turtle Routing versteht.
Ein Werkzeug, mit dem entfernte Nutzer ohne zentrales VPN-Gateway leicht beitreten können, wäre in modernen Umgebungen eine starke Funktion.
Wir alle sollten Iceberg Articles kennenlernen und anwenden: https://john.kozubik.com/pub/IcebergArticle/tip.html
Ich nutze Tailscale tatsächlich in einem Produktionssystem. Die Server stehen entweder physisch in der Nähe oder an einem anderen kontrollierten Standort, und mehrere Hundert Nutzer, die Hunderte Kilometer entfernt sind, arbeiten alle über Tailscale.
Zwei Dinge muss ich sagen. Tailscale ist erstaunlich und wirklich gut. Dieses System könnte ohne Tailscale nicht existieren, oder wir bräuchten mindestens 10 zusätzliche Teammitglieder für einen 24/7-Betrieb.
Man muss die Erwartungen aber etwas dämpfen. Es ist nicht so gut wie das „Internet“. Die Latenz springt regelmäßig nach oben, Verbindungen brechen gelegentlich ab, und MagicDNS bleibt im wahrsten Sinne des Wortes wie von Zauberhand stehen oder gerät mit dem System in Konflikt.
Bei so vielen Nutzern haben wir fast jedes Problem erlebt, das man erleben kann, und morgen kann schon wieder ein neues auftauchen.
Trotzdem glaube ich an Tailscale und seine Vision. Es ist ein völlig neuer Ansatz, der Hardware-Kontrolle gibt, die Kosten senkt und die Sicherheit erhöht.
Der erste große Produktionsserver war ein 4-Core-Linux-Laptop.
Ich selbst nutze Tailscale auch sehr gern für intern selbstgehostete Systeme, aber für einen öffentlichen Produktionsdienst habe ich es bisher nie in Betracht gezogen, daher würde mich die Konfiguration interessieren.
Ich mag Tailscale, aber dieser Artikel wirkt unheimlich.
Das Internet war erfolgreich, weil es auf Standards aufgebaut war und vollständig frei war.
Bei Tailscale ist WireGuard Open Source, und es gibt auch Headscale, aber hängt die Struktur, in der „jeder eine IP hat“, nicht davon ab, dass Tailscale einen riesigen IP-Adressraum besitzt?
Wenn man entweder auf eine vollständige IPv6-Verbreitung warten oder sich auf zentralisiertes IPv4, Server und proprietäre Dinge verlassen muss, wirkt das etwas heuchlerisch.
Es ist funktional nicht vollständig gleichwertig zu Tailscale, unterstützt aber derzeit die meisten Funktionen und wird täglich verbessert.
Wenn ich mich richtig erinnere, wird einer der Kernentwickler für diese Arbeit von Tailscale bezahlt.
Ich nutze es für meine private selbstgehostete Infrastruktur, und es funktioniert sehr gut. Auch das Einrichten einer benutzerdefinierten URL für den Control-Server war unter Windows und Android relativ einfach.
Ich nutze auch taildrop und stelle Docker-Container im tailnet bereit; Headscale funktioniert gut genug, dass es einen Versuch wert ist.
Der benötigte IP-Raum muss nur so groß wie der größte Wassergraben sein, und man kann immer nur mit einem Wassergraben gleichzeitig verbunden sein.
Ich mag Tailscale, aber dieser Artikel liest sich zu sehr nach Selbstbeweihräucherung.
Es ist ein Mesh-VPN-Produkt mit Zusatzdiensten, und als solches ist es großartig, aber weder eine neue noch eine einzigartige Idee.
Warum sollte diese Lösung ein neues Internet sein und nicht einfach eine andere Alternative?
Ich möchte mich jedenfalls nicht für die gesamte Internet-Infrastruktur auf ein einziges Unternehmen verlassen. Deshalb bleibe ich lieber beim traditionellen Internet, auch wenn es komplexer ist.
Die großen Probleme sind eher gesellschaftlicher als technischer Natur, und neue Technik wird sie nicht lösen.
Nimm soziale Medien als Beispiel: Man kann sich eine Welt vorstellen, in der Facebook/Twitter/TikTok/YouTube/Reddit/HN so reibungslos funktionieren wie BitTorrent.
Die App auf meinem Computer nimmt am „Facebook“-Netzwerk teil, meine Freunde sehen über ihre jeweiligen App-Instanzen, dass ich online bin, und Feed und Pinnwand werden direkt von meinem Gerät bereitgestellt.
Es wäre eine Struktur, in der 2 Personen, 1000 Personen oder mehrere Millionen ohne zentrale Server direkt miteinander kommunizieren.
BitTorrent, Soulseek, Bitcoin und andere Peer-to-Peer-Netzwerke haben bereits gezeigt, dass so etwas möglich ist.
Aber um es so reibungslos zu machen wie den Besuch von facebook.com, tauchen überall technische Probleme auf. Nahtlose Peer-to-Peer-Verbindungen ohne Port-Forwarding, dynamisches DNS oder fortgeschrittenes Wissen über Netzwerk-, Sicherheits- und Systemadministration sind die erste große Hürde.
Was passiert, wenn Nodes offline sind, wie geht man mit Latenz und Last um, wenn man sich mit Tausenden, Hunderttausenden oder Millionen Rechnern verbinden muss, um einen Feed zu holen, wie wird gecacht, wie werden Updates und Benachrichtigungen gepusht, wie kommunizieren sehr alte Nodes miteinander, wo werden Daten gespeichert und wie regelt man Auffindbarkeit und Sicherheit — all das sind technische Probleme.
Die meisten davon lassen sich lösen, aber um die Erfahrung so idiotensicher zu machen wie zentralisierte Dienste, braucht es enormen Aufwand, um jedes einzelne Problem zu lösen.
Auch das Fediverse arbeitet seit über 10 Jahren an einem kleinen Teil dieses Problems, aber selbst heute braucht es noch einen ziemlich fähigen Systemadministrator, um eine Erfahrung zu bieten, die twitter.com ähnelt oder etwas schlechter ist.
Sollte nicht Yggdrasil das neue Internet werden? https://yggdrasil-network.github.io
Wenn nicht, warum ausgerechnet Tailscale und nicht Netbird, Nebula, Netmaker oder andere Konkurrenten?
Der Text ist sehr gut geschrieben, vermittelt aber ein seltsames Gefühl, als stünde etwas wie eine Übernahme, ein Strategiewechsel, eine Ausgründung oder eine Einstellung bevor. Auch „Das ist erst der Anfang“ klingt wie berühmte letzte Worte.
Der Ausgewogenheit halber: Als Tailscale-Nutzer bin ich zufrieden und beeindruckt davon, dass es einfach funktioniert, ohne dass man sich groß darum kümmern muss.
Allerdings sollte man bedenken, dass es trotz guter Funktion noch immer ein Forschungsprojekt ist.
Ich nutze den Tailscale-Dienst wirklich gern und bin dankbar dafür, aber dieser Artikel hat mich nicht angesprochen.
Ich mag inspirierende Sammelreden von CEOs und stimme zu, dass es im Computing absurd viel Entwickler-Reibung und Komplexität gibt, aber Tailscale hat selbst auch Reibung und entwickelt sich überhaupt nicht in eine Richtung, die das Problem im großen Bild löst.
Vor ein paar Wochen habe ich meinen Vater in mein tailnet eingeladen, um per Remote Desktop Probleme an seinem Computer zu beheben. Er hat die Einladung angenommen, und im Web-Interface der TS-Domain war das Gerät zu sehen, aber
pingfunktionierte nicht.Jetzt hasst mein Vater Tailscale, und weil ich vorher gesagt hatte, wie toll es sei, hat auch meine Glaubwürdigkeit gelitten. In seinen Augen war es Zeitverschwendung und ein Ding, „das einfach nicht richtig funktioniert“.
Ziemlich kontraintuitiv. Die Organisationsfunktion ist nicht für diesen Zweck gedacht; stattdessen sollte jede Person ihr eigenes tailnet anlegen und diese dann miteinander verbinden.
Siehe: https://github.com/tailscale/tailscale/issues/10731
pingoder RDP erlaubt sind.Für diesen Einsatzzweck sind eher Tools wie TeamViewer oder AnyDesk geeignet.
Ich denke, der Autor hat das Problem falsch diagnostiziert, und die vorgeschlagene Lösung beseitigt Zentralisierung nicht, sondern verbirgt sie nur.
AWS ist nicht wegen IPv4 oder Rechenzentren teuer, sondern vor allem wegen der Software, der Managed Services und der Fähigkeit, Server schnell hinzuzufügen.
Wenn ein „ernsthaftes Unternehmen“ AWS oder ähnlichen Anbietern kein Geld zahlen will, kann es Rackspace mieten und eigene Server im Colocation-Betrieb betreiben, und viele Unternehmen tun das tatsächlich.
Ich stimme nicht zu, dass Zertifikate Zentralisierung geschaffen hätten. Zertifikate trennen nicht in diejenigen, die sie haben, und diejenigen, die sie nicht haben, und das ist auch nichts, das man mit dem Besitz eines Mainframes vergleichen könnte.
Dass HTTPS de facto Pflicht geworden ist, hat nicht dazu geführt, dass Menschen eigene Domains oder Subdomains haben; das war aus Bequemlichkeit ohnehin schon der Fall.
Als weiterer Punkt der Zentralisierung wird DNS genannt, aber Tailscale vermeidet DNS überhaupt nicht. MagicDNS hängt ebenfalls an der ICANN-Root, und die Tailscale-Control-Plane ebenso.
Wenn man nur eine kostenlose Subdomain braucht, gibt es viele Anbieter dafür.
Wenn man hinter CGNAT sitzt, ist ein tailnet auch nicht wirklich weniger zentralisiert. Denn der Traffic muss über DERP-Server laufen.
Wenn das Traffic-Volumen nicht mehr Gbps, sondern Tbps erreicht, bezweifle ich, dass Tailscale das weiterhin kostenlos anbieten kann.
Ich stimme zu, dass Tailscale und ähnliche Lösungen hilfreich sind für den letzten verbliebenen Anwendungsfall, in dem man auf Computer hinter NAT zugreifen muss, und ich denke auch, dass das zig Millionen Nutzer erreichen könnte.
Aber das reicht nicht aus, um allein schon den Titel neues Internet zu beanspruchen.
Im Artikel selbst wird darauf hingewiesen, dass diese Annahme falsch ist.
Diese Idee ist natürlich nicht neu.
IPv6 sollte allen Ende-zu-Ende-Konnektivität geben, und ursprünglich war IPsec als verpflichtender Bestandteil von IPv6 gedacht, um jedem Internet-Host eine kryptografische Identität zu geben.
Mit IPv6 und WireGuard zusammen bekommt man Privatsphäre, Sicherheit und Performance. Der Nachteil ist die Komplexität der Einrichtung.
Tailscale steht auf den Schultern von Giganten. Dazu gehören IPv4, WireGuard, Samy Kamkars NAT-Punching, OpenSSH und noch mehr.
Der Vorteil ist, dass Tailscale sie kombiniert hat und die Verwaltungsoberfläche größtenteils einfach ist.
Allerdings gilt das über Zertifizierungsstellen Gesagte auch für Tailscale. Beide nutzen freie Open-Source-Software, um letztlich einen proprietären Dienst anzubieten.
Trotzdem ist das kein großes Problem, weil fast alles auf freier Open-Source-Software basiert, es Headscale gibt und Tailscale das offenbar akzeptiert.
Es ist zwar ein Nachteil, aber nicht der entscheidende, und praktisch gibt es auch kaum Vendor Lock-in. Aus Sicht von Geschäft und Support könnte das sogar ein Vorteil sein.
Die Prämisse des Artikels war bis zum letzten Absatz wirklich gut, aber dort musste ich dann noch einmal zurücklesen.
Tailscale macht das Internet zwar wieder einfacher, aber man bleibt weiterhin von einem Vermieter abhängig.
Im Internet war das nie nötig und ist es auch heute nicht zwingend. Selbst wenn vieles zentralisiert wurde, kann man auch heute noch mit nur einem Link jeden beliebigen Server weltweit erreichen.
Als Gegenargument wird andernorts das Self-Hosting von Headscale genannt: https://github.com/juanfont/headscale
Mit nur ein paar Konfigurationsänderungen funktioniert es mit dem normalen Tailscale-Client, und ich nutze es selbst.