7 Mart 2024’te yaşanan Tailscale.com kesintisi olayı

• 7 Mart 2024’te süresi dolan TLS sertifikası nedeniyle tailscale.com yaklaşık 90 dakika boyunca kesintiye uğradı, ancak etki çoğunlukla dokümantasyon ve pazarlama sitesiyle sınırlı kaldı
• Sorun, Aralık 2023’teki web sitesi yenilemesi ve yeni hosting ortamına geçişten yaklaşık 90 gün sonra ortaya çıktı; IPv6 desteği olmayan ortamı telafi etmek için kurulan özel proxy yapılandırması otomatik yenilemeyi engelledi
• Sertifika süre sonu izleme probu yalnızca IPv6 yolunu kontrol ettiğinden, ayrı geçerli sertifikaya sahip proxy’nin arkasından geçerek tailscale.com ve www.tailscale.com için yaklaşan süre sonunu kaçırdı
• Genel Tailscale kullanımı çoğunlukla kesintiye uğramadı, ancak dokümantasyon, blog, install.sh ve doğrudan URL’yi bilmeyen kullanıcıların yönetim konsoluna erişim akışı etkilendi
• Tailscale, ek AAAA kaydını kaldırıp manuel yenileme yaparak hizmeti geri getirdi; kısa vadede manuel yenileme düzeni ve IPv4/IPv6 ayrı kontrolleri uygulayıp daha doğrudan IPv6 desteğini hedefliyor

---

Sertifika süre sonunun neden kaçırıldığı

• 7 Mart 2024’te tailscale.com ve www.tailscale.com için TLS sertifikalarının süresi doldu ve site erişimi yaklaşık 90 dakika boyunca kesildi
• Aralık 2023’te Tailscale, büyük bir web sitesi yenilemesiyle birlikte yeni bir hosting sağlayıcısına geçti
• Yeni hosting sağlayıcısı varsayılan olarak IPv6 desteklemediği için Tailscale, IPv6 isteklerini işlemek amacıyla kendi proxy’sini çalıştırdı ve ek AAAA kaydı tanımladı
• Hosting sağlayıcısı bu yapılandırmayı “misconfiguration” olarak değerlendirip uyarı gönderdi, ancak bu yapılandırmanın otomatik sertifika yenilemesinin tamamlanmasını engellediği uyarıda açıkça belirtilmedi
• Sertifika süre sonu izleme için kullanılan prob, yalnızca IPv6 yolunu kontrol etti
  • Prob, özel proxy üzerinden geçti
  • Proxy, ayrı yönetilen geçerli bir sertifikaya sahipti
  • Bu yüzden tailscale.com ve www.tailscale.com için gerçek sertifika süre sonu önceden fark edilmedi

Kullanıcılara yansıyan etki

• Etki, web sitesine bağlı kaynaklar ve kurulum akışlarında yoğunlaştı
  • Tailscale dokümantasyonu, blog ve diğer web tabanlı referans kaynakları kesinti sırasında erişilemez durumdaydı
  • Yönetim konsolu ve ayar sayfasının kendisi etkilenmedi, ancak https://login.tailscale.com/ adresine doğrudan gitmeyi bilmeyen kullanıcılar bu sayfanın çevrimdışı olduğunu düşünebilirdi
  • Hızlı kurulum betiği kullanılamadığı için bazı kurulumlar ve otomatik kurulumlar aksadı
• Tailscale paket kurulumunu fiilen sağlayan alan adları erişilebilirdi ve Go’nun go get mekanizması üzerinden çözümlemenin durmasının, önbellekleme sayesinde sınırlı kaldığı değerlendirildi
• Tailscale’in tasarımı gereği, kullanıcıların büyük bölümü çoğu kullanım senaryosunda bu kesintiden etkilenmedi; doğrudan bağlantı ilkesi sayesinde ağ, tailscale.com gibi belirli uç noktaların anlık erişilebilirliğine daha az bağımlı

Kurtarma ve tekrarını önleme

• Sorun tespit edildikten sonra Tailscale, “ek” AAAA kaydını geçici olarak kaldırdı ve ilgili sertifikaları manuel olarak yeniledi
• Bu adımla kullanıcıların gördüğü kesinti hemen giderildi ve site ile hizmetleri IPv6 üzerinden sunmak için kayıt kısa süre sonra geri yüklendi
• Otomatik yenileme sorunu devam ettiğinden, kısa vadede yinelenen takvim hatırlatmaları ve belirlenmiş manuel yenileme zamanlarıyla sertifikaları doğrudan yenilemeyi planlıyor
• Prob altyapısı, IPv4 ve IPv6 uç noktalarını ayrı ayrı kontrol edecek şekilde güncellenecek
• Uzun vadede hedef, web sitesi altyapısında IPv6’yı daha doğrudan destekleyerek özel proxy ihtiyacını ortadan kaldırmak

[GN⁺]

Hacker News yorumları

• Süresi dolan sertifikalar artık kesintilerin yeni DNS’i gibi görünüyor
  Yine de Tailscale’in ne kadar iyi yapılmış olduğuna hâlâ şaşırıyorum. Daha çok hafif bir kullanıcı sayılırım ama birkaç şirket içi sunucuya ve AWS prodüksiyon ortamına Tailscale ile erişiyorum
  Her yerden çalışabiliyorum. Hafta sonu bir ECS konteyneri dağıtmaya çalışıyordum; yerel Wi-Fi o kadar yavaştı ki dağıtım sürekli zaman aşımına uğradı
  Bu yüzden şirket içindeki geliştirme makinesine SSH ile girip en güncel kodu git pull ile çektim ve dağıtımı oradan yaptım. Hem şirket içi ortam hem de AWS, açık port olmadan güvenli durumdaydı; AWS’teki küçük bir EC2 üzerinde yalnızca Tailscale ajanını çalıştırarak prodüksiyon Aurora veritabanını da açık port olmadan test edebiliyorum
  Başka bir geliştiriciye ağ erişimi vermek gerektiğinde de Tailscale bunu çok kolaylaştırıyor; erişimi geri almak da aynı şekilde. Bu dağıtımı GitHub Actions gibi bir şeyle yapıp kötü internet sorununu aşabilirdim ama manuel yapmak istedim ve Tailscale bunu mümkün kıldı

  • GitHub Actions ile dağıtım yaparken de Tailscale hâlâ kullanışlı. Şu anda GHA worker’ın SSH ile girip dağıtımı başlatabilmesi için bulut VM’in SSH portunu standart dışı bir porttan açık tutuyorum
    İleride herhangi bir GHA worker’ın port açmadan dağıtım makinesine erişebilmesi için şu action’ı kullanmayı düşünüyorum: https://github.com/tailscale/github-action
  • Kararsız bağlantılarda mosh ve GNU screen kullanıyorum. Her 10 saniyede bir kopsa bile şaşırtıcı derecede iyi çalışıyor

• Süresi dolan sertifika yine bir kazaya yol açmış
  Olay sonrası analizin bir parçası olarak kurulum betiğini pazarlama sitesinden ayırmayı ya da başka bir alternatif yol koymayı öneririm. Böylece pazarlama sitesi faaliyetleri, müşterilerin operasyonlarının kritik yoluyla ilgisiz hale gelir. Bu tür şeyler sık yaşandığı için, normal bir ayrımı korumaya neredeyse ulaşılmışken olması daha da üzücü
  Birden fazla sağlayıcının çalışma süresini izlediğinizde GitHub ya da Zendesk sitelerinin bazı bölümlerinin beklenenden daha sık çöktüğünü görüyorsunuz. Üstelik bunlar nispeten iyi örnekler

  • Pazarlama sitesinin güvenlik önceliği çoğu zaman ürünün kendisinden daha düşüktür; kurulum betikleri ise genelde ürünle benzer seviyede korunmalıdır
  • Tüm sertifikaları ve son kullanma tarihlerini izleyen bir servis olup olmadığını merak ediyorum
    Cloudflare, alan adını orada barındırırsanız bu kısmı epey hallediyor gibi görünüyor ama bunun şartı Cloudflare kullanmak

• Eski şirketimde yaptığımız hatanın aynısı. Pazarlama sitesi www.foo.com ana sayfasına web uygulaması giriş sayfası app.foo.com için bağlantı koymuştuk
  İlk pazarlama sitesi kesintisi yaşanana kadar, aylık 40 dolarlık hosting planının basit bir pazarlama sitesi değil, kritik altyapı olduğunu fark etmemiştik. Kelimenin tam anlamıyla yük taşıyan 40 dolarlık bir hosting’di. Uygulama çökmedi ama kullanıcılar çöktüğünü sandı
  Kullanıcıların çoğu, bizim oluşturduğumuz yolu izler; başka bir yol olduğunu bilmez. O tek yolu kaldırdığınızda kullanıcıların bir kısmının tamamen yolunu kaybettiğini öğrendik

  • Tarayıcıya tailscale yazınca ilk sonuç tailscale.com oluyor. Tailscale yönetici konsolunu sık kullanmadığım için başka bir URL ezberlemiyorum
    Eskiden cloudflare yazdığımda tarayıcı dash.cloudflare.com adresini otomatik tamamlardı; ama cloudflare.com web sitesini sadece bir kez ziyaret ettikten sonra ilk sonuç o oldu ve Cloudflare’da da aynı şeyi yapmaya başladım

• Bu ekip gerçekten iyi ama fiyatların aşırı yüksek olduğunu düşünüyorum. Düzgün erişim denetimi için VPN’e ayda 18 dolar ödemeyi yönetime satmak neredeyse imkânsız; düşük katmanları da o özellik olmadan satmak zor

  • İçeride Tailscale’i neyle karşılaştırdıklarını gerçekten merak ediyorum. Tailscale basit bir VPN’den çok daha fazlasını yapıyor
    Daha ucuz seçenekler neler ve onlar da SSH özellikleri, otomasyon servisleri için OAuth ağ kimlik doğrulaması, Kubernetes kümesi içinde VPN node load balancer yapılandırması, Let’s Encrypt üzerinden ACME sertifika isteği otomasyonu sunuyor mu merak ediyorum
    Sadece ücretsiz katmanda kullandığım birkaç özelliği saysam bile, bunların çoğu genelde bir VPN servisinin rolü olarak düşünülmeyen şeyler. Özellikler de sürekli ekleniyor; bence oldukça ilginç ve rekabetçi bir seçenek. Hatta düşük fiyatlı katmanlarda sunduklarının çok fazla olmasına şaşırıyorum; bu yüzden bu değerlendirmeyi daha da merak ediyorum
  • O zaman headscale kurup kendi barındırmanızla ücretsiz kullanabilirsiniz
    Tailscale ile kısmen örtüşen rakip ürünler de var; istediğiniz şeyle birebir uyuşmayabilirler
    Yine de birkaç dakika içinde projenin bazı parçaları eskisinden çok daha iyi birlikte çalışır hale geldi
    Yaptığı işe kıyasla gerçekten nadir görülen derecede basit araçlardan biri; ücretsiz katmanı da 100 cihaz ve 3 kullanıcıyla oldukça cömert
  • Bunu ikna etmek çok kolaydı. OpenVPN yapılandırmasından kurtulduk ve Tailscale sayesinde yeni çalışan onboarding’i ile birçok şeyi doğru şekilde yapmak çok daha kolaylaştı. Tamamen uzaktan çalışan bir şirket olduğumuz için bu daha da önemli
    Elbette rolüm gereği bu konularda yönetimi ikna etme konusunda epey etkim vardı ama fiyat sorun olmadı
    Geçen yıl nisandan beri memnun bir müşteriyiz ve herkes premium, yani pahalı katmanı kullanıyor. Geliştirme hızı da etkileyici. Yıllar sürebileceği söylenen bazı özellikler daha geçen yıl yayımlandı
    Cloudflare One da alternatif olabilirdi ama muhtemelen daha pahalı olurdu
  • Hangi yönetimin ayda 18 dolara takıldığını bilmiyorum. Kişi başı maliyet olarak bakınca, çalışanlar için alınan onlarca şey arasında neredeyse sıfıra yakın bir maliyet
  • Bizi Twingate’e iten temel neden buydu. Kullanınca yönlendirme özelliklerini Twingate tarafında biraz daha fazla sevmeye başladım. Tailscale’den hoşlanmadığım anlamına gelmiyor; ikisini de kullanım amacına göre kullanıyoruz

• Web sitesi sağlayıcısı olarak kimi kullandıklarını merak ediyorum. Neredeyse diğer tüm sağlayıcılar IPv6 desteği veriyor; IPv6 yüzünden bu kadar çok dolambaçlı yol izlemek zorunda kalmaları garip geliyor

  • $ host www.tailscale.com çıktısına bakınca, www.tailscale.com için IPv4 adresi 76.76.21.21 Vercel, IPv6 adresleri ise Amazon
    IPv4 Let’s Encrypt sertifikası kullanıyor, IPv6 ise Amazon sertifikası kullanıyor

• Aralık ayında büyük ölçekli bir rollout’u gönül rahatlığıyla yapabilecek kadar CI/CD ve izleme altyapılarının sağlam olması gerçekten imrenilecek bir şey. Mühendislik kültürleri epey güçlü görünüyor.
  Ancak hâlâ yanıtlanmamış sorular var. IPv6 yapılandırması IPv4’ün otomatik sertifika yenilemesini bozduysa bunun neden çok daha önce yaşanmadığını merak ediyorum. Kesintinin giderilmesinin neden 90 dakika sürdüğünü de merak ediyorum. Bu bir blog yazısı ve gerçek bir olay sonrası analiz değil ama en azından kısa bir zaman çizelgesi olsaydı iyi olurdu.
  Ayrıca neden IPv6’yı yerel olarak destekleyen bir DNS sağlayıcısına geçmediklerini de merak ediyorum. Betikler veya paketlere özel ayrı bir domain tutmanın operasyonel yüküne değip değmediğini de merak ediyorum. Paket depoları gibi üçüncü taraflar hariç, başka yerlerin de bunu böyle yapıp yapmadığını merak ediyorum.

  • Anladığım kadarıyla kesintiden 90 gün önce mevcut yapılandırmaya geçmişler. Geçiş sırasında kurulan ilk sertifika 90 günlüktü; dolayısıyla kesinti geçişten 90 gün sonra yaşanmış oldu.
  • Vercel kullanıyorlar ve Vercel’in IPv6 desteği yok.

• Proxy’nin neden TLS’i sonlandırması gerektiğini anlamıyorum. Sadece bir TCP proxy olsaydı, en azından izleme sistemi sertifikanın süresinin dolmak üzere olmadığı yanılgısına düşmezdi.
  Üstelik domain doğrulaması TLS-ALPN challenge ile yapılıyorsa, TCP proxy otomatik yenilemeyi de mümkün kılabilirdi.

  • TCP proxy, PROXY protokolü gibi bir şey kullanılmadığı sürece kullanıcı IP adresini kaybeder. Bunun için hedef HTTPS sunucusunun da bunu desteklemesi gerekir ve yetkisiz kullanıcıların kendi PROXY başlıklarını enjekte etmesini engellemenin bir yoluna da ihtiyaç vardır.
    Kullanıcı IP’sine hiç ihtiyaç yoksa sorun değil, ama loglar ve kötüye kullanım tespiti için çoğu zaman faydalıdır.
    https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt
  • Çok büyük bir sebep değil ama HTTP/3 TCP üzerinde çalışmaz; UDP proxy işletmek de pek keyifli bir iş olmasa gerek.
  • TLS’i sonlandırmaya gerek yok. Bu bizim hatalarımızdan biriydi ve düzelteceğimiz iş kalemlerinden biri.
    İlk kez IPv6’nın bozuk olduğunu fark ettiğimizde aceleyle bir proxy kurduk; o sırada proxy’yi kuran kişiler ACME’nin nasıl çalıştığını bilmiyordu.
    Bunu sadece TCP proxy’ye çevirmeyi planlıyoruz.
  • TLS’i sonlandırmayan bir proxy, Hetzner gibi bir serviste çalıştırmak için uygundur. CAA’yı düzgün yapılandırırsanız sağlayıcıya yalnızca gecikme ve erişilebilirliği emanet etmiş olursunuz; CloudFront veya EC2 tabanlı proxy gibi saçma derecede pahalı servislerden de kaçınabilirsiniz.
    Görünüşe göre Tailscale pkgs.tailscale.com için NetActuate kullanıyor. NetActuate, makul bir fiyata birden çok noktada uçta sonlandırmayan proxy sunmaya yardımcı olabilir gibi görünüyor. Web sitesinde fiyat yok ama çıkış trafiğine 50 kat marj koyan bir şirket gibi durmuyor.
  • IPv6 için ön tarafa AWS CloudFront CDN koymuş olabilirler. Böyle yapınca TLS CloudFront’ta sonlandırılır ve bildiğim kadarıyla bu isteğe bağlı değildir.

• Tailscale gibi güvenlikle az da olsa temas eden bir alanda çalışan bir kuruluş bir kez bile tökezlediğinde, benim gibi biraz paranoyak biri için bile fazla riskli hissettiriyor.
  Bu konuda daha iyi bir açıklamaya ihtiyaç var.

• Zaten altyapı izlemesi vardır; tüm herkese açık domain’lere IPv4 ve IPv6 üzerinden bağlanıp sertifika 19 gün içinde sona erecekse uyarı veren 50 satır kod eklemek yeterli. Otomatik yenilemeyi de 20 gün öncesinden çalıştırırsınız, biter.
  Küçük şirketin ilk dönemlerinde SSL yenilemeyi birkaç kez kaçırdıktan sonra bu kodu yıllar önce yazdım; o zamandan beri SSL kaynaklı kesinti yaşanmadı.
  Takvim davetine gerek yok; gereken düzeltme tek başına bu. “Prober altyapısını IPv4 ve IPv6 endpoint’lerini ayrı ayrı kontrol edecek şekilde güncelleyeceğiz” kısmı asıl önemli nokta.

• “Bu yapılandırma ilgili sağlayıcı tarafından yanlış yapılandırma olarak değerlendirildiği için, dağıtımdan itibaren sürekli uyarı alıyorduk” deniyor.
  Yani 90 gün boyunca sertifikayla ilgili uyarılar alıp sonunda sertifika mı başarısız oldu?

  • 90 gün boyunca sertifika uyarısı almaktan çok, 90 gün boyunca DNS ile ilgili uyarı almışlar gibi görünüyor. IPv6/AAAA DNS kaydı varsa Vercel’in otomatik sertifika yenilemeyi reddettiğini Tailscale ekibi olaydan önce bilmiyor gibiydi.
    Gerçek uyarıyı görmediğim için, bu uyarının bu durumu açıkça belirtip belirtmediğini bilmiyorum.