3 ms·
A good friend of mine is currently in a project that has quite the remote setup: 1. RDP to the consultancy's HQ. 2. From within that environment RDP to the cl
by Tade0 3y ago
A good friend of mine is currently in a project that has quite the remote setup:
1. RDP to the consultancy's HQ.
2. From within that environment RDP to the client's machines.
All via VPN, going across the Atlantic at one point. You can't have a metting because every 10 minutes or so some part of this chain breaks and you have to reconnect.
Needless to say it's not easy to get anything done this way, so the project is already delayed and losing money.
The hilarious part is that his rate is now somewhat higher than mine, but I would have to be in a precarious financial situation to join that project(in reaction to this situation management... started looking into expanding the team).
- mr_mitm 3y agoI can top that: For one of our customers we have to 1. Enter a Windows VM on our native Linux Laptop to use the Citrix client 2. Use the Citrix client to access customer's terminal server 3. Use RDP to access a special Windows laptop 4. Enter a Linux VM on the Windows laptop Coming back from lunch I have to enter credentials four separate times to unlock everything.
- Tade0 3y agoAt this level I suspect it disconnects when you look at it funny. Hope the rate makes it worth it.
- jwestbury 3y agoYears ago, I worked in support at AWS. Because of the rather peculiar way AWS accounts are linked, any company with access to AWS GovCloud had all of their accounts flagged as GovCloud accounts -- and all of their support requests were routed to my team, a team full of US citizens (most of whom either had security clearance or were pursuing it - but that's another story). Anyway, this meant we got a really, uh, interesting collection of customer support requests -- and, more important, architectures. My favorite is what I decided to dub "the InterNAT." The InterNAT involved a VPC subnet which had its routing rules configured to route all traffic via an EC2 NAT instance (these were the days before NAT gateway). All well and good... except that this VPC also had a VPN configured, which routed their traffic to an EC2 instance in a VPC in another of their accounts. That EC2 instance then routed the connections out of a NAT instance in its own VPC, before eventually connections reached the Internet. What's especially interesting about this is that EC2's network stack is designed to detect and mitigate tromboning[0], but by creating this particular architecture, they had unwittingly managed to bypass those protections. So, not only were they routing through multiple NAT instances across multiple VPCs just to reach the Internet, but they were managing to route outside of the EC2 network fabric in the process, substantially increasing network latency. Coda: Our bathrooms in the support office in Seattle had stark white walls in the stalls, which actually worked okay as whiteboards. People would doodle while taking a shit. So, of course, I diagrammed the InterNAT in a stall a few days after discovering it. Probably two years later, I saw a picture of it pop up in my Facebook feed, and had to cop to having drawn it. Bonus: My second-favorite story (albeit much shorter) was the curious case of SSL onloading. You may have heard of SSL offloading -- using a reverse proxy or load balancer to handle SSL termination, rather than doing it on-host, in order to save resources on your actual webservers. Well, I had a customer -- also in the (in)famous GovCloud queue -- who had decided to implement the reverse. Plaintext HTTP into the load balancer, but HTTPS into the webserver. I guess this is trying to protect against the case where the call is coming from inside the house? 0. https://www.catonetworks.com/blog/the-sound-of-the-trombone/ https://www.catonetworks.com/blog/the-sound-of-the-trombone/