Der Ausfall von Tailscale.com am 7. März 2024

 (tailscale.com)
2 Punkte von GN⁺ 2024-04-01 | 1 Kommentare | Auf WhatsApp teilen
  • Aufgrund eines am 7. März 2024 abgelaufenen TLS-Zertifikats war tailscale.com etwa 90 Minuten lang nicht erreichbar, wobei die Auswirkungen sich hauptsächlich auf die Dokumentation und die Marketing-Website beschränkten
  • Das Problem wurde rund 90 Tage nach dem Website-Relaunch und dem Umzug auf ein neues Hosting im Dezember 2023 sichtbar; eine Konfiguration mit einem eigenen Proxy zur Ergänzung einer Umgebung ohne IPv6-Unterstützung verhinderte die automatische Erneuerung
  • Ein Prober zur Überwachung des Zertifikatsablaufs prüfte nur den IPv6-Pfad und lief dabei über einen Proxy mit einem separat gültigen Zertifikat, sodass das nahende Ablaufdatum von tailscale.com und www.tailscale.com unbemerkt blieb
  • Die allgemeine Nutzung von Tailscale war größtenteils nicht unterbrochen, aber Dokumentation, Blog, install.sh und der Zugriffsfluss zur Verwaltungskonsole für Nutzer ohne direkte URL-Kenntnis waren betroffen
  • Tailscale stellte den Betrieb durch das Entfernen zusätzlicher AAAA-Records und eine manuelle Erneuerung wieder her und strebt nach einer kurzfristigen manuellen Erneuerungsregelung sowie getrennten IPv4/IPv6-Prüfungen künftig eine direktere IPv6-Unterstützung an

Warum das Auslaufen des Zertifikats übersehen wurde

  • Am 7. März 2024 liefen die TLS-Zertifikate von tailscale.com und www.tailscale.com ab, wodurch der Zugriff auf die Website für etwa 90 Minuten unterbrochen war
  • Im Dezember 2023 migrierte Tailscale im Zuge eines größeren Website-Relaunchs zu einem neuen Hosting-Anbieter
  • Da der neue Hosting-Anbieter IPv6 nicht standardmäßig unterstützte, betrieb Tailscale einen eigenen Proxy zur Verarbeitung von IPv6-Anfragen und richtete zusätzliche AAAA-Records ein
  • Der Hosting-Anbieter wertete diese Konfiguration als „misconfiguration“ und verschickte eine Benachrichtigung, erwähnte dabei aber nicht ausdrücklich, dass diese Konfiguration den Abschluss der automatischen Zertifikatserneuerung verhinderte
  • Der Prober zur Überwachung des Zertifikatsablaufs prüfte nur den IPv6-Pfad
    • Der Prober lief über den eigenen Proxy
    • Der Proxy verfügte über ein separat verwaltetes, gültiges Zertifikat
    • Deshalb wurde das tatsächliche Auslaufen der Zertifikate von tailscale.com und www.tailscale.com nicht im Voraus sichtbar

Sichtbare Auswirkungen für Nutzer

  • Die Auswirkungen konzentrierten sich auf Materialien und Installationsabläufe, die von der Website abhängen
    • Die Tailscale-Dokumentation, der Blog und andere webbasierte Referenzmaterialien waren während des Ausfalls nicht erreichbar
    • Die Verwaltungskonsole und die Einstellungsseiten selbst waren nicht betroffen, aber Nutzer, die den direkten Aufruf von https://login.tailscale.com/ nicht kannten, konnten annehmen, dass diese Seite offline sei
    • Das Schnellinstallationsskript war nicht nutzbar, was einige Installationen und automatisierte Installationen beeinträchtigte
  • Die Domains, die die eigentliche Installation der Tailscale-Pakete bereitstellen, blieben erreichbar, und Unterbrechungen bei der Auflösung über Gos go get-Mechanismus waren dank Caching wohl minimal
  • Aufgrund des Designs von Tailscale erlebten die meisten Nutzer in den meisten Anwendungsfällen durch diesen Ausfall keine Unterbrechung, da das Netzwerk dank des Prinzips direkter Verbindungen weniger von der unmittelbaren Verfügbarkeit bestimmter Endpunkte wie tailscale.com abhängt

Wiederherstellung und Vermeidung künftiger Vorfälle

  • Nach Feststellung des Problems entfernte Tailscale vorübergehend die „zusätzlichen“ AAAA-Records und erneuerte die betroffenen Zertifikate manuell
  • Dadurch wurde die für Nutzer sichtbare Störung sofort behoben, und die Records wurden bald wiederhergestellt, um die Website und Dienste per IPv6 bereitzustellen
  • Das Problem mit der automatischen Erneuerung besteht weiterhin; kurzfristig plant das Unternehmen daher, Zertifikate direkt mit redundanten Kalendererinnerungen und festgelegten manuellen Erneuerungszeitpunkten zu erneuern
  • Die Prober-Infrastruktur soll so aktualisiert werden, dass IPv4- und IPv6-Endpunkte getrennt geprüft werden
  • Langfristig will Tailscale IPv6 in der Web-Infrastruktur direkter unterstützen, sodass kein eigener Proxy mehr erforderlich ist

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-04-01
Hacker-News-Meinungen

  • Ablaufende Zertifikate sind inzwischen wohl das neue DNS der Ausfälle.
    Trotzdem bin ich immer noch erstaunt, wie gut Tailscale gebaut ist. Ich bin eher ein leichter Nutzer, greife aber über Tailscale auf zwei Umgebungen zu: ein paar On-Premises-Server und unsere AWS-Produktionsumgebung.
    Ich kann von überall arbeiten. Am Wochenende wollte ich einen ECS-Container deployen, aber das lokale WLAN war so langsam, dass das Deployment ständig wegen Timeouts scheiterte.
    Also habe ich mich per SSH auf meine On-Premises-Entwicklungsmaschine eingeloggt, dort den neuesten Code mit git pull geholt und von dort aus deployed. Sowohl On-Premises als auch AWS waren ohne offene Ports abgesichert, und wenn auf einer kleinen EC2-Instanz in AWS nur der Tailscale-Agent läuft, kann ich auch die Produktions-Aurora-Datenbank ohne offene Ports testen.
    Auch wenn man anderen Entwicklern Netzwerkzugriff geben muss, ist Tailscale sehr einfach, und das Entziehen von Rechten ebenso. Dieses Deployment hätte man auch über GitHub Actions o. Ä. abwickeln können, um schlechte Internetverbindungen zu umgehen, aber ich wollte es manuell machen, und Tailscale hat das ermöglicht.

    • Auch bei Deployments mit GitHub Actions ist Tailscale weiterhin nützlich. Derzeit habe ich den SSH-Port einer Cloud-VM auf einem nicht standardmäßigen Port geöffnet, damit ein GHA-Worker per SSH hineinkommt und das Deployment starten kann.
      Künftig möchte ich diese Action nutzen, damit beliebige GHA-Worker ohne Port-Exposure auf die Deployment-Maschine zugreifen können: https://github.com/tailscale/github-action
    • Bei instabilen Verbindungen nutze ich mosh und GNU screen. Selbst wenn die Verbindung alle 10 Sekunden abreißt, funktioniert das erstaunlich gut.

  • Abgelaufene Zertifikate haben wieder einmal einen Ausfall verursacht.
    Als Teil der Postmortem-Analyse würde ich empfehlen, das Installationsskript von der Marketing-Website zu trennen oder einen alternativen Pfad vorzuhalten. Dann wären Aktivitäten auf der Marketing-Website unabhängig vom kritischen Pfad des Kundenbetriebs. Solche Dinge passieren häufig; umso bedauerlicher ist es, weil man offenbar schon fast bei einer üblichen Trennung angekommen war.
    Wenn man die Verfügbarkeit verschiedener Anbieter verfolgt, sieht man, dass Teile von GitHub- oder Zendesk-Websites häufiger ausfallen, als man erwarten würde. Und die gehören noch zu den besseren Beispielen.

    • Die Sicherheitspriorität einer Marketing-Website ist oft niedriger als die des eigentlichen Produkts, und ein Installationsskript sollte normalerweise auf einem ähnlichen Niveau wie das Produkt geschützt werden.
    • Ich frage mich, ob es einen Dienst gibt, der alle Zertifikate und Ablaufdaten überwacht.
      Cloudflare scheint einiges davon zu übernehmen, wenn man die Domain dort hostet, aber dann ist eben Cloudflare Voraussetzung.

  • Das ist derselbe Fehler, den wir bei einer früheren Firma gemacht haben. Auf der Startseite der Marketing-Site www.foo.com hatten wir einen Link zur Login-Seite der Web-App app.foo.com.
    Erst nach dem ersten Ausfall der Marketing-Site wurde uns klar, dass der 40-Dollar-Hosting-Plan pro Monat keine einfache Marketing-Site war, sondern kritische Infrastruktur. Im wahrsten Sinne des Wortes ein tragendes 40-Dollar-Hosting. Die App war nicht down, aber die Nutzer dachten, sie sei es.
    Ich habe gelernt, dass Nutzer meist einfach dem von uns angelegten Pfad folgen und oft nicht wissen, dass es andere Wege gibt; nimmt man diesen einen Pfad weg, ist ein Teil der Nutzer völlig verloren.

    • Wenn man im Browser tailscale eingibt, ist das erste Ergebnis tailscale.com. Ich nutze die Tailscale-Admin-Konsole nicht häufig genug, um mir extra eine andere URL zu merken.
      Früher hat der Browser bei Eingabe von cloudflare automatisch dash.cloudflare.com vervollständigt; nachdem ich die Website cloudflare.com genau einmal besucht hatte, wurde das zum ersten Ergebnis, und bei Cloudflare mache ich nun dasselbe.

  • Das Team ist wirklich gut, aber ich finde die Preise viel zu hoch. Ordentliche Zugriffskontrolle für ein VPN für 18 Dollar im Monat an die Geschäftsführung zu verkaufen, ist fast unmöglich, und die niedrigeren Tiers sind ohne diese Funktion schwer zu verkaufen.

    • Ich würde wirklich gern wissen, womit Tailscale intern verglichen wird. Tailscale macht weit mehr als ein einfaches VPN.
      Welche günstigeren Optionen gibt es, und bieten diese ebenfalls SSH-Funktionen, OAuth-basierte Netzwerkauthentifizierung für Automatisierungsdienste, den Aufbau von VPN-Node-Loadbalancern innerhalb eines Kubernetes-Clusters sowie automatische ACME-Zertifikatsanforderungen über Let’s Encrypt?
      Schon wenn ich nur ein paar der Funktionen aufzähle, die ich im kostenlosen Tier nutze, sind viele davon Dinge, die man normalerweise nicht als Aufgabe eines VPN-Dienstes ansehen würde. Es kommen laufend weitere Funktionen hinzu, daher halte ich es für eine ziemlich interessante und konkurrenzfähige Option. Eher bin ich überrascht, wie viel im günstigen Tier enthalten ist, weshalb mich diese Einschätzung umso mehr interessiert.
    • Dann kann man headscale installieren und selbst hosten, dann lässt es sich ohne Kosten nutzen.
      Es gibt auch konkurrierende Produkte, die sich teilweise mit Tailscale überschneiden, auch wenn sie vielleicht nicht genau zu dem passen, was man möchte.
      Allerdings liefen Teile unseres Projekts innerhalb weniger Minuten deutlich besser zusammen als zuvor.
      Für das, was es leistet, ist es eines der selten wirklich einfachen Tools, und auch das kostenlose Tier ist mit 100 Geräten und 3 Nutzern ziemlich großzügig.
    • Das ließ sich sehr leicht verkaufen. Wir sind von unserer OpenVPN-Konfiguration weggekommen, und Tailscale hat es viel einfacher gemacht, das Onboarding neuer Mitarbeiter und verschiedene andere Dinge auf die richtige Art zu erledigen. Als vollständig remote arbeitendes Unternehmen ist das noch wichtiger.
      Natürlich hatte ich in meiner Rolle durchaus Einfluss, die Geschäftsführung bei solchen Themen zu überzeugen, aber der Preis war kein Problem.
      Wir sind seit letztem April zufriedene Kunden, und alle nutzen Premium, also den teuren Tier. Auch die Entwicklungsgeschwindigkeit ist beeindruckend. Einige Funktionen, von denen es hieß, sie könnten Jahre dauern, wurden bereits im vergangenen Jahr veröffentlicht.
      Cloudflare One wäre ebenfalls eine Alternative gewesen, wäre aber wohl teurer gewesen.
    • Ich weiß nicht, welche Geschäftsführung an 18 Dollar im Monat scheitert. Pro Person betrachtet ist das im Vergleich zu den Dutzenden Dingen, die man für Mitarbeiter kauft, praktisch ein Betrag nahe null.
    • Das war der Hauptgrund, der uns zu Twingate gedrängt hat. Nach der Nutzung gefällt mir die Routing-Funktionalität bei Twingate etwas besser. Das heißt nicht, dass ich Tailscale nicht mag; wir nutzen beide je nach Einsatzzweck.

  • Ich frage mich, welchen Anbieter sie für die Website verwenden. Fast alle anderen Anbieter unterstützen IPv6, daher klingt es seltsam, dass wegen IPv6 so viele Umwege nötig sind.

    • Wenn man sich das Ergebnis von $ host www.tailscale.com ansieht, gehört die IPv4-Adresse 76.76.21.21 von www.tailscale.com zu Vercel, die IPv6-Adressen gehören zu Amazon.
      IPv4 nutzt ein Let’s-Encrypt-Zertifikat, IPv6 ein Amazon-Zertifikat.

  • Dass CI/CD und Monitoring so robust sind, dass man ihnen im Dezember einen großen Rollout anvertraut, ist wirklich beneidenswert. Die Engineering-Kultur wirkt ziemlich stark.
    Allerdings gibt es noch unbeantwortete Fragen. Wenn die IPv6-Konfiguration die automatische Zertifikatserneuerung für IPv4 kaputtgemacht hat, frage ich mich, warum das nicht schon viel früher passiert ist. Ebenso, warum die Behebung des Ausfalls ganze 90 Minuten gedauert hat. Es ist ein Blogbeitrag und keine echte Postmortem-Analyse, aber selbst ein kurzer Zeitplan wäre hilfreich gewesen.
    Außerdem frage ich mich, warum sie nicht zu einem DNS-Anbieter wechseln, der IPv6 nativ unterstützt. Und ob der Betriebsaufwand für eine separate Domain nur für Skripte oder Pakete den Nutzen wert ist. Abgesehen von Dritten wie Paket-Repositories frage ich mich, ob andere das auch so machen.

    • Soweit ich es verstehe, haben sie 90 Tage vor dem Ausfall auf die aktuelle Konfiguration umgestellt. Das bei der Migration installierte anfängliche Zertifikat hatte eine Laufzeit von 90 Tagen, daher trat der Ausfall 90 Tage nach der Migration auf.
    • Sie nutzen Vercel, und Vercel unterstützt kein IPv6.

  • Ich verstehe nicht, warum der Proxy TLS terminieren muss. Wenn es einfach ein TCP-Proxy gewesen wäre, hätte das Monitoring zumindest nicht fälschlich angenommen, dass das Zertifikat nicht kurz vor dem Ablauf steht.
    Außerdem hätte ein TCP-Proxy, wenn die Domain-Validierung per TLS-ALPN-Challenge erfolgte, möglicherweise auch die automatische Erneuerung ermöglicht.

    • Ein TCP-Proxy verwirft die IP-Adresse des Nutzers, sofern man nicht etwas wie das PROXY-Protokoll verwendet. Dafür müsste auch der Ziel-HTTPS-Server das unterstützen, und man bräuchte eine Methode, um zu verhindern, dass nicht autorisierte Nutzer eigene PROXY-Header einschleusen.
      Wenn man die Nutzer-IP überhaupt nicht braucht, ist das kein Problem, aber für Logs und Missbrauchserkennung ist sie oft nützlich.
      https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt
    • Kein riesiger Grund, aber HTTP/3 läuft nicht über TCP, und einen UDP-Proxy zu betreiben, dürfte nicht besonders angenehm sein.
    • Es gibt keinen Grund, TLS zu terminieren. Das war einer unserer Fehler und ist ein Arbeitspunkt, den wir beheben werden.
      Als wir zuerst feststellten, dass IPv6 kaputt war, haben wir in Eile einen Proxy aufgesetzt, und die Leute, die ihn damals eingerichtet haben, wussten nicht, wie ACME funktioniert.
      Wir werden ihn einfach auf einen TCP-Proxy umstellen.
    • Ein Proxy, der TLS nicht terminiert, lässt sich gut bei Diensten wie Hetzner betreiben. Wenn CAA korrekt gesetzt ist, überlässt man dem Anbieter nur Latenz und Verfügbarkeit und kann absurd teure Dienste wie CloudFront oder EC2-basierte Proxys vermeiden.
      Soweit ich sehe, nutzt Tailscale für pkgs.tailscale.com NetActuate. NetActuate könnte vermutlich dabei helfen, zu vernünftigen Preisen nicht terminierende Proxys an mehreren Standorten bereitzustellen. Preise stehen nicht auf der Website, aber es wirkt nicht wie ein Unternehmen, das auf ausgehenden Traffic eine 50-fache Marge aufschlägt.
    • Möglicherweise hatten sie für IPv6 ein AWS CloudFront CDN davor geschaltet. Dann würde CloudFront TLS terminieren, und soweit ich weiß, ist das keine Option, die man abwählen kann.

  • Wenn eine Organisation wie Tailscale in einem Bereich, der auch nur ein bisschen mit Sicherheit zu tun hat, auch nur einmal patzt, fühlt sich das für jemanden, der wie ich leicht paranoid ist, schon zu riskant an.
    Dafür braucht es eine bessere Erklärung.

  • Da es vermutlich Infrastruktur-Monitoring gibt, reichen 50 Zeilen Code, die für alle öffentlichen Domains per IPv4 und IPv6 verbinden und warnen, wenn ein Zertifikat in weniger als 19 Tagen abläuft. Die automatische Erneuerung lässt man 20 Tage vorher laufen, fertig.
    Nachdem wir in der Frühphase einer kleinen Firma ein paar SSL-Erneuerungen verpasst hatten, habe ich diesen Code vor Jahren geschrieben, und seitdem gab es keine SSL-bezogenen Ausfälle mehr.
    Kalendereinladungen sind nicht nötig; die einzige nötige Änderung ist genau das. Entscheidend ist der Punkt: „Wir aktualisieren die Prober-Infrastruktur, sodass IPv4- und IPv6-Endpunkte separat geprüft werden.“

  • Dort steht: „Diese Konfiguration wurde von dem Anbieter als Fehlkonfiguration betrachtet, sodass wir seit der Bereitstellung fortlaufend Warnungen erhalten haben.“
    Heißt das, sie haben 90 Tage lang zertifikatsbezogene Warnungen bekommen und dann ist das Zertifikat fehlgeschlagen?

    • Es klingt eher so, als hätten sie 90 Tage lang DNS-bezogene Warnungen erhalten, nicht Zertifikatswarnungen. Das Tailscale-Team wusste vor dem Vorfall offenbar nicht, dass Vercel die automatische Zertifikatserneuerung verweigert, wenn IPv6-/AAAA-DNS-Records vorhanden sind.
      Ich habe die tatsächliche Warnung nicht gesehen, daher weiß ich nicht, ob sie das klar mitgeteilt hat.