Don't get me wrong, it's kinda cool, but it seems like a really bad idea to actually do it.
Conservation of the port number space is required because this space is a limited resource, so applications are expected to participate in the traffic demultiplexing process where feasible. The port numbers are expected to encode as little information as possible that will still enable an application to perform further demultiplexing by itself. [...] IANA strives to assign only one assigned port number per service or application.
Why do I know this? Consul by default uses 5-6 ports, and one of them conflicts with an IETF registered port in-use by our data center provider. Was hoping that the RFCs gave some ammo for a resolution in my favor, came out more humble and wondering if Consul really needed that many ports.
Some of it understandable, e.g. when one port is for stuff that is always meant to stay behind your firewall, and another for public access. In that case it actually makes things easier to do properly. But so often it appears to be entirely gratuitous.
There are use cases - many nefarious cases but some real world cases.
Let's say your university allows everything through 80 but blocks everything else. You could SSH home or stream content.
Another use case could be that you have a web site and game server on same server. An interesting implementation could be to listen on port 80 so that they could connect to yourserver.com via HTTP and view information about the game/server and connect on the same port. Interesting but not very practical.
I suppose an acceptable/respectable use case would be custom load balancers or honey pots.
This advantages of serve2 is that it is 100% go and can be integrated and used without any extra dependencies or multi-setup :)
To me, an advantage in usability is having a PPA with properly built .deb packages. If I have to use a language-specific package manager that I don't already use regularly, you've likely lost me, unless I really need this functionality. If it doesn't come with a proper daemon mode (correct forking, PID file support, proper file or syslog logging), sample config file, man page, or an init file, that's even worse. I am much less likely to use this in any type of "production" environment if I have to maintain those pieces myself. Running things in a screen session is so "I'm running a Minecraft server".
That is not to criticize your work. You've done a great job! serve2d looks very interesting and I might actually have to give it a try sometime.
Great! This seems to be a very good Selling Point for go!
If anyone's interested, Corkscrew is an alternative solution, allows you to disguise SSH as HTTP/HTTPS traffic, useful for getting through restrictive firewalls to administer remote machines:
I do think serve2d is considerably more flexible than Corkscrew, though, being able to tunnel anything over TLS if needed. Or other transports, if more are added. I also let you use the same ports for other things.
In the end we modified our clients to include a decoy cipher suite in the SSL negotiation. That kept the network happy, and was enough for our multiplexer to then internally route to the correct backend.
You can get the SSH client to connect over this either by using an openssl s_client trick, or by just using my little tunnel tool (https://github.com/joushou/tunnel).
Postgres (which I would recommend over MySQL any day) seems to have a saner client-initiated protocol. I only read part of the spec, but I'll try to see what pattern would need matching later today.
frontend mux
mode tcp
bind EXTERNAL_IP_HERE:443
acl is_tls req.ssl_ver gt 3
acl is_ssh payload(0,8) -m str SSH-2.0-
tcp-request inspect-delay 5s
tcp-request content accept if is_ssh
tcp-request content accept if is_tls
use_backend ssh if is_ssh
use_backend https if is_tls
First of all, I'd like to thank my wife, who helped motivate me, my parents, who you know, did the thing that brought me here, my work, for paying me to browse news and occasionally code...
So, why Go? Because it was easiest that way. Try to take a look at how simple the ProxyConn thing is, which is the core of the entire thing. Go is a tool that I found suitable for the task. It also brings things like easy cross-compilation after the code has been written (Seriously, GOOS=windows go build on my mac and I get a PE32+, GOOS=darwin go build on my linux desktop and I get a Mach-O binary). You also get to interact easily with the wonderful Go infrastructure, in case you don't want to redirect to external services.
Why make something that already exists? Well, I didn't know that there were so many solutions, I just thought "Hmm, I wonder if I can make this work in a nice fashion...". That's not going to stop me from continuing development of my own, however. I have ideas I want to try, features I want to implement. It's powering everything on my own servers, and the stealthiness of SSH over TLS (NOT just SSH on port 443) have been (ab)used multiple times already.
Is my solution better than the others? Well, I of course like my own solution, but with few exceptions, I think I bring some interesting flexibility to the game. A lot fo solutions seem to be fixed for a certain purpose, such as SSH and HTTPS, usually just in their regular variants. I don't really care what you want to serve, as long as you can write down some unique bytes in the config for serve2d, or write a more complicated handler directly for serve2. Add transports if you want. Want SSH over TLS over WebSocket over IP over avian carriers? Add the transports.
I'm going to sleep now, and I hope the world haven't self-ignited before I wake up. It's really exciting and motivating to see how people react to private projects.