O operador da VPN vê quais sites você visita?

Pergunte o que a VPN pode ver e a resposta depende de onde você está no caminho. Na camada de sessão o operador tem eventos de autenticação e contagens de bytes. Na camada de pacotes tem endereços de destino e horários. Na camada de DNS pode ter os próprios nomes. Cada camada responde a uma pergunta diferente, e nenhum interruptor o move entre elas.

Defina a camada antes de fazer uma afirmação

A mesma conexão produz registros diferentes em cada ponto, e uma declaração sobre privacidade só faz sentido quando nomeia o ponto. Leia a tabela coluna por coluna: o que existe naquela camada, o que um operador pode ver ali e o que esses mesmos registros ainda não podem dizer.

Ler uma camada como o quadro completo é o começo tanto de afirmações exageradas quanto de falsa tranquilidade. Um provedor que diz não registrar a navegação pode estar correto sobre o registro de URLs e ainda assim guardar registros de sessão, e uma captura de pacotes que mostra apenas endereços não vira histórico de navegação sem buscas reversas e suposições.

Ao avaliar uma política, encontre a frase que descreve cada camada. Se a política não as separa, pergunte quais registros existem em vez de aceitar uma declaração genérica sobre criptografia.

Inventário de sessões: o que um servidor OpenVPN comum guarda

Por padrão, um servidor OpenVPN não captura o tráfego. A saída normal é um inventário de sessões: a conta que se autenticou, o endereço de origem de onde veio, carimbos de tempo de início e fim, o endereço de túnel atribuído e os totais de bytes em cada direção. Isso é um inventário de sessões, não uma lista de destinos.

Opções de registro podem acrescentar detalhes. Um nível de verbosidade mais alto escreve mais sobre o handshake, e um arquivo de status pode listar clientes conectados, mas nenhum dos dois transforma o servidor em proxy transparente. Produzir URLs exige terminar TLS ou rodar um proxy explícito, e ambos mudam o arranjo de confiança em vez de habilitar um recurso oculto.

Por isso a versão precisa da afirmação de que não há log de navegação é mais estreita do que soa. O servidor não conhece a página, mas sabe que uma sessão existiu e aproximadamente quanto dado passou por ela. Se esse registro de sessão é mantido, e por quanto tempo, é uma questão de política separada.

Pacotes internos e externos são evidências diferentes

A captura de pacotes é como se vê o que realmente atravessa o túnel. No servidor, nomeie a interface do túnel e escreva em um arquivo que possa ser analisado offline:

sudo tcpdump -ni tun0 -w /tmp/tun.pcap
sudo tcpdump -r /tmp/tun.pcap -nn | head

Esse arquivo contém o tráfego interno decifrado: o endereço de túnel do cliente como origem, o endereço de destino e a porta, os tamanhos dos pacotes e o horário. Ele não contém o caminho HTTP nem o corpo da resposta, a menos que TLS tenha sido terminado em algum lugar, e são dados sensíveis cuja retenção é uma decisão de política e não uma conveniência de depuração.

Uma captura na interface física mostra outra coisa. Ali você vê pacotes externos endereçados ao endpoint da VPN, com o payload cifrado dentro. Endereços não relacionados que aparecem nesse arquivo são normais quando existe um adaptador virtual, porque o dispositivo de túnel carrega os fluxos internos enquanto o transporte cifrado carrega os externos.

Pergunte a qual pergunta a captura deve responder. O uso do túnel por um aplicativo é visível no adaptador virtual; a alcançabilidade do túnel até o endpoint é visível no físico. Usar qualquer um dos arquivos como quadro completo produz conclusões que os dados não sustentam.

O DNS é o lugar onde os nomes se tornam visíveis

O DNS continua sendo a exceção prática. O resolvedor vê os nomes que lhe pedem para resolver, então quem o opera descobre quais sites um cliente procura mesmo quando as conexões seguintes são cifradas. A captura do túnel mostra endereços; o resolvedor mostra nomes.

Verifique qual endereço o resolvedor usou para alcançar um serviço externo. A resposta é o endereço de saída do resolvedor, e compará-lo com a saída da VPN diz se a consulta passou pelo túnel:

dig +short myip.opendns.com @resolver1.opendns.com
dig example.com
sudo tcpdump -ni any udp port 53

Se esse endereço corresponde à conexão local e não à saída do túnel, a consulta contornou a VPN e o nome era visível no caminho local. Repita a verificação após uma atualização do cliente, porque uma versão nova pode mudar qual resolvedor o perfil instala.

O DNS cifrado desloca a visibilidade em vez de removê-la. A rede não vê mais a consulta, mas o resolvedor ainda vê, e a questão da confiança apenas muda de mãos. O nome do servidor TLS no handshake da conexão é outro sinal parcial: muitas vezes sobrevive mesmo quando o payload é opaco, então os endereços de destino não são os únicos metadados que um servidor de encaminhamento pode observar.

Três tipos de registro e quem pode lê-los

A contabilização de sessões, os registros por nome e as evidências de vazamento são três produtos diferentes com três obrigações diferentes. Os logs de sessão são baratos e de baixa sensibilidade, e respondem quem se conectou e quando. Registros por nome exigem um resolvedor que registre ou um proxy explícito, e criam uma obrigação de divulgação com as pessoas afetadas. A evidência de vazamento é um teste do lado do cliente que compara o que o resolvedor revela com a saída do túnel.

Anote qual dos três você opera, quem pode lê-lo e por quanto tempo ele permanece. Afirmações de que um serviço não mantém logs descrevem uma camada, e só permanecem verdadeiras nesse escopo. O mesmo provedor pode ser preciso sobre sessões e errado sobre DNS.

Mantenha o teste reproduzível: a mesma consulta ao resolvedor, a mesma interface de captura e a mesma comparação. Uma afirmação de privacidade que não pode ser testada em uma camada nomeada é um slogan, não um fato operacional.