# Understanding the OpenFlux Dual-Role Binary: Client and Exit Node Modes

> Discover the dual roles of the OpenFlux binary. Learn how it functions as an internet-facing exit node or a local SOCKS5 client proxy.

- Repository: [p1neappleXpress/OpenFlux](https://github.com/p1neappleXpress/OpenFlux)
- Tags: deep-dive
- Published: 2026-09-13

---

**The OpenFlux dual-role binary is a single executable that operates either as an exit node (forwarding tunneled traffic to the internet) or as a local SOCKS5 client proxy, determined by command-line flags parsed in [`main.go`](https://github.com/p1neappleXpress/OpenFlux/blob/main/main.go).**

The OpenFlux project (`p1neappleXpress/OpenFlux`) provides a versatile networking tool that eliminates the need for separate client and server installations. This OpenFlux dual-role binary combines both functions into one codebase, enabling operators to deploy a lightweight SOCKS5 proxy or a privileged traffic forwarder using the same artifact.

## How the Dual-Role Binary Works

According to the source code in [`main/main.go`](https://github.com/p1neappleXpress/OpenFlux/blob/main/main/main.go), the binary determines its operational mode early in the execution lifecycle. Lines 31-38 define the command-line flags that control role selection, while lines 55-58 enforce mutual exclusivity, ensuring exactly one role is active at runtime.

At lines 61-66, the application logs the chosen mode, and the code branches at lines 71-82 to initialize the appropriate transport layer. Finally, lines 109-130 launch the specific role logic: either the exit-node handler (lines 111-125) or the SOCKS5 client (lines 127-130).

## Exit Node Mode

When executed with the `-exit-node` flag, the binary assumes the role of an **exit node**—a privileged server that receives tunneled connections and forwards raw TCP traffic to its final destination.

### Requirements and Configuration

Exit node mode requires **root privileges** on Linux and macOS to open raw sockets. Administrators can optionally bind the node to a dedicated egress IP using the `-local-ip` flag.

The implementation creates a packet-level tunnel via `tunnel.NewTCPTunnel`, defined in [`tunnel/tunnel.go`](https://github.com/p1neappleXpress/OpenFlux/blob/main/tunnel/tunnel.go). When a custom egress IP is specified, the code configures iptables rules to suppress kernel TCP-RST packets, as logged at lines 112-124 of [`main.go`](https://github.com/p1neappleXpress/OpenFlux/blob/main/main.go).

```bash

# Run as an exit node (needs root)

sudo ./OpenFlux -exit-node --local-ip 10.0.0.2

# → Logs: “Running as EXIT NODE (needs root for raw socket)”

```

## Client Mode

With the `-client` flag, the binary operates as a **local SOCKS5 proxy**, accepting connections from applications and tunneling them through the selected transport to an exit node.

### SOCKS5 Server Initialization

The client instantiates a SOCKS5 server using `socks5.NewSOCKS5Server` (defined in [`socks5/socks5.go`](https://github.com/p1neappleXpress/OpenFlux/blob/main/socks5/socks5.go)), binding to the address specified by the `-socks5` flag. This server forwards requests through the tunnel interface (`tun`) and the transport layer (`trans`).

### Supported Transports

The client supports multiple transport mechanisms including Yandex Docs, Yandex Volga, and the encrypted MAX protocol. Transport selection occurs through the `-transport` flag, with additional parameters like `-url`, `-maxToken`, and `-maxUid` configuring the specific backend.

```bash

# Run as a client that uses Yandex Docs transport

./OpenFlux -client \
    -socks5 :1080 \
    -transport yandex \
    -url https://docs.yandex.ru/d/ABCDEFG

# → Logs: “Running as CLIENT (SOCKS5 on :1080)”

```

For encrypted tunnels using the MAX transport, the binary enables AES-256-GCM encryption when a key file is provided:

```bash

# Run as a client that uses the encrypted MAX transport

./OpenFlux -client \
    -socks5 :1080 \
    -transport oneme \
    -maxToken <TOKEN> \
    -maxUid 123456 \
    -encryption-key-file ./secret.key

# → Logs: “Transport encryption: AES-256‑GCM enabled”

```

## Key Implementation Files

The dual-role architecture relies on several core components:

- **[`main/main.go`](https://github.com/p1neappleXpress/OpenFlux/blob/main/main/main.go)**: Parses flags, validates role selection, builds transport and tunnel instances, and launches the appropriate runtime mode.
- **[`tunnel/tunnel.go`](https://github.com/p1neappleXpress/OpenFlux/blob/main/tunnel/tunnel.go)**: Implements `NewTCPTunnel`, the foundational component used by both roles to encapsulate traffic at the packet level.
- **[`transport/transport.go`](https://github.com/p1neappleXpress/OpenFlux/blob/main/transport/transport.go)**: Defines the `Transport` interface and common configuration shared across all transport implementations.
- **[`socks5/socks5.go`](https://github.com/p1neappleXpress/OpenFlux/blob/main/socks5/socks5.go)**: Provides the SOCKS5 server implementation used exclusively in client mode.
- **[`transport/oneme/max_transport.go`](https://github.com/p1neappleXpress/OpenFlux/blob/main/transport/oneme/max_transport.go)**: Example transport implementation for the MAX protocol, demonstrating how client-mode transports interface with the tunnel layer.

## Summary

- The OpenFlux dual-role binary combines exit node and client functionality into a single executable controlled by `-exit-node` or `-client` flags.
- Exit nodes require root privileges to handle raw sockets and optionally bind to specific egress IPs using `-local-ip`.
- Client mode exposes a local SOCKS5 proxy via `socks5.NewSOCKS5Server`, supporting multiple transport backends including Yandex Docs and encrypted MAX.
- Role selection and validation occur in [`main/main.go`](https://github.com/p1neappleXpress/OpenFlux/blob/main/main/main.go) (lines 31-58), with initialization branching at lines 71-82 and runtime logic at lines 109-130.
- Both modes share the `tunnel.NewTCPTunnel` infrastructure for consistent packet handling across the architecture.

## Frequently Asked Questions

### What privileges are required to run the OpenFlux binary as an exit node?

Exit node mode requires root privileges on Linux and macOS systems to open raw TCP sockets and optionally configure iptables rules to suppress kernel TCP-RST packets when binding to a custom egress IP.

### Can the OpenFlux binary run as both a client and exit node simultaneously?

No. The source code in [`main/main.go`](https://github.com/p1neappleXpress/OpenFlux/blob/main/main/main.go) (lines 55-58) enforces mutual exclusivity, validating that exactly one role is selected via command-line flags. The binary must be launched separately for each role.

### Which file handles the SOCKS5 proxy functionality in client mode?

The [`socks5/socks5.go`](https://github.com/p1neappleXpress/OpenFlux/blob/main/socks5/socks5.go) file implements the SOCKS5 server functionality through `socks5.NewSOCKS5Server`, which the client mode initializes to accept local connections and forward them through the tunnel transport.

### What encryption options are available when using the client mode?

When using the MAX transport (`-transport oneme`), the client supports AES-256-GCM encryption by specifying an `-encryption-key-file` path, enabling end-to-end encryption of tunneled traffic between the client and exit node.