Could you establish a site-to-site VPN link from your director's lan to the
remote lan that is currently only accessible from the jump host?

If you're concerned about the remote site having access to the central lan
with director on it, you could vlan tag all packets from remote lan VPN and
pass tagged traffic to director server, forbidding other clients.

If need be, maybe modify the idea so that the central director's server has
a site-to-site VPN link to the remote lan. Maybe more difficult to do if
the director doesn't have a public IP (so maybe the remote VPN server will
have difficulty reaching the director to complete the tunnel?) Also, a
network infrastructure link will be maintained on something that isn't a
piece of core network equipment (director server), hiding the configuration
from network admins.

MAYBE, you could give director access to remote lan via standard VPN (one
way, client initiated, road warrior, whichever term means "not site to site
VPN"). You could run into issues with the VPN connection disconnecting.
Maybe solve those issues by having a runbeforejob script that verifies the
tunnel is up, and if it isn't restarts the VPN connection prior to the
backup starting. However, if there's any instance where the clients would
need to reach out to the director, and if the client initiated VPN proves
to be unstable, you could have an issue. I have no reason to believe that
client initiated VPN is unstable, but I guess it's possible. Also you would
probably need to initiate this connection entirely using command line
tools, which I haven't done but imagine is possible using openvpn or
similar.

I'm sure there might be bacula features that cover these eventualities, but
I'm not a big enough bacula expert to know about them.



Robert Gerber
402-237-8692
r...@craeon.net

On Fri, Dec 15, 2023, 3:59 AM Martin Reissner <mreiss...@wavecon.de> wrote:

> Hello and sorry for the generic subject. My issue is as follows:
>
> I have a centralized director which should be used to backup several
> setups with multiple clients/fds in a cloud environment. In those setups
> there is only one gateway/jumphost with a public ip, the actual
> clients/fds only have an address in an internal subnet and are reachable
> from outside via ssh-proxyjump from the gw/jumphost or via a loadbalancer.
>
> So far the only solutions I have come up with are portforwardings on the
> gw eg. port 19102 gets forwarded to client1 port 9102, 29102 to client2
> 9102 and so on. This works but is kind of tedious with many clients.
>
> I read something about client initiated backups using the tray monitor.
> I will look into that but scheduling backups on the clients/fds takes
> away one of the main advantages of bacula, which is the centralized
> scheduling.
>
> Are there any further options that I might not have found or thought of?
>
>
> _______________________________________________
> Bacula-users mailing list
> Bacula-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bacula-users
>
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Reply via email to