README
¶
rndz-go
A simple rendezvous protocol implementation to help NAT traversal or hole punching.
Golang implementation for rndz.
Table of Contents
Features
- Simple and lightweight implementation
- Supports both TCP and UDP protocols
- Easy to integrate with existing Go projects
Installation
To install rndz-go, use go get:
go get github.com/optman/rndz-go
Usage
Here's how you can use rndz-go to perform NAT traversal or hole punching.
TCP
Client 1
import (
"context"
"net/netip"
"github.com/optman/rndz-go/client/tcp"
)
func main() {
rndzServer := "your-rendezvous-server"
c := tcp.NewClient(rndzServer, "c1", netip.AddrPort{})
defer c.Close()
l, _ := c.Listen(context.Background())
defer l.Close()
for {
conn, _ := l.Accept()
defer conn.Close()
// Handle connection
}
}
Client 2
import (
"context"
"net/netip"
"github.com/optman/rndz-go/client/tcp"
)
func main() {
rndzServer := "your-rendezvous-server"
c := tcp.NewClient(rndzServer, "c2", netip.AddrPort{})
defer c.Close()
conn, _ := c.Connect(context.Background(), "c1")
defer conn.Close()
// Use connection
}
UDP
import (
"net/netip"
"github.com/optman/rndz-go/client/udp"
)
func main() {
rndzServer := "your-rendezvous-server"
id := "your-client-id"
c := udp.NewClient(rndzServer, id, netip.AddrPort{})
// Use client
}
License
This project is licensed under the MIT License - see the LICENSE file for details.
Documentation
¶
Overview ¶
Package rndz provides a simple rendezvous protocol implementation to help NAT traversal or hole punching.
To connect a node behind a firewall or NAT (such as a home gateway), which only allows outbound connections, you not only need to know its gateway IP, but also have the node send you traffic first.
This applies not only to IPv4 but also to IPv6. As IPv4 needs to deal with NAT, both need to deal with firewalls.
How rndz works ¶
Setup a publicly accessible server as a rendezvous point, to observe all peers' addresses and forward connection requests.
Each peer needs a unique identity. The server will associate the identity with the observed address. A listening peer will keep pinging the server and receive forwarded requests. A connecting peer will request the server to forward its connection requests.
After receiving a forwarded connection request from the server, the listening peer will send a dummy packet to the connecting peer. This will open the firewall or NAT rule for the connecting peer; otherwise, all packets from the peer will be blocked.
After that, we return native socket types `net.Conn` and `net.UDPConn` to the caller.
The essential part is that we must use the same port to communicate with the rendezvous server and peers.
The implementation depends on socket options SO_REUSEADDR and SO_REUSEPORT, so it is OS dependent. For TCP, the OS should allow the listening socket and connecting socket to bind to the same port. For UDP, the OS should correctly dispatch traffic to connected and unconnected UDP sockets all binding to the same port.
Source Files
Directories