WireSock Secure Connect 3.x: O que se esconde por trás das notas de lançamento

Em 8 de abril de 2026, foi lançado o WireSock Secure Connect 3.4.4 – o primeiro lançamento oficial da versão 3.x.

Para nós, esta não é apenas mais uma atualização, mas uma transição para uma nova base arquitetural. Ela oferece uma separação mais clara dos componentes, melhor isolamento e novos recursos que usuários comuns e administradores aguardavam há muito tempo.

Ao mesmo tempo, o produto em si se tornou visivelmente mais complexo. Há mais configurações, assim como cenários de uso, e isso aconteceu não tanto por uma vida boa, mas sob a influência de circunstâncias externas, generosamente apoiadas pelo financiamento e pelo ritmo stakhanovista de trabalho de órgãos governamentais conhecidos por todos nós. Neste artigo, quero ir um pouco além das notas de lançamento e falar sobre coisas que não são imediatamente aparentes, mas explicam melhor por que o WireSock Secure Connect 3.x era necessário.

Nova arquitetura

Uma das desvantagens mais frequentemente criticadas do cliente oficial WireGuard é a dificuldade de ativar uma conexão para usuários sem privilégios elevados. A razão é bastante simples: no Windows, as operações relacionadas à criação e configuração de interfaces de rede estão vinculadas a direitos administrativos ou a permissões delegadas para gerenciar a configuração de rede, que geralmente estão associadas ao grupo integrado Network Configuration Operators.

No WireSock, esse problema foi parcialmente contornado devido ao chamado modo "transparente". Nesse cenário, os pacotes são interceptados pelo driver de rede, criptografados e descriptografados usando Network Address Translation (NAT), e, portanto, não é necessário levantar e configurar um adaptador virtual separado.

Na prática, isso tornou muito mais fácil usar uma VPN em ambientes onde o usuário não tem direitos de administrador local e onde o próprio fato de solicitar privilégios elevados já se torna um problema.

Mas a solução ainda era parcial. No modo de adaptador virtual, o WireSock, incluindo a versão 2.x, assim como o cliente oficial WireGuard, enfrentou a mesma característica arquitetural do Windows: esse cenário exigia privilégios elevados.

Nessa situação, um passo lógico foi dividir o aplicativo em duas partes: uma de serviço privilegiada, executando operações de sistema, e uma de cliente, responsável por sua configuração e gerenciamento de túneis.

Na minha opinião, esse esquema adicionou muita conveniência. A VPN agora pode ser ativada mesmo antes de o usuário fazer login no sistema, a interface do usuário não precisa ser mantida em execução constantemente, ela pode não apenas ser minimizada na bandeja, mas também fechada completamente, e executada somente quando necessário. Ao mesmo tempo, apareceu uma ferramenta CLI que pode funcionar com serviços em segundo plano e abre cenários normais de uso a partir da linha de comando.

É claro que houve críticas. A lógica dos usuários era compreensível: fechei a VPN e alguns serviços continuam a viver suas vidas lá. Daí veio a proposta lógica de adicionar botões para iniciar e parar serviços na interface do usuário. Mas isso nos levaria de volta ao ponto de onde estávamos tentando sair: a interface do usuário teria que ser vinculada novamente a operações privilegiadas e, de fato, executada novamente com direitos de administrador.

Sim, esse modelo pode parecer incomum. Mas é essa separação que oferece as principais vantagens da nova arquitetura. Ela remove a dependência desnecessária de cenários de usuário de privilégios elevados e permite que o WireSock funcione não como um aplicativo monolítico com uma janela e lógica de rede misturadas, mas como um sistema mais maduro com uma interface, serviços e conexão VPN vivendo separadamente. É nessa direção que estamos tentando desenvolver o WireSock, principalmente como uma solução corporativa madura.

KillSwitch / Network Lock

Essa função tem sido solicitada há muito tempo e com bastante insistência. De alguma forma, ela já existia antes, mas apenas no modo de adaptador virtual, onde sua implementação era semelhante à usada no cliente WireGuard original e dependia da tabela de roteamento. Essa abordagem não pode ser considerada a mais confiável e, para o modo transparente, é completamente insustentável.

Deve-se notar que a solicitação para tal função foi, em alguns lugares, bastante emocional. Um usuário dos EUA até prometeu parar de usar o WireSock se o KillSwitch não aparecesse. Dado que estávamos falando de um produto gratuito, a pressão não era a mais "obrigatória", mas de alguma forma ficou na memória.

No WireSock Secure Connect 3.x, o KillSwitch é implementado no nível do filtro NDIS de rede, ou seja, estamos falando de um mecanismo de bloqueio mais rígido e de nível inferior. Graças a isso, o KillSwitch pode ser configurado para bloquear todo o tráfego em caso de perda de conexão VPN, falha do serviço em segundo plano ou mesmo ao alternar entre perfis.

À primeira vista, a função parece bastante simples, mas, na prática, é um dos elementos mais importantes para cenários em que o vazamento de tráfego é inaceitável. Isso pode ser trabalho remoto, acesso a recursos corporativos internos, uso de uma VPN em redes com restrições rígidas ou simplesmente uma situação em que o usuário não quer que os aplicativos comecem a acessar a rede em torno do túnel, mesmo que por um curto período de tempo.

Vale a pena mencionar separadamente uma característica não muito óbvia que pode aparecer ao usar um KillSwitch "estrito", ou seja, no modo em que o bloqueio não é removido automaticamente quando o túnel é desconectado. Nessa configuração, podem surgir dificuldades com a reconexão se o endpoint do servidor não for especificado por um endereço IP, mas por um nome de domínio. O problema aqui é simples: com o bloqueio ativo, o cliente pode simplesmente não conseguir resolver esse nome via DNS e, portanto, não conseguirá restabelecer a conexão.

Tentamos suavizar ao máximo esse cenário. O WireSock armazena em cache os endereços IP e, ao alternar entre os perfis, os nomes de domínio são resolvidos, se possível, por meio de um túnel já existente. Mas essa característica ainda deve ser levada em consideração, especialmente se uma política de bloqueio estrita for usada e as configurações estiverem vinculadas a nomes DNS.

Global Split Tunneling: uma configuração em vez de um zoológico de exceções

Esta é, novamente, uma das funções que nos pediram há muito tempo. Antes da versão 3.x, as configurações de split tunneling tinham que ser definidas separadamente para cada perfil e, em algum momento, isso começou a se transformar em uma pequena, mas muito cansativa fonte de caos.

Na prática, para muitos usuários, o conjunto de exceções quase não mudava de perfil para perfil. Os servidores, países, parâmetros de conexão mudavam, mas a lista de aplicativos, endereços ou rotas que precisavam ser deixados de fora do túnel ou, inversamente, forçados através dele, geralmente permanecia a mesma. Como resultado, as mesmas configurações tinham que ser duplicadas manualmente, garantindo que não divergissem entre os perfis e sempre lembrando onde exatamente o que ainda não havia sido corrigido.

É por isso que, na versão 3.x, o split tunneling pode ser configurado globalmente, uma vez para todo o aplicativo, e então aplicar essas regras a todos os perfis de uma só vez.

Na lista seca de alterações, isso pode ser facilmente confundido com uma pequena conveniência, embora, na realidade, o significado dessa função seja muito mais significativo: menos duplicação, menos discrepâncias entre os perfis e um comportamento mais previsível do cliente.

Suporte para AmneziaWG 2.0

Esta é outra função que nos pediram há muito tempo, por razões bem conhecidas por todos nós. Como já observei repetidamente em publicações anteriores, o WireSock Secure Connect usa a implementação do protocolo WireGuard da Cloudflare como base, ou seja, o BoringTun. Vale a pena notar que, em termos de desempenho, ele supera visivelmente os forks do wireguard-go, no qual o cliente Amnezia original para Windows é construído.

Adicionamos o processamento de intervalos de tags de pacotes H1–H4 diretamente ao nosso fork do BoringTun. Os parâmetros S1–S4 são processados no código do próprio WireSock. No futuro, queremos desenvolver essa mecânica em direção a um mascaramento mais plausível e, com o tempo, substituir as inserções geradas aleatoriamente por uma imitação de protocolos de rede reais.

Vale a pena mencionar, no entanto, algumas diferenças. Para ser honesto, os parâmetros I1–I5 sempre me pareceram excessivamente complicados para um usuário comum. A ideia de coletar um dump binário de um pacote no Wireshark e, em seguida, inseri-lo manualmente na configuração parece interessante, mas é mais um exercício de engenharia do que uma configuração que pode ser chamada de realmente amigável.

Portanto, no WireSock, escolhemos uma abordagem diferente e adicionamos nossos próprios parâmetros para gerar pacotes de imitação. Em vez de um conjunto de I1–I5, Id, Ip e Ib são usados: domínio, protocolo e perfil do navegador. Atualmente, os perfis de mascaramento para QUIC e DNS são suportados, e planejamos expandir essa lista no futuro. Na prática, esse esquema acaba sendo mais compreensível e útil, porque permite trabalhar não com números abstratos, mas com um modelo de configuração mais significativo.

CLI: duas ferramentas diferentes

Vale a pena mencionar separadamente as mudanças relacionadas às ferramentas de linha de comando. O cliente de console minimalista, que existia desde a primeira versão, foi movido para um instalador SDK separado e, juntamente com a nova arquitetura, apareceu outro CLI para gerenciar serviços em segundo plano.

O formato SDK separado reflete melhor o papel real desse cliente. A partir da segunda versão, ele era necessário não tanto como uma alternativa à interface do usuário principal, mas como um backend para ferramentas como TunnlTo ou SplitWire-Turkey, bem como uma base para cenários de implantação minimalistas e integração em soluções de terceiros.

A solicitação para um cliente tão minimalista era bastante perceptível. Em algum momento, até a Microsoft veio até nós com estatísticas sobre suas falhas, onde a contagem chegava a dezenas de milhões de eventos. Isso soou, é claro, alarmante, mas o bug em si acabou sendo bastante inofensivo: após a conclusão do trabalho, o cliente tentou gravar uma mensagem no log. Não foi difícil corrigir isso, e a história acabou sendo mais engraçada, mas mostra bem que essa ferramenta foi realmente usada muito e em uma variedade de cenários.

O novo CLI, que apareceu na versão 3.x, resolve um problema diferente. Se o cliente de console minimalista era focado principalmente em cenários headless e integração, a nova ferramenta se tornou parte da arquitetura de serviço do WireSock Secure Connect e se destina a gerenciar serviços em segundo plano a partir da linha de comando.

Na prática, isso significa que as principais ações relacionadas à conexão, desconexão e gerenciamento de perfis agora podem ser executadas sem uma interface do usuário e sem quaisquer soluções alternativas. Para automação, scripts e maneiras mais minimalistas de trabalhar, isso acabou sendo um desenvolvimento bastante natural do novo modelo de serviço.

Onde obter tudo isso

Por razões óbvias, para alguns usuários, a questão de "onde baixar" nos últimos anos se tornou tão prática quanto a questão de "o que há de novo".

Para instalação via winget, o cliente principal é publicado como NTKERNEL.WireSockVPNClient, e o cliente de console minimalista como NTKERNEL.WireSockVPNClientCLI. No site do WireSock, os downloads para Secure Connect e SDK também estão disponíveis separadamente.

Ao mesmo tempo, nem tudo é perfeito com o próprio site. wiresock.net, como é fácil adivinhar, é instável ou não abre para alguns provedores na Rússia. Portanto, estamos tentando duplicar as versões mais recentes também no grupo oficial no Telegram. No entanto, a situação com o Telegram em nossos tempos difíceis também é ambígua. No final, a ironia do momento é que, para baixar uma VPN, às vezes você precisa primeiro de outra VPN.

Em vez de uma conclusão

Se tentarmos reduzir tudo o que foi dito a uma ideia, o WireSock Secure Connect 3.x se tornou mais complexo não por causa da complexidade, mas porque o mundo ao redor não se tornou mais simples. Por trás das notas de lançamento secas, neste caso, não há apenas uma lista de novas funções, mas uma tentativa de tornar a ferramenta mais resistente aos cenários que, há alguns anos, pareciam raros ou mesmo exóticos.

Como sempre, ficaremos felizes em receber feedback, comentários e relatórios de bugs. Tudo isso ajuda a mover o produto na direção certa.

A todos, o bem.