Beat your firewall with a self-hosted or peer-provided VPN.Connecting your workstation with your home-computer or laptop with SSH ( Working), RDP or VNC.P2P chatting, mailing, VoIP, streaming, gaming, screen-sharing, file-sharing, gambling, troubleshooting and what not.Those cases that I have tested are labelled as 'working'. If you found any of these useful, or useless, or you have found entirely new applications for tunnel, please post at discussions. Some of the following ideas are rather sketchy, haven't been tested at all, and may not work, but nonetheless are documented here, at least for the time being, just for the sake of inspiration. WebRTC without TURN) or joining a remote LAN, should find tunnel useful. Broadly speaking, anything that involves NAT/firewall traversal (e.g. Applicationsīelow are some random use-cases I could think of for tunnel. Point your redis-cli at the forwarded local port. Need to connect to a remote Redis instance hosted by a peer or yourself? At the remote host, expose the TCP port that redis-server runs on (default: 6379), with tunnel.Īt your local machine, use tunnel to forward a TCP port to the remote port. But it sure makes the experience sweeter as it uses GNU Readline and remembers the input history (accessible with the up/down arrow keys similar to your local bash sessions). Tunnel -l '/dev/null ' -b 5000 -k 'your secret ' 'node_id_of_workplace:49090 ' Runs tunnel as daemon with stderr redirected to given path. Can use environment variable TUNNEL_RELAY instead. If used, it must be used by both the peers. flag denotes use of UDP instead of the default TCP. The secret string may also be passed using the environment variable TUNNEL_KEY. When server can be found on LAN with private IP =, tunnel connects through LAN.Ĭlient and server must use the same secret to be able to connect with each other. The -I option is handy when client is running on a laptop that occasionally gets connected to the LAN the server is on. The port used, is always reported at stdout. If no local-port is provided using the -b option, tunnel uses a random unused port. ID: Every node is given a unique ( base64) ID. KISS: Just a single, small, portable, shell-script.įor the special case of IPFS, see #examples below.

Option to host your own relay server (easily and for free).

Resilience: Peers auto-reconnect in the face of intermittent connectivity.

Each node can act as both server and client. Server can support multiple clients at any given time.

Many-to-One: The forwarding peer acts as the client and the forwardee peer acts as the server.

Multiplexing: Each tunnel supports multiple concurrent connections.

Traffic between peer and relay is encrypted (TLS).

Security: To connect, peers must know the unique ID of the serving peer and a shared secret key.Firewalls don't cause problems as only outgoing http(s) connections are used.TCP/UDP tunnel between peers, each of which may be behind (multiple) NAT(s), i.e.Designed mainly for p2p connections between peers behind (multiple) NAT/firewalls. Secure, multiplexed, TCP/UDP port forwarder using piping-server by as relay.

Beebeep host file