DeCarabas/fwd
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity
A small port-forwarding utility
126 commits 2 branches 14 tags 20 MiB
Find a file
Brandon W Maister 6c10d8eece feat: Discover docker ports as well 
If processes are running in a container then the fwd process
can't read their internal FDs without the CAP_SYS_ADMIN property
which is equivalent to sudo. Even with sudo, I think you need to do
a lot of work to be able to read them -- spawning a process within
the cgroup, doing work there, and then communicating back.

This just uses the docker api to populate some default ports, which
later get overwritten if fwd can find a native process.

The Docker port scan takes about 1.5ms, and the full port scan takes
40+ms, so this adds basically no overhead.
2024-07-31 15:32:45 -07:00
.github/workflows Allow manual trigger of workflow dispatch 2024-04-14 06:51:26 -07:00
.vscode I'm not sure I ever actually got these to work? 2022-10-26 07:12:59 -07:00
src feat: Discover docker ports as well 2024-07-31 15:32:45 -07:00
.gitignore Enumerate all of the listening processes and their ports 2022-10-04 18:13:57 +00:00
Cargo.lock feat: Discover docker ports as well 2024-07-31 15:32:45 -07:00
Cargo.toml feat: Discover docker ports as well 2024-07-31 15:32:45 -07:00
config.toml Starting configuration, probably doesn't work 2022-10-18 11:28:56 -07:00
LICENSE Fill out Cargo.toml and also LICENSE 2022-10-26 07:11:38 -07:00
README.md Make notes about the future 2023-08-28 09:25:46 -07:00
rustfmt.toml Try to make the UI better when unconnected 2022-10-16 08:55:30 -07:00
test.py Protocol version, async pump, start some testing 2022-12-16 13:57:52 -08:00

README.md

fwd

A port-forwarding utility.

Here's how it works:

  1. Get the latest release of fwd
  2. You install fwd on the server somewhere in your $PATH (like /usr/bin/)
  3. You install fwd on the client (like your laptop)
  4. You run fwd on the client to connect to the server, like so:
doty@my.laptop$ fwd some.server

fwd will connect to some.server via ssh, and then show you a screen listing all of the ports that the server is listening on locally. Use the up and down arrow keys (or j/k) to select the port you're interested in and press e to toggle forwarding of that port. Now, connections to that port locally will be forwarded to the remote server.

If the port is something that might be interesting to a web browser, you can press <ENTER> with the port selected to open a browser pointed at that port.

If something is going wrong, pressing l will toggle logs that might explain it.

Press q to quit.

Future Improvements:

  • Clipboard integration: send something from the remote end of the pipe to the host's clipboard. (Sometimes you really want to copy some big buffer from the remote side and your terminal just can't make that work.)

  • Client heartbeats: I frequently wind up in a situation where the pipe is stalled: not broken but nothing is getting through. (This happens with my coder.com pipes all the time.)