[nanomsg] Re: off topic: traversing http firewalls

  • From: Garrett D'Amore <garrett@xxxxxxxxxx>
  • To: nanomsg@xxxxxxxxxxxxx
  • Date: Wed, 25 Feb 2015 18:04:39 -0500

Well, if you want to tunnel *SP* protocols — just use web socket.  There is a 
robust client in libnanomsg, and a simple server support there as well.  
(Simple, because it doesn’t support multiplexing multiple sockets / servers or 
http itself on the same port.)

*mangos* has a vastly more capable server, allowing you to mix multiple sockets 
(based on different URI paths) or even serve up HTTP or other HTTP based 
protocols, all using the same port 80 (or 443 if you use TLS.   Only mangos can 
do TLS at present, either with web socket or without.)

You could make a mangos device server that does the web socket stuff, but which 
simply forwards traffic to a libnanomsg peer on the inside, if you can’t use Go 
for some reason.  (We do this on a project I’m working on.)

Note that mangos ability to do this sort of thing with web socket is *really* 
new.  I’ve only just begun to explore the capabilities here, but I think this 
is going to permit some very flexible and powerful architectures to be built up 
really quickly.  With mangos on web socket, there is no longer any need for a 
TCP mux server, for example.  And, the web socket code seems to be close to TCP 
in terms of performance from my own testing.

Of course, *none* of this addresses the original question, which was tunneling 
*SSH*, which is *not* SP.

        - Garrett

> On Feb 25, 2015, at 5:56 PM, George Lambert <marchon@xxxxxxxxx> wrote:
> 
> After multiple drafts - here is an explanation of reversing client and
> server roles to eliminate much of the hassle of firewall issues.
> 
> SInce Nanomsg can invert the roles of server and client - you can get
> really clever here
> 
> Here is an example:  Typical TCP Language for Client/Server  Clients
> make requests - servers process requests
> 
> But what it actually means is Servers listen for connections: and
> Clients initiate connections.
> 
> Firewalls typically allow for Outgoing Requests (though sometimes they
> restrict ports)
> Servers listen for connections on a port and reply to connecting hosts.
> 
> With nanomsg you can mix and match the protocol behavior verses the
> connection role.
> 
> The Role of SERVER with NanoMsg - NanoCat in this example  [ means
> listen for connections on port: is initiated with BIND ]
> The Role of CLIENT with NanoCat  [ means connecting to (public) server
> on port: is initiated with CONNECT ]
> 
> Client (Making Request: Connect on port 1234)  --> Server ( Sending
> Reply: Waiting for Requests - Listening on port 1234 )
> 
> A simple SERVER with NanoCat  [BIND means listen for connections on port]
> nanocat --rep --bind tcp://96.126.106.15:1234 --data "Listening As
> Server - behaving as server"  --format ascii
> 
> A simple CLIENT with NanoCat  [CONNECT means listen for connections on port]
> nanocat --req --connect tcp://96.126.106.15:1234 --data "Connecting as
> client - behaving as client" --format ascii
> 
> an example to try of going the other way
> 
> A listening Server can initiate requests on a connection rather than
> process them and wait for a response
> (on connection initiates a Request to the connecting Client and awaits
> a Reply : LISTENING on port 1234)  --> Client ( Accepts a request:
> issues responses - Connecting on port 1234 )
> 
> Typically - you would expect the Server to be making replies (but here
> I have made the client make the reply):
> 
> nanocat --rep --connect tcp://96.126.106.15:1234 --data "client
> behaving as reply provider" --format ascii
> 
> you would also expect the Client to be making requests (but here I
> have made the server make the request):
> 
> nanocat --req --bind tcp://96.126.106.15:1234 --data "Listening As
> Server - as request provider "  --format ascii
> 
> I have temporarily left a server up for you to try it out one one of
> my public servers here: (could go away in time)
> 
> nanocat --rep --connect tcp://96.126.106.15:1234 --data "client
> behaving as reply provider" --format ascii
> 
> 
> 
> 
> On Wed, Feb 25, 2015 at 1:11 PM, Garrett D'Amore <garrett@xxxxxxxxxx> wrote:
>> 
>>> On Feb 25, 2015, at 1:06 PM, Jason E. Aten <j.e.aten@xxxxxxxxx> wrote:
>>> 
>>> Only tangentially related to nanomsg:
>>> 
>>> What do you guys use to go through http-only (port 80) firewalls?
>>> 
>>> I'd like to find a golang library capable of tunneling ssh through an http 
>>> firewall. I'm not worried about https, but strictly http.
>>> 
>>> There must be some library already available/recommended?
>> 
>> Um, SSH itself?  I mean, you can ssh to port 80, and if the far end speaks 
>> SSH, and is listening on port 80, then its all good.
>> 
>> If you want to proxy SSH and *other* things over port 80, you’d have to 
>> invent a protocol to do that (basically passing SSH inside HTTP frames or 
>> handing off a socket — probably making use of WebSocket would be a good idea 
>> and does the latter.  The problem is that websocket has its own message 
>> framing, so you’d have to implement that framing in your client.)
>> 
>> Other methods involve the use of generic VPN clients.  (OpenVPN does this.)
>> 
>>        - Garrett
>> 
>> 
> 
> 
> 
> -- 
> P THINK BEFORE PRINTING: is it really necessary?
> 
> This e-mail and its attachments are confidential and solely for the
> intended addressee(s). Do not share or use them without approval. If
> received in error, contact the sender
> and delete them.
> 


Other related posts: