Here is the spec of tunneling http://muffin.doit.org/docs/rfc/tunneling_ssl.html On Wed, Feb 25, 2015 at 6:04 PM, Garrett D'Amore <garrett@xxxxxxxxxx> wrote: > 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. >> > > -- 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.