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?
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
