O incidente de indisponibilidade do Tailscale.com em 7 de março de 2024

 (tailscale.com)
2 pontos por GN⁺ 2024-04-01 | 1 comentários | Compartilhar no WhatsApp
  • Em 7 de março de 2024, o tailscale.com ficou fora do ar por cerca de 90 minutos devido a um certificado TLS expirado, mas o impacto ficou concentrado principalmente na documentação e no site de marketing
  • O problema apareceu cerca de 90 dias depois da reformulação do site e da migração para uma nova hospedagem em dezembro de 2023; uma configuração de proxy próprio criada para contornar a falta de suporte a IPv6 impediu a renovação automática
  • O prober de monitoramento de expiração de certificados verificava apenas a rota IPv6 e passava por um proxy com um certificado válido separado, deixando passar a expiração iminente dos certificados reais de tailscale.com e www.tailscale.com
  • O uso normal do Tailscale, em sua maior parte, não foi interrompido, mas houve impacto na documentação, no blog, no install.sh e no fluxo de acesso ao console de administração para usuários que não conheciam a URL direta
  • A Tailscale recuperou o serviço removendo registros AAAA adicionais e renovando manualmente o certificado; depois de adotar um esquema temporário de renovação manual e verificações separadas de IPv4/IPv6, busca oferecer suporte a IPv6 mais direto

Por que a expiração do certificado passou despercebida

  • Em 7 de março de 2024, os certificados TLS de tailscale.com e www.tailscale.com expiraram, deixando o acesso ao site indisponível por cerca de 90 minutos
  • Em dezembro de 2023, a Tailscale migrou para um novo provedor de hospedagem junto com uma grande reformulação do site
  • Como o novo provedor de hospedagem não oferecia suporte nativo a IPv6, a Tailscale operava seu próprio proxy para processar requisições IPv6 e configurou registros AAAA adicionais
  • O provedor de hospedagem tratou essa configuração como uma “misconfiguration” e enviou um alerta, mas o aviso não especificava que ela impediria a conclusão da renovação automática do certificado
  • O prober usado para monitorar a expiração de certificados verificava apenas a rota IPv6
    • O prober passava pelo proxy próprio
    • O proxy tinha um certificado válido gerenciado separadamente
    • Por isso, a expiração real dos certificados de tailscale.com e www.tailscale.com não foi detectada com antecedência

Impacto visto pelos usuários

  • O impacto se concentrou em materiais e fluxos de instalação dependentes do site
    • A documentação do Tailscale, o blog e outros materiais de referência baseados no site ficaram inacessíveis durante a indisponibilidade
    • O console de administração e as páginas de configuração em si não foram afetados, mas usuários que não sabiam acessar diretamente https://login.tailscale.com/ poderiam achar que a página estava offline
    • O script de instalação rápida ficou indisponível, prejudicando algumas instalações e instalações automatizadas
  • O domínio que efetivamente fornece os pacotes de instalação do Tailscale permaneceu acessível, e a interrupção da resolução via mecanismo go get do Go parece ter sido mínima graças ao cache
  • Pelo design do Tailscale, a maioria dos usuários, na maioria dos casos de uso, não sofreu interrupção com este incidente, e o princípio de conexões diretas torna a rede menos dependente da disponibilidade imediata de endpoints específicos como tailscale.com

Recuperação e prevenção de recorrência

  • Depois de identificar o problema, a Tailscale removeu temporariamente os registros AAAA “adicionais” e renovou manualmente os certificados relacionados
  • Essa ação resolveu imediatamente a indisponibilidade visível aos usuários, e os registros foram restaurados pouco depois para oferecer o site e os serviços via IPv6
  • Como o problema de renovação automática permaneceu, no curto prazo a empresa planeja renovar diretamente os certificados com alertas redundantes no calendário e horários definidos para renovação manual
  • A infraestrutura de prober será atualizada para verificar separadamente os endpoints IPv4 e IPv6
  • No longo prazo, o objetivo é oferecer suporte a IPv6 de forma mais direta na infraestrutura do site, em uma arquitetura que não exija um proxy próprio

Leituras relacionadas

1 comentários

 
GN⁺ 2024-04-01
Opiniões no Hacker News

  • Certificados expirando agora são o novo DNS das indisponibilidades
    Ainda assim, continuo impressionado com o quanto o Tailscale é bem construído. Sou mais um usuário leve, mas acesso via Tailscale dois ambientes: alguns servidores on-premises e o ambiente de produção na AWS
    Posso trabalhar de qualquer lugar. No fim de semana, tentei fazer deploy de um contêiner ECS, mas o Wi‑Fi local estava tão lento que o deploy continuava estourando o tempo limite
    Então entrei por SSH na máquina de desenvolvimento on-premises, fiz git pull do código mais recente e fiz o deploy a partir dali. Tanto o ambiente on-premises quanto a AWS estavam seguros, sem portas abertas, e, se eu simplesmente rodar o agente do Tailscale em uma pequena EC2 na AWS, também consigo testar o banco Aurora de produção sem portas abertas
    Quando preciso dar acesso de rede a outro desenvolvedor, o Tailscale também é muito fácil, e revogar o acesso é igualmente simples. Esse deploy poderia ter sido feito com algo como GitHub Actions para evitar o problema da internet ruim, mas eu queria fazer manualmente, e o Tailscale tornou isso possível

    • Mesmo ao fazer deploy com GitHub Actions, o Tailscale ainda é útil. Hoje deixo a porta SSH de uma VM na nuvem aberta em uma porta não padrão para que o worker do GHA possa entrar por SSH e iniciar o deploy
      No futuro, pretendo usar esta action para que qualquer worker do GHA consiga acessar a máquina de deploy sem expor portas: https://github.com/tailscale/github-action
    • Em conexões instáveis, uso mosh e GNU screen. Funciona surpreendentemente bem mesmo caindo a cada 10 segundos

  • Um certificado expirado causou outro incidente
    Como parte do post-mortem, recomendo separar o script de instalação do site de marketing ou criar outro caminho alternativo. Assim, a atividade do site de marketing deixa de fazer parte do caminho crítico das operações dos clientes. Como esse tipo de coisa é comum, é ainda mais frustrante porque eles já estavam quase mantendo um isolamento normal
    Ao acompanhar o uptime de vários provedores, quedas em partes dos sites do GitHub ou do Zendesk são mais comuns do que se imagina. E eles ainda estão entre os bons exemplos

    • A prioridade de segurança do site de marketing muitas vezes é menor do que a do produto em si, e o script de instalação normalmente deveria ser protegido em um nível semelhante ao do produto
    • Fico me perguntando se existe algum serviço que monitore todos os certificados e suas datas de expiração
      A Cloudflare parece cuidar bem dessa parte se você hospedar o domínio lá, mas isso vem com a condição de usar a Cloudflare

  • É o mesmo erro que cometemos em uma empresa antiga. Colocamos na home do site de marketing www.foo.com um link para a página de login do web app app.foo.com
    Só depois da primeira indisponibilidade do site de marketing percebemos que o plano de hospedagem de 40 dólares por mês não era apenas um simples site de marketing, mas infraestrutura crítica. Literalmente uma hospedagem de 40 dólares sustentando carga. O app não caiu, mas os usuários acharam que tinha caído
    Aprendi que os usuários simplesmente seguem o caminho que criamos e muitas vezes não sabem que existe outro; se você remove esse único caminho, parte dos usuários fica completamente perdida

    • Se você digita tailscale no navegador, o primeiro resultado é tailscale.com. Como não uso o console de administração do Tailscale com frequência, não me dou ao trabalho de memorizar outra URL
      Antes, ao digitar cloudflare, o navegador autocompletava dash.cloudflare.com, mas depois de visitar o site cloudflare.com uma única vez, ele virou o primeiro resultado, e acabei fazendo a mesma coisa com a Cloudflare

  • Essa equipe é muito boa, mas acho o preço exagerado. É quase impossível vender para a diretoria um controle de acesso decente para VPN custando 18 dólares por mês, e os tiers mais baixos ficam difíceis de vender sem esse recurso

    • Tenho muita curiosidade sobre com o que estão comparando o Tailscale internamente. O Tailscale faz muito mais do que uma VPN simples
      Quais são as opções mais baratas, e elas também oferecem recurso de SSH, autenticação de rede via OAuth para serviços de automação, configuração de balanceador de carga de nós VPN dentro de clusters Kubernetes e automação de solicitação de certificados ACME via Let’s Encrypt?
      Só listando alguns recursos que uso no tier gratuito, já há muita coisa que normalmente não se considera papel de um serviço de VPN. E eles continuam adicionando recursos, então acho uma opção bastante interessante e competitiva. Na verdade, fico ainda mais curioso com essa avaliação porque me surpreende o quanto eles oferecem nos tiers mais baratos
    • Então dá para instalar o headscale e hospedar por conta própria, sem custo
      Também há produtos concorrentes que se sobrepõem em parte ao Tailscale, e talvez não sejam exatamente o que você quer
      Ainda assim, em poucos minutos, partes do projeto passaram a se encaixar muito melhor do que antes
      Pelo que faz, é uma daquelas ferramentas raramente simples, e o tier gratuito também é bem generoso, com 100 dispositivos e 3 usuários
    • Para nós foi muito fácil convencer. Saímos de uma configuração com OpenVPN, e o Tailscale tornou muito mais fácil fazer onboarding de novos funcionários e várias outras coisas da maneira correta. Isso é ainda mais importante por sermos uma empresa totalmente remota
      Claro que, pelo meu papel, eu tinha bastante influência para convencer a diretoria nesse tipo de assunto, mas o preço não foi um problema
      Somos clientes satisfeitos desde abril do ano passado e todos usam o tier premium, ou seja, o caro. A velocidade de desenvolvimento também impressiona. Alguns recursos que diziam poder levar anos já foram lançados no ano passado
      O Cloudflare One também poderia ser uma alternativa, mas teria sido mais caro
    • Não sei que diretoria tropeça em 18 dólares por mês. Em termos de custo por pessoa, é praticamente zero perto das dezenas de coisas que se compram para um funcionário
    • Esse foi o principal motivo que nos empurrou para o Twingate. Depois de usar, passei a gostar um pouco mais dos recursos de roteamento do Twingate. Não quer dizer que eu não goste do Tailscale; usamos ambos conforme o caso

  • Fico curioso sobre qual provedor eles usam para o site. Quase todos os outros provedores têm suporte a IPv6, então soa estranho precisar de tantos contornos por causa do IPv6

    • Pelo resultado de $ host www.tailscale.com, o endereço IPv4 76.76.21.21 de www.tailscale.com é da Vercel, e os endereços IPv6 são da Amazon
      O IPv4 usa um certificado da Let’s Encrypt, e o IPv6 usa um certificado da Amazon

  • Dá até inveja ver que o CI/CD e o monitoramento deles são sólidos a ponto de confiarem em um rollout grande em dezembro. A cultura de engenharia parece bem forte.
    Ainda assim, há perguntas que ficaram sem resposta. Se a configuração de IPv6 quebrou a renovação automática de certificados do IPv4, fico curioso para saber por que isso não aconteceu muito antes. Também fico curioso para saber por que levou 90 minutos para resolver a interrupção. É um post de blog, não uma análise post-mortem de verdade, mas teria sido bom ter ao menos uma linha do tempo simples.
    Também fico curioso para saber por que eles não migram para um provedor de DNS com suporte nativo a IPv6. E se o ônus operacional de manter um domínio separado só para scripts ou pacotes realmente vale a pena. Excluindo terceiros como repositórios de pacotes, fico curioso se outros também fazem assim.

    • Pelo que entendi, eles mudaram para a configuração atual 90 dias antes da interrupção. O certificado inicial instalado na migração era válido por 90 dias, então a falha ocorreu 90 dias depois da migração.
    • Eles usam Vercel, e a Vercel não tem suporte a IPv6.

  • Não entendo por que o proxy precisava terminar TLS. Se fosse apenas um proxy TCP, pelo menos o monitoramento não teria se enganado achando que o certificado não estava perto de expirar.
    Além disso, se a validação de domínio estava sendo feita com um desafio TLS-ALPN, um proxy TCP poderia até ter permitido a renovação automática.

    • Um proxy TCP descarta o endereço IP do usuário, a menos que use algo como o protocolo PROXY. Para isso, o servidor HTTPS de destino também precisa dar suporte a isso, e também é preciso uma forma de impedir que usuários não autorizados injetem seu próprio cabeçalho PROXY.
      Se você não precisa do IP do usuário, não é um problema, mas ele costuma ser útil para logs e detecção de abuso.
      https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt
    • Não é um motivo enorme, mas HTTP/3 não roda sobre TCP, e operar um proxy UDP não parece ser algo muito divertido.
    • Não há necessidade de terminar TLS. Esse foi um dos nossos erros e é um item de trabalho a corrigir.
      Quando descobrimos inicialmente que o IPv6 estava quebrado, colocamos um proxy às pressas, e as pessoas que configuraram o proxy na época não sabiam como o ACME funcionava.
      Vamos mudar para um proxy TCP simples.
    • Um proxy que não termina TLS é uma boa opção para rodar em serviços como a Hetzner. Com CAA configurado corretamente, você acaba deixando com o provedor apenas a latência e a disponibilidade, e também pode evitar serviços absurdamente caros como CloudFront ou proxies baseados em EC2.
      Pelo que vi, a Tailscale parece usar a NetActuate em pkgs.tailscale.com. A NetActuate provavelmente conseguiria ajudar a fornecer proxies não terminadores em vários pontos de presença por um preço razoável. Não há preços no site, mas não parece uma empresa que coloque uma margem de 50 vezes sobre o tráfego de saída.
    • Eles podem ter colocado uma CDN AWS CloudFront na frente para IPv6. Nesse caso, o TLS é terminado no CloudFront e, pelo que sei, isso não é opcional.

  • Se uma organização como a Tailscale escorrega uma única vez em qualquer área minimamente ligada à segurança, para alguém só um pouco paranoico como eu isso já parece arriscado demais.
    Essa parte precisa de uma explicação melhor.

  • Como eles devem ter monitoramento de infraestrutura, basta adicionar 50 linhas de código que acessem todos os domínios públicos via IPv4 e IPv6 e emitam alerta se o certificado expirar em menos de 19 dias. A renovação automática roda 20 dias antes e pronto.
    Depois de perder algumas renovações de SSL no início de uma pequena empresa, escrevi esse código anos atrás, e desde então não tivemos incidentes relacionados a SSL.
    Não precisa de convite de calendário; a única correção necessária é essa. O ponto central é “atualizar a infraestrutura de probes para verificar separadamente os endpoints IPv4 e IPv6”.

  • Está escrito que “essa configuração era considerada uma má configuração por aquele provedor, então recebíamos alertas continuamente desde que a implantamos”.
    Então eles receberam alertas relacionados ao certificado por 90 dias e depois o certificado falhou?

    • Parece mais que eles receberam alertas relacionados a DNS por 90 dias, não alertas de certificado. A equipe da Tailscale aparentemente não sabia, antes do incidente, que a Vercel recusava a renovação automática de certificados quando havia registros DNS IPv6/AAAA.
      Como não vi o alerta real, não sei se ele explicava isso com clareza.