Best way to maintain some remote control but not absolute?
-
@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.
-
@Dashrender said in Best way to maintain some remote control but not absolute?:
@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.
At some point in the escalation process, the physical visit will be necessary.
Usually this is me asking them to look at their router and cable modem for the lights, tell them to call the ISP.
Check for lights on the server. Lights on the NIC port, etc.Sometimes I'll have a savvy person ping stuff for me.
