The first quarter of 2020 changed our personal and professional life in a lot of ways. I’ve read a lot of articles around the trends of adoption of cloud services and all software that should facilitate the challenge of enabling in every country the same practices and processes of working remotely.
During the last couple of months, I’ve received from small-medium businesses owners and IT professionals the same question how to transition smoothly and quickly. Working in the operations field for mid-large organisations it required me to step back from the most obvious and structured approaches and be more flexible and down-to-earth.
Medium-large organisations have embraced working remotely and designed or adapted quickly thanks to a set of the feature-rich solution implemented a long time ago, once the option paralysis of choosing a vendor/partner was gone away.
Thinking at Small-Business Scale
Understanding the requirements is always key to suggest a solution that it isn’t just fit for purpose, but it is also fit for use.
I will not consider the most strange needs that some clients have but I will focus on the most popular scenario which was hybrid IT services similar to this one:
- Under 5-10 users
- Important software installed on shared workstations (running windows professional edition – so with the option of RDP if needed).
- Less than 2-3 Servers
- Small usage of cloud (public or private) for external SaaS (Mail, Websites, Transactional SMS, VoIP Services, etc..).
- Consumer/ Small business-grade internet connection ( w/ or w/o a public static IP).
The requests were always on minimising the capital expenditure because the impact on their business is already terribly strong and the wanted to react quickly.
I’ve the added to this list couple of more:
- The solution must be at least aligned (or higher) with the level of the security of the existing IT services.
- The business in general must be capable of self-supporting and understanding the solution (for keeping costs under control and reverting if needed).
VDI (Virtual Desktop Infrastructure)
Most of the VDI applications from Microsoft, Citrix, VMWare were listed but was not the suggested solution (except for one case) because each one required quite a big effort and resources to be implemented properly.
Migration to Cloud Services
Backup and DR applications frequently offer the solution of restoring/replicating services in the cloud (the usual gateway-drug), even if that was applicable in some cases this strategy of migration (it’s basically a lift-and-shift in disguise) wasn’t the favourite choice for most of the businesses.
Migration to SAAS offering was suggested but the analysis of mapping all the dependencies in the workflow of some business required a deeper knowledge and was left for a next and future step.
VPN (Virtual Private Network)
There different flavours of VPN in some cases business owners were already familiar with this technology.
To explain what the VPN is and works in layman’s terms I usually described it as a way of extending private networks over the internet I split into 2 main categories “permanent” (site-to-site VPN) and “ad-hoc” (SSL-VPN).
Permanent VPNs (site-to-site) require devices/appliances, configuration and efforts that were always out of scope.
Ad-Hoc VPN (SSL VPNS) was suggested and we started the design and implementation steps required and I gave some advice suggesting, for instance, OpenVPN. that I’ve used and I’m familiar with.
Microsoft Auto-VPN/Always-On VPN requirements were not met (Active Directory Domain Services and Active Directory Certificate Services) and required more steps to be implemented.
Remote Support / Access
Nowadays the choice of remote support/access is endless, but I’ve shortlisted few here and I must admit that the majority of users were happy with one of these because it’s easy to implement it even as a band-aid.
This is a list in alphabetical order:
- AnyDesk
- Chrome Remote Desktop
- Connectwise Control
- DWService
- Hamachi (it’s more a VPN than a Remote support app but for the user experience/perspective is like remote desktop support)
- LogMeIn
- TeamViewer
- VNC (any implementation or flavour of it).
Are there other ways?
Where there is a will there is a way.
A SSH server can be used to create a tunnel (even a reverse-tunnel if there are no Linux boxes on the network) to expose in a VPN-like manner some ports used by your application on workstation or servers.
Poor Man’s VPN – SSH Tunnel with Port-Forwarding
Using an SSH server to tunnel access ports that are not exposed to the internet is not a new concept or something that I’ve discovered today.
I remember that I’ve read it on a Linux magazine nearly 20 years ago in a quick how-to guide to access a database server (not directly exposed to the internet) from an ssh connection to the webserver at the time of the dot-com boom.
Without digressing any further I’ve created a script to use the feature of SSH port forwarding, to tunnel the RDP Traffic which wasn’t exposed by the firewall.
Once the SSH Server is installed, configured to allow port-forwarding and exposed to the internet (via port forwarding) on the router/gateway. You can create even a single local user account on the Linux-box, but it would better to have individual accounts.
I’ve created a Powershell script for each user on their local workstation to start the tunnel to their remote workplace and then connect via RPD or the protocol they need.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 |
# Paolo Frigo, https://www.scriptinglibrary.com # This scripts creates connect a local port to a remote port via an SSH tunnel # SCENARIO: POOR-MAN'S VPN # # HOST1 on NETWORKA wants to connect to HOST2 on NETWORKB, # HOST2 is not exposed to the internet and there are not port-forwarding configured # if there is an internet facing ssh server let's call it JUMPBOX available in # the networkB that box can be used to tunnel the connection. # SETTINGS # ----------------------------------------------------------------------------------- #Local port $LocalPort = "12345" # HOST1 can be on 10.1.2.4/24 NETWORKA #Target box $TargetBox = "192.168.1.94" # HOST2 $TargetPort = "3389" # RDP #SSH Server #JUMPBOX $Username = "PaoloF" $MyLinuxBox = "mylinuxbox.fqdn-or-Public-IP" $RemotePortForSSH = "22" # DEPENDENCY CHECK # ----------------------------------------------------------------------------------- # This script requires PLINK, if is not present will be downloaded try{ $plinktest = Invoke-expression "plink.exe" } catch{ Write-Warning "PLINK DEPENDENCY IS MISSING. Downloading the latest version of PLINK.." Invoke-WebRequest "https://the.earth.li/~sgtatham/putty/latest/w64/plink.exe" -o "plink.exe" If(Test-Path "plink.exe"){ Write-Output "Download completed!" } } Write-Output "CREATING THE SSH TUNNEL USING PORT-FW" invoke-expression "plink.exe -P $($RemotePortForSSH) -L $($LocalPort):$($TargetBox):$($TargetPort) $($Username)@$($MyLinuxBox)" |
The script requires to change the configuration parameters for your needs and will use PLINK to connect via SSH and start the tunnel. As usual, you can find all code examples in my Github repo.
I hope you’ve found this article useful, happy remote working and stay safe!