
Um utilitário de CLI Linux que encaminha de forma transparente todo o tráfego do sistema através da rede Tor usando nftables. Ele permite rotação rápida de IP e alternância fácil das configurações globais de proxy para tarefas de privacidade.
Recursos • Requisitos • Instalação • Uso • Como Funciona • Verificação • Contribua
Nenhuma configuração por aplicação é necessária - basta sudo ttp start e todas as conexões passam pelo Tor.
[!CAUTION] O TTP é uma ferramenta projetada para auxiliar na privacidade roteando o tráfego através do Tor. No entanto, nenhuma ferramenta pode garantir 100% de anonimato. Sua segurança também depende do seu comportamento (por exemplo, usar um navegador comum em vez do Tor Browser, fazer login em contas, etc.). Sempre use o TTP como parte de uma estratégia de segurança em múltiplas camadas.
[!WARNING] Se você é um denunciante ou está envolvido em atividades de alto risco, NÃO use o TTP. Em vez disso, use ferramentas oficialmente auditadas e confiáveis como o TailsOS ou o Tor Browser diretamente. Os autores e contribuidores do TTP não assumem qualquer responsabilidade pela sua segurança ou pelas consequências do uso deste software.
Scripts legados de proxy transparente (TorGhost, Anonsurf) sobrescrevem arquivos de configuração e constroem conjuntos de regras iptables que falham abertos: quando quebram, o tráfego sai em texto claro. O TTP foi construído ao contrário - ele falha fechado e não mantém nada em disco.
| Falha fechada por construção | Uma tabela nftables isolada inet ttp com um reject abrangente e policy drop no encaminhamento. Em caso de travamento, acionamento do watchdog ou saída anormal, o tráfego é roteado pelo Tor ou bloqueado - nunca liberado. |
| Nada persiste | O estado da sessão, torrc, arquivo de lock e logs vivem apenas em tmpfs (/run/ttp/, /run/tor/ttp/). Um reboot não deixa resíduos nem lock obsoleto. |
| Sem configuração por aplicação | TCP e DNS são interceptados na camada de rede. Sem configurações SOCKS5, sem variáveis de ambiente de proxy, sem necessidade de suporte da aplicação. |
| DNS sem reescrever seu sistema | Uma sobreposição mount --bind em /etc/resolv.conf em vez de uma edição, além de um drop-in volátil que neutraliza o systemd-resolved, respaldado por um drop em nível de kernel em qualquer tráfego de resolver que não seja loopback. |
| A alegação de vazamento é medida | Cada regra de contenção é testada em um namespace de rede isolado contra o conjunto de regras real gerado, e cada teste primeiro prova que consegue ver um vazamento antes de afirmar que não há nenhum. Veja Verificação. |
transitions) monitora o Tor, as chains do nftables e a sobreposição de DNS via um
duplo watch inotify que detecta a troca de alvo de symlink. Ele repara uma vez,
depois aplica um killswitch de emergência.--bypass-user,
--bypass-group) com correspondência nativa de UID/GID do nftables, ou execute um único
comando fora do Tor com ttp bypass <cmd> via uma slice de cgroups v2.torrc.ttp-tor.service volátil
em portas não padrão, deixando uma instância Tor existente intacta.Escolha o método que melhor se adapta às suas necessidades. Pacotes nativos são fortemente recomendados para estabilidade do sistema, segurança e desinstalação limpa.
Instalar via pacotes nativos garante que todas as dependências do sistema (tor, nftables) e otimizações em nível de kernel (SELinux) sejam gerenciadas pelo gerenciador de pacotes do seu SO.
Baixe o .deb ou .rpm para a versão desejada a partir da última release - os pacotes são assets de release e não estão versionados no repositório - depois instale-o:
sudo apt install ./transparent-tor-proxy_0.4.9_all.debsudo dnf install ./transparent-tor-proxy-0.4.9-1.noarch.rpmcd packaging && makepkg -siPara instruções sobre como verificar a integridade e autenticidade dos assets de release, consulte o Guia de Verificação de Release.
Se você é um desenvolvedor ou deseja instalar a partir do repositório:
git clone https://github.com/onyks-os/TransparentTorProxy.git
cd TransparentTorProxy
sudo ./scripts/install.sh
[!TIP] Por que usar
./install.sh?
Diferente dos instaladores Python padrão, este script é "inteligente". Em sistemas baseados em Red Hat, ele detecta se o SELinux está em modo Enforcing e compila dinamicamente um módulo de política personalizado (a partir dettp_tor_policy.te) para permitir que o Tor se vincule às portas não padrão exigidas pelo TTP (9041, 9054). Esta otimização em nível de kernel não pode ser realizada pelopip.
Para instalar o TTP via gerenciadores de pacotes específicos do Python (pipx ou pip com ambientes virtuais), consulte a Referência de Métodos Alternativos de Instalação.
O TTP foi projetado para ser simples e leve. Para a lista completa de comandos CLI, opções, códigos de saída e especificações técnicas, consulte a Referência de Interfaces Externas.
A maioria dos comandos que modificam a rede requer privilégios de root (sudo):
Iniciar o proxy:
sudo ttp start
Parar o proxy:
sudo ttp stop
Verificar o status da sessão atual:
ttp status
Verificar o roteamento e a latência do Tor:
ttp check
Solicitar um novo IP de saída (rotacionar circuitos):
sudo ttp refresh
Para configurações mais avançadas e perfis de contorno, consulte a Referência de Perfis Avançados de Segurança e Uso ou consulte a Referência de Interfaces Externas.
Para confirmar que o túnel está funcionando corretamente e que não há vazamentos:
Verificar o IP de Saída do Tor:
curl -s https://check.torproject.org/api/ip
Verificar o Roteamento de DNS:
# Should return a valid IP via Tor's DNSPort
dig +short A check.torproject.org
Teste de Vazamento de DNS (Terminal):
# This TXT query SHOULD return an EMPTY output
dig +short TXT whoami.ipv4.akahelp.net
Nota: Uma saída vazia é o comportamento esperado sob o Tor. O resolvedor transparente do Tor não suporta registros TXT; se este comando retornar o IP do seu ISP real, você tem um vazamento de DNS.
Verificação Baseada na Web: Sempre realize testes adicionais em dnsleaktest.com e ipleak.net.
Para remover o TTP completamente do sistema:
sudo ./scripts/uninstall.sh
O TTP roteia de forma transparente todo o tráfego de rede orquestrando subsistemas padrão do kernel Linux, utilitários do sistema e as interfaces de controle do Tor:
flowchart LR
App["Application"] --> Local["Local Network"]
Local --> DNS["systemd-resolved (Intercepted)"]
DNS --> NFT["nftables (inet ttp table)"]
NFT --> Tor["Tor Daemon"]
Tor --> Internet["Internet"]inet ttp atomicamente para interceptar tráfego TCP e DNS, redirecionando-os para o Tor enquanto previne vazamentos de IPv6 e DoT/DoH./etc/resolv.conf com uma configuração volátil respaldada por RAM via um bind-mount em nível de kernel para garantir que as chamadas DNS sejam resolvidas pelo Tor.Para um passo a passo detalhado dos fluxos de execução, hooks do sistema, limites de segurança e componentes modulares, consulte o:
O TTP foi projetado para sempre restaurar sua rede, mesmo em casos extremos:
| Cenário | O que acontece |
|---|---|
ttp stop | Limpeza sem vazamentos: aplica bloqueio de desmontagem, encerra o Tor graciosamente, executa o abate ativo de sockets, aguarda 1,5s, limpa o rastreamento de conexões, restaura firewall e DNS (via flush e delete da tabela), e exclui o arquivo de lock |
Ctrl+C / kill | O manipulador de sinais captura SIGINT/SIGTERM e executa a limpeza normal antes de sair |
kill -9 / Queda de Energia | O próximo ttp start detecta o arquivo de lock órfão, limpa quaisquer pilhas de mount obsoletas e restaura automaticamente |
| Emergência manual | Execute sudo ./scripts/restore-network.sh para limpar todas as regras nftables, redefinir o DNS e excluir o arquivo de lock |
[!WARNING]
- Tor Browser: Aplicações que usam um proxy SOCKS5 explícito criarão um duplo salto Tor. Use um navegador comum em vez disso enquanto o TTP estiver ativo.
- DNS-over-HTTPS (DoH): Navegadores comuns (Firefox, Chrome, Brave, Edge) podem usar DoH, contornando o DNS do sistema. O TTP mitiga o DoH via uma defesa em 3 camadas: (1) todo o tráfego TCP de saída (incluindo DoH) é redirecionado para a TransPort do Tor; (2) domínios canário comuns de DoH são mapeados para
0.0.0.0notorrc; (3) resolvedores de IP DoH públicos são bloqueados na porta TCP/UDP 443 (bloqueando DoH HTTP/3 QUIC). Para segurança máxima, desative DoH / "DNS Seguro" nas configurações do seu navegador.- IPv6: Totalmente suportado quando disponível. O TTP detecta dinamicamente o loopback IPv6 e roteia o tráfego IPv6 através do Tor. Se o host não tiver suporte a loopback IPv6 OU se a opção
--no-ipv6for passada, o TTP descarta todo o tráfego IPv6 de saída para prevenir vazamentos.- Variação do IP de saída: Conexões diferentes podem mostrar IPs de saída diferentes devido ao isolamento de streams do Tor.
Para uma análise completa dos riscos residuais, limites de confiança arquiteturais e o modelo de ameaças STRIDE, consulte:
O TTP usa um Makefile para automatizar e padronizar o pipeline de testes. Isso garante que cada alteração seja verificada contra testes unitários e de integração antes de ser commitada.
[!IMPORTANT] Sempre execute
make verifyantes de enviar código. Se este comando falhar, o código NÃO está pronto para produção.
| Comando | Objetivo |
|---|---|
make test | Executa Testes Unitários rápidos localmente (sem necessidade de root, totalmente mockados). |
make integration-debian | Executa testes completos de sistema dentro de um contêiner Docker privilegiado (Debian). |
make integration-all | Executa testes de integração para todas as distros suportadas (Debian, Fedora, Arch). |
make verify | Executa Testes Unitários + Todos os Testes de Integração. |
make build | Gera pacotes nativos .deb e .rpm. |
make clean | Remove todos os artefatos de build, caches e arquivos temporários. |
A alegação de zero vazamentos do TTP é medida, não afirmada. O
Network Sandbox Engine constrói
um namespace de rede isolado, carrega o conjunto de regras real gerado pelo TTP nele,
gera o tráfego que um vazamento consistiria, e observa a interface veth de fronteira
com um sniffer Scapy.
Cada teste de contenção é executado duas vezes. assert no leaks também é verdadeiro quando o
sniffer nunca iniciou, quando o nome da interface está errado, ou quando o tráfego
nunca saiu do processo, então cada teste primeiro executa o mesmo estímulo com o
conjunto de regras limpo e exige que o pacote seja visto. Só então ele afirma
que o conjunto de regras do TTP o impede. Um harness que não consegue observar um vazamento falha no
teste em vez de passar.
Coberto: DNS simples (UDP e TCP), TCP comum, DoT na 853, QUIC DoH em UDP/443, ICMP, UDP arbitrário, IPv6 — além da outra direção, que um UID isento ainda pode alcançar a LAN. Um firewall que bloqueasse tudo passaria nos primeiros sete e falharia no oitavo.
# libpcap is required: the sniffer compiles a BPF filter, and Scapy dlopen()s
# the unversioned libpcap.so that only the -devel/-dev package ships.
sudo apt install nftables iproute2 conntrack libpcap0.8 libpcap-dev # Debian/Ubuntu
sudo dnf install nftables iproute2 conntrack libpcap libpcap-devel # Fedora/RHEL
pip install -e ".[nse]"
make test-nse # runs as root; TTP_REQUIRE_NSE=1 so it cannot skip itself
Isso é executado no CI a cada push (o job Zero-leak ruleset verification) e como
um passo em scripts/verify.sh antes de uma release.
Embora os testes de integração com Docker sejam rápidos e atômicos, eles não capturam 100% das nuances de kernel/systemd. Para alterações críticas, é altamente recomendado testar em uma VM QEMU real:
# Start a specific VM (e.g., arch)
./scripts/vm/start.sh arch
# Sync current code to the VM
./scripts/vm/send.sh
# Snapshot management for easy rollbacks
./scripts/vm/snapshot.sh arch save before-risky-test
Se algo der errado, execute o comando de diagnóstico:
sudo ttp diagnose
├── pyproject.toml # Package metadata and dependencies
├── README.md
├── CONTRIBUTING.md # Contribution guidelines
├── SECURITY.md # Security policy
├── scripts/ # Installation, verification, and VM management scripts
├── assets/ # Branding and demo assets
├── packaging/ # Packaging configurations (.deb, .rpm, Arch PKGBUILD)
├── ttp/ # Main Python source package
│ └── resources/ # Internal package resources (SELinux policies, etc.)
├── tests/ # Unit, integration, and leak testing suites
└── docs/ # Technical documentation, threat models, and ADRs
Contribuições são bem-vindas, e as áreas onde a ajuda mais importa são restritas e específicas:
Comece por CONTRIBUTING.md, que documenta as duas regras nas quais este código é construído: nunca corrija um bug sem adicionar a verificação que o teria detectado, e um teste que afirma uma ausência deve primeiro provar que consegue detectar uma presença.
| Bugs e solicitações de recursos | GitHub Issues |
| Vulnerabilidades de segurança | SECURITY.md - por favor, não abra uma issue pública |
| Suporte de versão e EOL | SUPPORT.md |
| Releases e pacotes | GitHub Releases · PyPI |
Este projeto é mantido em tempo livre. Uma estrela ajuda outros a encontrá-lo; patrocínio ajuda a mantê-lo funcionando.
MIT. Veja LICENSE para mais informações.