2024년 3월 7일 발생한 Tailscale.com 장애 사건

• 2024년 3월 7일 만료된 TLS 인증서 때문에 tailscale.com이 약 90분 동안 중단됐지만, 영향은 주로 문서와 마케팅 사이트에 머묾
• 2023년 12월 웹사이트 개편과 새 호스팅 이전 뒤 약 90일 만에 문제가 드러났고, IPv6 미지원 환경을 보완한 자체 프록시 구성이 자동 갱신을 방해함
• 인증서 만료 감시 프로버가 IPv6 경로만 확인하면서 별도 유효 인증서를 가진 프록시를 통과해, 실제 tailscale.com과 www.tailscale.com의 만료 임박을 놓침
• 일반적인 Tailscale 사용은 대부분 중단되지 않았지만, 문서, 블로그, install.sh, 직접 URL을 모르는 사용자의 관리 콘솔 접근 흐름에는 영향이 있었음
• Tailscale은 추가 AAAA 레코드 제거와 수동 갱신으로 복구했고, 단기 수동 갱신 체계와 IPv4/IPv6 분리 점검을 거쳐 더 직접적인 IPv6 지원을 목표로 함

---

인증서 만료를 놓친 이유

• 2024년 3월 7일 tailscale.com과 www.tailscale.com의 TLS 인증서가 만료되어 약 90분 동안 사이트 접속이 중단됨
• 2023년 12월 Tailscale은 대규모 웹사이트 개편과 함께 새 호스팅 제공업체로 이전함
• 새 호스팅 제공업체가 IPv6를 기본 지원하지 않아, Tailscale은 IPv6 요청 처리를 위해 자체 프록시를 운영하고 추가 AAAA 레코드를 설정함
• 호스팅 제공업체는 이 구성을 “misconfiguration”으로 보고 알림을 보냈지만, 해당 구성이 자동 인증서 갱신 완료를 막는다는 점은 알림에 명시되지 않음
• 인증서 만료 감시용 프로버는 IPv6 경로만 확인함
  • 프로버는 자체 프록시를 통과함
  • 프록시는 별도로 관리되는 유효한 인증서를 갖고 있었음
  • 이 때문에 tailscale.com과 www.tailscale.com의 실제 인증서 만료가 사전에 드러나지 않음

사용자에게 보인 영향

• 영향은 웹사이트에 의존하는 자료와 설치 흐름에 집중됨
  • Tailscale 문서, 블로그, 기타 웹사이트 기반 참고 자료가 장애 중 접근 불가였음
  • 관리 콘솔과 설정 페이지 자체는 영향이 없었지만, https://login.tailscale.com/로 직접 이동하는 방법을 모르는 사용자는 해당 페이지가 오프라인이라고 생각할 수 있었음
  • 빠른 설치 스크립트를 사용할 수 없어 일부 설치와 자동 설치에 지장이 생김
• Tailscale 패키지 설치를 실제로 제공하는 도메인은 접근 가능했으며, Go의 go get 메커니즘을 통한 해석 중단은 캐싱 덕분에 최소였다고 봄
• Tailscale의 설계상 대부분의 사용자는 대부분의 사용 사례에서 이번 장애로 중단을 겪지 않았고, 직접 연결 원칙 덕분에 네트워크가 tailscale.com 같은 특정 엔드포인트의 즉시 가용성에 덜 의존함

복구와 재발 방지

• 문제를 확인한 뒤 Tailscale은 “추가” AAAA 레코드를 일시 제거하고 관련 인증서를 수동으로 갱신함
• 이 조치로 사용자에게 보이는 장애는 즉시 해결됐고, 사이트와 서비스를 IPv6로 제공하기 위해 레코드는 곧 복원됨
• 자동 갱신 문제는 남아 있어, 단기적으로는 중복 캘린더 알림과 지정된 수동 갱신 시간을 두고 직접 인증서를 갱신할 계획임
• 프로버 인프라는 IPv4와 IPv6 엔드포인트를 별도로 확인하도록 업데이트할 예정임
• 장기적으로는 웹사이트 인프라에서 IPv6를 더 직접 지원해 자체 프록시가 필요 없는 구조를 목표로 함

[GN⁺]

Hacker News 의견들

• 만료되는 인증서는 이제 장애의 새로운 DNS라고 봄
  그래도 Tailscale이 얼마나 잘 만들어졌는지는 아직도 놀라움. 가벼운 사용자에 가깝지만, 온프레미스 서버 몇 대와 AWS 프로덕션 환경이라는 두 곳에 Tailscale로 접근하고 있음
  어디서든 일할 수 있음. 주말에 ECS 컨테이너를 배포하려는데 로컬 와이파이가 너무 느려 배포가 계속 시간 초과됐음
  그래서 온프레미스 개발 머신에 SSH로 들어가 최신 코드를 git pull하고 거기서 배포했음. 온프레미스와 AWS 모두 열린 포트 없이 안전한 상태였고, AWS의 작은 EC2에 Tailscale 에이전트만 띄우면 프로덕션 Aurora 데이터베이스도 열린 포트 없이 테스트 가능함
  다른 개발자에게 네트워크 접근 권한을 줘야 할 때도 Tailscale은 아주 쉽고, 권한 회수도 마찬가지임. 이 배포는 GitHub Actions 같은 걸로 처리해 열악한 인터넷 문제를 피할 수도 있었지만, 수동으로 하고 싶었고 Tailscale이 그걸 가능하게 해줌

  • GitHub Actions로 배포할 때도 Tailscale은 여전히 유용함. 지금은 GHA 워커가 SSH로 들어와 배포를 시작할 수 있게 클라우드 VM의 SSH 포트를 비표준 포트로 열어두고 있음
    앞으로는 어떤 GHA 워커든 포트를 노출하지 않고 배포 머신에 접근할 수 있도록 이 액션을 쓰려 함: https://github.com/tailscale/github-action
  • 불안정한 연결에서는 mosh와 GNU screen을 씀. 10초마다 끊겨도 놀라울 정도로 잘 동작함

• 만료 인증서가 또 사고를 냈음
  사후 분석의 일부로 설치 스크립트를 마케팅 사이트에서 떼어내거나 다른 대체 경로를 두는 걸 권함. 그래야 마케팅 사이트 활동이 고객 운영의 핵심 경로와 무관해짐. 이런 일이 흔하므로 보통의 격리를 유지하는 데 거의 도달해 있는 상태라 더 아쉬움
  여러 제공자의 가동 시간을 추적해 보면 GitHub나 Zendesk 사이트 일부가 내려가는 일이 예상보다 흔함. 그나마 이들은 좋은 사례에 속함

  • 마케팅 사이트의 보안 우선순위는 제품 자체보다 낮은 경우가 많고, 설치 스크립트는 보통 제품과 비슷한 수준으로 보호되어야 함
  • 모든 인증서와 만료일을 감시해 주는 서비스가 있는지 궁금함
    Cloudflare는 도메인을 그쪽에 호스팅하면 이 부분을 꽤 처리해 주는 것 같지만, Cloudflare를 써야 한다는 조건이 붙음

• 예전 회사에서 했던 실수와 같음. 마케팅 사이트 www.foo.com 홈에 웹앱 로그인 페이지 app.foo.com 링크를 걸어뒀음
  첫 마케팅 사이트 장애가 나고서야 월 40달러 호스팅 플랜이 단순한 마케팅 사이트가 아니라 핵심 인프라였다는 걸 깨달음. 말 그대로 하중을 받는 40달러짜리 호스팅이었음. 앱은 내려가지 않았지만 사용자는 내려갔다고 생각했음
  사용자는 우리가 만들어 둔 경로를 따라갈 뿐 다른 길이 있다는 걸 모르는 경우가 많고, 그 경로 하나를 없애면 사용자 일부는 완전히 길을 잃는다는 걸 배웠음

  • 브라우저에 tailscale을 치면 첫 결과가 tailscale.com임. Tailscale 관리자 콘솔을 자주 쓰지 않으니 굳이 다른 URL을 외우지 않음
    예전에는 cloudflare를 입력하면 브라우저가 dash.cloudflare.com을 자동완성했는데, cloudflare.com 웹사이트를 딱 한 번 방문한 뒤로 그게 첫 결과가 됐고, Cloudflare에서도 같은 행동을 하게 됨

• 이 팀은 정말 좋지만 가격이 너무 과하다고 봄. 제대로 된 접근 제어가 VPN에 월 18달러나 들어서는 경영진에게 팔기 거의 불가능하고, 낮은 티어는 그 기능 없이는 팔기 어려움

  • 내부적으로 Tailscale을 무엇과 비교하는지 정말 궁금함. Tailscale은 단순 VPN보다 훨씬 많은 일을 함
    더 싼 선택지는 무엇이고, 그것들도 SSH 기능, 자동화 서비스용 OAuth 네트워크 인증, Kubernetes 클러스터 안에서 VPN 노드 로드밸런서 구성, Let’s Encrypt를 통한 ACME 인증서 요청 자동화를 제공하는지 궁금함
    무료 티어에서 쓰고 있는 기능만 몇 가지 나열해도 보통 VPN 서비스의 역할로 생각하지 않는 것들이 많음. 기능도 계속 추가되고 있어 꽤 흥미롭고 경쟁력 있는 선택지라고 봄. 오히려 저가 티어에서 제공하는 것이 너무 많아 놀라워서 이런 평가가 더 궁금함
  • 그러면 headscale을 설치해 직접 호스팅하면 비용 없이 쓸 수 있음
    Tailscale과 일부 겹치는 경쟁 제품도 있고, 원하는 것과 완전히 맞지는 않을 수 있음
    다만 몇 분 만에 프로젝트 일부가 이전보다 훨씬 잘 맞물려 돌아가게 됐음
    하는 일에 비해 정말 드물게 단순한 도구 중 하나이고, 무료 티어도 기기 100대와 사용자 3명으로 꽤 넉넉함
  • 이건 설득하기 아주 쉬웠음. OpenVPN 구성에서 벗어났고, Tailscale 덕분에 신규 직원 온보딩과 여러 일을 올바른 방식으로 하기가 훨씬 쉬워졌음. 완전 원격 회사라 더 중요함
    물론 내 역할상 이런 주제로 경영진을 설득하는 영향력이 꽤 있기는 했지만, 가격은 문제가 되지 않았음
    작년 4월부터 만족하며 쓰는 고객이고 모두 프리미엄, 즉 비싼 티어를 사용 중임. 개발 속도도 인상적임. 몇 년 걸릴 수 있다고 했던 기능 일부가 이미 작년에 출시됐음
    Cloudflare One도 대안이 될 수 있었지만, 그건 더 비쌌을 것임
  • 어떤 경영진이 월 18달러에 걸려 넘어지는지 모르겠음. 1인당 비용으로 보면 직원을 위해 사는 수십 가지 물건 중 거의 0에 가까운 비용임
  • 그게 우리를 Twingate로 밀어낸 핵심 이유였음. 써보니 라우팅 기능은 Twingate 쪽을 조금 더 좋아하게 됨. Tailscale을 싫어한다는 뜻은 아니고, 둘 다 용도별로 쓰고 있음

• 웹사이트 제공자를 어디 쓰는지 궁금함. 다른 거의 모든 제공자가 IPv6 지원을 하는데, IPv6 때문에 이렇게 많은 우회를 해야 한다는 게 이상하게 들림

  • $ host www.tailscale.com 결과를 보면 www.tailscale.com의 IPv4 주소 76.76.21.21은 Vercel이고, IPv6 주소들은 Amazon임
    IPv4는 Let’s Encrypt 인증서를 쓰고, IPv6는 Amazon 인증서를 씀

• 12월에 대규모 롤아웃을 믿고 할 만큼 CI/CD와 모니터링이 탄탄하다는 게 정말 부러움. 엔지니어링 문화가 꽤 강해 보임
  다만 아직 답이 안 된 질문들이 있음. IPv6 설정이 IPv4의 자동 인증서 갱신을 깨뜨린 거라면 왜 훨씬 예전에 겪지 않았는지 궁금함. 장애 해결에 왜 90분이나 걸렸는지도 궁금함. 블로그 글이고 진짜 사후 분석은 아니지만 간단한 시간표라도 있었으면 좋았을 듯함
  또 왜 IPv6를 네이티브로 지원하는 DNS 제공자로 옮기지 않는지도 궁금함. 스크립트나 패키지 전용 도메인을 따로 두는 운영 부담이 감당할 가치가 있는지도 궁금함. 패키지 저장소 같은 제3자는 제외하고, 다른 곳들도 이렇게 하는지 궁금함

  • 이해하기로는 장애 90일 전에 현재 구성으로 바꾼 것 같음. 마이그레이션 때 설치한 초기 인증서가 90일짜리였고, 그래서 마이그레이션 90일 뒤에 장애가 난 셈임
  • 이들은 Vercel을 쓰고 있고, Vercel은 IPv6 지원이 없음

• 프록시가 왜 TLS를 종료해야 하는지 모르겠음. 그냥 TCP 프록시였다면 적어도 모니터링이 인증서 만료가 임박하지 않았다고 착각하지는 않았을 것임
  게다가 도메인 검증을 TLS-ALPN 챌린지로 하고 있었다면 TCP 프록시는 자동 갱신도 가능하게 했을 수 있음

  • TCP 프록시는 PROXY 프로토콜 같은 걸 쓰지 않는 한 사용자 IP 주소를 버림. 그러려면 대상 HTTPS 서버도 이를 지원해야 하고, 인가되지 않은 사용자가 자기 PROXY 헤더를 주입하지 못하게 막는 방법도 필요함
    사용자 IP가 전혀 필요 없다면 문제가 아니지만, 로그와 남용 탐지에는 종종 유용함
    https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt
  • 엄청난 이유는 아니지만 HTTP/3는 TCP 위에서 동작하지 않고, UDP 프록시를 운영하는 건 그리 즐거운 일이 아닐 듯함
  • TLS를 종료할 필요가 없음. 그게 우리의 실수 중 하나였고 고칠 작업 항목임
    처음 IPv6가 깨졌다는 걸 발견했을 때 급히 프록시를 세웠고, 당시 프록시를 세운 사람들이 ACME가 어떻게 동작하는지 몰랐음
    그냥 TCP 프록시로 바꿀 예정임
  • TLS를 종료하지 않는 프록시는 Hetzner 같은 서비스에 올리기 좋음. CAA를 제대로 설정하면 제공자에게 지연 시간과 가용성만 맡기게 되고, CloudFront나 EC2 기반 프록시처럼 터무니없이 비싼 서비스를 피할 수도 있음
    보니 Tailscale은 pkgs.tailscale.com에 NetActuate를 쓰는 듯함. NetActuate라면 합리적인 가격으로 여러 거점에서 비종단 프록시를 제공하는 데 도움을 줄 수 있을 것 같음. 웹사이트에 가격은 없지만, 송신 트래픽에 50배 마진을 붙이는 회사 같지는 않음
  • IPv6용으로 앞단에 AWS CloudFront CDN을 두었을 수 있음. 그렇게 하면 CloudFront에서 TLS를 종료하게 되고, 선택 사항은 아닌 것으로 알고 있음

• Tailscale이라는 조직이 보안과 조금이라도 맞닿은 영역에서 단 한 번이라도 삐끗하면, 나처럼 약간만 편집증적인 사람에게도 너무 위험하게 느껴짐
  이 부분에 대해 더 나은 설명이 필요함

• 인프라 모니터링이 있을 테니, 모든 공개 도메인에 대해 IPv4와 IPv6로 접속하고 인증서가 19일 안에 만료되면 경고하는 코드 50줄을 추가하면 됨. 자동 갱신은 20일 전에 돌리면 끝임
  작은 회사 초기에 SSL 갱신을 몇 번 놓친 뒤 이 코드를 몇 년 전에 작성했고, 그 이후 SSL 관련 장애는 없었음
  달력 초대는 필요 없고, 필요한 수정은 이거 하나뿐임. “프로버 인프라를 업데이트해 IPv4와 IPv6 엔드포인트를 별도로 확인하겠다”는 부분이 핵심임

• “그 구성이 해당 제공자에게 오구성으로 간주되어, 배포한 뒤부터 계속 경고를 받아왔다”고 되어 있음
  그러면 인증서 관련 경고를 90일 동안 받다가 인증서가 실패한 건가?

  • 인증서 경고를 90일 받은 게 아니라 DNS 관련 경고를 90일 받은 것에 더 가까워 보임. IPv6/AAAA DNS 레코드가 있으면 Vercel이 인증서 자동 갱신을 거부한다는 사실을 Tailscale 팀이 사고 전에는 몰랐던 것 같음
    실제 경고를 본 건 아니라서 그 경고가 이 사실을 명확히 알려줬는지는 모르겠음