Used this tutorial to setup SSH over the HTTPS to my raspPi.
Worked well, I thought I could cheekily reuse the solution to tunnel VNC over 80.
The tutorial basically breaks down to 3 simple steps (and I think I'm understanding this right, but i'm not a Network Engineering professional).
1) This tutorial wants to avoid port forwarding.
2) Wetty is used to run a 'web server' on a random port that serves an SSH terminal.
3) Beame is used to effectively provide a 'DynamicDNS' type behaviour with SSL for free. ( I believe this is achieved by running the beame-insta-sslapplication on Raspbian, which I guess connects to Beame with the generated Cert and reports your IP... then when any data hits the Beame URL it gets forwarded to the IP of my Raspberry Pi where the beame-insta-sslapplication is listening on 80 and redirects to whatever port Wetty is running on, guess 80 is always open??)
Anyway, it works! I then wanted to 'upgrade' from plain old SSH to VNC, so my thinking was...
1) Have VNC server running on port 5901 (functionally similar to Wetty, just a service on a port).
2) Redirect traffic received on 80 to 5901 with Beame (rather than to the Wetty port).
3) When trying to use the solution direct my remote VNC client to the Beame hostname on port 80, hoping the magic would take place and all would work!
Unfortunately it just times out, what am I doing wrong here? I thought about port forwarding but I didn't need this to connect to Wetty running on a random port, no different to how VNC server is running as a service on a random port, so I shouldn't have to do this.
I also made sure to VNC to port 80 (understanding the redirect would be there), still not working.
If you're wondering why I need to do all of this over 80 its because i'm behind a very restricted network regarding outbound ports.
Any ideas? Thanks
Woodstock
答案1
What beame-insta-ssl does is establish a “reverse” tunnel. It connects (outbound) to a tunnel broker. This connection is then used to transfer all data. It’s very similar to a SSH RemoteForward. It is also very different from a DDNS service, because it does not require changing router or (inbound) firewall settings.
Then, to the most important point: The tunnel broker will only listen on port 443. The next important point: It is exclusively made for HTTP(S). It uses the http-proxy Node module. It does not deal with generic TCP connections or anything else.
tl;dr: Won’t work.
The tutorial does not set up “SSH over HTTPS”. You’re not talking to SSH (directly) but to wetty, which comes with an integrated HTTP server. That’s why it works.
However, you can use a real DDNS service, stunnel (on both server and client) and appropriate port forwarding to create a TLS-secured VNC server. It could also listen on port 443, making it possible to connect via HTTP proxies and/or through restrictive firewalls.
Alternatively, you could look into Guacamole, which provides “HTML5 SSH/VNC”. It’s a lot like wetty but also does VNC and file transfers over SFTP. Hosting it is very simple using Docker. It would also require DDNS and port forwarding.
If you can’t set up port forwards, host services or do not have a public IPv4 address (due to CGNAT, DS-Lite, whatever) you could look into a VPN service that allows hosting services or rent a VPS to play tunnel broker yourself.