Hi @supafly270 ,
Thank you for contacting Octopus, given the details you’ve supplied, it sounds like what you’re after is indeed a Worker!
Workers allow you to offload Octopus tasks thus freeing up Octopus server resources for other tasks; but they can also act as jump boxes (your point 3); therefore my recommendation would be to read through that Worker documentation I linked to above, as well as this page which goes into more detail on which worker will suit your needs.
Note also that Workers are just tentacles, as the software agent you install is the same, but by virtue of adding the ‘tentacle’ to the Workers screen, Octopus recognises it as a worker rather than a tentacle. And best of all, they do not count towards your total number of deployment targets - so what’s not to like about workers! 
So first setup a new server on the same subnet as the load balancer; then in Octopus, go to Infrastructure > Workers and install the worker suited to your needs on that new server (Windows / Linux / Mac):
(follow any onscreen instructions to get the worker setup in Octopus and also configured on the new server)
Polling workers are for those cases where the subnet doesn’t allow Internet access except for specific servers / devices. In which case you’ll almost certainly need to add an outbound firewall rule for port 10943. Otherwise a listening worker (tentacle) will work fine.
Next, add the new worker to a dedicated load balancer worker pool (more on why the worker pool should be a dedicated pool is discussed below):
Then back in your project, edit the step that runs your load balancer’s config script and select a worker pool for your step’s task to run on.
If you look at the example screenshots below, you’ll see I’m using a worker pool that I named Load balancer worker pool, but of course you’re welcome to use your own naming convention:
Given you need a worker / jump box that is under your control, I’d recommend you stick with Runs directly on a worker (default).
At this point, when the step runs, Octopus will pass the script to that worker pool, and to the worker in the pool, which will then execute it - and configure the load balancer as directed by the script.
In my example, there’s only one worker in the Load balancer worker pool (see the screenshot below) - which is perfectly acceptable; but that doesn’t stop you having more than one worker in a given pool; maybe you want a 2nd worker in the pool for redundancy.
So a caveat to be aware of is that if you do decide to add more workers to that pool, then all subsequent workers added to the Load balancer worker pool, must be on the same subnet as the 1st worker and the load balancer. Otherwise weird things will happen like tasks you expected to be executed on another subnet are instead executed on the load balancer subnet, eeeeck! 
Or to put it another way, I recommend you treat the Load balancer worker pool as a worker pool dedicated to only executing tasks on your load balancer and nothing else!
If you have any questions about workers or need more information, let me know and I’ll be happy to help where I can.
Regards
Mark
Mark Lamprecht
Solutions Architect | St Ives, Cambridgeshire, UK
