O Jogo da Imitação: O Próximo Passo para Contornar Bloqueios de Rede
A evolução das técnicas para mascarar o tráfego VPN, migrando de simples ruídos para a imitação de protocolos como QUIC, DNS e SIP, visando enganar sistemas de inspeção profunda de pacotes (DPI).
MundiX News·14 de junho de 2026·15 min de leitura·👁 8 views
O WireGuard rapidamente se estabeleceu como um protocolo VPN popular, apreciado por sua simplicidade, velocidade e arquitetura limpa, contrastando com legados mais pesados como IPsec e OpenVPN. No entanto, o que antes era uma força – sua previsibilidade e simplicidade – tornou-se um ponto fraco. A facilidade com que o WireGuard pode ser identificado o tornou um alvo relativamente simples para bloqueio. Assim que as tentativas de bloqueio começaram, surgiram as primeiras estratégias para ocultar o tráfego WireGuard. Inicialmente, eram métodos rudimentares, como adicionar pacotes UDP aleatórios antes do handshake para confundir a Inspeção Profunda de Pacotes (DPI) no início da sessão. Posteriormente, o AmneziaWG deu um passo adiante, alterando a própria aparência dos pacotes WireGuard, modificando cabeçalhos, tamanhos e inserindo dados "junk" (lixo) durante o handshake. O AmneziaWG 2.0 expandiu ainda mais as possibilidades, introduzindo os campos S3 e S4, além dos já existentes S1 e S2, permitindo que as inserções controladas fossem aplicadas não apenas ao handshake, mas também a outros tipos de mensagens, incluindo o fluxo de dados principal. Paralelamente, desenvolveu-se a ideia de pacotes de imitação: em vez de simplesmente enviar lixo aleatório antes do handshake, enviavam-se pacotes que se assemelhavam ao tráfego de outros protocolos para enganar a classificação inicial.
Este artigo explora o próximo estágio dessa evolução. Se antes os pacotes de imitação serviam principalmente como uma cortina de fumaça temporária antes do handshake, agora a imitação é transferida para o próprio fluxo de dados. Os pacotes de transporte do AmneziaWG na rede começam a se parecer com QUIC, DNS, STUN ou SIP. Quando se fala que o DPI reconhece o WireGuard, pode-se imaginar um sistema quase mágico: uma caixa inteligente no provedor de internet que decifra pacotes, analisa conteúdo, constrói modelos complexos e só então emite um veredito. Na prática, a situação é frequentemente mais simples. O WireGuard possui tipos de mensagens fixos, tamanhos previsíveis para os pacotes iniciais e uma ordem de troca característica no início da sessão. O Handshake Initiation, seguido pelo Handshake Response, e depois os dados de transporte. Tudo isso viaja sobre UDP, e os primeiros pacotes da conexão são bastante reconhecíveis. Para o DPI, essa é uma situação conveniente. Basta observar os sinais externos: tamanho dos pacotes, ordem, primeiros bytes, comportamento da sessão UDP. Se eles formam um padrão familiar, o fluxo pode ser marcado como WireGuard. E a partir daí, ações podem ser tomadas: bloqueio, lentidão, interrupção após o handshake ou simplesmente o envio para uma categoria separada para análise posterior. Nesse sentido, o WireGuard se apresenta de forma excessivamente "honesta". É limpo, minimalista e previsível. Para o protocolo, isso é uma virtude, mas em redes com filtragem agressiva, essa previsibilidade se torna uma desvantagem significativa.
A primeira ideia foi simples: se o DPI detecta o WireGuard pelo início característico da sessão, é preciso tornar esse início menos perceptível. Antes do handshake real, o cliente envia alguns pacotes UDP com dados aleatórios. Eles não carregam nenhuma carga útil significativa, apenas criam um ruído de fundo. Como resultado, o Handshake Initiation não aparece mais como o primeiro pacote em um fluxo vazio, mas se perde entre outras datagramas. Isso, claro, não se assemelha a uma proteção esteganográfica séria. Mas a ideia em si é importante: o cliente não confia mais apenas que o DPI não o reconhecerá, mas começa a formar ativamente a imagem que um observador verá. Contra filtros simples, essa abordagem pode realmente funcionar, especialmente se o bloqueio estiver vinculado aos primeiros pacotes da sessão UDP. Se o Handshake Initiation for visto em um local limpo, o fluxo é marcado como WireGuard e bloqueado. Se não for visto, a conexão tem uma chance de prosseguir. No entanto, o ruído aleatório tem um limite claro. Se um conjunto de pacotes com conteúdo aleatório aparecer repentinamente antes de uma sessão VPN, isso também se torna um indicativo. Sim, não é mais WireGuard puro. Mas também não é um protocolo de aplicação normal. Protocolos comuns raramente iniciam uma conversa com um conjunto de bytes sem sentido e sem estrutura. O ruído pode confundir um classificador simples, mas por si só não torna o tráfego semelhante a algo permitido. Ele mais sugere: "eu não sou WireGuard, sou apenas algo estranho". E em redes com filtragem rígida, "algo estranho" também não é uma máscara muito eficaz. O AmneziaWG deu um passo adiante, alterando a própria aparência dos pacotes. Se as primeiras tentativas de mascaramento escondiam o WireGuard atrás de ruído antes da sessão, o AmneziaWG foi mais fundo e começou a modificar a aparência dos pacotes. A ideia é simples: se o DPI reconhece o protocolo por características distintas, é preciso tornar essas características menos estáveis. Portanto, o AmneziaWG pode adicionar pacotes "junk" antes do handshake, alterar os valores dos cabeçalhos de tipo de mensagem e adicionar dados extras dentro do handshake para que ele não se destaque pelo tamanho usual. Como resultado, não apenas o início da sessão é mascarado, mas os próprios pacotes que antes eram usados para identificar o WireGuard. O DPI não vê mais o handshake de referência: os tamanhos mudam, os tipos de pacotes parecem diferentes, as assinaturas se tornam difusas. Na prática, o AmneziaWG auto-hospedado em muitos casos se mostra notavelmente mais resiliente que o WireGuard comum. E, no entanto, ainda é um jogo de ocultação: tornar o WireGuard menos parecido consigo mesmo. O AmneziaWG 2.0 expandiu o espaço para manobras. Se antes as inserções principais se aplicavam ao handshake, agora uma adição controlada foi introduzida para outros tipos de mensagens. Do ponto de vista prático, são quatro campos S1-S4. Cada um deles é responsável por um tipo de pacote WireGuard: S1 para Handshake Initiation; S2 para Handshake Response; S3 para Cookie Reply; S4 para Transport Data. Ao lado deles estão H1-H4. Estes são os valores com os quais o AmneziaWG substitui o cabeçalho padrão do tipo de mensagem WireGuard. Além disso, na segunda versão, eles podem ser definidos não apenas por números específicos, mas também por intervalos. Como resultado, o pacote se torna externamente menos estável: uma inserção controlada aparece antes dele, e o cabeçalho WireGuard familiar deixa de ser tão óbvio. No entanto, na minha opinião, a expansão mais interessante do AmneziaWG 2.0 é o S4, que se refere ao Transport Data, ou seja, ao fluxo de dados principal. Isso significa que o espaço para mascaramento não existe apenas no início da conexão, mas ao longo de toda a vida do túnel. E aqui surge uma pergunta natural: se em cada pacote já existe espaço para uma inserção controlada, é realmente necessário preenchê-lo com bytes aleatórios? Por que não usar esse espaço de forma que o pacote se pareça não com ruído aleatório, mas com outro protocolo? A ideia é substituir o ruído aleatório em S1-S4 por uma estrutura significativa, semelhante ao tráfego de outro protocolo. E em combinação com pacotes de imitação e "junk" gerados corretamente, isso ajuda a formar um perfil de conexão externo mais plausível. Obviamente, para uma imitação bidirecional completa, ambos os lados do túnel VPN são necessários. No servidor, o amneziawg-proxy é responsável por isso: um proxy UDP separado que é colocado antes do servidor AmneziaWG. O próprio AmneziaWG é movido para o loopback, por exemplo, para 127.0.0.1, e a porta UDP pública é ocupada pelo proxy. É essa porta que o DPI vê de fora, e é com ela que as verificações externas interagem. A tarefa do proxy do servidor consiste em duas coisas. Primeiro, ele responde a sondas ativas como um serviço real. Se um QUIC Initial, uma consulta DNS, um STUN Binding Request ou um SIP Request chegar à porta, o proxy retorna a resposta esperada do protocolo correspondente: para QUIC, é o Version Negotiation; para DNS, é uma resposta DNS; para STUN, é o Binding Success; para SIP, é o 100 Trying. Isso é importante, porque a mascaramento passivo já não é suficiente. O filtro pode não apenas observar o tráfego que passa, mas também verificar ativamente uma porta suspeita: é realmente QUIC, DNS, STUN ou SIP? Se a porta estiver silenciosa ou responder de forma diferente do que um serviço real deveria, a máscara rapidamente desaparece. Segundo, o proxy trabalha com a direção do tráfego do servidor. Os pacotes AmneziaWG já contêm inserções S controladas, e o proxy pode sobrescrever esse local não com bytes aleatórios, mas com bytes característicos do protocolo selecionado. Como resultado, os pacotes de resposta do lado do servidor começam a parecer QUIC, DNS, STUN ou SIP, embora a carga útil criptografada do AmneziaWG permaneça dentro. Mas isso é apenas metade da história. Para que a imitação seja bidirecional, o cliente também deve ser capaz de formar pacotes no mesmo estilo. Essa parte é implementada pelo WireSock Secure Connect 3.5+. Ele cria pacotes de imitação do cliente e preenche as inserções S em seu lado para que a direção do cliente para o servidor não pareça um AmneziaWG comum, mas sim tráfego do protocolo selecionado. É a combinação de WireSock Secure Connect 3.5+ e amneziawg-proxy que torna a abordagem completa. O proxy é responsável pelo lado do servidor, pelas respostas às sondas e pelo mascaramento do fluxo de resposta. O WireSock Secure Connect cuida do lado do cliente. Juntos, eles alteram a aparência das datagramas na rede para que, para um observador externo, não seja WireGuard nem "WireGuard ofuscado", mas sim tráfego do protocolo selecionado: QUIC, DNS, STUN ou SIP. Essa abordagem desenvolve a ideia de pacotes de imitação I1-I4 e a eleva a um novo nível. Esses parâmetros em si, na minha opinião, não são os mais convenientes para o usuário, então no WireSock Secure Connect eu os substituí por um esquema mais compreensível: domínio, protocolo e perfil do navegador. Mas a ideia é eficaz: em vez de ruído aleatório antes do handshake, apresentar ao DPI um tráfego semelhante a outro protocolo. E se o servidor também responder a esses pacotes como um serviço real, e o fluxo subsequente continuar parecendo o protocolo selecionado, a máscara se torna muito mais convincente. O modo QUIC na porta pública do servidor. O Wireshark analisa o fluxo como QUIC normal: Initial com CRYPTO, depois Handshake e Protected Payload. Dentro, o túnel AmneziaWG permanece, e a forma externa dos pacotes é definida pelo amneziawg-proxy e Wiresock Secure Connect. O preenchimento aleatório ajuda a ocultar os sinais reconhecíveis, mas não torna o tráfego semelhante a um protocolo normal. Ele mais cria incerteza: não é mais WireGuard puro, mas também não é algo familiar para a rede. A imitação de protocolo funciona de forma diferente. Sua tarefa não é apenas remover a assinatura do WireGuard, mas substituí-la por uma imagem mais plausível. Para que o pacote pareça não um conjunto de bytes aleatórios, mas sim QUIC, DNS, STUN, SIP ou algo mais. Para o DPI, essa é uma situação diferente. O pacote não apenas deixa de parecer WireGuard, mas começa a parecer um pacote normal do protocolo selecionado. No início da datagrama, aparece uma estrutura significativa de QUIC, DNS, STUN ou SIP, em vez de bytes aleatórios que simplesmente mascaram o cabeçalho WireGuard. Claro, isso não torna o tráfego invisível. Mas o custo da análise muda. É uma coisa bloquear tudo que se parece com WireGuard ou com ruído UDP estranho. Outra coisa é começar a suspeitar agressivamente de tráfego que se parece com QUIC, DNS, STUN ou SIP, sem afetar os serviços reais que usam os mesmos protocolos. Em redes onde falsos positivos são indesejáveis, isso é um jogo completamente diferente. Atualmente, o amneziawg-proxy oferece vários modos de imitação: QUIC, DNS, STUN, SIP e auto. No modo auto, o protocolo de imitação é selecionado separadamente para cada cliente com base no primeiro pacote que chega dele na porta pública. QUIC parece a escolha padrão mais natural. A internet moderna já está repleta de tráfego QUIC/HTTP3: ele viaja sobre UDP, é criptografado, tem alta entropia e geralmente não se parece com o bom e velho protocolo de texto. Se for necessário escolher uma máscara "padrão", QUIC parece lógico. Outra opção interessante é o DNS. Por um lado, o DNS é frequentemente permitido mesmo em redes bastante restritas. Por outro lado, o tráfego DNS é geralmente esperado na porta 53, e seu comportamento pode ser cuidadosamente monitorado. Portanto, aqui é especialmente importante que o pacote não pareça WireGuard com uma inserção aleatória no início, mas seja analisado normalmente como uma mensagem DNS. Modo DNS. Na captura, são visíveis consultas e respostas DNS normais: registros A/AAAA/HTTPS, subdomínios, registros OPT. Com o encaminhamento de sondas DNS ativado, os sondadores podem receber respostas reais do resolvedor upstream, então a porta não parece apenas um placeholder, mas um serviço DNS funcional. STUN é útil onde o tráfego WebRTC ou outro tráfego de travessia NAT é esperado na rede. Nesse modo, os pacotes se parecem com Binding Request / Binding Success Response normais. Não é a camuflagem mais universal, mas em um ambiente adequado, ele se encaixa bem na imagem esperada. Modo STUN. Pacotes do cliente parecem Binding Request, pacotes do servidor parecem Binding Success Response com XOR-MAPPED-ADDRESS. Para o observador, isso se assemelha a uma troca normal de NAT traversal/WebRTC. SIP parece o modo mais incomum. A ideia de mascarar uma VPN como sinalização VoIP à primeira vista parece estranha, mas na prática a imagem se torna bastante convincente: cabeçalhos SIP de texto, solicitações INVITE, OPTIONS, REGISTER, SUBSCRIBE e respostas familiares como 100 Trying ou 200 OK. Este modo mostra bem o quão longe chegamos do simples preenchimento aleatório: o tráfego não está apenas se escondendo, mas tentando desempenhar o papel de um serviço bastante específico. Modo SIP. Na captura, são visíveis INVITE, CANCEL, NOTIFY, OPTIONS, REGISTER, SUBSCRIBE e respostas como 100 Trying, 180 Ringing, 200 OK. Na rede, tal fluxo se parece com a sinalização de infraestrutura VoIP. O modo auto é necessário para cenários onde o mesmo servidor atende clientes com diferentes modos de imitação. Nesse modo, o proxy não fixa um protocolo antecipadamente, mas observa o primeiro pacote de cada cliente. Se o pacote se assemelha a QUIC, DNS, STUN ou SIP, o proxy memoriza esse protocolo para a sessão atual e o utiliza para o tráfego de resposta. Se o primeiro pacote não se assemelha a nenhum modo conhecido, a sessão permanece no estado none e funciona como um encaminhamento AmneziaWG comum sem imitação de protocolo por parte do proxy. O amneziawg-proxy funciona no servidor. Ele cobre o lado do servidor da tarefa: recebe tráfego na porta UDP pública, responde a sondas ativas e mascara o fluxo de resposta do servidor para o cliente. Mas para uma imitação completa, isso não é suficiente. Se o cliente envia pacotes AmneziaWG comuns, e o servidor responde com pacotes mascarados, a imagem fica unilateral. De fora, parece melhor do que o AmneziaWG comum, mas a direção do cliente para o servidor ainda permanece um ponto fraco. Para imitação bidirecional, o cliente também deve participar do jogo. Ele deve formar pacotes de imitação antes do handshake e preencher as inserções S não com bytes aleatórios, mas com a estrutura do protocolo selecionado. Essa parte é implementada pelo WireSock Secure Connect 3.5+. Portanto, um cenário completo é construído com base na combinação de dois componentes. O amneziawg-proxy é responsável pelo lado do servidor, pelas respostas às sondas e pelo mascaramento do fluxo de resposta. O WireSock Secure Connect cuida do lado do cliente. Juntos, eles permitem que o tráfego, para um observador externo, não pareça WireGuard ou WireGuard ofuscado, mas sim QUIC, DNS, STUN ou SIP. Há ainda outro detalhe prático que vale a pena destacar: tudo isso pode ser observado não apenas através de logs e tcpdump. No amneziawg-install, juntamente com o proxy, um painel web está sendo desenvolvido. Ele mostra o status dos peers, o último handshake, contadores RX/TX, o tempo de atividade do servidor e o tempo de inicialização. Abaixo, em um bloco separado, são exibidas as sessões de proxy ativas: endereço real do cliente, porta pública do proxy, porta de destino do AmneziaWG, protocolo reconhecido e tempo da última atividade. Painel Web AmneziaWG. No topo, são visíveis as versões dos componentes e o tempo de atividade do servidor, abaixo – a lista de peers, o último handshake e os contadores RX/TX. Um bloco separado de sessões de proxy ativas mostra as sessões de proxy reais: endereço remoto do cliente, porta do proxy, porta de destino, protocolo reconhecido e tempo da última atividade. Na captura de tela, duas sessões ativas são visíveis: uma definida como sip e outra como none. Este é um bom exemplo para o modo auto: parte dos clientes pode usar imitação de protocolo completa, e parte pode passar por encaminhamento AmneziaWG comum sem máscara reconhecida. Anteriormente, tal imagem teria que ser montada manualmente: verificar logs, executar tcpdump, correlacionar endereços e portas. Agora, os detalhes principais estão disponíveis diretamente do navegador. Claro, o painel web não substitui o diagnóstico normal. Se for necessário entender o que exatamente está acontecendo na rede, tcpdump e Wireshark ainda serão úteis. Para o lado do cliente, o WireSock Secure Connect de console também é útil: ele pode gravar o tráfego do túnel em arquivos PCAP, que podem ser abertos e analisados posteriormente no Wireshark. Mas para o controle diário, o painel web é visivelmente mais conveniente do que o trabalho constante com logs e dumps de tráfego. Não há vitória final na luta contra o DPI. Esta não é uma área onde se pode inventar um truque elegante uma vez e resolver o problema para sempre. Qualquer método em massa, mais cedo ou mais tarde, começa a ser estudado. Primeiro, o filtro reconhece o WireGuard por sinais óbvios de handshake. Então, quando a ofuscação e o junk aleatório aparecem, ele começa a olhar mais amplamente: para timings, volumes, repetitividade, comportamento da sessão, reação a verificações ativas. Se uma imitação específica se tornar massiva, ela também será analisada. Portanto, a questão principal não é se é possível tornar o tráfego completamente indetectável. Provavelmente não. Muito mais importante é outra coisa: quão caro e arriscado se torna destacá-lo. Bloquear WireGuard puro é relativamente simples. Bloquear ruído UDP suspeito também pode ser feito, especialmente em uma rede com filtragem agressiva. Mas começar a bloquear tráfego que se parece de forma convincente com QUIC, DNS, STUN ou SIP já é mais difícil. Pode-se afetar serviços reais, quebrar aplicativos, obter falsos positivos e reclamações. É aqui que a imitação de protocolo eleva o nível. Ela não torna o túnel invisível, mas muda a economia da detecção: distinguir tal tráfego do legítimo se torna mais difícil, mais caro e mais arriscado em termos de efeitos colaterais. Não quero que este artigo seja lido como uma promessa de "agora tudo funciona em todos os lugares". Isso não acontece. A eficácia sempre depende da rede específica. O DPI de diferentes operadoras é configurado de forma diferente. Em alguns lugares, basta esconder o handshake; em outros, o junk ajuda; em outros, uma imitação completa é necessária; e em alguns, o modo escolhido pode nem mesmo fornecer um ganho perceptível. Existem também cenários onde a imitação de protocolo não ajudará em princípio: por exemplo, redes com listas brancas, onde apenas endereços ou serviços pré-aprovados são permitidos, bem como bloqueio direto do endereço IP do servidor. Nesses casos, o tráfego pode parecer QUIC, DNS, STUN ou SIP o quanto quiser, mas isso não mudará a política de rede em si. Não existe um perfil universal que funcione igualmente bem em todas as condições. Qualquer imitação deixa um rastro comportamental. Mesmo que uma datagrama individual seja analisada lindamente como DNS, QUIC, STUN ou SIP, permanecem os timings, volumes, duração da sessão, distribuição de tamanhos de pacotes, reação a verificações repetidas. Um servidor DNS real, um serviço SIP real e um túnel VPN mascarado sob eles podem ser semelhantes no nível de um único pacote, mas não são obrigados a se comportar da mesma forma no nível de uma sessão longa. O proxy também não é gratuito em termos de recursos. É uma camada adicional no userspace: ele recebe UDP, gerencia sessões, responde a pacotes de sonda, reescreve o preenchimento e encaminha o tráfego adiante. Para um VPS doméstico ou uma pequena instalação, os custos adicionais provavelmente serão aceitáveis. Mas em velocidades próximas a um gigabit, já vale a pena observar a CPU, as chamadas de sistema e o escalonamento por núcleos. As capturas de tela do Wireshark neste artigo também devem ser interpretadas corretamente. Elas mostram que o tráfego é analisado puramente como o protocolo selecionado. Esta é uma parte importante da tarefa, mas não uma prova de indetectabilidade. O DPI real pode observar não apenas um pacote, mas também o comportamento do fluxo como um todo. E, finalmente, esta é uma tecnologia de dupla finalidade. É útil para privacidade, acesso a servidores próprios e estabilidade de conexão em redes com filtragem agressiva. Mas, como quase qualquer ferramenta de rede, ela pode ser usada de diferentes maneiras. Essa escolha permanece na consciência de quem a aplica. Em resumo, a evolução é a seguinte. Primeiro, tentaram esconder o WireGuard do DPI com ruído antes do handshake. Depois, surgiu o AmneziaWG, que começou a modificar os próprios sinais do protocolo: cabeçalhos, tamanhos e junk dentro do handshake. O AmneziaWG 2.0 deu mais espaço para inserções controladas através de S1-S4, incluindo o fluxo de dados principal. O próximo passo se apresentou naturalmente. Se já existe um espaço no pacote que pode ser controlado, ele pode ser preenchido não com bytes aleatórios, mas com a estrutura de outro protocolo. É aqui que começa o "jogo da imitação". O WireGuard na rede não deve parecer WireGuard, mas sim QUIC, DNS, STUN ou SIP comum. A imitação não se limita mais a alguns pacotes antes do handshake. A máscara escolhida é mantida também no fluxo de trabalho, e o servidor responde a pacotes de sonda como um serviço real faria. Neste esquema, o WireSock Secure Connect 3.5+ cuida do lado do cliente, e o amneziawg-proxy cobre o lado do servidor: responde a pacotes de sonda, mascara o fluxo de resposta e ajuda a construir uma imagem plausível de ambos os lados do túnel. A partida contra o DPI, é claro, não termina aqui. É apenas mais um movimento em um jogo longo. Mas, na minha opinião, um movimento lógico: da ideia de "esconder a VPN na aleatoriedade", passamos gradualmente para uma ideia mais madura, onde o túnel se torna parte da paisagem de rede esperada. O projeto descrito é um desenvolvimento independente da comunidade e não está relacionado à Amnezia, amnezia.org, ao aplicativo Amnezia VPN ou ao serviço Amnezia Free VPN. Ele utiliza o protocolo aberto AmneziaWG e ferramentas relacionadas. Os nomes "Amnezia", "AmneziaWG" e as marcas registradas associadas pertencem aos seus respectivos proprietários e são usados aqui apenas para fins de identificação.
🛡️⚡
Pare de pesquisar. Comece a hackear.
O MundiX é seu copiloto de pentest com IA: comandos exatos, análise de outputs e próximo passo na kill chain — em segundos.
Sem cartão para começar · Planos a partir de R$49/mês
O WireGuard rapidamente se estabeleceu como um protocolo VPN popular, apreciado por sua simplicidade, velocidade e arquitetura limpa, contrastando com legados mais pesados como IPsec e OpenVPN. No entanto, o que antes era uma força – sua previsibilidade e simplicidade – tornou-se um ponto fraco. A facilidade com que o WireGuard pode ser identificado o tornou um alvo relativamente simples para bloqueio. Assim que as tentativas de bloqueio começaram, surgiram as primeiras estratégias para ocultar o tráfego WireGuard. Inicialmente, eram métodos rudimentares, como adicionar pacotes UDP aleatórios antes do handshake para confundir a Inspeção Profunda de Pacotes (DPI) no início da sessão. Posteriormente, o AmneziaWG deu um passo adiante, alterando a própria aparência dos pacotes WireGuard, modificando cabeçalhos, tamanhos e inserindo dados "junk" (lixo) durante o handshake. O AmneziaWG 2.0 expandiu ainda mais as possibilidades, introduzindo os campos S3 e S4, além dos já existentes S1 e S2, permitindo que as inserções controladas fossem aplicadas não apenas ao handshake, mas também a outros tipos de mensagens, incluindo o fluxo de dados principal. Paralelamente, desenvolveu-se a ideia de pacotes de imitação: em vez de simplesmente enviar lixo aleatório antes do handshake, enviavam-se pacotes que se assemelhavam ao tráfego de outros protocolos para enganar a classificação inicial.
Este artigo explora o próximo estágio dessa evolução. Se antes os pacotes de imitação serviam principalmente como uma cortina de fumaça temporária antes do handshake, agora a imitação é transferida para o próprio fluxo de dados. Os pacotes de transporte do AmneziaWG na rede começam a se parecer com QUIC, DNS, STUN ou SIP. Quando se fala que o DPI reconhece o WireGuard, pode-se imaginar um sistema quase mágico: uma caixa inteligente no provedor de internet que decifra pacotes, analisa conteúdo, constrói modelos complexos e só então emite um veredito. Na prática, a situação é frequentemente mais simples. O WireGuard possui tipos de mensagens fixos, tamanhos previsíveis para os pacotes iniciais e uma ordem de troca característica no início da sessão. O Handshake Initiation, seguido pelo Handshake Response, e depois os dados de transporte. Tudo isso viaja sobre UDP, e os primeiros pacotes da conexão são bastante reconhecíveis. Para o DPI, essa é uma situação conveniente. Basta observar os sinais externos: tamanho dos pacotes, ordem, primeiros bytes, comportamento da sessão UDP. Se eles formam um padrão familiar, o fluxo pode ser marcado como WireGuard. E a partir daí, ações podem ser tomadas: bloqueio, lentidão, interrupção após o handshake ou simplesmente o envio para uma categoria separada para análise posterior. Nesse sentido, o WireGuard se apresenta de forma excessivamente "honesta". É limpo, minimalista e previsível. Para o protocolo, isso é uma virtude, mas em redes com filtragem agressiva, essa previsibilidade se torna uma desvantagem significativa.
A primeira ideia foi simples: se o DPI detecta o WireGuard pelo início característico da sessão, é preciso tornar esse início menos perceptível. Antes do handshake real, o cliente envia alguns pacotes UDP com dados aleatórios. Eles não carregam nenhuma carga útil significativa, apenas criam um ruído de fundo. Como resultado, o Handshake Initiation não aparece mais como o primeiro pacote em um fluxo vazio, mas se perde entre outras datagramas. Isso, claro, não se assemelha a uma proteção esteganográfica séria. Mas a ideia em si é importante: o cliente não confia mais apenas que o DPI não o reconhecerá, mas começa a formar ativamente a imagem que um observador verá. Contra filtros simples, essa abordagem pode realmente funcionar, especialmente se o bloqueio estiver vinculado aos primeiros pacotes da sessão UDP. Se o Handshake Initiation for visto em um local limpo, o fluxo é marcado como WireGuard e bloqueado. Se não for visto, a conexão tem uma chance de prosseguir. No entanto, o ruído aleatório tem um limite claro. Se um conjunto de pacotes com conteúdo aleatório aparecer repentinamente antes de uma sessão VPN, isso também se torna um indicativo. Sim, não é mais WireGuard puro. Mas também não é um protocolo de aplicação normal. Protocolos comuns raramente iniciam uma conversa com um conjunto de bytes sem sentido e sem estrutura. O ruído pode confundir um classificador simples, mas por si só não torna o tráfego semelhante a algo permitido. Ele mais sugere: "eu não sou WireGuard, sou apenas algo estranho". E em redes com filtragem rígida, "algo estranho" também não é uma máscara muito eficaz. O AmneziaWG deu um passo adiante, alterando a própria aparência dos pacotes. Se as primeiras tentativas de mascaramento escondiam o WireGuard atrás de ruído antes da sessão, o AmneziaWG foi mais fundo e começou a modificar a aparência dos pacotes. A ideia é simples: se o DPI reconhece o protocolo por características distintas, é preciso tornar essas características menos estáveis. Portanto, o AmneziaWG pode adicionar pacotes "junk" antes do handshake, alterar os valores dos cabeçalhos de tipo de mensagem e adicionar dados extras dentro do handshake para que ele não se destaque pelo tamanho usual. Como resultado, não apenas o início da sessão é mascarado, mas os próprios pacotes que antes eram usados para identificar o WireGuard. O DPI não vê mais o handshake de referência: os tamanhos mudam, os tipos de pacotes parecem diferentes, as assinaturas se tornam difusas. Na prática, o AmneziaWG auto-hospedado em muitos casos se mostra notavelmente mais resiliente que o WireGuard comum. E, no entanto, ainda é um jogo de ocultação: tornar o WireGuard menos parecido consigo mesmo. O AmneziaWG 2.0 expandiu o espaço para manobras. Se antes as inserções principais se aplicavam ao handshake, agora uma adição controlada foi introduzida para outros tipos de mensagens. Do ponto de vista prático, são quatro campos S1-S4. Cada um deles é responsável por um tipo de pacote WireGuard: S1 para Handshake Initiation; S2 para Handshake Response; S3 para Cookie Reply; S4 para Transport Data. Ao lado deles estão H1-H4. Estes são os valores com os quais o AmneziaWG substitui o cabeçalho padrão do tipo de mensagem WireGuard. Além disso, na segunda versão, eles podem ser definidos não apenas por números específicos, mas também por intervalos. Como resultado, o pacote se torna externamente menos estável: uma inserção controlada aparece antes dele, e o cabeçalho WireGuard familiar deixa de ser tão óbvio. No entanto, na minha opinião, a expansão mais interessante do AmneziaWG 2.0 é o S4, que se refere ao Transport Data, ou seja, ao fluxo de dados principal. Isso significa que o espaço para mascaramento não existe apenas no início da conexão, mas ao longo de toda a vida do túnel. E aqui surge uma pergunta natural: se em cada pacote já existe espaço para uma inserção controlada, é realmente necessário preenchê-lo com bytes aleatórios? Por que não usar esse espaço de forma que o pacote se pareça não com ruído aleatório, mas com outro protocolo? A ideia é substituir o ruído aleatório em S1-S4 por uma estrutura significativa, semelhante ao tráfego de outro protocolo. E em combinação com pacotes de imitação e "junk" gerados corretamente, isso ajuda a formar um perfil de conexão externo mais plausível. Obviamente, para uma imitação bidirecional completa, ambos os lados do túnel VPN são necessários. No servidor, o amneziawg-proxy é responsável por isso: um proxy UDP separado que é colocado antes do servidor AmneziaWG. O próprio AmneziaWG é movido para o loopback, por exemplo, para 127.0.0.1, e a porta UDP pública é ocupada pelo proxy. É essa porta que o DPI vê de fora, e é com ela que as verificações externas interagem. A tarefa do proxy do servidor consiste em duas coisas. Primeiro, ele responde a sondas ativas como um serviço real. Se um QUIC Initial, uma consulta DNS, um STUN Binding Request ou um SIP Request chegar à porta, o proxy retorna a resposta esperada do protocolo correspondente: para QUIC, é o Version Negotiation; para DNS, é uma resposta DNS; para STUN, é o Binding Success; para SIP, é o 100 Trying. Isso é importante, porque a mascaramento passivo já não é suficiente. O filtro pode não apenas observar o tráfego que passa, mas também verificar ativamente uma porta suspeita: é realmente QUIC, DNS, STUN ou SIP? Se a porta estiver silenciosa ou responder de forma diferente do que um serviço real deveria, a máscara rapidamente desaparece. Segundo, o proxy trabalha com a direção do tráfego do servidor. Os pacotes AmneziaWG já contêm inserções S controladas, e o proxy pode sobrescrever esse local não com bytes aleatórios, mas com bytes característicos do protocolo selecionado. Como resultado, os pacotes de resposta do lado do servidor começam a parecer QUIC, DNS, STUN ou SIP, embora a carga útil criptografada do AmneziaWG permaneça dentro. Mas isso é apenas metade da história. Para que a imitação seja bidirecional, o cliente também deve ser capaz de formar pacotes no mesmo estilo. Essa parte é implementada pelo WireSock Secure Connect 3.5+. Ele cria pacotes de imitação do cliente e preenche as inserções S em seu lado para que a direção do cliente para o servidor não pareça um AmneziaWG comum, mas sim tráfego do protocolo selecionado. É a combinação de WireSock Secure Connect 3.5+ e amneziawg-proxy que torna a abordagem completa. O proxy é responsável pelo lado do servidor, pelas respostas às sondas e pelo mascaramento do fluxo de resposta. O WireSock Secure Connect cuida do lado do cliente. Juntos, eles alteram a aparência das datagramas na rede para que, para um observador externo, não seja WireGuard nem "WireGuard ofuscado", mas sim tráfego do protocolo selecionado: QUIC, DNS, STUN ou SIP. Essa abordagem desenvolve a ideia de pacotes de imitação I1-I4 e a eleva a um novo nível. Esses parâmetros em si, na minha opinião, não são os mais convenientes para o usuário, então no WireSock Secure Connect eu os substituí por um esquema mais compreensível: domínio, protocolo e perfil do navegador. Mas a ideia é eficaz: em vez de ruído aleatório antes do handshake, apresentar ao DPI um tráfego semelhante a outro protocolo. E se o servidor também responder a esses pacotes como um serviço real, e o fluxo subsequente continuar parecendo o protocolo selecionado, a máscara se torna muito mais convincente. O modo QUIC na porta pública do servidor. O Wireshark analisa o fluxo como QUIC normal: Initial com CRYPTO, depois Handshake e Protected Payload. Dentro, o túnel AmneziaWG permanece, e a forma externa dos pacotes é definida pelo amneziawg-proxy e Wiresock Secure Connect. O preenchimento aleatório ajuda a ocultar os sinais reconhecíveis, mas não torna o tráfego semelhante a um protocolo normal. Ele mais cria incerteza: não é mais WireGuard puro, mas também não é algo familiar para a rede. A imitação de protocolo funciona de forma diferente. Sua tarefa não é apenas remover a assinatura do WireGuard, mas substituí-la por uma imagem mais plausível. Para que o pacote pareça não um conjunto de bytes aleatórios, mas sim QUIC, DNS, STUN, SIP ou algo mais. Para o DPI, essa é uma situação diferente. O pacote não apenas deixa de parecer WireGuard, mas começa a parecer um pacote normal do protocolo selecionado. No início da datagrama, aparece uma estrutura significativa de QUIC, DNS, STUN ou SIP, em vez de bytes aleatórios que simplesmente mascaram o cabeçalho WireGuard. Claro, isso não torna o tráfego invisível. Mas o custo da análise muda. É uma coisa bloquear tudo que se parece com WireGuard ou com ruído UDP estranho. Outra coisa é começar a suspeitar agressivamente de tráfego que se parece com QUIC, DNS, STUN ou SIP, sem afetar os serviços reais que usam os mesmos protocolos. Em redes onde falsos positivos são indesejáveis, isso é um jogo completamente diferente. Atualmente, o amneziawg-proxy oferece vários modos de imitação: QUIC, DNS, STUN, SIP e auto. No modo auto, o protocolo de imitação é selecionado separadamente para cada cliente com base no primeiro pacote que chega dele na porta pública. QUIC parece a escolha padrão mais natural. A internet moderna já está repleta de tráfego QUIC/HTTP3: ele viaja sobre UDP, é criptografado, tem alta entropia e geralmente não se parece com o bom e velho protocolo de texto. Se for necessário escolher uma máscara "padrão", QUIC parece lógico. Outra opção interessante é o DNS. Por um lado, o DNS é frequentemente permitido mesmo em redes bastante restritas. Por outro lado, o tráfego DNS é geralmente esperado na porta 53, e seu comportamento pode ser cuidadosamente monitorado. Portanto, aqui é especialmente importante que o pacote não pareça WireGuard com uma inserção aleatória no início, mas seja analisado normalmente como uma mensagem DNS. Modo DNS. Na captura, são visíveis consultas e respostas DNS normais: registros A/AAAA/HTTPS, subdomínios, registros OPT. Com o encaminhamento de sondas DNS ativado, os sondadores podem receber respostas reais do resolvedor upstream, então a porta não parece apenas um placeholder, mas um serviço DNS funcional. STUN é útil onde o tráfego WebRTC ou outro tráfego de travessia NAT é esperado na rede. Nesse modo, os pacotes se parecem com Binding Request / Binding Success Response normais. Não é a camuflagem mais universal, mas em um ambiente adequado, ele se encaixa bem na imagem esperada. Modo STUN. Pacotes do cliente parecem Binding Request, pacotes do servidor parecem Binding Success Response com XOR-MAPPED-ADDRESS. Para o observador, isso se assemelha a uma troca normal de NAT traversal/WebRTC. SIP parece o modo mais incomum. A ideia de mascarar uma VPN como sinalização VoIP à primeira vista parece estranha, mas na prática a imagem se torna bastante convincente: cabeçalhos SIP de texto, solicitações INVITE, OPTIONS, REGISTER, SUBSCRIBE e respostas familiares como 100 Trying ou 200 OK. Este modo mostra bem o quão longe chegamos do simples preenchimento aleatório: o tráfego não está apenas se escondendo, mas tentando desempenhar o papel de um serviço bastante específico. Modo SIP. Na captura, são visíveis INVITE, CANCEL, NOTIFY, OPTIONS, REGISTER, SUBSCRIBE e respostas como 100 Trying, 180 Ringing, 200 OK. Na rede, tal fluxo se parece com a sinalização de infraestrutura VoIP. O modo auto é necessário para cenários onde o mesmo servidor atende clientes com diferentes modos de imitação. Nesse modo, o proxy não fixa um protocolo antecipadamente, mas observa o primeiro pacote de cada cliente. Se o pacote se assemelha a QUIC, DNS, STUN ou SIP, o proxy memoriza esse protocolo para a sessão atual e o utiliza para o tráfego de resposta. Se o primeiro pacote não se assemelha a nenhum modo conhecido, a sessão permanece no estado none e funciona como um encaminhamento AmneziaWG comum sem imitação de protocolo por parte do proxy. O amneziawg-proxy funciona no servidor. Ele cobre o lado do servidor da tarefa: recebe tráfego na porta UDP pública, responde a sondas ativas e mascara o fluxo de resposta do servidor para o cliente. Mas para uma imitação completa, isso não é suficiente. Se o cliente envia pacotes AmneziaWG comuns, e o servidor responde com pacotes mascarados, a imagem fica unilateral. De fora, parece melhor do que o AmneziaWG comum, mas a direção do cliente para o servidor ainda permanece um ponto fraco. Para imitação bidirecional, o cliente também deve participar do jogo. Ele deve formar pacotes de imitação antes do handshake e preencher as inserções S não com bytes aleatórios, mas com a estrutura do protocolo selecionado. Essa parte é implementada pelo WireSock Secure Connect 3.5+. Portanto, um cenário completo é construído com base na combinação de dois componentes. O amneziawg-proxy é responsável pelo lado do servidor, pelas respostas às sondas e pelo mascaramento do fluxo de resposta. O WireSock Secure Connect cuida do lado do cliente. Juntos, eles permitem que o tráfego, para um observador externo, não pareça WireGuard ou WireGuard ofuscado, mas sim QUIC, DNS, STUN ou SIP. Há ainda outro detalhe prático que vale a pena destacar: tudo isso pode ser observado não apenas através de logs e tcpdump. No amneziawg-install, juntamente com o proxy, um painel web está sendo desenvolvido. Ele mostra o status dos peers, o último handshake, contadores RX/TX, o tempo de atividade do servidor e o tempo de inicialização. Abaixo, em um bloco separado, são exibidas as sessões de proxy ativas: endereço real do cliente, porta pública do proxy, porta de destino do AmneziaWG, protocolo reconhecido e tempo da última atividade. Painel Web AmneziaWG. No topo, são visíveis as versões dos componentes e o tempo de atividade do servidor, abaixo – a lista de peers, o último handshake e os contadores RX/TX. Um bloco separado de sessões de proxy ativas mostra as sessões de proxy reais: endereço remoto do cliente, porta do proxy, porta de destino, protocolo reconhecido e tempo da última atividade. Na captura de tela, duas sessões ativas são visíveis: uma definida como sip e outra como none. Este é um bom exemplo para o modo auto: parte dos clientes pode usar imitação de protocolo completa, e parte pode passar por encaminhamento AmneziaWG comum sem máscara reconhecida. Anteriormente, tal imagem teria que ser montada manualmente: verificar logs, executar tcpdump, correlacionar endereços e portas. Agora, os detalhes principais estão disponíveis diretamente do navegador. Claro, o painel web não substitui o diagnóstico normal. Se for necessário entender o que exatamente está acontecendo na rede, tcpdump e Wireshark ainda serão úteis. Para o lado do cliente, o WireSock Secure Connect de console também é útil: ele pode gravar o tráfego do túnel em arquivos PCAP, que podem ser abertos e analisados posteriormente no Wireshark. Mas para o controle diário, o painel web é visivelmente mais conveniente do que o trabalho constante com logs e dumps de tráfego. Não há vitória final na luta contra o DPI. Esta não é uma área onde se pode inventar um truque elegante uma vez e resolver o problema para sempre. Qualquer método em massa, mais cedo ou mais tarde, começa a ser estudado. Primeiro, o filtro reconhece o WireGuard por sinais óbvios de handshake. Então, quando a ofuscação e o junk aleatório aparecem, ele começa a olhar mais amplamente: para timings, volumes, repetitividade, comportamento da sessão, reação a verificações ativas. Se uma imitação específica se tornar massiva, ela também será analisada. Portanto, a questão principal não é se é possível tornar o tráfego completamente indetectável. Provavelmente não. Muito mais importante é outra coisa: quão caro e arriscado se torna destacá-lo. Bloquear WireGuard puro é relativamente simples. Bloquear ruído UDP suspeito também pode ser feito, especialmente em uma rede com filtragem agressiva. Mas começar a bloquear tráfego que se parece de forma convincente com QUIC, DNS, STUN ou SIP já é mais difícil. Pode-se afetar serviços reais, quebrar aplicativos, obter falsos positivos e reclamações. É aqui que a imitação de protocolo eleva o nível. Ela não torna o túnel invisível, mas muda a economia da detecção: distinguir tal tráfego do legítimo se torna mais difícil, mais caro e mais arriscado em termos de efeitos colaterais. Não quero que este artigo seja lido como uma promessa de "agora tudo funciona em todos os lugares". Isso não acontece. A eficácia sempre depende da rede específica. O DPI de diferentes operadoras é configurado de forma diferente. Em alguns lugares, basta esconder o handshake; em outros, o junk ajuda; em outros, uma imitação completa é necessária; e em alguns, o modo escolhido pode nem mesmo fornecer um ganho perceptível. Existem também cenários onde a imitação de protocolo não ajudará em princípio: por exemplo, redes com listas brancas, onde apenas endereços ou serviços pré-aprovados são permitidos, bem como bloqueio direto do endereço IP do servidor. Nesses casos, o tráfego pode parecer QUIC, DNS, STUN ou SIP o quanto quiser, mas isso não mudará a política de rede em si. Não existe um perfil universal que funcione igualmente bem em todas as condições. Qualquer imitação deixa um rastro comportamental. Mesmo que uma datagrama individual seja analisada lindamente como DNS, QUIC, STUN ou SIP, permanecem os timings, volumes, duração da sessão, distribuição de tamanhos de pacotes, reação a verificações repetidas. Um servidor DNS real, um serviço SIP real e um túnel VPN mascarado sob eles podem ser semelhantes no nível de um único pacote, mas não são obrigados a se comportar da mesma forma no nível de uma sessão longa. O proxy também não é gratuito em termos de recursos. É uma camada adicional no userspace: ele recebe UDP, gerencia sessões, responde a pacotes de sonda, reescreve o preenchimento e encaminha o tráfego adiante. Para um VPS doméstico ou uma pequena instalação, os custos adicionais provavelmente serão aceitáveis. Mas em velocidades próximas a um gigabit, já vale a pena observar a CPU, as chamadas de sistema e o escalonamento por núcleos. As capturas de tela do Wireshark neste artigo também devem ser interpretadas corretamente. Elas mostram que o tráfego é analisado puramente como o protocolo selecionado. Esta é uma parte importante da tarefa, mas não uma prova de indetectabilidade. O DPI real pode observar não apenas um pacote, mas também o comportamento do fluxo como um todo. E, finalmente, esta é uma tecnologia de dupla finalidade. É útil para privacidade, acesso a servidores próprios e estabilidade de conexão em redes com filtragem agressiva. Mas, como quase qualquer ferramenta de rede, ela pode ser usada de diferentes maneiras. Essa escolha permanece na consciência de quem a aplica. Em resumo, a evolução é a seguinte. Primeiro, tentaram esconder o WireGuard do DPI com ruído antes do handshake. Depois, surgiu o AmneziaWG, que começou a modificar os próprios sinais do protocolo: cabeçalhos, tamanhos e junk dentro do handshake. O AmneziaWG 2.0 deu mais espaço para inserções controladas através de S1-S4, incluindo o fluxo de dados principal. O próximo passo se apresentou naturalmente. Se já existe um espaço no pacote que pode ser controlado, ele pode ser preenchido não com bytes aleatórios, mas com a estrutura de outro protocolo. É aqui que começa o "jogo da imitação". O WireGuard na rede não deve parecer WireGuard, mas sim QUIC, DNS, STUN ou SIP comum. A imitação não se limita mais a alguns pacotes antes do handshake. A máscara escolhida é mantida também no fluxo de trabalho, e o servidor responde a pacotes de sonda como um serviço real faria. Neste esquema, o WireSock Secure Connect 3.5+ cuida do lado do cliente, e o amneziawg-proxy cobre o lado do servidor: responde a pacotes de sonda, mascara o fluxo de resposta e ajuda a construir uma imagem plausível de ambos os lados do túnel. A partida contra o DPI, é claro, não termina aqui. É apenas mais um movimento em um jogo longo. Mas, na minha opinião, um movimento lógico: da ideia de "esconder a VPN na aleatoriedade", passamos gradualmente para uma ideia mais madura, onde o túnel se torna parte da paisagem de rede esperada. O projeto descrito é um desenvolvimento independente da comunidade e não está relacionado à Amnezia, amnezia.org, ao aplicativo Amnezia VPN ou ao serviço Amnezia Free VPN. Ele utiliza o protocolo aberto AmneziaWG e ferramentas relacionadas. Os nomes "Amnezia", "AmneziaWG" e as marcas registradas associadas pertencem aos seus respectivos proprietários e são usados aqui apenas para fins de identificação.
📤 Compartilhar & Baixar
🧰 Ferramentas recomendadas
Divulgação: alguns links são patrocinados. Podemos receber comissão se você comprar — sem custo extra para você. Só indicamos o que faz sentido para a comunidade.
