Tecnologia JIT WireGuard

Melhorias no WireGuard da Fly.io

• A Fly.io converte contêineres em VMs e os executa em hardware ao redor do mundo aproveitando o poder do Firecracker.
• Usa muito o WireGuard, que agora passou a fazer parte da API para clientes.
• Sempre que o CLI flyctl é executado, ele cria uma pilha TCP/IP e se comunica diretamente com as Fly Machines usando um endereço IPv6 exclusivo.
• Essa abordagem tem vantagens e desvantagens, e houve algumas melhorias.

Situação anterior

• Servidores de "gateway" espalhados pelo mundo aceitavam conexões WireGuard e faziam a ligação com a rede privada apropriada.
• Cada execução do flyctl criava ou se conectava a um processo agente em segundo plano.
• O agente criava uma nova configuração de peer WireGuard na API GraphQL.
• A API enviava a configuração do peer ao gateway apropriado por meio do sistema de mensageria NATS.
• No gateway, o serviço wggwd recebia a configuração, armazenava em um banco de dados SQLite e a adicionava ao kernel.
• A API respondia à requisição GraphQL entregando a configuração, e o flyctl se conectava ao peer WireGuard.
• O NATS é rápido, mas não garante a entrega, e não limpava peers antigos que permaneciam nos gateways.

Um jeito melhor

• Armazenar peers WireGuard não exige um banco de dados complexo.
• O sistema foi alterado para que o gateway busque a configuração na API sempre que necessário.
• Os peers podem ser adicionados ao kernel apenas quando o cliente quiser se conectar e removidos quando não forem mais necessários.

Tornando possíveis peers JIT do WireGuard

• A interface de configuração do WireGuard no kernel Linux usa Netlink.
• É possível identificar e interceptar pacotes de solicitação de conexão WireGuard com filtro BPF e packet socket.
• O WireGuard não tem conceitos de "cliente" e "servidor"; é um protocolo ponto a ponto.
• Quando o flyctl envia um pacote UDP ao gateway, isso é um handshake initiation.
• É possível capturar conexões de entrada usando um filtro BPF.
• Como ele é baseado no framework de protocolo Noise, é preciso descriptografar para identificar a solicitação.
• É possível criar um feed de eventos para obter a chave pública de qualquer usuário que tente se conectar ao gateway.
• Sempre que um novo peer é visto, suas informações são buscadas e instaladas por meio de uma requisição à API HTTP interna.

Lançando apps em minutos

• Na Fly.io, é possível fazer deploy de apps rapidamente e obter seu próprio peer JIT WireGuard.

Olhando os gráficos

• Após operar esse sistema por algumas semanas, o número de peers WireGuard obsoletos restantes nos gateways caiu de forma significativa.
• Os gateways mantêm menos estado e a configuração dos peers ficou mais rápida.
• Um gráfico do Grafana mostra os resultados bem-sucedidos no dia da transição.

Opinião do GN⁺

• As melhorias da Fly.io no WireGuard são um bom exemplo de como aumentar significativamente o desempenho e a estabilidade da rede.
• Essa abordagem pode ser especialmente útil para reforçar o gerenciamento de tráfego de rede e a segurança em serviços baseados em nuvem.
• Outros projetos com funcionalidades parecidas incluem Tailscale e ZeroTier, que também oferecem alternativas de VPN para usuários individuais e corporativos.
• Ao adotar WireGuard, é preciso considerar configuração de rede, políticas de segurança e compatibilidade.
• Os benefícios dessa tecnologia incluem alto desempenho e configuração simples, mas a integração com infraestrutura existente e a operação podem trazer desafios.

[GN⁺]

Opiniões no Hacker News

• Dizem que o WireGuard no kernel do Linux não tem a capacidade de instalar peers sob demanda, o que causa problemas na implementação do design.

  • Há dificuldades de design porque o WireGuard no kernel do Linux não possui a função de instalar peers conforme a solicitação.
  • É possível adicionar peers em tempo de execução, mas a ideia parece ser autenticar o peer antes de adicioná-lo à interface, para evitar entradas desnecessárias.
  • Usam filtros eBPF para gerenciar diretamente conexões baseadas em roteamento de chaves criptográficas com partes autenticadas e, depois da validação, adicionam o peer à interface e o removem após um timeout.

• Concordo que uma requisição HTTP é mais confiável do que roteamento por fila de mensagens, mas fiquei surpreso que mensagens perdidas no NATS tenham impactado tanto o serviço.

  • Concorda que requisições HTTP diretas são mais confiáveis do que filas de mensagens, mas estranha que a perda de mensagens no NATS tenha causado impacto significativo no serviço.
  • Esperava que o NATS tentasse retransmitir em caso de perda de mensagens, e demonstra curiosidade sobre por que houve um problema de confiabilidade tão perceptível.

• Gostaria de divulgar um projeto experimental recente. Se você tem interesse em construir apps em Go que atuem como peers WireGuard em user space, dê uma olhada.

  • Apresenta seu próprio projeto para quem tem interesse em criar apps em Go que funcionem como peers WireGuard em user space.
  • A proposta é se apoiar no excelente trabalho do wireguard-go, mas simplificando-o para torná-lo mais adequado ao uso como biblioteca.
  • Tem interesse em construir um service mesh e acredita que, embora o suporte a várias linguagens possa ser difícil, deve ser possível implementar uma API de socket.
  • Menciona que ainda não vê aceleração por hardware para a criptografia do WireGuard, o que pode dificultar competir com mTLS.
  • Diz que atua como freelancer na área de redes rápidas/seguras e convida interessados a entrarem em contato por e-mail no perfil.

• É interessante que o padrão seja tunelar o WireGuard sobre WebSockets. Não é bom para desempenho, mas deve servir para tarefas de DevOps em que o flyctl é usado.

  • Chama atenção para o fato de que tunelar WireGuard por WebSockets é a configuração padrão.
  • Não é o ideal em termos de desempenho, mas provavelmente não será um problema para tarefas de DevOps que usam o flyctl.
  • Demonstra curiosidade sobre o futuro de QUIC/HTTP3 e questiona se operadores de rede passarão a tratar corretamente UDP na porta 443 em vez de bloqueá-lo.

• Nós podemos instalar o peer como iniciadores, e o flyctl é o respondente. O kernel do Linux inicia a conexão WireGuard com o flyctl. Esse método funciona, e o protocolo não se importa muito com quem é servidor ou cliente. Novas conexões são instaladas o mais rápido possível.

  • Explica o método em que eles instalam o peer como iniciadores, enquanto o flyctl responde e o kernel do Linux inicia a conexão WireGuard.
  • Menciona que o protocolo não depende muito dos papéis de servidor e cliente, e que novas conexões podem ser estabelecidas muito rapidamente.

• Minha startup usou o Fly por quase um ano. O recurso principal de transformar código em código implantado em menos de um minuto é lindo. Dá para subir e derrubar novos nós em segundos.

  • Compartilha a experiência da startup usando o Fly por quase um ano.
  • Avalia positivamente a capacidade de implantar código rapidamente, mas sente que a empresa ainda é um pouco imatura.
  • Menciona uma experiência em que o servidor de API da Fly ficou inacessível por 48 horas e problemas de desconexões inconsistentes no produto "db".
  • Aponta que o acesso à API da Fly caía com frequência, o que causava problemas para implantar alterações em novos serviços.
  • Diz sentir falta da experiência de deploy, mas afirma estar mais satisfeito usando o Cloud Run do GCP.

• “Toda vez que você executa o flyctl, nossa adorável e gigantesca CLI cria uma pilha TCP/IP do nada e fala diretamente com Fly Machines usando um endereço IPv6 exclusivo.”

  • Demonstra curiosidade sobre a explicação de que, ao executar o flyctl, uma pilha TCP/IP é criada na hora e se comunica diretamente com Fly Machines por meio de um endereço IPv6 exclusivo.

• O que impede que o pacote inicial de handshake seja retransmitido para a pilha de rede? Isso parece que evitaria perda de pacotes. Além disso, qual é o objetivo de verificar udp[8] = 1 no filtro eBPF?

  • Levanta perguntas sobre o mecanismo que impede o pacote inicial de handshake de ser retransmitido para a pilha de rede e sobre o motivo de verificar um valor específico de pacote UDP no filtro eBPF.

• Como faço para implantar qualquer aplicação dockerizada no Fly.io? Podem ficar com meu dinheiro.

  • Expressa interesse e disposição para pagar para saber como implantar uma aplicação dockerizada no Fly.io.

• Para todo o resto, vou fazer uma propaganda descarada do Netmaker.

  • Compartilha uma experiência satisfatória com o Netmaker, menciona a necessidade pessoal de acesso a uma AWS VPC e espera que o Netmaker seja adotado mais amplamente.