Occasional blog posts from a random systems engineer
home about posts
24 Apr, 2025 · Read in about 2 min · (227 Words)
History
In my homelab setup, the way services are run are not the simplest of approaches and I often find this bites me - but every challenge is an opening for learning, which is always great (unless I just want something to work).
The challenge I’m talking about today is client identification with NAT outside of HTTP.
What I mean is, in the world of HTTP, load balancers are often used. However, it’s useful to be able to access the connecting client IP (or end-user). The actual packets are obviously from the load-balancer to the server, so we use HTTP headers for forwarding this information.
However, when it comes to other protocols (namely SSH in this case), this is harder.
Applications such as Gitlab (or in my original case, Phabricator), you get a web-service and it bundles together an SSH server, which needs opening up. Given the usualy boundaries that would be put in-front of any sort of SSH server, hosting an intentionally publicly-accessible SSH server immediately makes you want to add some protection, right!
Normally, fail2ban or similar applications are useful - monitor SSH logs and use IPtables to block traffic from IPs with highb amount of failed authentication attempts.
Load balancing SSH
What if we then put this SSH server behind some ‘load balancers’.
In my case, it looked something like:
Three externally accessible VPS
Instagram Engineering
Shopify Engineering