proxychains-masq 0.1.0

TUN-based proxy chain engine — routes TCP flows through SOCKS4/5, HTTP CONNECT, and HTTPS CONNECT proxy chains via a userspace network stack.
Documentation
# proxychains-tun

Routes all TCP traffic from an arbitrary program through a configurable chain of
SOCKS/HTTP proxies — without `LD_PRELOAD`.

## Background

proxychains-tun merges two existing tools:

- **[proxychains-ng]https://github.com/haad/proxychains** — the de-facto standard
  for routing application traffic through SOCKS/HTTP proxy chains. proxychains-ng works
  by injecting a shared library via `LD_PRELOAD` that intercepts libc network calls.

- **[oniux]https://gitlab.torproject.org/tpo/core/oniux** — a Tor isolation tool that
  places the target program in a dedicated Linux network namespace containing only a TUN
  device, routing all traffic through Tor. No `LD_PRELOAD` required.

proxychains-tun keeps proxychains-ng's configuration format and chain engine (strict,
dynamic, random, round-robin; SOCKS4/5, HTTP CONNECT, HTTPS CONNECT, raw), and replaces
the `LD_PRELOAD` transport layer with oniux's namespace isolation approach.

## How it works

1. **Namespace isolation** — the target program is cloned into a fresh Linux network
   namespace (`CLONE_NEWNET`), a new mount namespace (`CLONE_NEWNS`), and an
   unprivileged user namespace (`CLONE_NEWUSER`) via `clone(2)`. Inside that namespace
   the only network interface is a TUN device; there is no route to the host network.

2. **TUN device** — the parent process owns the TUN file descriptor and runs a userspace
   TCP/IP stack ([smoltcp]https://github.com/smoltcp-rs/smoltcp) against it. Every TCP
   connection the isolated program opens arrives as raw IP packets at the parent.

3. **Proxy chain engine** — for each incoming TCP flow the parent selects proxies
   according to the configured chain mode and dials the target through them using the
   appropriate SOCKS4/SOCKS5/HTTP CONNECT/HTTPS CONNECT/raw handshake sequence.

4. **DNS interception** — the child's `/etc/resolv.conf` is bind-mounted to point at a
   synthetic nameserver IP (`169.254.42.53`). DNS queries are intercepted in the TUN poll
   loop; each queried hostname is assigned a fake IP from the configured
   `remote_dns_subnet` range, which is mapped back to the original hostname when the
   program later connects to that IP.

Because isolation happens at the network-namespace level, **every** TCP connection the
program makes is forced through the proxy chain — including connections from statically
linked binaries, interpreted scripts, and programs that issue raw `connect(2)` syscalls
directly.

## Comparison with proxychains-ng

| Feature                      | proxychains-ng             | proxychains-tun                      |
|------------------------------|----------------------------|--------------------------------------|
| Mechanism                    | `LD_PRELOAD` library       | Linux network namespaces + TUN       |
| Statically linked binaries   | No                         | Yes                                  |
| Raw syscall bypass           | Possible                   | Impossible                           |
| macOS support                | Yes                        | No (Linux only)                      |
| Root required                | No                         | No (unprivileged user namespaces)    |
| Config format                | proxychains.conf           | Same proxychains.conf                |
| DNS interception             | Library hook (fake-IP)     | Namespace resolv.conf + fake-IP      |
| Proxy protocols              | SOCKS4/5, HTTP, raw        | SOCKS4/5, HTTP, HTTPS, raw           |

## Requirements

- Linux with unprivileged user namespaces enabled. On kernels that restrict them (e.g.
  some Ubuntu and Debian configurations), set:
  ```sh
  sysctl -w kernel.unprivileged_userns_clone=1
  ```
- Rust toolchain (`cargo build`)

## Building

```sh
cargo build --release
# binary: target/release/proxychains-tun
```

## Configuration

Copy `proxychains.example.conf`, edit the `[ProxyList]` section, and place it in one of
the standard locations:

```sh
cp proxychains.example.conf ~/.proxychains/proxychains.conf
$EDITOR ~/.proxychains/proxychains.conf
```

Config file search order (same as proxychains-ng):

1. `-f <file>` flag or `$PROXYCHAINS_CONF_FILE` environment variable
2. `./proxychains.conf`
3. `~/.proxychains/proxychains.conf`
4. `/etc/proxychains.conf`

## Usage

```
proxychains-tun [OPTIONS] <cmd> [args...]

Options:
  -f, --config <FILE>      Path to proxychains.conf
  -l, --log-level <LEVEL>  Log level: error, warn, info, debug, trace [default: warn]
  -h, --help               Print help
  -V, --version            Print version
```

### Examples

```sh
# Route curl through the configured proxy chain
proxychains-tun curl https://ifconfig.me

# Explicit config file
proxychains-tun -f /etc/myproxies.conf wget -qO- https://example.com

# Show which proxies are selected for each connection
proxychains-tun -l info curl https://ifconfig.me

# Run an entire shell session with all traffic proxied
proxychains-tun bash
```

### Proxy flow output

With `-l info`, one line is printed per connection showing the proxy path used:

```
INFO proxychains_masq::chain: |dynamic-chain| 1.2.3.4:1080 → example.com:443
INFO proxychains_masq::chain: |random-chain| 5.6.7.8:9050 → 9.10.11.12:1080 → ifconfig.me:80
```

Setting `quiet_mode` in the config file or using `-l warn` suppresses this output.

## License

GPLv3. See [LICENSE](LICENSE).

## Acknowledgements

- [proxychains-ng]https://github.com/haad/proxychains by Rokas Kupstys et al. — proxy
  chain engine design, configuration format, and proxy protocol implementations
  (SOCKS4/4a, SOCKS5, HTTP CONNECT).

- [oniux]https://gitlab.torproject.org/tpo/core/oniux by the Tor Project — Linux
  namespace isolation approach, TUN device setup, and netlink interface configuration
  code.