JIT WireGuard

Artigo original ↗ Discussão no Hacker News ↗

Ferramentas de VPN baseadas em WireGuard e acesso à AWS

  • Netmaker é discutido como uma malha auto-hospedável baseada em WireGuard semelhante ao Tailscale; Netbird também é recomendado, mas criticado por coleta extensa de dados e comportamento arriscado do daemon (por exemplo, criar túneis SSH como root).
  • Alguns perguntam por que não usar opções nativas da AWS (VPC peering, PrivateLink, AWS VPN, SSM). As respostas: elas são voltadas para conectividade entre VPCs, não para acesso barato e simples no estilo SSH através de muitas contas; a saída da AWS VPN pode ser cara para muito tráfego, enquanto SSM + SSH funciona, mas exige agentes/permissões e mais ferramentas.

Conceito de JIT WireGuard e detalhes de implementação

  • O blog sobre peers WireGuard “just-in-time” resolve o problema de que o WireGuard no kernel não tem uma API nativa de “instalação de peer sob demanda”.
  • Eles interceptam apenas pacotes de iniciação usando eBPF (udp[8] = 1), então decidem em userspace se vão autorizar e instalar um peer; peers obsoletos são removidos depois.
  • Alguns sugerem usar NFQUEUE para enfileirar pacotes para userspace e então aplicar o veredito (descartar/permitir) após a configuração, permitindo fail-open e escalando para múltiplos workers.
  • Há discussão sobre repetir o pacote inicial do handshake após a instalação do peer; isso foi considerado possível e uma otimização elegante, embora não implementada no artigo.
  • A abordagem busca suportar muitos peers potenciais sem pré-carregá-los todos no kernel; os peers vivem principalmente em um banco de dados e são instalados sob demanda. Técnicas semelhantes são usadas por outros sistemas baseados em WireGuard para ficar dentro dos limites de recursos.
  • JIT é esclarecido como “just-in-time configuration”, não compilação; alguns observam que o termo é amplamente usado fora de compiladores (por exemplo, em manufatura).

Debate sobre o design e as limitações do WireGuard

  • Uma linha de crítica: o WireGuard é fortemente preso a uma interface de rede; alguns gostariam que fosse um “filtro” genérico, utilizável com descritores de arquivo arbitrários, desbloqueando composições mais flexíveis.
  • Outros defendem o objetivo de design: superfície de configuração mínima para facilitar auditoria e segurança prática, em contraste com a complexidade do IPSec.
  • As reclamações focam menos no protocolo e mais nas ferramentas: configs em estilo .ini, desalinhamento entre wg e wg-quick, e UX de cliente desajeitada (especialmente no Windows).
  • Vários observam que o WireGuard não é uma “solução VPN” completa: não há push embutido de rotas/DNS nem distribuição centralizada de políticas. Workarounds incluem rodar BGP ou escrever clientes personalizados, mas isso é complexo demais para muitos, especialmente em mobile.
  • O modelo de “cryptokey routing” é visto como fundamental; produtos de nível superior (Tailscale, Netmaker etc.) existem justamente para adicionar gestão, política e distribuição de rotas sobre ele.

Navegador, userspace e stacks de rede alternativas

  • Executar WireGuard em navegadores é limitado pela falta de raw sockets; apenas caminhos baseados em HTTP/WebSocket funcionam. Alguns projetos usam relays (por exemplo, WebSocket sobre servidores relay especializados) e WebAssembly para aproximar o comportamento de uma VPN.
  • OpenZiti/BrowZer é apresentado como exemplo: um modelo com service worker + WebAssembly que permite que navegadores entrem em uma rede overlay privada via WebSockets, após uma injeção inicial de script.
  • O flyctl da Fly usa uma stack TCP/IP em userspace mais WireGuard em userspace; o sistema operacional do host não é o peer WireGuard, apenas o processo da CLI é. Um modo separado de peer “real” também está disponível para acesso em nível de sistema operacional.
  • Alguns acham stacks TCP/IP em userspace conceitualmente estranhas, mas outros observam que elas eram comuns historicamente e estão se tornando cada vez mais práticas.

Mensageria de plano de controle (NATS vs HTTP)

  • Comentadores se surpreendem que a coordenação baseada em NATS tenha tido perda de mensagens suficiente para afetar a confiabilidade.
  • Observa-se que o NATS “core” não oferece durabilidade/reentrega; JetStream adiciona esses recursos, mas talvez não estivesse configurado ou disponível quando foi projetado.
  • Funcionários da Fly dizem que provavelmente “usaram NATS errado” e perceberam que um broker de mensagens adicionava complexidade sem maior expressividade para seus casos simples de mensagem única; um modelo direto de requisição HTTP é mais fácil de raciocinar e monitorar.

Restrições de VPN da Apple/macOS

  • Há a alegação de que a GUI oficial do WireGuard para macOS precisa ser distribuída pela App Store porque a Apple retém as permissões de VPN necessárias de apps distribuídos pela web/por conta própria; isso é enquadrado como hostil à privacidade, já que o uso da App Store vincula o software à identidade do usuário e ao hardware.
  • Outros contestam isso, apontando clientes VPN fora da App Store que funcionam bem, o que sugere que a afirmação original é exagerada.
  • Esclarecimento: as APIs mais novas de Network Extension/System Extension exigem permissões específicas, que a Apple agora concede a membros do Developer Program, então compilar o app exato do WireGuard a partir do código-fonte como não membro do programa não funcionará totalmente sem desativar recursos de segurança. APIs VPN mais antigas ou diferentes continuam utilizáveis por apps fora da App Store.

Experiência com a plataforma Fly.io

  • Vários usuários elogiam a ergonomia para desenvolvedores da Fly.io: implantações globais rápidas, inicialização muito veloz para workloads, rede Anycast e recursos como FLY_REPLAY e LiteFS, que tornam clusterização global e acesso de baixa latência mais fáceis do que em provedores VPS tradicionais.
  • Outros relatam sérios problemas de confiabilidade: interrupções de vários dias para serviços críticos, oferta de “db”/Postgres instável e explicitamente “não gerenciada”, e indisponibilidades da API/plano de controle que bloqueiam deploys. Isso leva alguns a migrar para GCP (Cloud Run ou GKE) em busca de menos surpresas e melhor documentação.
  • Alguns continuam usando a Fly.io apesar das arestas, na esperança de que a plataforma amadureça para uma alternativa estável centrada em Anycast.

Escolhas de transporte e conectividade

  • Para flyctl, o WireGuard muitas vezes é tunelado por WebSockets por padrão para sobreviver a redes restritivas onde UDP (mesmo na porta 443) é bloqueado ou pouco confiável; WireGuard puro em UDP é suportado como opção.
  • Esse padrão é escolhido para minimizar falhas de UDP difíceis de depurar; fazer sondagens de “happy eyeballs” para escolher entre UDP e WebSocket é considerado complexidade desnecessária dado o foco da Fly (plataforma em nuvem, não serviço VPN genérico).
  • A discussão confirma que o truque de handshake JIT funciona através de NAT desde que o 4-tuplo (IP+porta de origem/destino) permaneça consistente, já que NATs UDP típicos não inspecionam o conteúdo dos pacotes.

Miscelânea

  • Alguma confusão sobre a explicação da Fly de que o WireGuard no kernel não suporta peers “on-demand” é resolvida: peers podem ser adicionados em runtime, mas o esquema JIT exige autenticação e decisão antes de adicionar, para evitar armazenar grandes números de peers nunca usados.
  • Vários projetos de WireGuard/Noise em userland (por exemplo, bibliotecas Go) são mencionados, com ideias para túneis em nível de aplicação, transferência de arquivos no estilo magic-wormhole e overlays no estilo service mesh.
  • Fazer deploy de apps conteinerizados na Fly é descrito como simples: execute flyctl launch no diretório com o Dockerfile.