Tor sobre VPN: quem vê o seu IP e quem vê que usa Tor?

Liga o cliente VPN, espera pelo túnel e depois abre o Tor Browser para que construa um circuito. É essa sequência banal que decide quem vê o quê. Nessa ordem, o relé de entrada do Tor cumprimenta o endereço de saída da sua VPN, e o seu fornecedor de VPN cumprimenta um relé de guarda público. Faça ao contrário e ambos os observadores mudam. Vale a pena percorrer as duas ordens, porque as definições do cliente quebram em silêncio a sequência que as pessoas julgavam estar em vigor, e a verificação que o deteta é a mesma nos dois casos.

Comece pela ordem, não pelo produto

Duas disposições chamam-se «VPN com Tor», e só a primeira é comum. Com Tor sobre VPN, o túnel já está levantado quando o Tor arranca, por isso o processo tor envia a sua ligação de guarda para o túnel como qualquer outro tráfego de saída. Com VPN sobre Tor, o Tor arranca primeiro e a própria sessão VPN viaja pelo circuito, chegando ao fornecedor a partir de uma saída Tor.

O que muda entre elas é qual endereço fica na extremidade mais distante do elo mais exterior. Cada observador vê apenas o salto anterior, nunca o caminho completo: a guarda vê quem se ligou a ela, e o servidor VPN vê quem se ligou a ele. O Tor não transporta para fora o endereço local do seu túnel, e não existe nenhum campo no protocolo onde o pudesse fazer.

Nas duas ordens, o site de destino continua a ver uma saída Tor, e nenhuma ordem muda o que esse site aprende do seu início de sessão. A diferença fica limitada às duas margens.

O que vê o relé de entrada do Tor

A entrada, ou guarda, aceita uma ligação TCP comum numa porta de relé e inicia um handshake TLS com o cliente. Numa configuração Tor-sobre-VPN, a origem dessa ligação é a sua saída VPN. Numa configuração Tor-primeiro, é o endereço que a sua máquina usou para chegar à rede Tor, normalmente a sua ligação de casa.

Isso responde à metade IP da pergunta, mas só se o túnel transportou realmente a ligação. O processo Tor chega à guarda com o seu próprio socket, e esse socket não é regido pelas definições de proxy do Tor Browser. O navegador fala com o processo tor incluído através de SOCKS na porta 9150, e depois o tor abre a sua própria ligação usando a tabela de encaminhamento do kernel. Uma linha Socks5Proxy no torrc, ou um transporte de cliente, mudam esse caminho. Mais nada.

No Linux pode ler a resposta na própria máquina. Pergunte ao kernel que interface usaria para um endereço público arbitrário, e depois olhe para o endereço local da ligação estabelecida:

ip route get 203.0.113.10
sudo ss -tnp | grep -i tor

Se a rota disser dev wg0 ou dev tun0, e o endereço local na ligação estabelecida for o endereço do túnel, o Tor está dentro da VPN. Se a rota nomear a sua interface física, está fora, diga o que disser o indicador do cliente.

O que o seu fornecedor de VPN pode ver

O fornecedor termina a sua sessão VPN, por isso vê os endereços a que se liga. Os endereços dos relés de guarda são publicados no consenso público e as suas portas são bem conhecidas, por isso emparelhar um é uma pesquisa numa lista, não uma inspeção profunda de pacotes. Um fornecedor não precisa de quebrar o Tor para saber que uma sessão é Tor.

O que ele não vê é o resto do circuito. O relé intermédio e a saída são escolhidos dentro do Tor, e o fornecedor só trata do elo até à guarda. O conteúdo da página fica dentro do TLS que termina na saída, e a resolução de nomes para o tráfego Tor também acontece na saída, por isso não há nenhuma consulta DNS no fornecedor que correlacionar com um destino.

As pontes com obfs4 mudam a pesquisa, não a topologia. O endereço de uma ponte falta na lista pública de relés e o tráfego é moldado para não parecer Tor, por isso um operador que só compara endereços não o sinalizará. A sessão continua a vir do seu cliente VPN, e o fornecedor continua a ver um extremo, um volume e um horário.

A capacidade não é uma política de retenção

Um operador que pode observar uma ligação não prometeu guardá-la. O registo é uma decisão à parte, escrita numa política, limitada pela jurisdição e verificável apenas com provas em que já confia. O rótulo de sem registos não muda o papel de rede descrito acima.

A identidade da conta costuma importar mais do que o endereço de saída. Se iniciou sessão com um endereço de email, ou pagou com cartão, o fornecedor pode associar a sessão a si sem registar um único destino. Rodar os IP de saída não faz nada quanto a isso.

Verifique a cobertura antes de confiar em qualquer das duas respostas

A maioria de quem julga estar a correr Tor sobre VPN está a correr só uma parte. O encaminhamento dividido que exclui o Tor Browser, um interruptor de segurança que cobre o navegador mas não o serviço tor, uma unidade de arranque que corre antes de o túnel estar levantado e uma rota IPv6 que contorna o túnel são os quatro habituais.

Ler o ecrã de estado do cliente não testa nenhum deles. O teste que o faz: deixe o Tor Browser a correr, baixe o túnel e observe se a ligação de guarda sobrevive na interface física.

A ordem em que verifico, parando na primeira falha:

• ip route get 203.0.113.10 devolve o dispositivo do túnel.
• ss -tnp | grep -i tor mostra a ligação de guarda com um endereço local do túnel.
• ip -6 route não tem rota predefinida fora do túnel, ou o IPv6 está desligado no cliente.
• Baixar a VPN termina ou redireciona a ligação tor em vez de a deixar no elo físico.

Que ordem serve o que defende

As duas ordens escondem algo e expõem algo, por isso a resposta é uma escolha sobre o observador que lhe importa.

Leia por colunas até uma linha corresponder ao que tenta impedir. Se a preocupação é uma rede local ou um fornecedor de acesso que registe ou bloqueie o Tor, o Tor sobre VPN trata disso. Se a preocupação é que o operador da VPN saiba o seu endereço de casa, o VPN sobre Tor trata disso, e paga-o expondo o uso do Tor à sua própria rede e o endereço de casa à guarda.

Nenhuma das disposições deixa as duas margens cegas. Acrescentar um observador não elimina outro. A nota do Tor Project sobre executar uma VPN com Tor diz o mesmo do outro lado: o túnel muda em quem se confia e que caminhos de falha existem, por isso não é uma melhoria a acrescentar sem decidir o que queria esconder.

Decida primeiro o observador, escolha depois a ordem, e verifique com ip route get e ss em vez do indicador do cliente. Se o observador for alguém que pode obrigar o próprio fornecedor de VPN, nenhuma escolha de ordem resolve isso.