Best way to maintain some remote control but not absolute?
-
@Dashrender said in Best way to maintain some remote control but not absolute?:
SC to control Windows PCs and windows server VMs
ZT to manage XO to manage XSIf you are using a VPN you presumably always have a dedicated machine for that client. So you just.... open a web browser. That's it. Nothing more to it. It's always there, always ready to go. No SC, no PC, no Windows, no hops.
-
Where did VPN come into the discussion?
-
Remote Utilities allows use up to 10 clients including business for free. Chances are good I'll hook that up to the server. From there I suppose I could RDP to workstations.
Doesn't take care of using XO though. Maybe I would hook up RU to one workstation as well just in case. Otherwise I could access XO from the server VM, assuming it isn't down. If it is down, then I could get to the workstation instead and try to access XO. If that doesn't work, something is up with the hardware or network. -
@Dashrender said in Best way to maintain some remote control but not absolute?:
Where did VPN come into the discussion?
ZeroTier
-
So if you don't want to use ZT here's what I would do (and currently do when not using ZT). Set up a jump box and use dynamic tunnels for your access (or local tunnels but you need to know the ports ahead of time).
For the dynamic tunnels you can use:
ssh -D 1080 user@hostThis turn your SSH client into a SOCKS proxy. You can tell your browser to use a SOCKS proxy on port 1080 (default port) and just browse to the normal addresses on the remote network.
If you want to use local tunneling then you need:
ssh -L <localport>:<remoteip>:<remoteport> user@hostUse as many -L arguments as you need. You can also do both together.
This will give you access to anything you need, fully encrypted. RDP is possible with Remmina or the Remote Desktop Viewer application, along with VNC, SPICE, NX, and others.
-
@Dashrender said in Best way to maintain some remote control but not absolute?:
Where did VPN come into the discussion?
I was answering your questions about the ZT VPN...
-
For a kind of the out of the box thinking setup, you could just make a Guacamole VM and add all the remote hosts to it. Then just:
ssh -L <localport>:<remoteIP>:80 user@guacamolehostThen just open your browser to localhost:<localport> and have full access.
-
@scottalanmiller said in Best way to maintain some remote control but not absolute?:
@Dashrender said in Best way to maintain some remote control but not absolute?:
Where did VPN come into the discussion?
I was answering your questions about the ZT VPN...
Aww gotcha. ZT is definitely cool tech, but the inherent DNS issues make it a challenge. And unless you install ZT on all devices, you don't really have VPN to their network, only to those devices.
-
@Dashrender said in Best way to maintain some remote control but not absolute?:
Aww gotcha. ZT is definitely cool tech, but the inherent DNS issues make it a challenge. And unless you install ZT on all devices, you don't really have VPN to their network, only to those devices.
Just like any VPN.
-
Having a VPN from my workstation to a web server does not grant me access to the whole network like a traditional VPN does.
-
@Dashrender said in Best way to maintain some remote control but not absolute?:
Having a VPN from my workstation to a web server does not grant me access to the whole network like a traditional VPN does.
What do you mean "traditional" VPN? A traditional VPN gives you access to what you set it to, point to point, point to multipoint, multipoint to multipoint. A traditional VPN does both. If you put PPTP, L2TP, SSL, OpenVPN or IPSec from your workstation to the web server, you do not get full network access, yet those are all as traditional as VPNs get. In fact, you use HTTPS every day, which is an SSL VPN that doens't give any extra access.
-
@scottalanmiller said in Best way to maintain some remote control but not absolute?:
@Dashrender said in Best way to maintain some remote control but not absolute?:
Having a VPN from my workstation to a web server does not grant me access to the whole network like a traditional VPN does.
What do you mean "traditional" VPN? A traditional VPN gives you access to what you set it to, point to point, point to multipoint, multipoint to multipoint. A traditional VPN does both. If you put PPTP, L2TP, SSL, OpenVPN or IPSec from your workstation to the web server, you do not get full network access, yet those are all as traditional as VPNs get. In fact, you use HTTPS every day, which is an SSL VPN that doens't give any extra access.
Sure, but I know almost no one that VPNs into a single resource like that. Now I know that you and NTG are using a ton of Jump boxes to do this type of thing, but most SMBs (is is mainly an SMB forum, right?) do point to point or user to point on network full type access. This is what I mean by traditional VPN.
-
@Dashrender said in Best way to maintain some remote control but not absolute?:
Sure, but I know almost no one that VPNs into a single resource like that.
But that doesn't mean that it's not traditional (that's how it was done the most long ago) and it's still how 99.99% of VPNs are used (HTTPS, SSH are both VPNs that are almost always point to point and make up essentially all VPN traffic).
-
@Dashrender said in Best way to maintain some remote control but not absolute?:
Now I know that you and NTG are using a ton of Jump boxes to do this type of thing,
Jump boxes are not VPNs, though.
-
@Dashrender said in Best way to maintain some remote control but not absolute?:
but most SMBs (is is mainly an SMB forum, right?) do point to point or user to point on network full type access. This is what I mean by traditional VPN.
I would not call that "traditional" VPN. VPNs were point to point from the beginning. Even most all VPNs that you see as point to multipoint are not, they are point to point with the one end point providing a gateway to make it look like the VPN itself is point to multipoint. It's rarely the VPN mechanism doing that.
If you think of VPNs in this way, it will cause confusion as it encourages mentally encumbering VPNs with definitions and limitations that do not exist for them.
-
Do you have a better name for that then?
Oh and I do agree that VPN itself is always a Point to Point, but most implementations I've seen (again only SMB) are point to multipoint type installs (home user VPNing into office to access any/all network resources) or site to site, again all devices on one side can access all on the other.
-
@Dashrender said in Best way to maintain some remote control but not absolute?:
Do you have a better name for that then?
Point to Site or Site to Site are the terms you are looking for.
-
@Dashrender said in Best way to maintain some remote control but not absolute?:
Do you have a better name for that then?
Oh and I do agree that VPN itself is always a Point to Point, but most implementations I've seen (again only SMB) are point to multipoint type installs (home user VPNing into office to access any/all network resources) or site to site, again all devices on one side can access all on the other.
Remember PPTP on Windows? Point to Point was standard.
-
Is there some benefit to all the SSH/VPN/Jumpbox/ZT stuff over simply installing a remote tool on each machine I want to access?
If I just install remote on the VM(s), and one primary workstation, I can access anything I need, whether XO or XC. And from there I can RDP to other internal workstations if needed as well.
To me this seems easiest, barring possible cost of remote tool, but RemoteUtilities can be used in business for free up to 10 clients. My account only has a few so it's an easy button at this point.
I would think the very next easiest method is to go ahead and open up the server to RDP and deal with the dynamic IP issue some other way. As long as the server is functional, I can get in and do anything. But if the server is down, I'd be totally locked out.
The jumpbox or ZT elsewhere in the network would mitigate that one.If all else fails, I can always tell the client to run a Join.me session from somewhere else in the network.
-
@guyinpv said in Best way to maintain some remote control but not absolute?:
If all else fails, I can always tell the client to run a Join.me session from somewhere else in the network.
assuming they can get on the internet when your server is down.
