O Tor passa pela VPN? O que o túnel dividido muda
Um ícone de VPN conectada e um processo Tor em execução não provam que a conexão de entrada do Tor usou o túnel. Verifique a regra de divisão e depois o caminho de falha.
Eis a crença que vale a pena testar: um selo conectado significa que o tráfego do Tor passou primeiro pela VPN. A inferência falha mais vezes do que deveria, e falha em silêncio. Um emparelhador de túnel dividido pode deixar o processo Tor fora do túnel enquanto o dispositivo permanece conectado, e as duas observações são verdadeiras ao mesmo tempo. O ícone informa de uma interface; o caminho que os seus pacotes seguiram é uma pergunta separada. Responda a partir do encaminhamento e do emparelhador, não do selo.
O que um selo conectado prova, e o que não prova
Uma VPN conectada significa que uma interface está ativa e que existe um túnel até ao par. A conexão de entrada do Tor é outro fluxo, criado por outro processo, e se entra nesse túnel depende do emparelhador e da tabela de encaminhamento que lhe são aplicados. Exclua o processo e a VPN liga-se na mesma, o Tor constrói na mesma um circuito, e a ordem que pretendia não aconteceu. As duas observações respondem a perguntas diferentes, por isso nenhuma delas sozinha decide a ordem.
Essa lacuna não é um defeito de nenhuma das ferramentas. É exatamente para isso que serve uma regra de exclusão, e a regra foi provavelmente escrita por um motivo que alguém ainda recorda.
Que emparelhador o cliente aplica a uma conexão
O que decide o caminho é o emparelhador que o cliente aplica a cada conexão: um nome de processo, um prefixo de destino ou uma entrada de rota, conforme o cliente. Um atalho no ambiente de trabalho não corresponde a nenhum deles, porque é um lançador, não uma unidade de política. Leia o conjunto de regras do cliente e nomeie a unidade que ele realmente testa antes de raciocinar sobre o Tor. Se o cliente emparelha por destino, a pergunta passa a ser que prefixos ficam dentro do túnel e não que programa está a correr.
Uma regra baseada no destino que só leva prefixos de escritório privado é uma forma comum, e deixa as conexões de entrada ordinárias do Tor diretas por design. Essa é a política a funcionar como está configurada, e não é a ordem VPN-antes-de-Tor, por muito saudável que o selo pareça. Escreva o emparelhador e os prefixos excluídos na mesma linha das suas notas, porque esse par é a regra.
O que acontece ao Tor quando o túnel cai
Agora retire o túnel e observe o que o Tor faz, porque uma política que só se mantém enquanto a rede está saudável não é a política que descreveu. O cliente pode recusar o tráfego direto enquanto está em baixo, permiti-lo em silêncio, ou voltar a ligar-se e reaplicar a regra um momento depois. Uma desconexão manual e uma falha são eventos diferentes, e a falha é a que ninguém ensaiou. Teste com tráfego inofensivo e registe qual dos três resultados observou realmente.
Leia também o comportamento documentado do cliente, mas trate a documentação como uma hipótese até o seu teste concordar com ela. Os fornecedores descrevem o padrão; o seu perfil decide a exceção.
Porque o endereço de saída não pode responder à pergunta de entrada
Um site alcançado através do Tor comunica o endereço do relé de saída, o que lhe diz de onde o circuito emergiu e nada sobre como o primeiro salto deixou o seu dispositivo. As pessoas citam esse endereço como prova da ordem VPN-primeiro, e ele não pode suportar esse peso. A pergunta de entrada é local: que interface levou a conexão até ao primeiro relé e que endereço de origem o par da VPN teria visto. Responda com uma consulta de rota ou uma captura de pacotes no dispositivo, não com um site.
Dois caminhos diferentes podem produzir o mesmo país de saída, por isso um resultado coincidente prova ainda menos do que parece. Compare interfaces, não geografia.
Aplicações que nunca herdaram as definições do navegador
Um visualizador de documentos, um cliente de sincronização e um gestor de pacotes fazem cada um as suas próprias conexões, e nenhum herda as definições de proxy do navegador. Cada um segue o emparelhador do cliente, a sua própria configuração ou o proxy do sistema, e a combinação raramente é escrita. É assim que uma lista de exceções cresce: uma aplicação de cada vez, cada adição razoável, até ninguém poder dizer o que a lista cobre. Em vez disso, mantenha um diagrama curto por aplicação, nomeando o emparelhador, a rota e o comportamento em caso de falha.
Se a camada extra de VPN não serve nenhum propósito que possa enunciar, remover a camada é mais fácil de verificar do que manter uma longa lista de exceções. Entretanto, a nota do Projeto Tor sobre VPN aborda a mesma questão de ordem pelo outro lado. Menos peças móveis significa menos suposições a testar de novo após a próxima atualização do cliente.