ProSoundWeb Community

Please login or register.

Login with username, password and session length
Advanced search  

Pages: 1 2 3 [4]   Go Down

Author Topic: Connecting CL/QL Editor to Console over the internet  (Read 1480 times)

Andrien (No Last Name)

  • Jr. Member
  • **
  • Offline Offline
  • Posts: 84
Re: Connecting CL/QL Editor to Console over the internet
« Reply #30 on: July 15, 2020, 01:22:26 am »

I plan of remoting to an SQ system with VPN, doesn't seems as hard with ready made solution like OpenWRT or PFSense. One thing to note in tunneling is that many doesn't support Multicast packet which are used to transmit metering data I think, so on OpenVPN you might need the Tap adapter mode for multicast. I do trial run on Wireguard but it seems they do not transmit Multicast packet too. This solution assume you have public facing IP address (could try IPv6 if both your remote and local site support IPv6).
I do use AnyDesk for remoting, not as slick as Teamviewer but hell easier with upgrade path. There is one RDP who used to be on stand alone install and using perpetual license but generally most RDP are SaaS/Subscription based. Windows 10 pro also have built in RDP that can be linked to your Microsoft account I think, and afaik doesn't cost anything.
I will try Wireguard network on one of the church site I volunteer to help, and see if I could use the console editor remotely. They do have TF series  board and should be similar to CL/QL I think.
Logged

Russell Ault

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 667
  • Edmonton, AB
Re: Connecting CL/QL Editor to Console over the internet
« Reply #31 on: July 15, 2020, 01:40:29 am »

Thanks, Russ. Just looking for solutions for folks behind a firewall that can't open ports directly. There's only 1 port needed, BTW.

NGrok works, but it seems like it's just SSH port forwarding or something. Still don't really know exactly what's going on behind the scenes.
I found this, but it's definitely over my head ATM!

A quick read suggests that your link is on the right track, but in my mind it goes both too far and not far enough.

First, you'll need a computer somewhere on the Internet that you can forward the port to. Traffic forwarding doesn't tend to be super resource-intensive (even with ssh's cryptographic overhead), so a cheap VPS/container (etc.) of some kind will do the trick. If you already have a VPS somewhere doing something else (and not using the port you'd like to forward to) you should be able to glom this onto that. (If it is already using the port you want to forward to there may still be options depending on what you're trying to achieve and how much fun you're willing to have.) Just remember that whatever service provider you're using for this computer will have access to every forwarded packet, so chose wisely (and use TLS for everything).

On this VPS/container you'll need to configure sshd to allow its tunnelled ports to be gatewayed (most VPSs will have sshd gatewaying disabled by default). Next, create a new user that you'll use for just ssh tunnelling connections. This user should not have sudo access and no shell access (typically by setting shell to /usr/sbin/nologin). Make sure this user (well, all users on remotely-accessible computers, really) have strong passwords (if you can remember it, it's probably not strong enough).

On the local server you want to forward the port from, use an ssh client to connect to your remote computer as the tunnelling user you just created with the remote forwarding option set (typically -R). Note that the port on your local server that you're forwarding from and the port on the remote computer that you're forwarding to do not have to be the same. If the forwarded port number you want on the remote computer is greater than 1023, then you're in business.

If the forwarded port number you want on the remote computer is 1023 or less, forwarding will fail (most *nix operating systems don't allow non-root users to bind ports 1023 or lower, the so-called "well-known ports", for security reasons, and sshd prohibits it outright unless you're the root user). In this case (as in the case of the link you posted), you'll have to do an extra step.

First, pick a port number between 49152 and 65535. On the remote computer, setup a mechanism where all traffic to and from the well-known port you wish to use is redirected to the port number you just picked. There are a couple ways to do this: iptables (or whatever firewall is installed) is probably the easiest, but haproxy in TCP mode should do the trick as well (there are likely others, too). Then do the ssh connection as above, using the port number you picked as the remote port.

(In the link you posted they setup nginx to do the redirecting as a TLS termination proxy. This, in my mind, is a bad idea. Terminating TLS on the remote computer gives plaintext access to whoever is providing that computer, which is never a good idea in my books. It's better to forward the traffic encrypted and handle TLS termination on your local server. It also makes setting up the forwarding computer that much simpler (although acquiring a LetsEncrypt cert will be harder through the forward port, which is probably why the did it that way).)

For some additional security (and, more importantly, ease of scriptability) you can configure ssh to use certificates instead of passwords, but it's not necessary just to get yourself up and running. Creating some kind of script to manage the ssh connection (i.e. automatically restoring it if it breaks for whatever reason) will probably make your life easier in the long run.

[...]
I do use AnyDesk for remoting, not as slick as Teamviewer but hell easier with upgrade path. There is one RDP who used to be on stand alone install and using perpetual license but generally most RDP are SaaS/Subscription based. Windows 10 pro also have built in RDP that can be linked to your Microsoft account I think, and afaik doesn't cost anything.
[...]

RDP (i.e. the one built into Windows Pro) itself is great. Securing RDP over the Internet, though, is less so. Just like VLC, you will definitely want to be using some kind of outside encryption for RDP access (please, for the love of god, do not ever leave port 3389 open to the public Internet; just don't). SSH tunnelling is good, stunnel is good, VPN is good, RDGateway (if you have it) is very good (but not cheap!).

Also, depending on what you're trying to achieve, be aware that RDP tends to have some quirks. Unlike VLC (where you are effectively remote controlling the computer as it currently exists), RDP tends to assume that you want to use the remote computer as if it was actually sitting next to you. This means it switches its audio and video devices (etc.) to be those of the physical computer you're connecting from. This is great for working remotely, but terribly for remotely controlling a recording computer ("hey, where did my audio interface go" is literally a question I've asked myself when trying to remotely hit the record button over RDP at the top of show; some mistakes you only make once).

-Russ
Logged

Andrew Broughton

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 1722
    • Check Check One Two
Re: Connecting CL/QL Editor to Console over the internet
« Reply #32 on: July 15, 2020, 02:03:10 am »

Thanks, Russ.
I'm afraid though most of the stuff you're talking about is well over my head, so likely until I understand this better, or find someone who can help me build this, I'll have to use one of the free tools and keep testing.
The initial tests of control over the 'net are promising, and if things go well, I'll post back with more info.

If anyone his interested in this, has a CL or QL and some free time, I could always use more guinea pigs!
Contact me at my sig.
Logged
-Andy

"Well, my days of not taking you seriously are certainly coming to a middle..."

http://www.checkcheckonetwo.com
Saving lives through Digital Audio, Programming and Electronics.

Scott Holtzman

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 6002
  • Ghost AV - Avon Lake, OH
    • Ghost Audio Visual Systems, LLC
Re: Connecting CL/QL Editor to Console over the internet
« Reply #33 on: July 16, 2020, 02:32:24 am »

Why no love for teamviewer? We have a VM running on our server in our warehouse which is connected to the Cl3, Axient D's and Freespeak2. This allows me access from home. Even though I only live 20-30mins from the warehouse. Not relying on it for a show but seems to be a stable usable setup.

Will definitely keep following this thread as I'm sure going forward this sort of setup might get a lot more use


The key reason is he needs IP access between the two sites.


VPN's are more secure.  Software sitting in the presentation layer running in user space isn't very secure or stable. 
Logged
Scott AKA "Skyking" Holtzman

Ghost Audio Visual Solutions, LLC
Cleveland OH
www.ghostav.rocks

ProSoundWeb Community

Re: Connecting CL/QL Editor to Console over the internet
« Reply #33 on: July 16, 2020, 02:32:24 am »


Pages: 1 2 3 [4]   Go Up
 



Page created in 0.031 seconds with 22 queries.