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

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.

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, 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. 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.

# 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), 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.

# 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:

# 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: Parses flags, validates role selection, builds transport and tunnel instances, and launches the appropriate runtime mode.
• tunnel/tunnel.go: Implements NewTCPTunnel, the foundational component used by both roles to encapsulate traffic at the packet level.
• transport/transport.go: Defines the Transport interface and common configuration shared across all transport implementations.
• socks5/socks5.go: Provides the SOCKS5 server implementation used exclusively in client mode.
• 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 (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 (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 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.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}