70ddcafef8
Test coverage for the SOCKS dynamic forwarding feature beyond the hermetic protocol tests. No production code changed. 1. Cross-OS SOCKS end-to-end test (EndToEndTests.Socks, 4 rows over SMB): side1 hosts -D; a REAL curl on side1's node drives the TCP leg (to the internet - example.com, which also exercises far-side DNS resolution - and to a controlled dev-box responder), while the harness drives the UDP leg (DNS to 8.8.8.8 + a controlled echo), since no common CLI implements SOCKS5 UDP. Passes Windows<->Linux both ways on the lab. 2. Hermetic four-proxy stress test (SocksUnitTests.SocksStress_FourProxies...): both in-process ft instances run -D + -R, so four SOCKS proxies share one file tunnel (two hosted per side). 16 connections (4 per proxy) push 16 MB full-duplex simultaneously - 512 MB, every byte verified. 3. Cross-machine four-proxy stress test (EndToEndTests.SocksStress, 2 rows): the same four-proxy topology but the two ft instances run on DIFFERENT lab nodes over the real SMB tunnel. Each proxy is driven by curl running ON ITS HOST NODE against 127.0.0.1 (the way a SOCKS proxy is actually used), so nothing connects inbound to a proxy port and a node's firewall is never in the way - the exit just dials OUT to the dev-box server. All four download 32 MB concurrently through their local proxy (128 MB through the one tunnel); curl --fail makes a short transfer a non-zero exit, so exit 0 proves it all arrived. Passes Windows<->Linux both ways, including a Windows node hosting proxies. Supporting test infra: RunCommand(cmd) on the process runners (runs a client command on a node - local Process, or over the existing SSH channel - and captures exit code + output); SocksTestClient (SOCKS5 UDP-associate client helpers); and optional transferOverride / timeoutSeconds parameters on ConductTest (defaults unchanged for existing callers). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SjajJ7d3BhSZGfsMrGRS5S |
||
|---|---|---|
| ft | ||
| ft_test_env | ||
| ft_tests | ||
| img | ||
| .gitattributes | ||
| .gitignore | ||
| build-release.bat | ||
| build-release.ps1 | ||
| ft.sln | ||
| LICENSE.md | ||
| README.md | ||
File Tunnel
Tunnel TCP connections through a file server.
A full list of supported file systems can be found here.
Download
Portable executables for Windows, Linux and Mac can be found over in the releases section.
Example 1 - Bypassing a firewall
You'd like to connect from Host A to Host B, but a firewall is in the way. But both hosts have access to a shared folder.
Host A
ft.exe -L 5000:127.0.0.1:3389 --write "\\server\share\1.dat" --read "\\server\share\2.dat"
This command listens for connections on port 5000. When one is received, it is forwarded through the file tunnel and then onto 127.0.0.1:3389.
Host B
ft.exe --read "\\server\share\1.dat" --write "\\server\share\2.dat"
Now on Host A, connect the client to 127.0.0.1:5000 and it will be forwarded to the remote server.
This is what the File Tunnel looks like when operating:
Example 2 - Tunnel TCP through RDP (similar to SSH tunnel)
You'd like to connect to a remote service (eg. 192.168.1.50:8888), but only have access to Host B using RDP.
Host A
ft.exe -L 5000:192.168.1.50:8888 --write "C:\Temp\1.dat" --read "C:\Temp\2.dat"
Run an RDP client and ensure local drives are shared as shown here.
RDP to Host B.
Host B
ft.exe --read "\\tsclient\c\Temp\1.dat" --write "\\tsclient\c\Temp\2.dat"
Now on Host A, you can connect to 127.0.0.1:5000 and it will be forwarded to 192.168.1.50:8888
Other interesting features
-
-Lcan be used multiple times, to forward numerous ports through the one tunnel. -
To enable other computers to use the tunnel, specify a binding address of
0.0.0.0. For example:-L 0.0.0.0:5000:192.168.1.50:3389allows any computer on the network to connect to the tunnel and onto 192.168.1.50:3389 -
Use
-Rfor remote forwarding. For example:-R 5000:10.0.0.50:6000instructs the remote side to listen on port 5000, and when a connection is received forward it through the tunnel and onto 10.0.0.50:6000 via the local machine. This allows you to share a server running on your local machine, with other computers. -
Use
-Dfor dynamic (SOCKS) forwarding, just like SSH. For example:-D 1080starts a SOCKS4/4a/5 proxy on port 1080; each connection is dialed from the remote side, so applications can reach whatever the remote machine can. A bare-R 1080(no destination) is the reverse: it hosts the SOCKS proxy on the remote side, dialing out via your local machine. Handles both TCP (CONNECT) and SOCKS5 UDP (ASSOCIATE); no authentication. -
You can use another computer's internet connection by following these instructions.
How does it work?
The program starts a TCP listener, and when a connection is received it writes the TCP data into a file. This same file is read by the counterpart program, which establishes a TCP connection and onforwards the TCP data. To avoid the shared file growing indefinitely it is purged whenever it gets larger than 10 MB.