Architectural feedback: Resilience and leak prevention in a systemd-native Tor proxy (TTP)

Support
1

Hi,

I am developing an open-source Linux CLI tool called TransparentTorProxy (TTP). It provides system-wide transparent Tor routing on standard Linux distributions by orchestrating nftables, systemd, and DNS bind-mount overlays.

I’ve been inspired by Orbot (Android app), Whonix and Tails, and I’m interested in exploring how to harden Tor routing on a single-host environment, even though I’m aware it can never be as safe as Whonix/Tails due to the whole environment TTP is used in. Anyway, I have focused on fail-closed integrity and zero-leak teardown, but I would value your opinion on the architecture.

Current approach:

  • Volatile State: All runtime metadata and DNS configurations are stored in tmpfs to avoid forensic traces on physical storage.

  • Leak Mitigation: I use a bind-mount overlay on /etc/resolv.conf and inject volatile drop-ins for systemd-resolved to force DNS queries to Tor’s DNSPort. Outbound DoT and well-known DoH IPs are blocked via nftables.

  • Fail-Closed Watchdog: A background service (which is optional) monitors integrity. If firewall rules or DNS mounts are tampered with, it triggers an emergency network lockout.

  • Zero-Leak Teardown: During shutdown, the tool flushes the conntrack table and injects TCP resets to actively terminate pending local connections before lowering the firewall, preventing cleartext leaks during the teardown window.

My specific questions:

  • DNS Hijacking: Given your experience, is the use of a volatile bind-mount on /etc/resolv.conf combined with systemd-resolved drop-ins sufficiently robust against modern Linux applications that might bypass standard resolvers via D-Bus or NSS?
  • Teardown risks: Is the TCP reset + conntrack flush considered a reliable method to ensure no cleartext traffic survives a proxy shutdown, or are there low-level scenarios where a race condition could still allow a packet to pass?

Please, give me your honest technical feedback. The repository is available on Github at GitHub - onyks-os/TransparentTorProxy: A Linux CLI utility that transparently routes all system traffic through the Tor network using nftables. It enables rapid IP rotation and easy toggling of global proxy settings for privacy tasks. · GitHub.

Thank you for your time.

Best regards,

onyks

2

Couldnt understand the post how its gonna benefits Whonix development. You want just support for your tool or do you have any participation in whonix development? If only support, shift this topic to the support section.

3

This sounds like it has some overlap with TorVPN / onionmasq.

4

(You can post links now or edit your post.)

I don’t think such functionality should be mixed in the same source code repositoy. It violates unix philosophy.

Unnecessary.

Simple firewall rules:

  • Only 1 Linux user account debian-tor is allowed to use the internet.
  • All other Linux user accounts are not allowed to use the internet. Instead, their traffic is directed / redirected to a Tor SocksPort or TransPort.

No need to lower the firewall. A healthy shutdown process should terminate applications, networking, reboot.