search

xjasonlyu / tun2socks

tun2socks - powered by gVisor TCP/IP stack
https://github.com/xjasonlyu/tun2socks/wiki
GNU General Public License v3.0
2.85k stars 405 forks source link

[Feature] ConeNAT support #177

Open myloft opened 1 year ago

myloft commented 1 year ago

Description

From v2.4.1, the NAT type has changed to Symmetric NAT.

Is this feature related to a specific bug?

No response

Do you have a specific solution in mind?

No response

myloft commented 1 year ago

I'd be happy to help, although I don't know how to do it right now.

xjasonlyu commented 1 year ago

Before v2.4.0, the NAT part was written with a customized/unofficial UDP module, which makes it simple to implement Full-Cone NAT. But due to the aggressive gVisor update frequency, the API constantly changes, contributing the terrible code maintainability.

Therefore, starting from v2.4.0, the official gVisor net module was used to avoid regular code adaptations for its daily API updates. However, this also imported another issue - NAT. The gVisor abstracts its UDP module as a connection-based net, making it infeasible to receive packets from other sources, which causes the NAT type can only be symmetric for now.

To support Cone-NAT at this stage and keep the high code maintainability, we can only use a NAT table to map the connections and create a "fake" Port Restricted Cone NAT. The implementation can be done inside the tunnel/udp.go file. But it can be a bit complex and buggy at the beginning, and that's why I haven't implemented it yet. You're welcome if you want to contribute to this feature!

github-actions[bot] commented 1 year ago

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 7 days

GektorUA commented 1 year ago

Is there any possibility that Full Cone NAT will be back in future versions?

rurirei commented 1 year ago

The gVisor abstracts its UDP module as a connection-based net, making it infeasible to receive packets from other sources, which causes the NAT type can only be symmetric for now.

Is there any possibility that Full Cone NAT will be back in future versions?

maybe no.

rurirei commented 1 year ago

To support Cone-NAT at this stage and keep the high code maintainability, we can only use a NAT table to map the connections and create a "fake" Port Restricted Cone NAT. The implementation can be done inside the tunnel/udp.go file. But it can be a bit complex and buggy at the beginning,

how do we comfirm the source addr to map some *gonet.UDPConn connections?

dksslq commented 3 months ago

Nobody care this?