La nouvelle vision d’Internet selon Tailscale
(tailscale.com)- Tailscale veut créer une nouvelle couche 3 de l’OSI où tous les appareils se connectent directement et en toute sécurité, afin que les développeurs ne soient pas enfermés dans des architectures inutilement centrées sur la scalabilité
- Beaucoup de programmes n’ont en réalité pas besoin de scaler à grande échelle, mais Kubernetes, le déploiement en conteneurs et la collecte de logs dans le cloud sont devenus la norme par défaut, ce qui a ralenti le développement et l’exploitation
- La pénurie d’IPv4, le NAT, les pare-feu, les IP dynamiques et la structure des certificats TLS séparent les clients des serveurs et placent des fournisseurs cloud centralisés comme AWS au centre de la connectivité
- Tailscale veut attribuer à chaque appareil un certificat, une adresse IP, un nom DNS, un chiffrement de bout en bout et une identité, afin de permettre des connexions sûres même derrière un pare-feu et de faire de tous les appareils des pairs
- Le transfert de fichiers de Taildrop, fondé sur HTTP PUT, montre qu’il est possible de réduire les couches cloud intermédiaires, mais un tel écosystème d’applications nécessite d’abord une adoption suffisante
Point de départ de la vision de Tailscale
- Tailscale a peu parlé publiquement d’une vision plus large au-delà des fonctionnalités à court terme, mais certaines entreprises achètent Tailscale non seulement pour ses fonctions actuelles, mais aussi pour la connectivité qu’il pourrait rendre possible à l’avenir
- Le problème de départ n’était pas de devenir une entreprise de networking, mais de répondre à la dégradation de l’expérience développeur quand on essaie de faire scaler même ce qui n’a pas besoin de scaler
- Une génération qui se souvient de l’expérience des LAN des années 1990 se trouve dans le contexte de la création de Tailscale, et cette expérience sert de point de comparaison face à la complexité technique actuelle
- Les performances des ordinateurs, l’accessibilité de la programmation, les app stores, les systèmes de paiement et les graphismes se sont améliorés, mais beaucoup de tâches quotidiennes des développeurs qui étaient autrefois simples sont devenues au contraire plus difficiles
La surcharge de développement créée par une scalabilité inutile
- Les développeurs modernes sont formés à réfléchir à une échelle d’un milliard d’utilisateurs avant même d’écrire leur premier bout de code, et leurs choix d’algorithmes comme d’architecture tendent à privilégier la scalabilité
- Une mauvaise application de la notation big-O peut faire croire qu’une table de hachage est toujours plus rapide qu’un tableau, alors qu’avec une dizaine d’éléments, un tableau peut être plus rapide et plus simple
- Choisir une structure scalable peut, lorsqu’on ne scale jamais réellement, aboutir à un système plus lent et plus difficile à construire
- L’exemple d’un service à 500 000 pages vues par mois traité avec Kubernetes correspond à environ 0,2 requête par seconde ; à titre de comparaison, même les ordinateurs lents des années 1990 pouvaient lancer des programmes Perl ou Python en quelques millisecondes et traiter davantage de requêtes
- Les builds longs, les builds Docker, l’envoi vers des registres de conteneurs, les déploiements qui prennent de quelques dizaines de secondes à plusieurs minutes et les logs qui arrivent tard relèvent tous de la surcharge née de l’hypothèse selon laquelle « tout doit scaler »
- Tailscale s’est imposé comme un outil qui facilite la création de cette longue traîne de tâches qui n’ont pas besoin de scaler, comme les dashboards ou les générateurs de mèmes, auxquels tous les développeurs consacrent une part importante de leur temps
Comment l’Internet actuel accroît la complexité
- Une grande partie de cette complexité n’est pas intrinsèque : elle vient du fait qu’on applique des solutions complexes à des problèmes qui pourraient être résolus simplement
- Un système de logs consiste à streamer du texte d’un endroit à un autre, et pourtant le résultat peut n’apparaître que 5 minutes plus tard
- Un système d’orchestration est un programme qui lance d’autres programmes, alors que le noyau Unix le fait en quelques millisecondes depuis des décennies
- Le networking est essentiel au logiciel moderne, mais l’Internet actuel rend beaucoup de problèmes plus difficiles
- Plutôt que d’ajouter une couche au sommet de la pile OSI existante pour masquer les problèmes, Tailscale veut créer une nouvelle couche 3 de l’OSI reposant sur d’autres hypothèses
Centralisation du cloud et rente sur la connectivité
- Observer qui peut prélever une rente dans l’industrie technologique permet d’identifier les goulets d’étranglement, et dans la distribution logicielle actuelle, Tailscale estime qu’AWS occupe cette position
- Le cloud fournit des ressources de calcul scalables, mais un MacBook milieu de gamme peut traiter 10 à 100 fois plus d’opérations par seconde sur son SSD qu’un disque local dans le cloud
- Si un ordinateur personnel a du mal à devenir un serveur, c’est à cause de son emplacement et de la connectivité
- Il y a les pare-feu, le NAT, les IP dynamiques et les liaisons réseau asymétriques
- On peut configurer soi-même du port forwarding, une IP statique et des liens Internet redondants, mais cela demande beaucoup de travail et d’expertise
- Au final, on paie un hébergeur qui dispose d’adresses IP et de bande passante, et une entreprise sérieuse choisira un grand fournisseur à qui elle peut faire confiance pour l’accès au matériel
- L’idée selon laquelle « personne n’est licencié pour avoir choisi AWS » est reliée à l’ancienne formule appliquée à IBM
Les gatekeepers passés de l’OS à HTTPS
- IBM pouvait prélever une rente à l’époque du calcul centralisé, et Microsoft a bousculé cet équilibre avec l’informatique distribuée basée sur le PC
- Le monde actuel, centré sur le cloud et le mobile, serait selon Tailscale revenu à un modèle centralisé
- Les appareils de nos bureaux et de nos poches ont, selon les standards d’il y a 20 ans, la puissance de supercalculateurs, mais deviennent des briques inutiles si AWS tombe
- Même avec des serveurs multi-instances et des systèmes de consensus distribués, tout fonctionne le plus souvent au-dessus d’un fournisseur cloud centralisé
- Dans les années 1990, c’était le système d’exploitation qui déterminait l’interopérabilité et la connexion entre programmes ; après le web, JavaScript et la connectivité HTTPS sont devenus plus importants
- HTTPS repose fondamentalement sur une structure centralisée client-serveur
- Le serveur dispose d’une IP statique, d’un nom DNS, d’un certificat TLS et de ports ouverts
- Le client n’a généralement rien de tout cela
- Si le serveur disparaît, le client ne peut plus rien faire
- Pour des raisons de sécurité et à cause de la pénurie d’adresses IPv4, on a ajouté des pare-feu et du NAT, et la connectivité est devenue un flux unidirectionnel du client vers le serveur
Le New Internet selon Tailscale
- Depuis cinq ans, Tailscale construit un produit présenté comme une réponse à ce problème
- Chaque appareil reçoit un certificat, une adresse IP, un nom DNS, un chiffrement de bout en bout et une identité, et peut contourner les pare-feu en toute sécurité
- Tous les appareils peuvent devenir des pairs qui se connectent entre eux, plutôt que de conserver des rôles fixes de serveur et de client
- Tailscale affirme réaliser cela sans ajouter de latence ni de surcharge
- Les utilisateurs de Tailscale expérimentent déjà un environnement où plusieurs couches de complexité ont disparu, et où Internet fonctionne davantage comme on l’avait imaginé à l’origine
La simplification illustrée par Taildrop
- Taildrop est un petit exemple de la structure rendue possible par Tailscale
- Une fois Tailscale déjà installé, le cœur de Taildrop tient en un seul HTTP PUT
- L’émetteur envoie une requête HTTP au destinataire
- Il annonce « j’envoie tel fichier »
- Il transmet le fichier
- Sur l’Internet traditionnel, l’appareil récepteur est derrière un pare-feu et n’a ni port ouvert ni identité propre, ce qui impose de passer par un envoi dans le cloud puis un téléchargement ultérieur
- Cette approche via le cloud crée plusieurs couches supplémentaires
- Elle engendre des coûts de sortie réseau, de stockage et de CPU serveur
- Il faut décider quand supprimer les fichiers qui n’ont pas été téléchargés
- Il faut garder le serveur en ligne même quand il n’est pas utilisé
- Des employés du cloud pourraient théoriquement accéder aux fichiers, donc il faut du chiffrement
- Ce chiffrement exige un échange de clés entre l’émetteur et le destinataire
- Pour prévenir le destinataire qu’un fichier l’attend, il peut aussi falloir des systèmes de notifications push spécifiques à chaque plateforme
- Taildrop permet un transfert de fichiers gratuit parce que cette surcharge de coûts disparaît, ce qui s’inscrit dans le contexte de l’offre gratuite de Tailscale
Pourquoi l’adoption est nécessaire
- Taildrop est un exemple trivial, mais il sert de preuve d’existence d’une catégorie de programmes qui pourraient devenir 10 fois plus simples avec Tailscale
- Le manque de connectivité favorise la centralisation, la centralisation impose une rente même aux petits programmes, et cela produit des architectures lentes, complexes et difficiles à déboguer
- Pour que des applications ne fonctionnant que sur Tailscale apparaissent, il faut qu’un nombre suffisant de personnes utilise Tailscale
- Sans adoption suffisante, personne ne développera ces applications : c’est le problème de l’œuf et de la poule
- C’est pourquoi Tailscale investit fortement dans la gratuité, tout en développant aussi des fonctionnalités enterprise qui facilitent l’adoption en entreprise et le déploiement à l’échelle de groupes du Fortune 500
Objectif et situation actuelle
- Internet appartient à tout le monde ; il a existé plusieurs internetworks par le passé, mais c’est l’Internet le plus divers et le plus inclusif qui a gagné
- Le New Internet doit lui aussi pouvoir être utilisé par les développeurs à la maison, à l’université, par les salariés d’entreprise, et au final par tout le monde
- Aujourd’hui, environ 1 personne sur 30 000 dans le monde utilise le New Internet, c’est-à-dire Tailscale
- Tailscale affirme qu’il ne s’arrêtera pas tant que tout le monde ne pourra pas l’utiliser
- L’entreprise rappelle qu’il fut un temps où Microsoft était moqué pour vouloir mettre un ordinateur sur chaque bureau, et où TCP/IP n’était qu’une option additionnelle achetée auprès d’un tiers, pour souligner qu’en 30 ans le monde technologique peut changer très vite
1 commentaires
Avis sur Hacker News
Le problème éternel d’entreprises comme Tailscale, Cloudflare ou Google, c’est qu’en résolvant à la place d’Internet des problèmes qu’Internet aurait dû régler lui-même — par exemple de simples connexions sécurisées de bout en bout — elles ont intérêt à ce que ces problèmes perdurent.
Ce dont Internet a besoin, c’est de quelque chose comme IPv6 avec une infrastructure à clé publique fournie par DNSSEC et un chiffrement automatique via IPsec ; mais si cela était implémenté de façon largement compatible, le business de Tailscale s’effondrerait.
Au fond, leur activité dépend de la persistance du problème.
Repost : https://news.ycombinator.com/item?id=38570370
IPv6 est sorti en 1998 et, pendant les 21 années qui ont précédé le lancement de Tailscale en 2019, l’approche décrite n’a toujours pas été implémentée.
Qui l’a empêchée à l’époque, et qui l’empêche aujourd’hui ? Google, Cloudflare et Tailscale ont reçu de l’argent, ou une contrepartie équivalente comme des données personnelles, parce qu’ils ont résolu de vrais problèmes.
J’ai du mal à adhérer à cette sorte d’accélérationnisme inversé selon lequel il faudrait rendre Internet pire pour tout le monde afin qu’une vraie bonne solution finisse par émerger.
Ce n’est pas à cause de Tailscale que cette solution n’existe pas, mais à cause de la quantité énorme de travail nécessaire pour la créer ; et sans WireGuard, il est fort possible que Tailscale n’existerait pas non plus.
L’apparition de Tailscale a aussi donné naissance à Headscale, qui constitue une marche de plus vers la création de ce « quelque chose » dont il est question.
Dit simplement, malgré toutes les explications, l’idée centrale est que Tailscale se place au milieu lorsque les appareils essaient de se trouver.
Il existe d’autres approches. Le DNS dynamique, qui attribue un nom permanent à des machines n’ayant qu’une IP temporaire, existe depuis des décennies, même si sa réputation n’est pas excellente.
On peut aussi utiliser plusieurs nœuds de coordination qui se connaissent entre eux, ainsi qu’une liste publique de nœuds. Même si la liste vieillit, il suffit d’un seul nœud encore vivant pour se connecter et la mettre à jour ; Kademlia, qui sert de base au réseau Ethereum et à certains systèmes de partage de fichiers, fonctionne de cette manière.
Un compromis consistant à séparer la découverte et le transfert est également possible. Peertube trouve, via une recherche web classique, un serveur hébergeant le fichier à streamer en HTTP, tandis que le transfert réel se fait de façon distribuée, les spectateurs actuels s’envoyant les blocs entre eux ; le système passe donc bien à l’échelle quand une vidéo devient virale.
Il est donc tout à fait possible de faire autrement, sans qu’un acteur au milieu puisse couper l’arrivée d’oxygène.
Les anciens protocoles VPN ou des mécanismes d’authentification comme RADIUS ont des failles de sécurité graves, mais sont difficiles à corriger pour des raisons de compatibilité, alors même qu’ils opèrent à une échelle bien plus réduite que l’ensemble d’Internet.
Le fait que l’industrie traite le problème de l’ossification de TCP en abandonnant TCP pour le réimplémenter au-dessus d’UDP en dit long.
Le service de localisation peut aussi être auto-hébergé si on le souhaite, donc il n’est pas obligatoire d’utiliser leur service.
À part DNSSEC, c’est assez proche de ce qui est demandé.
Cette valeur ne disparaît pas avec l’arrivée d’IPsec.
Cela commence par une très longue plainte contre le contrôle centralisé qui extrait des rentes, et la plainte est en soi légitime.
Mais le texte s’égare ensuite dans des questions distinctes, comme de savoir si l’informatique client-serveur a du sens, ou si elle est la cause de la recherche de rente, pour finir par conclure que « demain, il y aura ceux qui ont Tailscale et ceux qui ne l’ont pas ».
Le roi est mort, vive le nouveau roi, en quelque sorte.
Il est assez petit et simple pour que même moi, qui ne suis pas programmeur, je puisse le réparer.
Comme tout le monde n’a pas sur Internet une IP accessible directement et sans pare-feu, on peut aussi utiliser du client-serveur pour parvenir au pair à pair.
Il peut être nécessaire de mettre en place un « supernœud » sur un serveur chez un hébergeur, mais s’il ne sert que de serveur de rendez-vous, le trafic ne passe pas par lui et le coût reste faible.
Je me méfie toujours fortement des entreprises qui essaient de concurrencer le « gratuit » : arrêtez d’utiliser du logiciel gratuit et payez-nous, en échange nous avons ajouté 100 fonctionnalités inutiles.
Comme avec Slack, cette stratégie d’entreprise peut réussir à court terme, mais ce type d’abonnement n’est pas à mon goût.
À mon avis, le vrai sujet n’est pas client-serveur contre pair à pair, mais propriétaire contre non propriétaire.
S’ils ne deviennent pas un géant de l’envergure de Microsoft d’ici dix ans, cela risque d’être difficile à faire accepter positivement.
À l’époque, c’était un outil vraiment excellent et simple pour concevoir et configurer des réseaux privés personnels. Il permettait facilement le partage de fichiers, les LAN de jeux locaux, la collaboration de développement, et même le streaming média.
L’avenir du pair à pair me semble moins ressembler à Tailscale qu’à une variante auto-hébergée de Hamachi, capable de relier de manière générale des nœuds situés derrière différents NAT et ASN, et comprenant les techniques de contournement de NAT, STUN/TURN et le routage en tortue.
Un outil permettant à des utilisateurs distants de rejoindre facilement un réseau sans passerelle VPN centrale serait une fonction puissante dans les environnements modernes.
Nous aurions tous intérêt à apprendre et appliquer les Iceberg Articles : https://john.kozubik.com/pub/IcebergArticle/tip.html
Nous utilisons réellement Tailscale sur des systèmes de production. Les serveurs sont physiquement proches ou dans d’autres emplacements contrôlés, et des centaines d’utilisateurs situés à des centaines de kilomètres travaillent tous via Tailscale.
Il faut dire deux choses. Tailscale est étonnant et vraiment excellent. Ce système n’aurait pas pu exister sans Tailscale, ou bien il aurait fallu au moins 10 personnes de plus dans l’équipe pour assurer une exploitation 24 h/24.
Cela dit, il faut revoir ses attentes à la baisse. Ce n’est pas aussi bon que « l’Internet ». La latence fait périodiquement des pics, les connexions tombent de temps en temps, et MagicDNS s’arrête littéralement comme par magie ou entre en conflit avec le système.
Avec autant d’utilisateurs, nous avons rencontré presque tous les problèmes imaginables, et un nouveau peut encore apparaître demain.
Malgré tout, je crois en Tailscale et en sa vision. C’est une approche entièrement nouvelle qui donne le contrôle du matériel tout en réduisant les coûts et en renforçant la sécurité.
Notre premier gros serveur de production était un ordinateur portable Linux à 4 cœurs.
J’utilise moi aussi beaucoup Tailscale pour de l’auto-hébergement interne, mais je n’avais jamais envisagé de l’utiliser pour un service de production public, donc la configuration m’intéresse.
J’aime Tailscale, mais cet article me donne froid dans le dos.
Si Internet a réussi, c’est parce qu’il a été construit sur des standards et qu’il était totalement libre.
Avec Tailscale, WireGuard est open source et il existe aussi des choses comme Headscale, mais la structure selon laquelle « tout le monde a une IP » ne dépend-elle pas du fait que Tailscale possède un immense espace d’adresses IP ?
Si l’on doit attendre une adoption complète d’IPv6, ou s’appuyer sur de l’IPv4 centralisé, des serveurs et des éléments propriétaires, cela paraît un peu hypocrite.
Il n’est pas totalement équivalent à Tailscale en matière de fonctionnalités, mais il prend déjà en charge la plupart des fonctions actuelles et s’améliore chaque jour.
Si je me souviens bien, l’un des principaux développeurs est rémunéré par Tailscale pour y travailler.
Je l’utilise pour mon infrastructure personnelle auto-hébergée et cela fonctionne très bien. La configuration d’une URL de serveur de contrôle personnalisée a aussi été relativement simple sous Windows et Android.
J’utilise aussi taildrop et j’expose des conteneurs Docker au tailnet ; Headscale fonctionne donc suffisamment bien pour mériter un essai.
L’espace IP nécessaire n’a besoin d’être aussi grand que la plus grande douve, et on ne peut être connecté qu’à une seule douve à la fois.
J’aime Tailscale, mais cet article se lit comme beaucoup trop autosatisfait.
C’est un produit de VPN maillé avec des services additionnels, et il est excellent en soi, mais l’idée n’est ni nouvelle ni unique.
Pourquoi cette solution devrait-elle être le nouvel Internet plutôt qu’une autre alternative ?
Quoi qu’il en soit, je ne veux pas que toute mon infrastructure Internet dépende d’une seule entreprise. Je vais donc continuer à utiliser l’Internet traditionnel, même s’il est complexe.
Les gros problèmes sont sociaux plus que techniques, et une nouvelle technologie ne les résoudra pas.
Prenons les réseaux sociaux : on peut imaginer un monde où Facebook/Twitter/TikTok/YouTube/Reddit/HN fonctionneraient aussi fluidement que BitTorrent.
L’application sur mon ordinateur participerait au réseau « Facebook », mes amis verraient que je suis en ligne via leurs propres instances de l’application, et mon fil ainsi que mon mur seraient servis directement depuis mon appareil.
Ce serait une architecture où 2 personnes, 1 000 personnes ou des millions de personnes communiquent directement, sans serveur central.
BitTorrent, Soulseek, Bitcoin et d’autres réseaux pair à pair ont déjà montré que c’était possible.
Mais pour rendre tout cela aussi fluide que se rendre sur facebook.com, toutes sortes de problèmes techniques surgissent. Une connexion pair à pair fluide sans redirection de ports, DNS dynamique ni connaissances avancées en réseau, sécurité et administration système est le premier gros obstacle.
Que faire si un nœud est hors ligne ? Qu’en est-il de la latence et de la charge lorsqu’il faut se connecter à des milliers, des centaines de milliers ou des millions de machines pour récupérer un fil ? Comment gérer le cache ? Comment pousser les mises à jour et les notifications ? Comment faire communiquer des nœuds très anciens ? Où stocker les données ? Comment gérer la découvrabilité et la sécurité ? Tout cela relève de problèmes techniques.
La plupart peuvent être résolus, mais atteindre une expérience aussi stupidement simple que celle d’un service centralisé demande un effort énorme, problème par problème.
Le Fediverse travaille depuis plus de 10 ans sur une petite partie de ce problème, mais il faut encore un administrateur système assez compétent pour offrir une expérience comparable à twitter.com, ou légèrement moins bonne.
Yggdrasil n’était-il pas censé devenir le nouvel Internet ? https://yggdrasil-network.github.io
Sinon, pourquoi Tailscale en particulier, et pas Netbird, Nebula, Netmaker ou un autre concurrent ?
L’article est très bien écrit, mais il donne l’étrange impression que quelque chose approche, comme une acquisition, une transition, une scission ou une fermeture. Même « ce n’est que le début » sonne comme de célèbres derniers mots.
Pour équilibrer, en tant qu’utilisateur de Tailscale, j’en suis satisfait et j’ai été impressionné par le fait que cela fonctionne tout simplement sans qu’on ait à trop s’en soucier.
Cela dit, même s’il fonctionne bien, il faut garder à l’esprit que cela reste un projet de recherche.
J’apprécie vraiment le service Tailscale et je l’utilise avec gratitude, mais cet article ne m’a pas parlé.
J’aime aussi les discours mobilisateurs de CEO inspirants, et je suis d’accord pour dire qu’il y a une quantité absurde de friction et de complexité pour les développeurs dans l’informatique, mais Tailscale a aussi ses propres frictions et ne va pas du tout dans le sens d’une résolution du problème d’ensemble.
Il y a quelques semaines, j’ai invité mon père dans mon tailnet pour corriger un problème sur son ordinateur via bureau à distance. Il a accepté l’invitation et l’interface web du domaine TS affichait bien son appareil, mais impossible de le ping.
Résultat, mon père déteste maintenant Tailscale, et comme je lui avais dit que c’était génial, ma crédibilité en a pris un coup. À ses yeux, ça lui a fait perdre du temps et c’était un truc qui « ne marche pas correctement ».
C’est assez contre-intuitif. La fonction d’organisation n’est pas faite pour ça ; à la place, chacun doit créer son propre tailnet puis les relier.
Référence : https://github.com/tailscale/tailscale/issues/10731
Pour ce genre d’usage, des outils comme TeamViewer ou AnyDesk sont plus adaptés.
Je pense que l’auteur a mal diagnostiqué le problème, et que la solution proposée ne supprime pas la centralisation, elle ne fait que la masquer.
Si AWS coûte cher, ce n’est pas à cause d’IPv4 ou des datacenters, mais surtout à cause du logiciel, des services managés et de la capacité à ajouter rapidement des serveurs.
Si une « entreprise sérieuse » ne veut pas payer AWS ou un acteur similaire, elle peut louer des racks et colocater ses propres serveurs, et beaucoup d’entreprises le font effectivement.
Je ne suis pas d’accord avec l’idée que les certificats auraient créé de la centralisation. Les certificats ne séparent pas ceux qui en ont de ceux qui n’en ont pas, et ce n’est pas comparable au fait de posséder ou non un mainframe.
Ce n’est pas parce que HTTPS est devenu pratiquement obligatoire que les gens se sont mis à avoir leur propre domaine ou sous-domaine ; ils le faisaient déjà, par commodité.
DNS est un autre point de centralisation, mais Tailscale ne l’évite pas du tout. MagicDNS dépend aussi de la racine ICANN, tout comme le plan de contrôle de Tailscale.
Si tout ce dont on a besoin est un sous-domaine gratuit, il existe beaucoup de fournisseurs qui en proposent.
Si l’on est derrière du CGNAT, un tailnet n’est pas vraiment moins centralisé non plus, car le trafic doit passer par des serveurs DERP.
Si le volume de trafic passe des Gbit/s aux Tbit/s, je doute que Tailscale puisse continuer à fournir cela gratuitement.
Je reconnais que les solutions de type Tailscale sont utiles pour le dernier cas restant : accéder à des ordinateurs derrière du NAT, et qu’elles pourraient atteindre des dizaines de millions d’utilisateurs.
Mais cela ne suffit pas à revendiquer le titre de nouvel Internet.
L’article lui-même souligne que cette hypothèse est fausse.
Ce genre d’idée n’est évidemment pas nouveau.
IPv6 était censé donner à tout le monde une connectivité de bout en bout, et IPsec devait à l’origine être un composant obligatoire d’IPv6 afin de donner à chaque hôte Internet une identité cryptographique.
Avec IPv6 et WireGuard ensemble, on obtient confidentialité, sécurité et performance. L’inconvénient, c’est la complexité de configuration.
Tailscale se tient sur les épaules de géants : IPv4, WireGuard, le NAT punching de Samy Kamkar, OpenSSH, et sans doute bien d’autres.
Son avantage est de les avoir combinés, avec une interface d’administration globalement simple.
Cela dit, ce qui est dit à propos des autorités de certification s’applique aussi à Tailscale. Dans les deux cas, on utilise du logiciel libre et open source pour fournir au final un service propriétaire.
Malgré tout, ce n’est pas un gros problème, car presque tout repose sur du libre/open source, Headscale existe aussi, et Tailscale semble l’accepter plutôt bien.
C’est certes un inconvénient, mais pas le principal ; dans les faits, il y a aussi très peu de dépendance fournisseur. Du point de vue du business et du support, cela peut même être un avantage.
La prémisse de l’article était vraiment bonne jusqu’au dernier paragraphe, qui m’a fait revenir dessus.
Oui, Tailscale rend à nouveau Internet plus simple, mais il faut toujours dépendre d’un propriétaire.
Sur Internet, ce n’était pas nécessaire, et ça ne l’est toujours pas forcément. Même si beaucoup de choses se sont centralisées, aujourd’hui encore, avec un simple lien, on peut se connecter à n’importe quel serveur dans le monde.
La réponse, mentionnée ailleurs, est l’auto-hébergement avec Headscale : https://github.com/juanfont/headscale
Avec quelques changements de configuration, cela fonctionne avec le client Tailscale standard, et je l’utilise moi-même.