mirror of
http://git.haproxy.org/git/haproxy.git/
synced 2024-12-11 22:15:14 +00:00
c14b7d94a0
These ones were design notes and ideas collected during the 1.5 development phase lying on my development machine. There might still be some value in keeping them for future reference since they mention certain corner cases.
168 lines
7.2 KiB
Plaintext
168 lines
7.2 KiB
Plaintext
2013/10/10 - possibilities for setting source and destination addresses
|
|
|
|
|
|
When establishing a connection to a remote device, this device is designated
|
|
as a target, which designates an entity defined in the configuration. A same
|
|
target appears only once in a configuration, and multiple targets may share
|
|
the same settings if needed.
|
|
|
|
The following types of targets are currently supported :
|
|
|
|
- listener : all connections with this type of target come from clients ;
|
|
- server : connections to such targets are for "server" lines ;
|
|
- peer : connections to such target address "peer" lines in "peers"
|
|
sections ;
|
|
- proxy : these targets are used by "dispatch", "option transparent"
|
|
or "option http_proxy" statements.
|
|
|
|
A connection might not be reused between two different targets, even if all
|
|
parameters seem similar. One of the reason is that some parameters are specific
|
|
to the target and are not easy or not cheap to compare (eg: bind to interface,
|
|
mss, ...).
|
|
|
|
A number of source and destination addresses may be set for a given target.
|
|
|
|
- listener :
|
|
- the "from" address:port is set by accept()
|
|
|
|
- the "to" address:port is set if conn_get_to_addr() is called
|
|
|
|
- peer :
|
|
- the "from" address:port is not set
|
|
|
|
- the "to" address:port is static and dependent only on the peer
|
|
|
|
- server :
|
|
- the "from" address may be set alone when "source" is used with
|
|
a forced IP address, or when "usesrc clientip" is used.
|
|
|
|
- the "from" port may be set only combined with the address when
|
|
"source" is used with IP:port, IP:port-range or "usesrc client" is
|
|
used. Note that in this case, both the address and the port may be
|
|
0, meaning that the kernel will pick the address or port and that
|
|
the final value might not match the one explicitly set (eg:
|
|
important for logging).
|
|
|
|
- the "from" address may be forced from a header which implies it
|
|
may change between two consecutive requests on the same connection.
|
|
|
|
- the "to" address and port are set together when connecting to a
|
|
regular server, or by copying the client's IP address when
|
|
"server 0.0.0.0" is used. Note that the destination port may be
|
|
an offset applied to the original destination port.
|
|
|
|
- proxy :
|
|
- the "from" address may be set alone when "source" is used with a
|
|
forced IP address or when "usesrc clientip" is used.
|
|
|
|
- the "from" port may be set only combined with the address when
|
|
"source" is used with IP:port or with "usesrc client". There is
|
|
no ip:port range for a proxy as of now. Same comment applies as
|
|
above when port and/or address are 0.
|
|
|
|
- the "from" address may be forced from a header which implies it
|
|
may change between two consecutive requests on the same connection.
|
|
|
|
- the "to" address and port are set together, either by configuration
|
|
when "dispatch" is used, or dynamically when "transparent" is used
|
|
(1:1 with client connection) or "option http_proxy" is used, where
|
|
each client request may lead to a different destination address.
|
|
|
|
|
|
At the moment, there are some limits in what might happen between multiple
|
|
concurrent requests to a same target.
|
|
|
|
- peers parameter do not change, so no problem.
|
|
|
|
- server parameters may change in this way :
|
|
- a connection may require a source bound to an IP address found in a
|
|
header, which will fall back to the "source" settings if the address
|
|
is not found in this header. This means that the source address may
|
|
switch between a dynamically forced IP address and another forced
|
|
IP and/or port range.
|
|
|
|
- if the element is not found (eg: header), the remaining "forced"
|
|
source address might very well be empty (unset), so the connection
|
|
reuse is acceptable when switching in that direction.
|
|
|
|
- it is not possible to switch between client and clientip or any of
|
|
these and hdr_ip() because they're exclusive.
|
|
|
|
- using a source address/port belonging to a port range is compatible
|
|
with connection reuse because there is a single range per target, so
|
|
switching from a range to another range means we remain in the same
|
|
range.
|
|
|
|
- destination address may currently not change since the only possible
|
|
case for dynamic destination address setting is the transparent mode,
|
|
reproducing the client's destination address.
|
|
|
|
- proxy parameters may change in this way :
|
|
- a connection may require a source bound to an IP address found in a
|
|
header, which will fall back to the "source" settings if the address
|
|
is not found in this header. This means that the source address may
|
|
switch between a dynamically forced IP address and another forced
|
|
IP and/or port range.
|
|
|
|
- if the element is not found (eg: header), the remaining "forced"
|
|
source address might very well be empty (unset), so the connection
|
|
reuse is acceptable when switching in that direction.
|
|
|
|
- it is not possible to switch between client and clientip or any of
|
|
these and hdr_ip() because they're exclusive.
|
|
|
|
- proxies do not support port ranges at the moment.
|
|
|
|
- destination address might change in the case where "option http_proxy"
|
|
is used.
|
|
|
|
So, for each source element (IP, port), we want to know :
|
|
- if the element was assigned by static configuration (eg: ":80")
|
|
- if the element was assigned from a connection-specific value (eg: usesrc clientip)
|
|
- if the element was assigned from a configuration-specific range (eg: 1024-65535)
|
|
- if the element was assigned from a request-specific value (eg: hdr_ip(xff))
|
|
- if the element was not assigned at all
|
|
|
|
For the destination, we want to know :
|
|
- if the element was assigned by static configuration (eg: ":80")
|
|
- if the element was assigned from a connection-specific value (eg: transparent)
|
|
- if the element was assigned from a request-specific value (eg: http_proxy)
|
|
|
|
We don't need to store the information about the origin of the dynamic value
|
|
since we have the value itself. So in practice we have :
|
|
- default value, unknown (not yet checked with getsockname/getpeername)
|
|
- default value, known (check done)
|
|
- forced value (known)
|
|
- forced range (known)
|
|
|
|
We can't do that on an ip:port basis because the port may be fixed regardless
|
|
of the address and conversely.
|
|
|
|
So that means :
|
|
|
|
enum {
|
|
CO_ADDR_NONE = 0, /* not set, unknown value */
|
|
CO_ADDR_KNOWN = 1, /* not set, known value */
|
|
CO_ADDR_FIXED = 2, /* fixed value, known */
|
|
CO_ADDR_RANGE = 3, /* from assigned range, known */
|
|
} conn_addr_values;
|
|
|
|
unsigned int new_l3_src_status:2;
|
|
unsigned int new_l4_src_status:2;
|
|
unsigned int new_l3_dst_status:2;
|
|
unsigned int new_l4_dst_status:2;
|
|
|
|
unsigned int cur_l3_src_status:2;
|
|
unsigned int cur_l4_src_status:2;
|
|
unsigned int cur_l3_dsp_status:2;
|
|
unsigned int cur_l4_dst_status:2;
|
|
|
|
unsigned int new_family:2;
|
|
unsigned int cur_family:2;
|
|
|
|
Note: this obsoletes CO_FL_ADDR_FROM_SET and CO_FL_ADDR_TO_SET. These flags
|
|
must be changed to individual l3+l4 checks ORed between old and new values,
|
|
or better, set to cur only which will inherit new.
|
|
|
|
In the connection, these values may be merged in the same word as err_code.
|