On Tuesday 21 August 2007 04:47:41 pm Kenny Dail wrote:
> > On Friday 17 August 2007 04:46:24 pm you wrote:
> > > > where x.x.x.227 is client's external NIC address, x.x.x.136 is bacula
> > > > server's external address; 192.168.0.{253,200} are the corresponding
> > > > private addresses. As you can see, while fd daemon on client has
> > > > indeed been bound to the private address, it still uses external one
> > > > for communicating with sd daemon on the remote bacula server. I've
> > > > been through all configuration options to no avail. Unfortunately,
> > > > binding sd on the server to private net only is not an option since
> > > > it also has numerous other clients configured, that are only
> > > > accessible via external net (desktop boxes all around the building,
> > > > etc). Is there any solution? I am running bacula 1.36.1.
> > >
> > > The FD is told to connect to the "Address" from the Director's Storage
> > > resource, so maybe you can set that to something that resolves to the
> > > internal network on the dual-NIC clients?
> >
> > AFAIK, in this case SD will always attempt to connect via internal
> > network upon request from any clients and that won't work for (the
> > majority of) my clients that are on external network. I am assuming there
> > is no way to specify multiple aliases for the same Storage resource in
> > bacula-dir.conf, but with different Addresses. Anyway, such setting
> > clearly belongs to client's configuration, so I consider it a bug. FD
> > should ensure that all of its communications with other daemons go
> > exclusively through the network address specified in its conf file (if
> > any). But I have no clue how to implement this since current bacula
> > networking model obviously contradicts.
>
> I use the client's hosts file to take care of directing the client to
> the right address.This does not work for SD. There is no way to tell file client on which host SD resides. There is no such configuration option for FD. It gets this information from director and I can't configure director and SD on the server to only listen on internal interface because the majority of clients are on external network and they won't be able to reach SD in that case. If you think it works for you then grab tcpdump and check for yourself - it does not. FD indeed will connect via configured interface but then it will also connect to SD on whatever hostname/interface *SD* has in its configuration file and will proceed sending all file data and attributes via this interface, not the first one. Only commands exchange protocol between FD and the director will be carried over the FD-configured interface. The only way to prevent this behavior as I see it is to add static routes on both internal network client and DIR/SD server to route all traffic to/from external interface to internal one transparently for bacula services. For this to work I would also need to enable routing on both machines and reconfigure firewall on DIR/SD server. Not an elegant solution by any means... --Ivan The information transmitted in this electronic communication is intended only for the person or entity to whom it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this information in error, please contact the Compliance HelpLine at 800-856-1983 and properly dispose of this information. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
