[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: TCP proxy for host on subnet



On 06/06/2017 14:22, Henning Follmann wrote:
On Tue, Jun 06, 2017 at 10:59:30AM +0100, Ron Leach wrote:

I was also unsure whether socat would hold open a connection to
name.server.tld even if no transactions were taking place, or whether socat
would only open the connection each time traffic arrived on 3129 and it
forked another child process.  The documentation seems to imply that the
'open' takes place before traffic and before forking, which suggests to me
that the connection is opened and remains open.  I'd prefer an arrangement
where a connection was made each time a transaction sequence was initiated
by traffic on the local, incoming, 3129 port (in my example), and then
closed when traffic stopped.


[...] With the fact that socat is pretty much the
universal patch cable, you are expecting too much here.
It seems you are looking for a protocol aware proxy.


Not wanting the proxy be protocol-aware, but considering what 'states' the proxy, and the destination-server, might remain in for extended periods of time. Just keeping in mind resource consumption and potential for congestion, so that performance issues don't turn out to compromise what - really - looks to be a promising solution.

In the meantime, between posts, I have done some testing and, because I could not find much comment about this aspect, I'd like to share here what I found.

I altered the command to log to a file in /var/log, and to log more details (options -d -d -d), including the 'connection' open and close, and the traffic sequences.

For tests, I used telnet on a source machine on this subnet, and socat on a proxy server to reach an smtp server we have at another site; I only passed the

EHLO,
HELP, and
QUIT

commands, because I did not want to falsely trigger the intrusion detection systems on the server. But those few commands served to reveal what socat was doing.

The socat command I used was

$ socat -d -d -d -lf /var/log/socat \ TCP4-LISTEN:3129,su=nobody,fork,range=192.168.0.0/24,reuseaddr \ TCP4:server.ourdomain.tld:4444

Here's what I found.

1. socat stopped right away; the log showed that socat could not create its child processes. I wondered whether this might be because socat needed to run as root. su, and then # socat started ok.

2. socat did not 'detach' from the keyboard session, so the screen remained with a blank line and no shell prompt. [This means that if I invoke a solution this way, I will have to have a session running all the time that I want socat to run.]

3.  Running telnet from a different test machine:
$ telnet 192.168.0.123 3129
resulted in:
220 server.ourdomain.tld ESMTP Exim Tue .........
and the simple transaction sequence followed, ending with
quit
221 server.ourdomain.tld closing connection
$
So the proxying worked fine.  But what did socat do, itself?

4.  On the proxy machine, /var/log/socat showed

a.  socat set itself up, listening on (in our test) 3129;
- no child processes at this point, and
- *no* outbound connection to server.ourdomain.tld - yet

b. A few seconds or so later, socat 'accepted connection' from the telnet test machine, and
- forked a child process, while
- remaining listening for any other connection from the acceptable range of IP addresses

c.  Meanwhile, the child process
- 'opened' a connection to server.ourdomain.tld:4444, and
- bridged that channel to the input channel from telnet machine, and
- transferred 88 bytes (the Exim 220 welcome message)
- There followed the short transaction exchange, then finally socat
- sensed 'EOF' on both sides and shut down transmission for both sides
- and the child process exited

5.  socat master process
- was (and is) still running
- and went on to pass additional test sequences from a variety of machines

6.  I can close socat using ^C

Henning, for a universal patch cable, it's pretty good, and seems to work sensibly in terms of resources, too, releasing connections and processes as they reach a quiescent state.

A useful suggestion; much appreciated.

regards, Ron


Reply to: