[cfg] Make sure Tempesta doesn't specify itself as a backend #774
Comments
|
Most of Web accelearators don't care abut such kind of fool protection, so low priority. Just add the config file checks to |
krizhanovsky
changed the title
As I understand both claims from issue are satisfied now: * mix of v4 and v6 addresses is handled * check is performed at the right time So there is basically nothing to fix. Remove misleading TODO: v6 case is alredy the same as v4 one. Remove redundant port check from tfw_addr_ifmatch() which happens in tfw_addr_eq() anyways. Replace direct sockaddr_in::sin6_port access with accessor function tfw_addr_port().
|
As mentioned in the description, the issue consists of two parts. First is that the same address may be specified as IPv4 or as IPv4-mapped IPv6. That was described in issue #775, and was fixed by #1081. Now IPv6 is used to represent all addresses, thus normalizing them during configuration stage. Last is about checking for matches at the very end of the configuration stage. That was fixed in somewhere near 6ff9bba which was a part of #851. That moved checking to the new stage which was called after all configuration was parsed. With all of the above, I believe the issue is fixed already. |
|
If Tempesta doesn't start (or at least prints warnings) with configuration having the same address as listening and a upstream, then we can just close the issue. It'd be good to have a functional test (or just add the check to some existing test), but with that the issue is low priority it's not necessary. |
As I understand both claims from issue are satisfied now: * mix of v4 and v6 addresses is handled * check is performed at the right time So there is basically nothing to fix. Remove misleading TODO: v6 case is alredy the same as v4 one. Replace direct sockaddr_in::sin6_port access with accessor function tfw_addr_port().
It indeed doesn't start. dmesg output: That's what happens when configuration below is used: |
|
Not so bad, thanks! |
A backend server (an IP address and port number) specified in Tempesta configuration may in fact turn out to be the same as an address where Tempesta listens to incoming requests from clients. The mistake is very easy to make. There should be a protection against that.
The problem was recognized before and seemingly fixed in 83c987f. However, the fix has issues of its own.
tfw_addr_ifmatch()that compares the addresses doesn't seem to handle this case. See issue Unify the representation of IP addresses in Tempesta #775.default, and that is done after complete configuration has been processed. So at the time the check is performed these servers are not in the configuration yet, so they are missed by the check.The listener's module is called and initialized before the module that handles backends. Yet the check is implemented in the listener's module. Perhaps it makes more sense to move it to the module for backends.
The text was updated successfully, but these errors were encountered: