## Background

Let's say we'd like to debug a remote machine but use some of the debugging
tools we have on our local machine like wireshark.

You *can* run `tcpdump` on the remote and then `scp` the file to your local
machine to analyze the traffic, but after doing that a few times you may want a
workflow with a tighter feedback loop. For this we'll forward traffic from a
remote machine to our local machine.

**Note:** There's also `termshark`, which is a `wireshark` TUI that you can run
on the remote. It's quite cool!

## Local

Run the following on your local machine to forward your remote's traffic:

```shell
$ ssh -R 4317:127.0.0.1:4317 -N -f user@remote
```

Here is an abridged explanation of the flags we're passing from `man ssh`:

```
-N     Do  not  execute  a remote command.  This is useful for just forwarding ports.
-f     Requests ssh to go to background just before command execution.
```

**Note:** I couldn't find a good explanation for the `-R` option, so I tried
removing it and re-running the command, but that results in a resolution error:

```
ssh: Could not resolve hostname 4317:127.0.0.1:4317: Name or service not known
```

The remote should now be forwarding traffic from port `4317` to our
machine. We can verify with the following:

```shell
$ nc -l 4317 -k
```

## Testing

Let's generate some traffic on the remote. **Note:** you should see the output
in the shell in which you're running `nc -l 4317 -k`.

```shell
$ telnet localhost 4317
Trying ::1...
Connected to localhost.
Escape character is '^]'.
hello
world
```

Locally you should see:

```shell
λ nc -l 4317 -k
hello
world
```

You should now be able to `tcpdump -i lo port 4317` or just use `wireshark`
locally.

Happy debugging!