Bacula-users

Re: [Bacula-users] Daemon listening on two subnets, requires TLS

2009-09-30 09:10:38
Subject: Re: [Bacula-users] Daemon listening on two subnets, requires TLS
From: baculalist AT encambio DOT com
To: bacula-users AT lists.sourceforge DOT net
Date: Wed, 30 Sep 2009 15:07:22 +0200
On mer., sept 30, 2009, Arno LEHMANN wrote:
>30.09.2009 13:38, baculalist AT encambio DOT com wrote:
>> Problem:
>> A single storage daemon listens on 64.12.34.56 AND 192.168.1.2,
>> and provides a certificate (myhost.domain.com corresponding to
>> 64.12.34.56) to incoming connections from directors and file
>> daemons. Incoming connections to 192.168.1.2 fail, because
>> mycert.domain.com only resolves to the first of the two IP
>> addresses. The configuration keyword TLS Require is set to
>> 'yes' (as it should be.)
>
>Definitely challenging :-)
>
Yes, but it shouldn't be. It's safe to assume that people use
Bacula, TLS, and have a host is behind a NAT router. That's not
exotic or challenging in itself.

>> Tested solution:
>> I've tried running two almost identical storage daemons. In this
>> case there are two configuration files, only differening in the
>> listening IP address and having two different certificates. Although
>> this should work, running 'bacula-sd <options> -c second-sd.conf'
>> fails silently and no new bacula-sd process is created.
>
>Have you set a different Name, Working Directory and, most important, 
>a different SDPort in the configuration?
>
Yes, the name 'Storage { Name = myhost(int|ext)-sd' is different.

Making a new working directory for each instance of a running daemon
makes administration more difficult, so I've not done that.

I think setting a different SDPort might work, as I believe the
storage daemon tries to write a pid file bacula-sd.<port>.pid,
being the same as the first running daemon. In practice however,
this is a hack because the same port number can be used on different
IP addresses.

I do understand your point. I'll either do one of these hacks or
change the source code to write a properly different .pid file (if
that's what is causing the silent failure.)

>> What is the proper way to go about listening on two subnets while
>> presenting the proper certificate to incoming TLS connections?
>
>I guess the Bacula TLS implementation would need some work. Apart from 
>that, different host names with their "own" certificates might be 
>required.
>
>I guess this might become a feature request...
>
That's my thought as well, so let's make a suggestion.

Feature request:
Introduce a way to associate a server certificate for TLS
connections in the '(Dir|FD|SD)Addresses' block, so that clients
receive the correct certificate (corresponding to the IP address
in question.)

Reason:
To allow Bacula users TLS connections even when having a mixed
network landscape of hosts with private and public IP addresses.
One host might be behind a NAT router for example, and so the
user would like to serve Bacula requests over a plain internal
IP address 192.168.1.2, as well as a tunneled one (bypassing the
NAT.)

Details:
As shown on 'Storage_Daemon_Configuratio.html', the following
structure allows a storage daemon to listen on multiple addresses.
This feature request describes missing logic as marked with '**'
in the altered structure below.

  SDAddresses  = {
    ipv4 = {
      addr = public.host.tld;
      port = 9103;
      **TLS Enable = (yes|no)**
      **TLS Require = (yes|no)**
      **TLS Verify Peer = (yes|no)**
      **TLS Allowed CN = "third.party.host.tld"**
      **TLS CA Certificate File = <path>**
      **TLS Certificate = <path>**
      **TLS Key = <path>**
      **TLS DH File = <path>**
    }
    ipv4 = {
      addr = privat.host.tld;
      port = 9103;
    }
  }

Is there some policy or special procedure for making feature
requests?

Regards,
Eduard

------------------------------------------------------------------------------
Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
http://p.sf.net/sfu/devconf
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users