1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
|
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.
|
