7 मार्च 2024 को हुई Tailscale.com आउटेज घटना

 (tailscale.com)
2 पॉइंट द्वारा GN⁺ 2024-04-01 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • 7 मार्च 2024 को समाप्त हुए TLS प्रमाणपत्र के कारण tailscale.com लगभग 90 मिनट तक बंद रहा, लेकिन प्रभाव मुख्यतः दस्तावेज़ और मार्केटिंग साइट तक सीमित रहा
  • दिसंबर 2023 में वेबसाइट के बड़े पुनर्गठन और नए होस्टिंग पर माइग्रेशन के लगभग 90 दिन बाद यह समस्या सामने आई, और स्व-प्रबंधित प्रॉक्सी कॉन्फ़िगरेशन, जो IPv6 सपोर्ट न होने की भरपाई के लिए बनाया गया था, ऑटो-रिन्यूअल में बाधा बना
  • प्रमाणपत्र समाप्ति की निगरानी करने वाला प्रोबर केवल IPv6 पाथ की जाँच कर रहा था, और अलग वैध प्रमाणपत्र वाले प्रॉक्सी से होकर गुजरने के कारण tailscale.com और www.tailscale.com के वास्तविक प्रमाणपत्रों की निकट आती समाप्ति को नहीं पकड़ सका
  • सामान्य Tailscale उपयोग अधिकांशतः बाधित नहीं हुआ, लेकिन दस्तावेज़, ब्लॉग, install.sh, और वे उपयोगकर्ता जो सीधे URL नहीं जानते थे, उनके लिए मैनेजमेंट कंसोल तक पहुँचने की प्रक्रिया प्रभावित हुई
  • Tailscale ने अतिरिक्त AAAA रिकॉर्ड हटाकर और मैन्युअल रिन्यूअल करके सेवा बहाल की, और अल्पकाल में मैन्युअल रिन्यूअल व्यवस्था व IPv4/IPv6 अलग-अलग जाँच के बाद अधिक प्रत्यक्ष IPv6 सपोर्ट का लक्ष्य रखा है

प्रमाणपत्र समाप्ति क्यों नहीं पकड़ी गई

  • 7 मार्च 2024 को tailscale.com और www.tailscale.com के TLS प्रमाणपत्र समाप्त हो गए, जिससे लगभग 90 मिनट तक साइट एक्सेस बाधित रही
  • दिसंबर 2023 में Tailscale ने बड़े वेबसाइट पुनर्गठन के साथ नए होस्टिंग प्रदाता पर माइग्रेट किया
  • नए होस्टिंग प्रदाता ने डिफ़ॉल्ट रूप से IPv6 सपोर्ट नहीं दिया, इसलिए Tailscale ने IPv6 अनुरोधों को संभालने के लिए अपना प्रॉक्सी चलाया और अतिरिक्त AAAA रिकॉर्ड सेट किए
  • होस्टिंग प्रदाता ने इस कॉन्फ़िगरेशन को “misconfiguration” मानकर अलर्ट भेजा, लेकिन अलर्ट में यह स्पष्ट नहीं था कि यही कॉन्फ़िगरेशन स्वचालित प्रमाणपत्र रिन्यूअल पूरा होने से रोक रहा है
  • प्रमाणपत्र समाप्ति की निगरानी के लिए प्रोबर केवल IPv6 पाथ की जाँच कर रहा था
    • प्रोबर स्व-प्रबंधित प्रॉक्सी से होकर गुजरता था
    • प्रॉक्सी के पास अलग से प्रबंधित एक वैध प्रमाणपत्र था
    • इस वजह से tailscale.com और www.tailscale.com के वास्तविक प्रमाणपत्रों की समाप्ति पहले से दिखाई नहीं दी

उपयोगकर्ताओं को दिखा प्रभाव

  • प्रभाव उन संसाधनों और इंस्टॉलेशन फ़्लो पर केंद्रित था जो वेबसाइट पर निर्भर थे
    • Tailscale दस्तावेज़, ब्लॉग, और अन्य वेबसाइट-आधारित संदर्भ सामग्री आउटेज के दौरान उपलब्ध नहीं थी
    • मैनेजमेंट कंसोल और सेटिंग पेज स्वयं प्रभावित नहीं थे, लेकिन जो उपयोगकर्ता https://login.tailscale.com/ पर सीधे जाना नहीं जानते थे, वे मान सकते थे कि वह पेज ऑफ़लाइन है
    • क्विक इंस्टॉल स्क्रिप्ट उपलब्ध नहीं थी, जिससे कुछ इंस्टॉलेशन और ऑटोमेटेड इंस्टॉल प्रभावित हुए
  • जिन डोमेन्स से वास्तव में Tailscale पैकेज इंस्टॉल होते हैं वे उपलब्ध रहे, और Go के go get मैकेनिज़्म के जरिए रिज़ॉल्यूशन रुकने का असर caching के कारण न्यूनतम रहा माना गया
  • Tailscale के डिज़ाइन के कारण अधिकांश उपयोगकर्ताओं को अधिकांश उपयोग मामलों में इस आउटेज से रुकावट नहीं हुई, और direct connection सिद्धांत की वजह से नेटवर्क tailscale.com जैसे किसी एक एंडपॉइंट की तत्काल उपलब्धता पर कम निर्भर है

रिकवरी और पुनरावृत्ति रोकथाम

  • समस्या की पुष्टि होने के बाद Tailscale ने “अतिरिक्त” AAAA रिकॉर्ड अस्थायी रूप से हटाए और संबंधित प्रमाणपत्रों को मैन्युअल रूप से रिन्यू किया
  • इस कदम से उपयोगकर्ताओं को दिखने वाली आउटेज तुरंत समाप्त हो गई, और साइट व सेवाओं को IPv6 पर उपलब्ध कराने के लिए रिकॉर्ड जल्द ही बहाल कर दिए गए
  • ऑटो-रिन्यूअल की समस्या बनी हुई है, इसलिए अल्पकाल में कंपनी डुप्लिकेट कैलेंडर अलर्ट और निर्धारित मैन्युअल रिन्यूअल समय के साथ प्रमाणपत्रों को सीधे रिन्यू करने की योजना बना रही है
  • प्रोबर इन्फ्रास्ट्रक्चर को IPv4 और IPv6 एंडपॉइंट्स की अलग-अलग जाँच करने के लिए अपडेट किया जाएगा
  • दीर्घकाल में लक्ष्य यह है कि वेबसाइट इन्फ्रास्ट्रक्चर में IPv6 को अधिक प्रत्यक्ष रूप से सपोर्ट किया जाए ताकि स्व-प्रबंधित प्रॉक्सी की आवश्यकता न रहे

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-04-01
Hacker News की राय

  • अब expiring certificates को outage का नया DNS कहना चाहिए
    फिर भी Tailscale कितना अच्छी तरह बनाया गया है, यह अब भी हैरान करता है। मैं heavy user नहीं हूँ, लेकिन कुछ on-prem servers और AWS production environment — इन दोनों तक Tailscale से access करता हूँ
    कहीं से भी काम कर सकता हूँ। वीकेंड पर ECS container deploy करने की कोशिश कर रहा था, लेकिन local Wi‑Fi इतना धीमा था कि deployment बार-बार timeout हो रहा था
    इसलिए on-prem development machine में SSH किया, latest code के लिए git pull चलाया और वहीं से deploy कर दिया। On-prem और AWS दोनों बिना खुले ports के सुरक्षित रहे, और AWS में किसी छोटे EC2 पर सिर्फ Tailscale agent चलाकर production Aurora database को भी बिना खुले ports के test किया जा सकता है
    जब किसी दूसरे developer को network access देना हो, तब भी Tailscale बहुत आसान है, और access revoke करना भी उतना ही आसान है। इस deployment को GitHub Actions जैसी किसी चीज़ से भी किया जा सकता था ताकि खराब internet की समस्या से बचा जा सके, लेकिन मैं इसे manually करना चाहता था, और Tailscale ने यह संभव बनाया

    • GitHub Actions से deploy करते समय भी Tailscale अब भी उपयोगी है। अभी मैं cloud VM के SSH port को एक non-standard port पर खोलकर रखता हूँ ताकि GHA worker SSH करके deployment शुरू कर सके
      आगे मैं यह action इस्तेमाल करना चाहता हूँ ताकि कोई भी GHA worker port expose किए बिना deployment machine तक पहुँच सके: https://github.com/tailscale/github-action
    • unstable connection पर मैं mosh और GNU screen इस्तेमाल करता हूँ। हर 10 सेकंड में disconnect हो तब भी यह हैरान करने लायक अच्छी तरह काम करता है

  • expired certificate ने फिर गड़बड़ की
    मेरा सुझाव है कि postmortem के हिस्से के रूप में install script को marketing site से अलग किया जाए, या कोई alternate path रखा जाए। इससे marketing site activity ग्राहक operations के critical path से अलग हो जाएगी। ऐसी घटनाएँ आम हैं, इसलिए सामान्य isolation बनाए रखने के इतने करीब पहुँचकर भी यह चूक होना और खलता है
    अगर कई providers की uptime ट्रैक करें, तो GitHub या Zendesk की साइट के कुछ हिस्सों का down होना उम्मीद से ज़्यादा आम है। वैसे ये फिर भी अच्छे उदाहरणों में आते हैं

    • marketing site की security priority अक्सर product से कम होती है, जबकि install script को आम तौर पर product के बराबर स्तर की सुरक्षा मिलनी चाहिए
    • सोच रहा हूँ कि क्या कोई ऐसी service है जो सभी certificates और उनकी expiry dates monitor करे
      लगता है Cloudflare यह काम काफी हद तक कर देता है अगर domain वहीं host हो, लेकिन शर्त यह है कि Cloudflare इस्तेमाल करना पड़ेगा

  • यह बिल्कुल वही गलती है जो मैंने एक पुरानी कंपनी में की थी। Marketing site www.foo.com के home पर web app login page app.foo.com का link लगाया था
    marketing site का पहला outage होने के बाद ही समझ आया कि महीने का $40 hosting plan कोई साधारण marketing site नहीं, बल्कि critical infrastructure था। सचमुच load झेलने वाला 40 डॉलर का hosting था। App down नहीं था, लेकिन users को लगा कि down है
    मैंने सीखा कि users अक्सर सिर्फ वही रास्ता अपनाते हैं जो हमने उनके लिए बनाया है; उन्हें यह पता ही नहीं होता कि कोई दूसरा रास्ता भी है। और अगर वह एक रास्ता हटा दो, तो कुछ users पूरी तरह भटक जाते हैं

    • browser में tailscale टाइप करने पर पहला result tailscale.com आता है। मैं Tailscale admin console इतना अक्सर इस्तेमाल नहीं करता कि कोई अलग URL याद रखूँ
      पहले cloudflare लिखने पर browser अपने-आप dash.cloudflare.com autocomplete कर देता था, लेकिन cloudflare.com website पर सिर्फ एक बार जाने के बाद वही पहला result बन गया, और Cloudflare में भी मैं वही करने लगा

  • टीम वाकई अच्छी है, लेकिन मेरी राय में pricing बहुत ज़्यादा है। ठीक-ठाक access control के लिए VPN पर महीने के 18 डॉलर देना management को बेचना लगभग नामुमकिन है, और lower tier को उस feature के बिना बेचना भी मुश्किल है

    • मैं सच में जानना चाहता हूँ कि लोग अंदरूनी तौर पर Tailscale की तुलना किससे करते हैं। Tailscale साधारण VPN से कहीं ज़्यादा काम करता है
      सस्ता विकल्प क्या है, और क्या वे भी SSH features, automation services के लिए OAuth network auth, Kubernetes cluster के अंदर VPN node load balancer configuration, और Let’s Encrypt के ज़रिए ACME certificate request automation देते हैं?
      सिर्फ free tier में जो features मैं इस्तेमाल कर रहा हूँ, उनमें भी कई ऐसी चीज़ें हैं जिन्हें आम तौर पर VPN service की भूमिका नहीं माना जाता। Features लगातार जुड़ भी रहे हैं, इसलिए यह काफ़ी दिलचस्प और competitive option लगता है। बल्कि low-cost tier में इतना कुछ मिलना ही मुझे चौंकाता है, इसलिए यह राय और भी दिलचस्प लगती है
    • तब headscale install करके self-host किया जा सकता है और बिना लागत के इस्तेमाल किया जा सकता है
      Tailscale से आंशिक रूप से overlap करने वाले कुछ competitors भी हैं, और हो सकता है वे आपकी ज़रूरत से पूरी तरह मेल न खाएँ
      लेकिन कुछ ही मिनटों में project के कुछ हिस्से पहले से कहीं बेहतर तरीके से एक-दूसरे से जुड़कर चलने लगे
      यह उन दुर्लभ tools में से एक है जो अपने काम के मुकाबले सचमुच बहुत simple हैं, और free tier भी 100 devices और 3 users के साथ काफी उदार है
    • इसे समझाना बहुत आसान था। हम OpenVPN configuration से बाहर आए, और Tailscale की वजह से नए employees का onboarding और कई दूसरे काम सही तरीके से करना बहुत आसान हो गया। पूरी तरह remote company होने के कारण यह और भी अहम है
      हाँ, मेरी भूमिका ऐसी है कि ऐसे विषयों पर management को मनाने में मेरा प्रभाव काफ़ी है, लेकिन price कोई समस्या नहीं थी
      मैं पिछले साल अप्रैल से संतुष्ट ग्राहक हूँ, और सब लोग premium यानी महँगे tier पर हैं। Development speed भी प्रभावशाली है। जिन कुछ features के लिए कहा गया था कि आने में कई साल लग सकते हैं, वे पिछले साल ही ship हो गए
      Cloudflare One भी एक alternative हो सकता था, लेकिन वह और महँगा पड़ता
    • समझ नहीं आता कि कौन-सा management महीने के $18 पर अटक जाता है। प्रति व्यक्ति लागत के हिसाब से देखें तो कर्मचारियों के लिए खरीदी जाने वाली दर्जनों चीज़ों में यह लगभग शून्य के बराबर है
    • यही वह मुख्य वजह थी जिसने हमें Twingate की ओर धकेला। इस्तेमाल करने के बाद routing functionality में मुझे Twingate थोड़ा ज़्यादा पसंद आया। इसका मतलब यह नहीं कि मैं Tailscale को नापसंद करता हूँ; हम दोनों को अलग-अलग उपयोग के लिए इस्तेमाल करते हैं

  • जानना चाहता हूँ कि वे website provider के रूप में किसका इस्तेमाल करते हैं। लगभग बाकी सभी providers IPv6 support देते हैं, इसलिए IPv6 की वजह से इतने workaround करने पड़ना अजीब लगता है

    • $ host www.tailscale.com के result को देखें तो www.tailscale.com का IPv4 address 76.76.21.21 Vercel का है, और IPv6 addresses Amazon के हैं
      IPv4 में Let’s Encrypt certificate इस्तेमाल होता है, और IPv6 में Amazon certificate इस्तेमाल होता है

  • दिसंबर में बड़े पैमाने पर rollout पर भरोसा करके आगे बढ़ सकना, इसका मतलब CI/CD और monitoring वाकई बहुत मज़बूत हैं — यह सच में ईर्ष्या करने लायक है। Engineering culture भी काफ़ी मज़बूत लगती है
    लेकिन अभी भी कुछ सवालों के जवाब नहीं मिले हैं। अगर IPv6 configuration ने IPv4 के automatic certificate renewal को तोड़ा, तो यह बहुत पहले क्यों नहीं हुआ — यह जानने की उत्सुकता है। outage को ठीक करने में 90 मिनट क्यों लगे, यह भी जानना चाहता हूँ। यह ब्लॉग पोस्ट है, असली postmortem नहीं, लेकिन एक साधारण timeline भी होती तो अच्छा रहता
    और यह भी जानना चाहता हूँ कि वे ऐसे DNS provider पर migrate क्यों नहीं करते जो IPv6 को native रूप से support करता हो। सिर्फ scripts या packages के लिए अलग domain रखना जितना operational burden लाता है, क्या वह वाकई उसके लायक है? package repository जैसे third party को छोड़कर, क्या और जगहें भी ऐसा करती हैं — यह भी जानना चाहता हूँ

    • मेरी समझ से, outage से 90 दिन पहले इन्होंने current configuration पर switch किया था। migration के समय install किया गया शुरुआती certificate 90 दिन के लिए था, इसलिए migration के 90 दिन बाद outage हुआ
    • ये Vercel का इस्तेमाल कर रहे हैं, और Vercel में IPv6 support नहीं है

  • समझ नहीं आता कि proxy को TLS terminate करने की ज़रूरत क्यों है। अगर यह सिर्फ़ TCP proxy होता, तो कम से कम monitoring यह गलतफ़हमी नहीं पालती कि certificate expiry पास नहीं है
    ऊपर से, अगर domain validation TLS-ALPN challenge से हो रही थी, तो TCP proxy शायद automatic renewal भी संभव बना सकता था

    • TCP proxy, जब तक PROXY protocol जैसी किसी चीज़ का उपयोग न करे, user IP address खो देता है। और इसके लिए target HTTPS server को भी इसे support करना होगा, साथ ही यह रोकने का तरीका चाहिए कि unauthorized user अपना PROXY header inject न कर सके
      अगर user IP की बिल्कुल ज़रूरत नहीं है तो यह समस्या नहीं, लेकिन logs और abuse detection में यह अक्सर उपयोगी होता है
      https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt
    • बहुत बड़ा कारण तो नहीं, लेकिन HTTP/3 TCP के ऊपर नहीं चलता, और UDP proxy चलाना शायद बहुत सुखद काम नहीं होगा
    • TLS terminate करने की ज़रूरत नहीं है। यह हमारी गलतियों में से एक था, और इसे ठीक करना हमारी action items में शामिल है
      जब हमें पहली बार पता चला कि IPv6 टूटा हुआ है, तब हमने जल्दी में proxy खड़ा किया था, और उस समय proxy सेट करने वाले लोगों को ACME के काम करने का तरीका नहीं पता था
      हम इसे बस TCP proxy में बदलने वाले हैं
    • जो proxy TLS terminate नहीं करता, वह Hetzner जैसी service पर तैनात करने के लिए अच्छा रहता है। अगर CAA ठीक से set किया जाए, तो आप provider पर सिर्फ latency और availability छोड़ते हैं, और CloudFront या EC2 आधारित proxy जैसी बेवजह महंगी services से बच सकते हैं
      देखकर लगता है कि Tailscale pkgs.tailscale.com के लिए NetActuate का उपयोग करता है। NetActuate शायद उचित कीमत पर कई locations से non-terminating proxy उपलब्ध कराने में मदद कर सकता है। उनकी website पर pricing नहीं है, लेकिन यह ऐसी कंपनी नहीं लगती जो egress traffic पर 50x margin लगाती हो
    • हो सकता है उन्होंने IPv6 के लिए सामने AWS CloudFront CDN लगाया हो। उस स्थिति में CloudFront पर TLS terminate करना पड़ता, और मेरी जानकारी में यह optional नहीं है

  • अगर Tailscale जैसी organization security से ज़रा भी जुड़े किसी क्षेत्र में एक बार भी फिसल जाए, तो मेरे जैसे थोड़े से paranoid व्यक्ति को भी यह बहुत जोखिमभरा महसूस होता है
    इस हिस्से पर बेहतर explanation की ज़रूरत है

  • infrastructure monitoring तो होगी ही, इसलिए बस इतना करना है कि सभी public domains के लिए IPv4 और IPv6 पर connect करके, अगर certificate 19 दिनों के भीतर expire होने वाला हो तो alert करने वाला 50 lines का code जोड़ दिया जाए। automatic renewal 20 दिन पहले चला दो, बस काम हो गया
    एक छोटी कंपनी के शुरुआती दिनों में SSL renewal कुछ बार छूट जाने के बाद मैंने यह code कई साल पहले लिखा था, और उसके बाद SSL से जुड़ा कोई outage नहीं हुआ
    calendar invite की ज़रूरत नहीं, बस यही एक fix चाहिए। “prober infrastructure को update करके IPv4 और IPv6 endpoints को अलग-अलग verify करेंगे” — यही मुख्य बात है

  • इसमें लिखा है, “उस configuration को उस provider ने misconfiguration माना, और deploy करने के बाद से लगातार warning भेजता रहा”
    तो क्या certificate से जुड़ी warnings 90 दिनों तक आती रहीं और फिर certificate fail हो गया?

    • यह certificate warnings 90 दिन तक आने से ज़्यादा, DNS से जुड़ी warnings 90 दिन तक आने जैसा लगता है। लगता है Tailscale team को incident से पहले यह पता नहीं था कि अगर IPv6/AAAA DNS record मौजूद हो, तो Vercel automatic certificate renewal को मना कर देता है
      मैंने actual warning नहीं देखी, इसलिए यह नहीं कह सकता कि warning ने इस बात को साफ़-साफ़ बताया था या नहीं