Incident de panne sur Tailscale.com survenu le 7 mars 2024

 (tailscale.com)
2 points par GN⁺ 2024-04-01 | 1 commentaires | Partager sur WhatsApp
  • En raison d’un certificat TLS expiré le 7 mars 2024, tailscale.com a été indisponible pendant environ 90 minutes, mais l’impact est resté principalement limité à la documentation et au site marketing
  • Le problème est apparu environ 90 jours après la refonte du site web et la migration vers un nouvel hébergeur en décembre 2023 ; une configuration de proxy maison mise en place pour compenser l’absence de prise en charge d’IPv6 a empêché le renouvellement automatique
  • La sonde de surveillance de l’expiration des certificats ne vérifiait que le chemin IPv6, en passant par un proxy doté d’un certificat valide distinct, ce qui a fait manquer l’expiration imminente réelle de tailscale.com et www.tailscale.com
  • L’usage habituel de Tailscale n’a globalement pas été interrompu, mais la documentation, le blog, install.sh et le parcours d’accès à la console d’administration pour les utilisateurs ne connaissant pas l’URL directe ont été affectés
  • Tailscale a rétabli le service en supprimant des enregistrements AAAA supplémentaires et en renouvelant manuellement les certificats ; l’entreprise vise à terme une prise en charge plus directe d’IPv6 après avoir mis en place un système de renouvellement manuel à court terme et des vérifications séparées IPv4/IPv6

Pourquoi l’expiration du certificat n’a pas été détectée

  • Le 7 mars 2024, les certificats TLS de tailscale.com et www.tailscale.com ont expiré, rendant le site inaccessible pendant environ 90 minutes
  • En décembre 2023, Tailscale a migré vers un nouvel hébergeur dans le cadre d’une refonte majeure de son site web
  • Le nouvel hébergeur ne prenant pas en charge IPv6 par défaut, Tailscale a exploité son propre proxy pour traiter les requêtes IPv6 et a configuré des enregistrements AAAA supplémentaires
  • L’hébergeur a envoyé une alerte en qualifiant cette configuration de « misconfiguration », mais l’alerte ne précisait pas que cette configuration empêchait l’achèvement du renouvellement automatique des certificats
  • La sonde chargée de surveiller l’expiration des certificats ne vérifiait que le chemin IPv6
    • La sonde passait par le proxy maison
    • Le proxy disposait d’un certificat valide géré séparément
    • Pour cette raison, l’expiration réelle des certificats de tailscale.com et www.tailscale.com n’a pas été détectée à l’avance

Impact visible pour les utilisateurs

  • L’impact s’est concentré sur les ressources et parcours d’installation dépendant du site web
    • La documentation Tailscale, le blog et d’autres ressources de référence basées sur le site étaient inaccessibles pendant la panne
    • La console d’administration et les pages de configuration elles-mêmes n’étaient pas affectées, mais les utilisateurs ne sachant pas aller directement sur https://login.tailscale.com/ pouvaient penser que cette page était hors ligne
    • Le script d’installation rapide ne pouvait pas être utilisé, ce qui a perturbé certaines installations et installations automatisées
  • Le domaine qui fournit réellement l’installation des paquets Tailscale restait accessible, et l’interruption de la résolution via le mécanisme go get de Go aurait été minimale grâce au cache
  • En raison de la conception de Tailscale, la plupart des utilisateurs n’ont pas subi d’interruption dans la majorité des cas d’usage lors de cette panne, car le principe de connexion directe rend le réseau moins dépendant de la disponibilité immédiate d’un point de terminaison spécifique comme tailscale.com

Rétablissement et prévention des récidives

  • Après avoir identifié le problème, Tailscale a temporairement supprimé les enregistrements AAAA « supplémentaires » et a renouvelé manuellement les certificats concernés
  • Cette mesure a immédiatement résolu la panne visible par les utilisateurs, et les enregistrements ont rapidement été rétablis pour continuer à fournir le site et les services en IPv6
  • Le problème de renouvellement automatique subsistant, Tailscale prévoit à court terme de renouveler directement les certificats en s’appuyant sur des alertes calendrier redondantes et des créneaux de renouvellement manuel définis
  • L’infrastructure de sondes sera mise à jour afin de vérifier séparément les points de terminaison IPv4 et IPv6
  • À long terme, l’objectif est de prendre en charge IPv6 plus directement dans l’infrastructure du site web afin d’éliminer la nécessité d’un proxy maison

À lire aussi

1 commentaires

 
GN⁺ 2024-04-01
Avis de Hacker News

  • Les certificats qui expirent sont désormais, à mon avis, le nouveau DNS des pannes.
    Cela dit, je reste impressionné par la qualité de conception de Tailscale. Je suis plutôt un utilisateur occasionnel, mais j’accède via Tailscale à deux environnements : quelques serveurs on-premise et un environnement de production AWS.
    Je peux travailler de n’importe où. Un week-end, je voulais déployer un conteneur ECS, mais le Wi-Fi local était tellement lent que les déploiements expiraient sans cesse.
    J’ai donc fait un SSH vers une machine de développement on-premise, exécuté git pull pour récupérer le dernier code, puis déployé depuis là. L’on-premise comme AWS étaient sécurisés sans ports ouverts, et il suffit de lancer l’agent Tailscale sur une petite EC2 AWS pour pouvoir tester la base de données Aurora de production sans aucun port ouvert.
    Quand il faut donner un accès réseau à un autre développeur, Tailscale rend aussi les choses très simples, tout comme la révocation des droits. Ce déploiement aurait pu être géré avec quelque chose comme GitHub Actions pour éviter les problèmes de mauvaise connexion Internet, mais je voulais le faire manuellement et Tailscale l’a rendu possible.

    • Même pour déployer avec GitHub Actions, Tailscale reste utile. Pour l’instant, le port SSH de la VM cloud est ouvert sur un port non standard afin qu’un worker GHA puisse s’y connecter en SSH et lancer le déploiement.
      À l’avenir, je compte utiliser cette action pour permettre à n’importe quel worker GHA d’accéder à la machine de déploiement sans exposer de port : https://github.com/tailscale/github-action
    • Sur les connexions instables, j’utilise mosh et GNU screen. Même avec des coupures toutes les 10 secondes, cela fonctionne étonnamment bien.

  • Encore un certificat expiré qui provoque un incident.
    Dans le cadre du post-mortem, je recommanderais de détacher le script d’installation du site marketing, ou de prévoir un autre chemin de secours. Ainsi, l’activité du site marketing ne ferait plus partie du chemin critique des opérations clients. Comme ce genre de chose arrive souvent, c’est d’autant plus dommage qu’ils étaient déjà presque arrivés au niveau d’isolation habituel.
    Quand on suit la disponibilité de plusieurs fournisseurs, on constate que des parties de sites comme GitHub ou Zendesk tombent plus souvent qu’on ne s’y attendrait. Et pourtant, ils font plutôt partie des bons élèves.

    • La sécurité du site marketing a souvent une priorité plus faible que celle du produit lui-même, alors que le script d’installation doit généralement être protégé à un niveau comparable à celui du produit.
    • Je me demande s’il existe un service qui surveille tous les certificats et leurs dates d’expiration.
      Cloudflare semble s’en charger assez bien si le domaine est hébergé chez eux, mais cela impose d’utiliser Cloudflare.

  • C’est la même erreur que nous avions commise dans une ancienne entreprise. Sur la page d’accueil du site marketing www.foo.com, nous avions mis un lien vers la page de connexion de l’application web app.foo.com.
    Ce n’est qu’après la première panne du site marketing que nous avons compris que le plan d’hébergement à 40 dollars par mois n’était pas un simple site marketing, mais une infrastructure critique. Littéralement, un hébergement à 40 dollars qui portait une charge. L’application n’était pas tombée, mais les utilisateurs pensaient que si.
    J’ai appris que les utilisateurs suivent simplement le chemin qu’on leur a donné, sans forcément savoir qu’il en existe d’autres, et que si l’on supprime ce chemin, une partie d’entre eux se retrouve complètement perdue.

    • Si l’on tape tailscale dans le navigateur, le premier résultat est tailscale.com. Comme je n’utilise pas souvent la console d’administration Tailscale, je ne mémorise pas vraiment une autre URL.
      Avant, quand je tapais cloudflare, le navigateur autocomplétait dash.cloudflare.com, mais après avoir visité une seule fois le site cloudflare.com, celui-ci est devenu le premier résultat, et j’ai commencé à faire la même chose avec Cloudflare.

  • Cette équipe est vraiment excellente, mais je trouve les prix beaucoup trop élevés. Un contrôle d’accès digne de ce nom à 18 dollars par mois pour un VPN est presque impossible à vendre à la direction, et les offres inférieures sont difficiles à vendre sans cette fonctionnalité.

    • Je serais vraiment curieux de savoir à quoi Tailscale est comparé en interne. Tailscale fait beaucoup plus qu’un simple VPN.
      Quelles sont les options moins chères, et proposent-elles aussi les fonctionnalités SSH, l’authentification réseau OAuth pour les services d’automatisation, la configuration d’un équilibreur de charge pour nœuds VPN dans un cluster Kubernetes, ou l’automatisation des demandes de certificats ACME via Let’s Encrypt ?
      Rien qu’en listant quelques fonctionnalités que j’utilise dans l’offre gratuite, on trouve beaucoup de choses qu’on n’associe généralement pas au rôle d’un service VPN. Les fonctionnalités continuent aussi d’arriver, ce qui en fait selon moi une option assez intéressante et compétitive. Je suis même surpris par tout ce qui est inclus dans les offres bon marché, donc ce genre d’évaluation m’intrigue d’autant plus.
    • Dans ce cas, on peut installer headscale et l’auto-héberger pour l’utiliser sans frais.
      Il existe aussi des produits concurrents qui recoupent en partie Tailscale, même s’ils ne correspondent pas forcément exactement à ce que l’on veut.
      Cela dit, en quelques minutes, une partie du projet s’est mise à fonctionner ensemble bien mieux qu’avant.
      C’est l’un de ces outils vraiment rares, très simples au regard de ce qu’ils font, et l’offre gratuite est aussi assez généreuse avec 100 appareils et 3 utilisateurs.
    • Pour nous, cela a été très facile à défendre. Nous sommes sortis d’une configuration OpenVPN, et Tailscale a rendu beaucoup plus simple l’onboarding des nouveaux employés et plein d’autres choses de la bonne manière. C’est d’autant plus important pour une entreprise entièrement à distance.
      Bien sûr, de par mon rôle, j’avais une influence non négligeable pour convaincre la direction sur ce genre de sujet, mais le prix n’a pas été un problème.
      Nous sommes clients satisfaits depuis avril dernier, et tout le monde utilise l’offre premium, c’est-à-dire le palier cher. Le rythme de développement est aussi impressionnant. Certaines fonctionnalités dont on nous disait qu’elles pourraient prendre des années ont déjà été lancées l’an dernier.
      Cloudflare One aurait aussi pu être une alternative, mais cela aurait été plus cher.
    • Je ne sais pas quel dirigeant bloque sur 18 dollars par mois. Rapporté au coût par personne, c’est quasiment zéro parmi les dizaines de choses qu’on achète pour un employé.
    • C’est la raison principale qui nous a poussés vers Twingate. Après l’avoir essayé, j’ai fini par préférer un peu les fonctionnalités de routage de Twingate. Cela ne veut pas dire que je n’aime pas Tailscale ; nous utilisons les deux selon les cas d’usage.

  • Je me demande quel fournisseur ils utilisent pour le site web. Presque tous les autres fournisseurs prennent en charge IPv6, donc il me paraît étrange de devoir mettre en place autant de contournements à cause d’IPv6.

    • D’après le résultat de $ host www.tailscale.com, l’adresse IPv4 76.76.21.21 de www.tailscale.com est chez Vercel, tandis que les adresses IPv6 sont chez Amazon.
      IPv4 utilise un certificat Let’s Encrypt, et IPv6 un certificat Amazon.

  • Je les envie vraiment d’avoir un CI/CD et un monitoring assez solides pour pouvoir lancer un gros déploiement en décembre en toute confiance. Leur culture d’ingénierie a l’air plutôt forte.
    Cela dit, il reste des questions sans réponse. Si la configuration IPv6 a cassé le renouvellement automatique des certificats IPv4, je me demande pourquoi ils ne l’ont pas rencontré beaucoup plus tôt. Je me demande aussi pourquoi il a fallu 90 minutes pour résoudre l’incident. C’est un billet de blog, pas une véritable analyse post-mortem, mais un simple calendrier aurait été appréciable.
    Je me demande aussi pourquoi ils ne migrent pas vers un fournisseur DNS qui prend en charge IPv6 nativement. Je me demande si la charge opérationnelle liée au maintien d’un domaine séparé pour les scripts ou les paquets vaut vraiment le coup. Et je me demande si d’autres font aussi cela, en excluant les tiers comme les dépôts de paquets.

    • D’après ce que je comprends, ils semblent être passés à la configuration actuelle 90 jours avant l’incident. Le certificat initial installé lors de la migration était valable 90 jours, donc l’incident est survenu 90 jours après la migration.
    • Ils utilisent Vercel, qui ne prend pas en charge IPv6.

  • Je ne vois pas pourquoi le proxy devait terminer TLS. S’il s’était agi d’un simple proxy TCP, au moins le monitoring n’aurait pas cru à tort que l’expiration du certificat n’était pas imminente.
    En plus, si la validation du domaine se faisait via un challenge TLS-ALPN, un proxy TCP aurait aussi pu permettre le renouvellement automatique.

    • Un proxy TCP perd l’adresse IP de l’utilisateur, sauf à utiliser quelque chose comme le protocole PROXY. Il faut alors que le serveur HTTPS cible le prenne aussi en charge, et il faut un moyen d’empêcher des utilisateurs non autorisés d’injecter leur propre en-tête PROXY.
      Si l’IP utilisateur n’est pas du tout nécessaire, ce n’est pas un problème, mais elle est souvent utile pour les logs et la détection d’abus.
      https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt
    • Ce n’est pas une raison énorme, mais HTTP/3 ne fonctionne pas au-dessus de TCP, et exploiter un proxy UDP ne doit pas être très agréable.
    • Il n’est pas nécessaire de terminer TLS. C’était l’une de nos erreurs, et c’est un point d’action à corriger.
      Quand nous avons découvert en urgence que l’IPv6 était cassé, nous avons monté un proxy, et les personnes qui l’ont mis en place ne savaient pas comment ACME fonctionnait.
      Nous allons passer à un simple proxy TCP.
    • Un proxy qui ne termine pas TLS se déploie bien sur des services comme Hetzner. Avec une configuration CAA correcte, on ne confie au fournisseur que la latence et la disponibilité, tout en évitant des services absurdement chers comme CloudFront ou des proxies basés sur EC2.
      À première vue, Tailscale semble utiliser NetActuate pour pkgs.tailscale.com. Avec NetActuate, ils devraient pouvoir proposer des proxies non terminants sur plusieurs sites à un prix raisonnable. Il n’y a pas de prix sur leur site, mais ils n’ont pas l’air d’être une entreprise qui prend une marge de 50× sur le trafic sortant.
    • Il est possible qu’ils aient placé AWS CloudFront CDN en frontal pour l’IPv6. Dans ce cas, TLS est terminé par CloudFront, et à ma connaissance ce n’est pas optionnel.

  • Quand une organisation comme Tailscale trébuche ne serait-ce qu’une seule fois dans un domaine qui touche de près ou de loin à la sécurité, cela paraît trop risqué même à quelqu’un d’un peu paranoïaque comme moi.
    Il faut une meilleure explication à ce sujet.

  • Ils ont sûrement du monitoring d’infra, donc il suffit d’ajouter 50 lignes de code qui se connectent à tous les domaines publics en IPv4 et en IPv6 et alertent si un certificat expire dans moins de 19 jours. Le renouvellement automatique tourne 20 jours avant, et c’est réglé.
    Après avoir raté plusieurs renouvellements SSL au début d’une petite entreprise, j’ai écrit ce code il y a quelques années, et depuis nous n’avons plus eu d’incident lié au SSL.
    Pas besoin d’invitation calendrier ; le seul correctif nécessaire est celui-là. L’essentiel est dans le passage disant qu’ils vont « mettre à jour l’infrastructure de preuve pour vérifier séparément les endpoints IPv4 et IPv6 ».

  • « Cette configuration était considérée comme une mauvaise configuration par ce fournisseur, et nous recevions donc des avertissements en continu depuis son déploiement », est-il écrit.
    Donc ils ont reçu des avertissements liés au certificat pendant 90 jours, puis le certificat a échoué ?

    • On dirait plutôt qu’ils ont reçu des avertissements liés au DNS pendant 90 jours, pas des avertissements sur le certificat. Il semble que l’équipe Tailscale ne savait pas avant l’incident que Vercel refuse le renouvellement automatique des certificats lorsqu’il existe des enregistrements DNS IPv6/AAAA.
      Je n’ai pas vu l’avertissement réel, donc je ne sais pas s’il indiquait clairement ce fait.