GOST Network Tunneling: TUN/TAP, Routing Tunnels, and TUNGO Deep Dive

Overview of GOST Network Tunneling

GOST (GO Simple Tunnel) extends beyond traditional proxying by supporting TUN/TAP virtual network devices, IP-layer routing tunnels, and the TUNGO (tun2socks) module. Together these capabilities let GOST operate as a flexible VPN and transparent proxying platform.

Key points

TUN/TAP device support

• TUN vs TAP. TUN operates at OSI Layer 3 and processes raw IP packets. TAP operates at Layer 2 and processes Ethernet frames (including ARP). GOST primarily relies on TUN because its VPN design focuses on IP-layer forwarding without Ethernet broadcast handling.
• Application role. TUN/TAP devices act as a bridge between user-space applications and the kernel network stack, allowing GOST to capture outbound IP packets, encapsulate them, transmit them over a tunnel, and re-inject them at the remote side.
• Introduced in v2.9. TUN/TAP support has been progressively refined and is a defining feature distinguishing GOST from pure proxy tools.

Library choices and cross-platform implementation

• Linux TUN. Since GOST v3 (beta.4), Linux TUN implementation uses wireguard-go, bringing improved performance, stability, and indirect WireGuard features (heartbeats, authentication).
• TAP support. The songgao/water library remains in use for TAP devices, valued for its lightweight, cross-platform API.
• Windows. Because Windows lacks a native TUN/TAP interface, GOST depends on the wintun driver for TUN functionality and typically pairs with OpenVPN's TAP-Windows6 driver for TAP mode.
• macOS. Supported through the same library approach with platform-specific kernel extensions.
• Transport universality. This design supports arbitrary IP-based protocols including TCP, UDP, and ICMP.

Configuration parameters

• Basic parameters. local_ip:port (local listener/address), remote_ip:port (tunnel endpoint), and net (CIDR address for the TUN device, e.g., 192.168.123.2/24) are required.
• Advanced parameters. name sets the interface name (e.g., tun0), mtu controls maximum packet size (commonly 1350–1420), gw specifies the default gateway (typically the server-side TUN IP), and route/routes define comma-separated CIDR ranges for split tunneling.
• Linux example. A minimal point-to-point VPN uses server-side services with listener.type: tun, metadata.net: 192.168.123.1/24, and a client configuration that sets addr: :0, net: 192.168.123.2/24, gw: 192.168.123.1, and a forwarder node pointing at the server. Full internet access requires enabling ip_forward and configuring NAT (e.g., iptables MASQUERADE on eth0).

Routing tunnel feature

• Concept. Routing tunnels extend TUN/TAP support by letting users define granular rules controlling packet flow based on destination, source, or protocol. This enables split tunneling, multi-exit VPN, load balancing, and cross-region network topologies.
• Mechanism. GOST's tun handler inspects packets read from the TUN device and matches them against configured routes, sending matches to a specific gateway or to a named GOST chain.
• Server configuration. Uses services.listener.metadata.routers containing named routes. Each route has a net (CIDR match), optional gateway (next-hop IP), and optional chain reference. Packets matching 192.168.100.0/24 can be forwarded to a gateway, while 192.168.101.0/24 traffic can be sent through chain-1 to a different remote server (e.g., via WSS).
• Client configuration. Sets net for its TUN device and uses route to define which destination networks send traffic through the tunnel. Only those destinations are captured by the local TUN.
• Static vs dynamic routing. GOST supports static routing natively. Dynamic routing protocols (OSPF, BGP) are not built in but can be layered by running a routing daemon (Quagga, FRRouting) on top of the TUN device.
• Enterprise example. A hub VPN server at HQ can route three branch networks (192.168.100.0/24, .101.0/24, .102.0/24) to their respective client gateways, while each branch uses route: 0.0.0.0/0 to send all internet traffic through HQ for centralized auditing.

TUNGO (tun2socks) module

• Core idea. TUNGO captures IP packets from a TUN device, parses TCP/UDP headers, and converts connections into SOCKS5 requests (CONNECT for TCP, UDP ASSOCIATE for UDP), transparently proxying traffic through one or more SOCKS servers.
• Dependencies. Likely integrates xjasonlyu/tun2socks, a Go implementation that includes a lightweight TCP/IP stack in user space, going beyond simple TUN libraries.
• Integration with GOST subsystems.
• Chain. Traffic can traverse a multi-hop chain of nodes with mixed protocols (relay, socks5, http) and transports (tcp, ws, wss), enabling multi-level proxying.
• Bypass/sniffing. Domain, IP, geo, and protocol-based rules can send matching traffic direct while proxying the rest (e.g., bypass 127.0.0.0/8, private RFC1918 ranges, and a china_ip_list.txt file).
• Load balancing and failover. Multiple nodes at the same hop distribute traffic and drop unhealthy peers automatically.
• Cross-platform. Core logic runs in user space; behavior is consistent across Linux, Windows, and macOS though driver requirements differ (wintun/TAP-Windows6 on Windows, native tun on Linux/macOS).
• Configuration. A minimal CLI invocation looks like gost -L "tungo://:0?name=tungo&net=192.168.123.1/24&mtu=1420&dns=1.1.1.1" -F "relay+wss://SERVER_IP:443?interface=eth0". YAML form uses services[].handler.type: tungo with metadata.udpTimeout and a separate chains: block defining hops and nodes.

Overall working model

• GOST captures packets from a virtual TUN/TAP device, applies user-defined rules, optionally translates them into SOCKS requests (TUNGO), and forwards them through GOST chains. The remote endpoint reverses the process, injecting packets back into its local network stack so both sides appear to share a virtual subnet. This unified model supports VPN, transparent proxying, split tunneling, and multi-hop anonymization from a single Go-based binary.