Como uma VPN funciona?

Como uma VPN funciona? Seu dispositivo constrói um túnel criptografado para um servidor que você escolhe, manda todo pacote por ele, e esse servidor encaminha seu tráfego ao destino real usando seu próprio IP. Pra qualquer um observando a rede entre você e o servidor VPN, tudo que veem é ruído criptografado indo pra um endereço. Pra qualquer um observando além do servidor VPN, seu tráfego parece ter vindo do servidor, não de você.

Essa é a versão de 30 segundos. O resto deste post desempacota cada passo com o detalhe real de protocolo, porque "túnel criptografado" é uma frase que esconde muita maquinaria interessante. Vamos cobrir o que realmente acontece durante um handshake de VPN, o que encapsulamento significa no nível de pacote, por que DNS tem que ir pelo túnel separadamente, como mascaramento de IP funciona (não é mágica, é NAT), e como os três protocolos principais diferem em sua tubulação.

Escrito pra pessoas que querem entender o sistema sem um diploma de redes.

A versão de 30 segundos

Você instala um cliente VPN e clica conectar. Por trás dos panos:

Cliente e servidor fazem um handshake. Provam quem são um pro outro e concordam em chaves de criptografia compartilhadas. Uma ou duas idas e vindas.
Seu SO roteia tráfego pra dentro do túnel. O cliente diz ao SO "manda tudo por esse adaptador de rede virtual". O túnel agora é a rota padrão.
Cada pacote é criptografado, embrulhado e mandado. O pacote original (destinado, digamos, à Wikipedia) é criptografado e colocado dentro de um novo pacote externo endereçado ao servidor VPN. Da perspectiva da rede, você só está falando com o servidor VPN.
O servidor desempacota e encaminha. Descriptografa o pacote interno, vê Wikipedia como destino, e manda adiante com seu próprio IP como origem. Wikipedia responde pro servidor, que reverte o processo.
DNS vai pelo mesmo túnel. Procurar wikipedia.org corre pelo túnel criptografado e resolve no servidor DNS do provedor de VPN, não no do seu provedor.

Esse é o pipeline inteiro. O resto é variação em como cada passo é implementado.

Passo 1: o handshake e a troca de chaves

Criptografia só funciona se ambos os lados concordarem numa chave. O handshake estabelece essa chave numa rede onde cada byte está potencialmente sendo observado.

Protocolos VPN modernos usam Diffie-Hellman ou sua variante de curva elíptica X25519 pra isso. Duas partes geram cada uma um par de chaves pública-privada, trocam as metades públicas, e independentemente computam o mesmo segredo compartilhado sem esse segredo nunca atravessar o fio. Um espião que captura cada byte não consegue derivá-lo.

Cada protocolo implementa isso diferente:

WireGuard. Uma ida e volta. Seu cliente manda uma iniciação Noise-protocol contendo sua chave pública efêmera e sua identidade (criptografada com a chave pública estática do servidor). O servidor responde com sua chave pública efêmera. Ambos os lados derivam chaves de sessão simétricas via HKDF e começam a mandar dados. Tempo de handshake numa rede saudável: 100ms ou menos.

OpenVPN. Um handshake TLS 1.2 ou TLS 1.3 completo, o mesmo vai-e-vem que um navegador faz ao conectar a um site HTTPS. ClientHello, ServerHello, troca de certificado, troca de chave, finished. Mais idas e voltas, mais bytes, mais CPU. Tempo de handshake: 500ms a mais de um segundo em redes mais lentas.

VLESS Reality. Um handshake TLS 1.3 pra um site público real legítimo (o alvo SNI). O protocolo Reality vincula criptograficamente a conexão ao certificado TLS daquele alvo enquanto roteia tráfego pra um servidor VPN diferente. Pra um observador de rede, o handshake é indistinguível de alguém visitando o alvo SNI. Autenticação VPN acontece dentro da sessão TLS via identidade UUID.

Depois do handshake, cada lado tem chaves de sessão simétricas. Criptografia simétrica é rápida; assimétrica (chave pública) é lenta. O handshake configura a sessão simétrica barata eficientemente. HTTPS usa o mesmo padrão pela mesma razão.

Passo 2: encapsulamento, não tunelamento físico

A palavra "túnel" faz pessoas imaginarem alguma separação física, uma estrada privada paralela à internet pública. A realidade é mais interessante. Um túnel VPN é só encapsulamento: colocar um pacote dentro de outro pacote.

Imagine um pacote IP regular indo pra Wikipedia. Tem um cabeçalho (origem: seu dispositivo, destino: IP da Wikipedia) e um payload (sua requisição HTTP). Quando o túnel está ativo, seu cliente pega o pacote inteiro, criptografa, e enfia dentro de um novo pacote externo endereçado ao servidor VPN. O pacote original agora está escondido dentro do novo envelope.

Roteadores entre você e o servidor VPN só veem o envelope externo. Roteiam baseado no cabeçalho externo, que diz "manda isso pro servidor VPN". Uma vez que chega, o servidor descriptografa o payload, encontra o pacote original dentro, e encaminha adiante.

Esse truque (um pacote IP envolvendo outro) é o mecanismo por trás de todo protocolo de "tunelamento" na internet. GRE, IPsec, WireGuard, OpenVPN: variações do mesmo tema. O encapsulamento acontece no adaptador de rede virtual que o cliente VPN instala (Wintun no Windows, TUN no Linux, utun no macOS). Seu SO vê uma interface de rede regular; o cliente VPN intercepta cada pacote roteado pra lá, criptografa, e manda o resultado pela rede real.

Passo 3: criptografia em trânsito

Uma vez que o handshake produz chaves de sessão, o protocolo as usa pra criptografar cada pacote de tráfego. As escolhas de cipher importam pra segurança e performance.

ChaCha20-Poly1305. Stream cipher com autenticação embutida. Rápido em dispositivos sem aceleração AES por hardware (celulares antigos, roteadores low-end). WireGuard usa exclusivamente. OpenVPN suporta. ChaCha20 é o padrão moderno pra protocolos projetados na última década.

AES-256-GCM. A contraparte block-cipher. Instruções de hardware AES-NI em todo CPU Intel e AMD desde 2010 fazem dessa a opção mais rápida em hardware desktop. Padrão moderno do OpenVPN. WireGuard não usa (os autores do WireGuard escolheram deliberadamente ChaCha20 pra evitar a dependência AES-NI pra uso embarcado).

AES-128-GCM. Mesma família, chave menor. Marginalmente mais rápido, marginalmente menos paranoico. Protocolos modernos usam 256 por padrão.

As partes "GCM" e "Poly1305" são importantes: são tags de autenticação. Criptografia sozinha te diz que um atacante não pode ler seu tráfego; autenticação te diz que um atacante não pode modificá-lo sem detecção. Uma VPN que criptografa mas não autentica está quebrada. Todo protocolo moderno usa criptografia autenticada (AEAD).

Cada pacote é criptografado independentemente com um contador que previne ataques de replay. Se um atacante captura um pacote e re-manda depois, a checagem de contador falha e o receptor descarta.

Passo 4: resolução DNS pelo túnel

DNS é o sistema que transforma wikipedia.org em endereço IP. Por padrão, seu SO manda queries DNS pra qualquer resolver entregue por DHCP, que geralmente é o do seu provedor. Isso acontece antes de qualquer tráfego web.

Sem tratamento de DNS, uma VPN vaza feio. Você conecta o túnel, seu navegador pede ao SO pra procurar bank.com, o SO manda a busca pro servidor DNS do seu provedor (fora do túnel), e seu provedor recebe uma lista de todo domínio que você visita apesar do túnel criptografado fazer seu trabalho pro tráfego real.

Um cliente VPN corretamente implementado roteia DNS pelo túnel. Vários mecanismos:

Substituir o resolver DNS do sistema. O cliente configura o servidor DNS na configuração de rede do SO pro resolver do provedor de VPN, que só é alcançável pelo túnel. Abordagem padrão.

Bloquear vazamentos DNS via regras de firewall. No Windows, o cliente VPN usa filtros do Windows Filtering Platform (WFP) pra bloquear queries DNS em qualquer interface além do túnel. Cinto-e-suspensórios: mesmo se algo tenta mandar uma query DNS pela interface errada, o firewall derruba.

Desabilitar smart-multi-homed name resolution. Windows por padrão manda queries DNS pra múltiplas interfaces de rede em paralelo e usa qualquer uma que responder primeiro. Esse recurso do Windows, chamado SMHNR, vaza queries DNS pro resolver original do provedor toda vez que você faz uma, mesmo com VPN ativa. Um cliente VPN correto desabilita SMHNR via NRPT (Name Resolution Policy Table) ou entradas de registro.

Bloquear IPv6 se o túnel é apenas IPv4. Se sua rede suporta IPv6 e a VPN não tunela IPv6, queries DNS IPv6 pulam o túnel inteiramente. Ou tunela IPv6 ou bloqueia totalmente.

O tratamento de DNS é onde muitas VPNs falham de jeitos sutis. Uma VPN que criptografa tráfego mas vaza DNS entrega ao seu provedor os mesmos metadados que teriam sem a VPN. Temos um post mais profundo sobre vazamentos DNS se quiser a versão grosseira.

Passo 5: mascaramento de IP via NAT

Quando o servidor VPN encaminha o pacote interno pra Wikipedia, tem que fazer uma escolha: como Wikipedia sabe pra onde mandar a resposta?

A resposta é Network Address Translation (NAT). O servidor VPN reescreve o IP de origem do pacote saindo do seu IP do lado do túnel pra seu próprio IP público, e registra o mapeamento numa tabela NAT. Quando Wikipedia responde, o servidor consulta o mapeamento, reescreve o destino de volta pro seu IP do túnel, criptografa o pacote, e manda de volta pelo túnel. Mesmo NAT que seu roteador doméstico usa, só que em escala.

Da perspectiva da Wikipedia, a origem da sua requisição é o IP público do servidor VPN. Wikipedia não consegue derivar seu IP doméstico daquela conexão. Eles podem derivar que você está usando uma VPN se cruzarem o IP contra listas conhecidas de saída de VPN (a maioria dos sites grandes faz pra detecção de fraude), mas não podem te identificar especificamente.

Isso também explica por que "IPs compartilhados" são um plus de privacidade e um menos de usabilidade. Se centenas de pessoas estão saindo pelo mesmo IP, tráfego pra um dado site não pode ser atribuído a nenhuma delas. O lado ruim: IPs compartilhados são mais propensos a serem sinalizados ou rate-limitados por sites que desconfiam deles (alguns bancos, alguns captchas, alguns serviços de streaming).

Passo 6: o truque de roteamento do SO

Como o cliente VPN convence seu SO a mandar tráfego pra dentro do túnel? Não interceptando sockets individuais. A abordagem padrão é instalar um adaptador de rede virtual e modificar a tabela de roteamento pra que esse adaptador vire a rota padrão.

O cliente adiciona:

Uma nova rota padrão pelo adaptador virtual (frequentemente como rotas split 0.0.0.0/1 e 128.0.0.0/1 pra sobrepor o padrão existente sem removê-lo).
Uma rota específica pro IP do servidor VPN pelo adaptador físico original, pra que os pacotes externos criptografados possam de fato deixar seu dispositivo.
Servidor DNS configurado pro resolver do lado do túnel.

Cada pacote de saída (exceto os endereçados ao servidor VPN) agora roteia pro adaptador virtual. O cliente VPN os pega, criptografa, encapsula, e manda o resultado pelo adaptador físico. O recurso de kill switch vive nessa mesma camada: se o túnel cai, o cliente ou mantém as rotas apontando pra um gateway inexistente (tráfego entra em blackhole) ou instala regras de firewall que bloqueiam tráfego até o túnel reconectar.

Como protocolos diferem na tubulação

Cobrimos o esqueleto comum. Cada protocolo preenche os detalhes diferente.

WireGuard. Apenas UDP. Handshake de tamanho fixo (148 bytes iniciação, 92 bytes resposta). Apenas ChaCha20-Poly1305. Roaming entre redes graciosamente porque estado de sessão é chaveado pelas identidades estáticas, não pelo par IP/porta. Implementações em userspace existem (boringtun, a que o Fexyn usa) mas implementações kernel também estão disponíveis. Tempo de conexão é o mais baixo dos três: abaixo de um segundo, frequentemente abaixo de 500ms warm.

OpenVPN. UDP ou TCP. Canal de controle baseado em TLS, canal de dados separado. Cipher configurável (moderno: AES-256-GCM ou ChaCha20-Poly1305). Apenas userspace, codebase maior, mais botões de configuração. Handshake mais lento, overhead por pacote maior. O veterano de compatibilidade: funciona em redes onde WireGuard não funciona, especialmente em modo TCP onde a conexão parece um stream TCP criptografado genérico.

VLESS Reality. Apenas TCP. O ponto inteiro é parecer HTTPS comum pra um observador de rede. O handshake é um handshake TLS 1.3 real pra um site público legítimo real (configurado como o alvo SNI tanto no cliente quanto no servidor). Dentro daquela sessão TLS, o protocolo VLESS carrega identidade (um UUID) e tráfego. O Vision flow (xtls-rprx-vision) que usamos adiciona um framing interno de baixo overhead pro tráfego VPN. Mais lento que WireGuard pra throughput bruto mas sobrevive em ambientes onde WireGuard e OpenVPN são bloqueados completamente.

Um cliente moderno escolhe por rede. Redes rápidas e abertas: WireGuard. Redes que bloqueiam WireGuard mas permitem TLS genérico: VLESS Reality. Redes que bloqueiam ambos mas permitem tráfego com formato OpenVPN: OpenVPN como o último fallback. O motor de rotação do Fexyn faz isso automaticamente.

O que seu provedor vê, com VPN ligada vs desligada

VPN desligada. Seu provedor vê o IP de cada servidor que você conecta, os domínios que você procura via DNS, e quanto dado flui quando. Não conseguem ler conteúdo HTTPS mas podem ler SNI (o domínio nos handshakes TLS), o que dá a eles a mesma visibilidade de domínio por outro ângulo.

VPN ligada, cliente bem implementado. Seu provedor vê um IP (o servidor VPN), bytes criptografados fluindo pra ele, e padrões de timing. Queries DNS vão pelo túnel, então o provedor não pode lê-las. SNI não é mais visível pro seu tráfego real, porque o único handshake TLS que o provedor vê é pro servidor VPN (ou pro alvo SNI com Reality, que geralmente é um site popular que não revela nada sobre seu destino). Seu provedor geralmente pode identificar que você está usando uma VPN, mas não quais sites visita por ela.

A mudança de confiança é visível nessa lista. Seu provedor perde tudo que tinha. O provedor de VPN ganha. Política de logging e confiança no provedor importam mais que qualquer recurso técnico único.

Overhead de performance

Uma VPN adiciona dois custos: trabalho de criptografia no seu CPU, e um hop extra no caminho do seu tráfego.

CPU. AES e ChaCha20 modernos se movem em múltiplos gigabits por segundo num único core. Pra internet doméstica típica (abaixo de 1 Gbps), o overhead de CPU é invisível.

Latência. Adicionar um hop adiciona latência proporcional à distância geográfica entre você, o servidor VPN, e o destino. Uma saída próxima adiciona 5-20ms; um hop transcontinental adiciona 100ms ou mais. Navegação e streaming absorvem isso bem; jogos competitivos não.

Throughput. WireGuard adiciona cerca de 60 bytes por pacote (cabeçalhos IP/UDP externos mais tag de autenticação), aproximadamente 4% de overhead de framing num MTU 1500 bytes. O overhead do OpenVPN é mais perto de 10%. O hit real de throughput geralmente é maior que a matemática por pacote porque o servidor VPN pode ser um gargalo se subdimensionado pra contagem de usuários. Em nossos próprios testes, WireGuard custa 5-10% da banda total numa conexão saudável; OpenVPN custa 15-25%. VLESS Reality fica entre eles com mais variância por causa do framing TLS.

A linha de fundo

Uma VPN funciona criptografando e encapsulando seu tráfego, mandando por um servidor escolhido, e encaminhando adiante com NAT. O handshake estabelece chaves de sessão. O encapsulamento faz roteadores verem só o pacote externo. DNS, kill switch, e mudanças na tabela de roteamento pegam os casos de borda que de outro jeito vazariam sua identidade real de rede.

O mecanismo é bem entendido e não é mágico. O benefício de privacidade depende de qual parte você está roteando, e o que fazem com o que veem. Escolha um protocolo combinando com suas condições de rede, um provedor combinando com seus requisitos de confiança, e um cliente que lida com os vetores de vazamento (DNS, IPv6, SMHNR, kill switch) corretamente.

FAQ

Pacotes IP criptografados e encapsulados. Seu pacote original (com sua origem e destino reais) é criptografado e colocado dentro de um novo pacote externo endereçado ao servidor VPN. Pra qualquer um observando a rede, o pacote externo é tudo que veem.

O passo de handshake usa criptografia de chave pública (X25519 no WireGuard, RSA ou ECDHE em TLS pra OpenVPN e Reality) pra estabelecer chaves de sessão simétricas sem essas chaves nunca atravessarem o fio. Uma vez que ambos os lados têm as chaves de sessão, cada pacote é criptografado com um cipher simétrico rápido (ChaCha20-Poly1305 ou AES-256-GCM) que inclui autenticação embutida.

Buscas DNS acontecem antes de tráfego web e podem vazar independentemente do túnel. Por padrão, seu SO manda DNS pra qualquer resolver entregue por DHCP, que geralmente é seu provedor. Um cliente VPN tem que ativamente redirecionar DNS pra dentro do túnel e bloquear quaisquer caminhos de vazamento (Windows SMHNR, fallback IPv6, DoH do navegador contornando DNS do SO).

TUN é uma interface virtual de camada-3 (IP); TAP é uma interface virtual de camada-2 (Ethernet). VPNs quase sempre usam TUN porque só precisam transportar pacotes IP. TAP é pra casos de uso que precisam de emulação Ethernet, como ponte de redes locais.

Sim, frequentemente. Pacotes WireGuard têm formato reconhecível; OpenVPN sobre UDP tem cabeçalho distintivo. Mesmo tráfego criptografado tem padrões de tamanho e timing que ferramentas de fingerprinting podem usar. VLESS Reality é o mais resistente porque imita TLS real pra um site real popular. "Criptografado" e "indetectável" são problemas diferentes.

Sem kill switch, seu SO volta pra rota padrão original e tráfego flui em texto plano do seu IP real. Com kill switch, o cliente ou mantém a tabela de roteamento apontada pro gateway do túnel (agora inexistente) (tráfego entra em blackhole) ou instala regras de firewall que bloqueiam todo tráfego até o túnel reconectar.

Sim, contra o operador da rede. O ponto de acesso Wi-Fi vê um túnel criptografado pro servidor VPN. Não conseguem ler seu tráfego, ver quais sites você visita, ou injetar conteúdo. HTTPS já protege muito disso; uma VPN adiciona defesa em profundidade e protege metadados como SNI.

Handshake menor (uma ida e volta vs várias), overhead por pacote menor, codebase mais simples mais fácil de otimizar, e um design deliberado de cipher único que evita overhead de negociação. WireGuard foi projetado em 2015 com as lições de protocolos mais velhos em mente.

Na rede: não. Veem bytes criptografados pro seu servidor VPN, mesma coisa que seu provedor veria. No dispositivo: talvez. Se seu dispositivo de trabalho tem software corporativo de gerenciamento (MDM, EDR), esse software pode ler tráfego no nível do SO antes de entrar na VPN. Privacidade no nível de rede é real; privacidade no nível de dispositivo depende do dispositivo.