springzfx / cgproxy

For example, if one device have a public ipv6 address, and start some services (e.g. sshd, webserver) that listen the public ipv6 address. The new logical organized iptables will block ssh user@public_ipv6_address or http://[public_ipv6_address]:webserver_port from another device.

I do some trying and find out that this problem can be solved by add on line.

Change:

cgproxy/cgroup-tproxy.sh

Lines 199 to 200 in 0eca327

    
           iptables -t mangle -N TPROXY_MARK 
        
           iptables -t mangle -A TPROXY_MARK -m addrtype ! --dst-type UNICAST -j RETURN

to:

ip6tables -t mangle -N TPROXY_PRE
ip6tables -t mangle -A TPROXY_PRE -m addrtype --dst-type LOCAL -j RETURN
ip6tables -t mangle -A TPROXY_PRE -m addrtype ! --dst-type UNICAST -j RETURN

and this problem is solved.

ps. The strange thing is, it seems that only ipv6 has this problem, and needs this line to fix it. Without this line, other devices can access private ipv4 address without problem. I don't have any public ipv4 address and can't test whether other devices can asses public ipv4 address or not.

there is a loop, fixed in d6394f2:

[::1]:2020 -> output -> lo -> prerouting -> v2ray -> 直连[::1]:2020

However, as you noticed, 127.0.0.1:2020 won't have the loop.
I made some test, [::1] and 127.0.0.1 behave different when meeting the following rule

ip[6]tables -t mangle -A TPROXY_PRE -m addrtype ! --dst-type UNICAST -j RETURN

127.0.0.1 match, aka not unicast
[::1] not mach, aka unicast

I have to say this seems confusing.

	iptables -t mangle -N TPROXY_MARK
	iptables -t mangle -A TPROXY_MARK -m addrtype ! --dst-type UNICAST -j RETURN

New logical organized iptables blocks incoming connection to public ipv6 address