It is clear that one end point will be a direct TUN location, and the other is leaning towards being an ssh into the remote host. But that leaves forwarded ports between the two hosts which serve no legitimate purpose other than servicing the socat TUN devices. You could setup port forwarding with ssh and use socat to connect those ports to a virtual TUN device.
#Linux socat tutorial how to
The trick with using ssh is how to bolt things together. You probably already have SSH setup so its much simpler to use because no SSL certificates need to be generated and distributed. While there are overviews of using socat with TUN and socat with SSL I think it is much simpler to just use SSH to protect the network link from eavesdropping. Note that if you send data to a TUN device there is no encryption happening so if those packets move over the real network you have a Virtual Public Network. Virtual networks are created using the TUN device of the Linux kernel. SYSTEM:"ssh myserver socat - /dev/urandom"Ĭreating a Virtual Private Network over SSH in a Single Line The below command makes /dev/urandom from a server available through a named pipe on the local machine. While creating virtual modems is not as attractive as it might once have been, other devices can be moved around too. (socat PTY,link=$HOME/dev/vmodem0,raw,echo=0,waitslaveĮXEC:"ssh socat - /dev/ttyS0,nonblock,raw,echo=0")
#Linux socat tutorial serial
The other location is an ssh connection to a server machine, where the standard IO is connected to the serial device on the remote machine. The first location creates a PTY device on the local machine allowing raw communication with the other location.
#Linux socat tutorial manual
I’ll use the example from the socat manual page shown below to demonstrate. One great use case for socat is making device files from one machine available on another one. $ socat TCP4-LISTEN:3334,reuseaddr,fork gopen:/tmp/capture,seek-end=0,append The client command, shown as the second command below, is very similar to the simpler example shown above except we now send standard IO to a socket address. The seek-end moves the file to zero bytes from the end and the append makes sure that bytes are appended to the file rather than overwriting it. The first command connects port 3334 on localhost to the file /tmp/capture. While this example is quite superfluous in that you could just use the shell > redirection to append to the file, you could also include a network link into the mix with minimal effort using socat as shown below. $ date | socat - GOPEN:/tmp/capture,append This is similar to the Web server example, a comma separated list of additional options for the location. The below keeps a log file of the time each time you execute it. For example, GOPEN (generic open) lets you specify append if you would like to append too rather than overwrite the file. Many of the socat location TYPEs take more than one option. Instead of connecting standard IO as the first location in the above command, using READLINE,history=$HOME/.http_history will cause socat to use readline to get your commands. If the network service is more interactive, you might like to use readline to track your command history, improve command editing, and allow you to search and recall your previous commands.
Notice that the port is specified using the service name and a comma separates the address from the cnrl option which handles line termination transformations for us. The below socat command will open a connection to a Web server and fetch a page to the console. Many network services handle control commands using plain text. For example, the command shown below will run the date command and transfer its output to standard output. The SYSTEM type can be used to execute a program and connect to its standard input and output. There are also shortcuts for some locations like STDIO (or just -) which reads and writes to standard input and output respectively. Locations have the general form of TYPE:options where TYPE can be CREATE, GOPEN or OPEN for normal filesystem files. In this article, we’ll take a look at socat and a few of its uses and end up creating a VPN over an ssh connection using a single command from the ssh client side.īecause socat allows bidirectional data flow between the two locations you specify, it doesn’t really matter which order you specify them in. I say that socat works on two locations rather than two files because you can grab data from a network socket, named pipe, or even setup a general virtual network interface as one end point. One way to think of socat is as the cat command which transfers data between two locations rather than from a file to standard output. The socat command shuffles data between two locations.
0 kommentar(er)
