UDP over SSH: Difference between revisions
mNo edit summary |
|||
| Line 1: | Line 1: | ||
Forward UDP traffic on a specific port (like Art-Net) to a remote client via SSH. |
Forward UDP traffic on a specific port (like Art-Net <ref>[[wikipedia:Art-Net]]</ref>) to a remote client via SSH <ref>[[wikipedia:SSH_(Secure_Shell)]]</ref>. |
||
== Background == |
== Background == |
||
| Line 8: | Line 8: | ||
SSH is based on TCP. Encapsulating UDP datagrams in TCP packets might have unwanted side effects. While a UDP datagram gets dropped if a transmission error occurs, TCP packets will be retransmitted which may cause unwanted delays. If such a delay is of any significance is open for discussion. |
SSH is based on TCP. Encapsulating UDP datagrams in TCP packets might have unwanted side effects. While a UDP datagram gets dropped if a transmission error occurs, TCP packets will be retransmitted which may cause unwanted delays. If such a delay is of any significance is open for discussion. |
||
Using DTLS <ref>[[wikipedia:Datagram_Transport_Layer_Security]]</ref> might be a better approach to encrypt UDP traffic. |
|||
== Diagram == |
== Diagram == |
||
| Line 23: | Line 25: | ||
===== Requirements ===== |
===== Requirements ===== |
||
* socat |
* socat |
||
* SSH |
|||
* SSH <ref>[[wikipedia:SSH_(Secure_Shell)]]</ref> |
|||
* remote computer that can receive SSH connections (e.g. Raspberry Pi) and whose SSH port is exposed to the internet (e.g. via port forwarding). |
* remote computer that can receive SSH connections (e.g. Raspberry Pi) and whose SSH port is exposed to the internet (e.g. via port forwarding). |
||
Revision as of 13:50, 5 February 2021
Forward UDP traffic on a specific port (like Art-Net [1]) to a remote client via SSH [2].
Background
This comes in handy if you don't want to expose the remote device's UDP port directly to the internet and/or you want the connection through the Internet to be encrypted.
Caveat
SSH is based on TCP. Encapsulating UDP datagrams in TCP packets might have unwanted side effects. While a UDP datagram gets dropped if a transmission error occurs, TCP packets will be retransmitted which may cause unwanted delays. If such a delay is of any significance is open for discussion.
Using DTLS [3] might be a better approach to encrypt UDP traffic.
Diagram
Implementations
Linux
Socat
Socat [4] is a command-line utility to read from and write to TCP and UDP network connections.
Requirements
- socat
- SSH
- remote computer that can receive SSH connections (e.g. Raspberry Pi) and whose SSH port is exposed to the internet (e.g. via port forwarding).
Example
Connect to the remote computer (example.com) via SSH and forward our local TCP port 7000 to the remote computer's local TCP port 7000:
ssh -L 7000:localhost:7000 example.com
Note: if you want to forward a port in the 1 - 1023 range you need root privileges (sudo).
Via the SSH shell on the remote computer (example.com) configure socat to listen on TCP port 7000 and forward the traffic (from port 7000) to IP address 10.0.0.2 on UDP port 6454:
sudo socat TCP-LISTEN:7000,fork UDP6:10.0.0.2:6454
On our local device we configure socat to listen on local UDP port 6454 and forward the traffic to local TCP port 7000, where the SSH port forward is configured:
sudo socat UDP-LISTEN:6454 TCP:localhost:7000
Now our local UDP traffic on port 6454 is tunneled to the remote device at 10.0.0.2 .