Kern Sibbald wrote:
> On Tuesday 10 October 2006 03:02, Brian A. Seklecki wrote:
>
>>> I have no idea how to control which address is used for outgoing
>>> communications other than by configuring your network gateway to go
>>>
> through
>
>>> the preferred device, which may not do exactly what you want.
>>>
>> I've just read through the whole thread. People seems to be getting
>> confused about a couple of concepts.
>>
>
> I don't think there was any confusion in my mind, but I was not aware that
> bind could be used for outgoing connections.
>
> Thanks for the detail.
>
> Is there someone who would like to work on this?
>
It certainly is possible to bind a socket to a local address prior to
calling connect(). It is not possible to bind it to multiple local
addresses prior to connect(). You may specify INADDR_ANY in the call to
bind(), but that will just cause the kernel to select the local address
in the usual way when connect() is called.
The problem is not can a source address be bound, it is what address do
we bind to? What if we have a bacula-sd that is on a different segment
than the workstations we want to back up? What if the DIRAddresses
directive is used to specify two addresses to listen on? This is why, as
Brian Seklecki pointed out, named has so many options to specify
query-source, ( not to mention notify-source and transfer-source),
address(es). bacula-dir would be required to, essentially, perform its
own manual (user controlled) routing.
In other words, Kern, you were right the first time, IMHO. Though I
agree that it CAN be done, since new directives for bacula-dir.conf (and
possibly for bacula-sd.conf as well) would be required, this should be
handled as a feature request.
That said, there may be one case where bind() could be used without
breaking any existing implementations and without requiring any new
directives. I believe that specifying the DIRAddress directive causes
bacula-dir to listen on one, and only one, address. If so, then it
should be possible to bind the sockets bacula-dir uses to make client
connections to bacula-sd's port 9103 and bacula-fd's port 9102 to the
address specified in DIRAddress. That would fix the original problem
this thread was started for, and I don't believe it would break anything
for anyone else. The bind() call would be made if, and only if,
DIRAddress is specified. Otherwise nothing would change. If that seems
like a reasonable thing to implement, then yes, I would be willing to
implement it and send in a patch.
> Regards,
>
> Kern
>
>
>> Firstly, consider the need to be able to manually specify the outbound
>> IPv4 address of "Client" connections from a daemon _as well_ as the
>> inbound address on which to listen for incoming service requests.
>>
>> In most shops, in almost all but the most basic configurations, the
>> generally accepted practice is to create abstraction between the
>> "system" and the "service" provided by it. Even if a system has a
>> single service/function, it still binds the service to a "Service VIP",
>> or "IP Alias (BSD)".
>>
>> I.e., almost all machines have a "Management Address" and "Service
>> VIP", especially in non-RFC1918-space-only shops.
>>
>> To give you an idea why this is a policy in most places: For example,
>> if a system crashes, you can pick up the VIP and move it to a different
>> system in the same VLAN.
>>
>> ...OR, if that service VIP has a CNAME pointing to it, you can simply
>> cut over the CNAME destination to a service VIP in a different VLAN
>> without breaking all your clients.
>>
>> Thus, "System-Service Abstraction"
>>
>> This becomes especially paramount in High Availability configurations
>> where at service VIP dangles between two or more servers. Consider the
>> Linux-HA system.
>>
>> It is also extremely important when you're trying to manage firewall
>> rule growth. At present, if you have multiple VIPs/IP Aliases on
>> Bacula, you can control which one "Listening Sockets" bind to, but say
>> for example, when writing rules that would permit the Director to send
>> control messages to File Daemons, or Storage Daemons to send messages to
>> Directors, or Consoles to Directors, you want your rules to reflect the
>> source address of the service VIP for "new client sockets".
>>
>> Consider ISC BIND named(8): It's got all kinds of crazy options for
>> binding listening sockets for incoming requests and specifying the
>> source _port_ and _address_ for outbound connections the daemon is
>> making in the capacity of a "client":
>>
>> Example:
>>
>> options {
>> directory "/";
>> listen-on { 1.2.3.4/32; };
>> query-source address 2.4.5.6 port 12346;
>> transfer-source 7.8.9.1;
>> notify-source 2.3.3.5;
>> ....
>> }
>>
>> All kinds of control.
>>
>>
>> -----------------
>>
>> Secondly, "Socket Source Address/Port" v.s. "Routing"
>>
>> These are *completely autonomous concepts*. I just went through this
>> bringing "-b" from FreeBSD syslogd(8) over to NetBSD(8):
>>
>>
>>
> http://cvsweb.netbsd.org/bsdweb.cgi/src/usr.sbin/syslogd/syslogd.c.diff?r1=1.78&r2=1.79&f=h
>
>> Check out lines 2107->2111
>>
>> This is an example with UDP, but the song remains the insane for TCP.
>>
>> When you bind(2)/listen(2) a socket(2), there are two modes: Passive and
>> active.
>>
>> The address which a socket listens/binds is wildcard by default. You
>> can set it though with getaddrinfo(2)...intuitive function call name,
>> huh?! >:}
>>
>> Another good example are present in Apache's HTTP CVS:
>> srclib/apr/network_io/unix/sockaddr.c
>>
>> There's no reference to any of this in any of Stevens` because those
>> were all written before the advent of HA and Distributed Systems,
>> possibly even IP Aliases/VIPs.
>>
>> Per my notes on "Service/System" abstraction, if a system has multiple
>> interfaces, there are two possibilities:
>>
>> *) The interfaces could have addresses in different subnets
>> *) The interfaces could have addresses in the same subnets
>>
>> A system could also have multiple VIPs or "IP Aliases" (BSD) on the
>> same interface within the same Subnet (the most likely scenario).
>>
>> When you specifically bind the source address of an outgoing TCP socket
>> to a specific VIP or Primary IP on an interface, the decision as to
>> which interface to transmit the outgoing packets is not made in the TCP
>> code, it is made at the next layer down on the OSI model -- the
>> underlying IPv4/IPv6 protocol.
>>
>> Example, if a system has two NICs. One within a management subnet with
>> RFC1918 address space, we'll say 10.0.0.100, and another with two IPs, a
>> primary IP and a service VIP in a public subnet, we'll say 216.239.37.99
>> and 216.239.37.100.
>> Consider the routing:
>>
>> Assume for the sake of sanity that the subnet masks on both interfaces
>> are /25 on the public interface and /23 on the RFC1918 interface. Via
>> "Directly Connected Interfaces", the system knows about 216.239.37.0/25
>> via "Ext", and 10.0.0.0/23 via "Int". It may also have a "Default
>> Gateway" configured of 215.239.37.1/32. He may also know about a
>> greater 10.0.0.0/8 via a "Static Route" via some internal
>> router/firewall at 10.0.0.1 -- manually configured "route add -net
>> 10.0.0.0/8 gw 10.0.0.1".
>>
>> Obviously, the default semantics apply to most modern operating systems:
>>
>> *) A layer 4 socket number discriminator is of course always required
>> for UDP/TCP, but not for ICMP/TCP/ESP/AH/etc.
>>
>> *) For outbound UDP/ICMP/TCP/ESP/AH etc layer 3 protocols
>> (/etc/protocols) sockets, if the source address is not specified, the
>> layer 4 default address of the interface "closest" to the remote address
>> is used.
>>
>> *) The layer 2 interface used for transmission is that of the one used
>> in the default layer 3 protocol address acquisition algorithm. The
>> kernel makes this decision though based on the routing table and
>> weighted priories and metrics. I.e, connected > static > null > learned
>> via IGP/BGP (2)
>>
>> *) The layer 3 address could be specified in the code / by the user, in
>> which case, a one of many VIPs within the same subnet on the same
>> interface could be used, but the layer 2 transmit interface remains the
>> same.
>>
>> *) The exception to the previous two rules are as follows:
>>
>> -) The remote address of the outbound TCP socket is in a subnet
>> known via "Directly Connected Route" on an interface other than
>> the source address the user specified the local socket
>>
>> -) The remote address of the outbound TCP socket is in a subnet
>> known by "Static Route" via a gateway/interface on an
>> interface in a subnet other than the address of the local socket.
>>
>> In these instances, the behavior is OS independent, but connect(2)
>> or bind(2) should fail miserably, even if functions themselves
>> return successfully. (1)
>>
>> *) For incoming passive listen sockets, if no bind address is specified,
>> it becomes a wildcard bind (examples: vintage inetd(8), etc.) --
>> unintelligent daemons like this were the reasons behind tcpwrappers.
>>
>> 1. Consider the routing:
>>
>> Assume for the sake of sanity that the subnet masks on the interfaces
>> are /25 on the public interface and /23 on the RFC1918 interface. Via
>> "Directly Connected Interfaces", the system knows about 216.239.37.0/25
>> via "Ext", and 10.0.0.0/23 via "Int". It may also have a "Default
>> Gateway" configured of 215.239.37.1/32. He may also know about a
>> greater 10.0.0.0/8 via a "Static Route" via some internal
>> router/firewall at 10.0.0.1 -- manually configured "route add -net
>> 10.0.0.0/8 gw 10.0.0.1".
>>
>> On this system, a random client program ("foo") could very easily bind
>> it's TCP socket source address to the VIP 216.239.37.100, then
>> connect(2) in active mode to a foreign destination address 10.0.3.101.
>> Or maybe tries to "ping -B 216.239.37.100 10.0.3.100".
>>
>> The operating system will very happily transmit that IPv4 packet
>> containing the TCP/ICMP packet out of the "Int" private interface with
>> the "Ext" VIP address as the source address. That datagram makes its
>> way onto the ethernet segment. As long as router 10.0.0.1/32, and all
>> of the corresponding routers en route to 10.0.3.101/32 are willing to
>> forward the packet (i.e., they know a return route to 216.239.37.100/32
>> via 10.0.0.100/32), it will actually work.
>>
>> If they dont, the socket will time out tranmitting IPv4 packets (which
>> contain a TCP SYN packet) that 10.0.0.1/32 will discard due to perhaps a
>> BOGON list.
>>
>> Next, vanquish all thoughts about using a Linux kernel specific kernel
>> hacks like IPCHAINs. Obviously a OS kernel-specific solution is not
>> optimal. There are some cheap tricks that you could do with OpenBSD's
>> pf(4) as well, but I certainly wouldn't go recommending those to anyone.
>>
>> Background on that:
>>
>> A lot of this confusion is Linux's fault.
>>
>> I've seen some Linux-specific hacks that like to accept command line
>> arguments for "Transmit Interface", like "./foo.bar -interface=eth0".
>> This has a lot to do with the fact that Linux considers VIPs separate
>> logical interface structures, thus verily easily blurring the
>> distinction.
>>
>> Clearly, this is just a lot of smoke and mirrors around choosing a
>> proper source address for the socket/ICMP/ESP/layer 3 datagram.
>>
>> In summary: You cant control the "Transmit Interface", you can control
>> the layer 4 socket number and the layer 3 transmit address; -- the
>> kernel will make the outbound layer 2 physical interface encapsulation
>> for you, based on your directly connected routes, static routes, default
>> gateway, IGPs, etc.
>>
>>
>> 2. See table: http://www.cisco.com/warp/public/105/21.html#building
>>
>>
>>
>> Finally, consider the practical examples:
>>
>> *) Bconsole will almost always run on a workstation with a single IP
>> address with a single default gateway. Outbound TCP connection source
>> address auto-determination applies 99% of time. However, if for some
>> internal security policy compels it, the Administrator would certainly
>> enjoy the ability to source the Concsole->Dir socket from an alternative
>> VIP.
>>
>> *) The FileDaemon running on a workstation will only use one source
>> address available to talk to Dir and StorageD.
>>
>> *) The FileDaemon running a HA or multi-homed server will almost always
>> want to use it's "Management" address on a private/RFC1918 network to
>> initiate outbound TCP connections for:
>>
>> - Messages from FileDir->Director (logs)
>> - Backup date from FileDir->StorageDir
>>
>> However, there is always the remote but entirely reasonable possibility
>> that the server has a dedicated backup network interface in a subnet
>> that overlaps with a static route assigned to the Management network.
>> Example:
>>
>> "Ext0": 1.2.3.4/25.
>> "Default gw": 1.2.3.1/32
>> "Mngmnt0" 10.0.100.200/24"
>> "Static 10.0.0.0/8 via 10.0.100.1"
>> "Backup0": 10.0.200.200/24
>> "Storage Dir": 10.0.200.100/32
>>
>> In this complicated but entirely possible scenario, being able to
>> specify the source address of the backup network interface helps the
>> kernel pick the proper transmit interface by allowing it to discriminate
>> the route known via directly connected over the metric/weight of the
>> static route.
>>
>> *) And of course, the StorageDir->Director and Director->StorageDir
>> connections, which could reside in HA/Load-Balanced configurations, rely
>> on the source address of the remote host to authenticate.
>>
>> Consider:
>>
>> 192.168.100.0/23
>>
>> [B-SD-Active .101][B-SD-Standby .102]
>> [B-SD-HA VIP .100]
>> |
>> |
>> \ /
>> Router {192.168.100.1/32}
>> {192.168.200.1/32}
>> / \
>> |
>> |
>> [B-Dir-HA .100]
>> [B-Dir-Active .101][B-Dir-Standby .102]
>>
>>
>>
>> In this config, the HA VIP for both is an IfAlias on the active system.
>> When it transmits to the configured HA address of the SD or Dir
>> resource, the remote active will fail to authenticate because the source
>> address will be that of the Active "Primary IP" and not the service VIP.
>>
>> Another great example of the need for source address specification is a
>> POSIX/Linux/BSD/UNIX system deployed as a remote VPN tunnel termination
>> point / router appliance.
>>
>> Details:
>>
>> - The remote private RFC1918 subnet is 172.16.100.0/24 at the branch
>> office.
>> - The local subnet at the HQ where the Dir/StorageD is is 172.16.99.0/24
>> - The HQ has a WAN connection 1.2.3.4, the Branch has a WAN connection
>> 2.3.4.5
>> - The IPSEC/ISAKMP ACLs will stipulate 172.168.0.0/12 on the HQ side and
>> 172.16.100.0/24 on the branch.
>> - When the branch office receives packets on it's internal interface
>> from LAN hosts matching 172.16.100.0/24 destined for 172.16.0.0/12, it
>> knows to ESP/AH them and transmit them out it's Ext., if not, NAT/PAT to
>> 2.3.4.5/32
>> - However, the remote branch machine/router/appliance whatever, when
>> generating packets itself destined for 172.16.0.0/12 will not attempt to
>> ESP/AH encapsulate unless you specify a source address of it's internal
>> interface. By default, kernel routing semantics will attempt to
>> transmit those packets out the Ext interface using NAT/PAT via the
>> default gateway.
>>
>> Consider it: The kernel has no way of knowing any kind of inverse /
>> reverse routing decision such as: "Hey Locally initiated traffic
>> destined for a subnet I know via an ESP/GRE tunnel, use this source
>> address if you wish to qualify for the VPN ACL and reach your
>> destination."
>>
>> That simply doesn't work.
>>
>> ~BAS
>>
>>
>>> In any event, unless I am misunderstanding something, Bacula has no
>>>
> mechanism
>
>>> for controlling outgoing addresses.
>>>
>>
>> -------------------------------------------------------------------------
>> Take Surveys. Earn Cash. Influence the Future of IT
>> Join SourceForge.net's Techsay panel and you'll get the chance to share your
>> opinions on IT & business topics through brief surveys -- and earn cash
>> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>> _______________________________________________
>> Bacula-users mailing list
>> Bacula-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bacula-users
>>
>>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Bacula-users mailing list
> Bacula-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bacula-users
>
>
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
