Simplest v5.11.0 Tun Sniff Config

[r3a1d3a1]

Would a gentleman please give me the simplest config to use the Tun service with sniffing capabilities to route some domains directly and some others to a Socks proxy?

Moreover, how would you setup linux routing to avoid "direct" connections looping back into V2 indefinitely?!
I tried binding freedom to another interface but my default route was still feeding "direct" connections into V2, using tun2socks, not the new Tun service, however.

Providing a guide for this case could serve other devs as well, since they could use the new V2 format just for the Tun setup with sniffing, and passing on the rest to an older V2 version without having to rewrite their config files.

Here's the config file that I thought would work but kept giving me panic: runtime error: invalid memory address or nil pointer dereference as soon as it received any packets.
Worth mentioning that it wouldn't parse the config with "destOverride": ["http", "tls"], even though the new docs mention it to be valid.

And here is my simple routing for when no direct connections are required:

ip tuntap add mode tun dev tun0
ip addr add 198.18.0.1/15 dev tun0
ip link set dev tun0 up

ip route del default
ip route add default via 198.18.0.1 dev tun0
ip route add $MYSERVERIP via 10.0.2.2 dev eth0

[hann-wang]

Actually destOverride should be destinationOverride

[hann-wang]

To prevent looping, consider implementing policy-based routing. For instance, you can designate a separate routing table for "proxy" connections that have different source addresses compared to "direct" connections.

[r3a1d3a1]

Thanks Hann.

Networking was never one of my strength, so I don't fully understand your suggestion. Code or config would be much appreciated.

For the time being, I hacked around the issue using a secondary V2 instance as a simple passthrough with a socks inbound in another namespace. If I could get interface binding to work properly though, I'd certainly prefer it over a hack.

Btw, is the following section from the config about IP of which interface to bind to, or which DNS-resolved destination IPs to accept? The dox are quite cryptic on the issue.

"routes": [
                {
                    "ip": [0, 0, 0, 0],
                    "prefix": 0
                }
            ],

Thanks again

[hann-wang]

You should configure the IP of the tun0 interface in the ips section, eg:

{
    "ips": [
                {
                    "ip": [192, 168, 18, 1],
                    "prefix": 24
                }
            ]
}

Additionally, after starting v2ray, you need to manually enable the tun0 interface and set up the IP, as v2ray does not seem to modify the tun0 interface configuration.

ip link set tun0 up
ip addr add 192.168.18.1/24 dev tun0

Regarding the routes section, you should keep the default route (0.0.0.0/0) to accept all packets coming through the tun0 interface.

For routing policies, you can view the default routing table with ip rule list command. Based on the default routing table, create a new routing table by adding one line to /etc/iproute2/rt_tables, eg:

100    custom_table

Then, create a default route in the custom routing table pointing to tun0:

ip route add default via 192.168.18.1 table custom_table

Your LAN (eth0) and tun0 addresses should go through the default routing table, with priority set to a smaller number:

ip rule add to 192.168.0.0/16 iif eth0 table local pref 100
ip rule add to 192.168.0.0/16 iif eth0 table main pref 101
ip rule add to 192.168.0.0/16 iif eth0 table default pref 102

Other routes should go through the custom routing table:

ip rule add iif eth0 table custom_table pref 103

For devices you want to proxy, set their gateway to the IP of the eth0 interface.

[r3a1d3a1]

Thank you very much friend.

If I understand correctly, you've taken the IP of the remote-server (A) out of the equation and focused solely on incoming packets.
If we call the machine where this routing is set up, B, then no special routing is applied to outgoing packets from B and doing a curl ifconfig.me from it, would not show A's IP.
Incoming packets to B, if destined for B or other nodes in that local network, are routed as usual, but if destined for somewhere else, they are fed to V2 using the custom_table route.

Please correct me if I'm wrong.

I will give it a shot and let you know.
Many thanks again!

[hann-wang]

Incoming packets to B, if destined for B or other nodes in that local network, are routed as usual, but if destined for somewhere else, they are fed to V2 using the custom_table route.

Yes. With the above configuration, there will be two routers in your local network. Router B will act as a secondary or 'side' router, while the outbound traffic from Router B itself will still be handled by the primary router.

[hann-wang]

If your primary router supports Docker, you could even consider deploying Router B within a container. Inside the container, you can create the tun0 interface and set up the routing tables.

[r3a1d3a1]

Truth be told, I have a raspberry Pi as my primary router which I intend to use this config on. So there won't be two routers and I should not need to manually set each client's gateway. But I do see the merit in having a gateway separate from the main router. Thank you.

[r3a1d3a1]

Finally got a chance to try your suggestions.
The routing worked great on Pi w/o any need to configure clients individually. Thanks a lot for that 🙏
I still received panic: runtime error: invalid memory address or nil pointer dereference as soon as V2 (5.12.1) received any packets on its Tun service, however. So tun2socks is here to stay I guess.