You're in charge of a decent-sized, multi-year project. You've been using a hosted ticketing- and documentation-service to manage the work and documentation for that work. Eighteen months ago, you received notice that the hoster is discontinuing their offering and that you need to be off their service by 2022-08-01 (when it goes into a read-only mode for thirty days before finally being offlined). Do you immediately start planning your move …or do you wait till July of 2022 to start trying to move everyone off?
I think you know where I'm going with this, but, "wait: there's more!"
Middle of last week, project's management-team sent out a request asking us to test their IP whitelisting solution. They had selected a new hosted ticketing- and documentation-system. However for security reasons, they didn't want it to be attackable from random people on the internet. Therefore, to access their new, hosted service, they needed to whitelist everybody. Obviously, whitelisting a primarily-remote workforce of several dozen people would be an unwieldy IP-list to maintain – especially when someone's IP changed due to, say, a power outage. So, they decided to whitelist the IP address of a bastion-host we'd set up for SSH-based tunneling into their networks. However, they didn't understand that our already whitelisted host was strictly for SSH tunneling and not a full-fledged VPN solution. They'd been told that in 2019 but never really bothered to understand the difference. This meant that they didn't understand why it wasn't really meant to be an HTTP proxy. Yes, we tunnel HTTP through it, but the whitelisted host is the first passthrough-hop in a multi-hop tunnel. The proxied HTTP content was all hosted in network-space that was topologically part of the same network-space that the egress-node of the multi-hop SSH-tunnel was in. Setting up the first-hop tunnel-host as a direct HTTP proxy would mean needing to set up a tunneled-proxy on that first-hop host …and a corresponding new browser session so it could be configured to use that new proxy-endpoint. All for for one URL.
Yesterday, they got one of the networks we tunnel to whitelisted. However, only sometimes does the login URL respond before timing out. And, when it does, the login service doesn't reliably recognize our 2FA tokens (and thus far, when I've actually been able to connect, has never recognized my token).
I reported these problems as I encountered them, but their response has been utter nonchalance, even when I reminded them "your current ticketing system dies at 0000 Monday".
