SOCKS Protocol Version 5 Library in Go. Full TCP/UDP and IPv4/IPv6 support

Describe actual behavior

What is your expected behavior

Specifications like the version of the project, operating system, or hardware

Steps to reproduce the problem

In RFC 1928, it says:

The DST.ADDR and DST.PORT fields contain the address and port that the client expects to use to send UDP datagrams on for the association. The server MAY use this information to limit access to the association.

But if the client is in a LAN, the server would get a totally different addr and port when receiving udp packets because of the NAT.Then how could i limit access to the udp association?

When server returns an any ip (0.0.0.0 or [::]), we should use conventional ip to replace the any ip given (0.0.0.0 or [::]). This behaviour adapts to most situations.

See v2fly/v2ray-core#523

Problem happens when socks5 proxy works on remote servers and different implementation will given different bind addr.

For most situations it is issues of servers. However, clients should behave normally in one case that returned bind addr is an ANYIP (0.0.0.0 or [::]), which indicate that we should use a conventional remote address to connect.

RFC does not illustrate the mechanism of bind addr; it is based on experience.

Describe actual behavior

What is your expected behavior

Specifications like the version of the project, operating system, or hardware

Steps to reproduce the problem

@txthinking

I would like to ask how you feel about using Go modules with this?

If you don't like go modules, my apologies, maybe I should have created an Issue first?

Anyway, curious about your thoughts. (And thank you for a nice looking Socks5 proxy!)

修复与三方软件privoxy配合使用 (privoxy是一个HTTP转socks5的软件，可能它有bug导致不支持分散的tcp write，导致此项目的socks5握手流程无法正常完成，改成一次性写入可以解决问题)

Fixes # .

Changes proposed in this pull request:

@mentions

Describe actual behavior

Support socks5 proxy behind socks5 proxy

What is your expected behavior

Support socks5 proxy behind socks5 proxy

Suggestion

The client/server side dialer can be set separately: https://github.com/txthinking/socks5/blob/master/client.go#L235 https://github.com/txthinking/socks5/blob/master/server.go#L396

Not associated with an existing issue.

Changes proposed in this pull request:

• This PR migrates txthinking/socks5 from using concrete net types(net.TCPAddr, net.TCPConn) to using interface net types(net.Addr, net.Conn, net.PacketConn).
• It also implements the ability to add a custom Resolver and a custom Dialer which use interface types as well.
• This allows developers to use custom dialers and resolves in order to work with alternate pseudo-TLD's directly. In my use case, this pseudo-tld is the .i2p space. Developers can now do something like this:

package main

import (
	"github.com/eyedeekay/sam3/helper"
	"github.com/eyedeekay/sam3/i2pkeys"
	"github.com/txthinking/socks5"
	"log"
)

func main() {
	// Create a SOCKS5 server
	addr := "127.0.0.1:8888"
	ip := "127.0.0.1"
	username := ""
	password := ""
	tcpTimeout := 60000
	udpTimeout := 60000
	i2pkeys.FakePort = true

	primary, err := sam.I2PPrimarySession("sam-socks", "127.0.0.1:7656", "socks5")
	if err != nil {
		panic(err)
	}

	socks5.Dial = primary
	socks5.Resolver = primary

	server, err := socks5.NewClassicServer(addr, ip, username, password, tcpTimeout, udpTimeout)
	if err != nil {
		panic(err)
	}
	log.Println("Client Created")

	// Create SOCKS5 proxy on localhost port 8000
	if err := server.ListenAndServe(nil); err != nil {
		panic(err)
	}

to transparently I2P-ify their applications.

Describe actual behavior

I am working on changing the socks5 of this project to full cone（nat1）. I would like to ask, can I only receive data packets from remote addr in the udp connection state? If a connect udp is established, such as 127.0.0.1:8003- >1.1.1.1:53, but I want to receive 1.1.1.2:33->127.0.0.1:8003 udp packets, can I only use the non-connected listening port to achieve this?

What is your expected behavior

nat1

Specifications like the version of the project, operating system, or hardware

Steps to reproduce the problem