On 03/11/2017 07:57 PM, Daniel Ruggeri wrote:
> Thanks, all, for the patience as I finally got back to this.
>
> On 2/24/2017 11:05 AM, Sander Hoentjen wrote:
>> On 02/20/2017 07:48 PM, William A Rowe Jr wrote:
>>> On Sat, Feb 18, 2017 at 4:25 PM, Daniel Ruggeri <drugg...@apache.org> wrote:
>>>> On 2017-02-15 09:07 (-0600), William A Rowe Jr <wr...@rowe-clan.net> wrote:
>>>>> On Wed, Feb 15, 2017 at 9:02 AM, Sander Hoentjen <san...@hoentjen.eu>
>>>>> wrote:
>>>>>> mod_remote ip has:
>>>>>> /* mod_proxy creates outgoing connections - we don't want those */
>>>>>> if (!remoteip_is_server_port(c->local_addr->port)) {
>>>>>> return DECLINED;
>>>>>> }
>>>>>> I am guessing something similar is needed for h2 connections?
>>>>> I suspect that the mod_remoteip logic is wrong, that it should be guarding
>>>>> against any subordinate connections and examining only explicitly
>>>>> configured
>>>>> ports / origin IPs. the PROXY protocol is not part of the HTTP protocol
>>>>> and
>>>>> incompatible with it, so the trust list logic isn't directly compatible
>>>>> (this is
>>>>> clearly explained in the PROXY pseudo-RFC.)
>>>>>
>>>> Hi, Bill. That is what the module is doing. The original authors wrote it
>>>> to have a list of virtual hosts it is explicitly enabled for and
>>>> explicitly disabled for. I added a third list for optional vhosts. In the
>>>> pre_connection hook, it checks to see if the connection's local_addr
>>>> (which should normally be the server's IP) is explicitly configured to
>>>> enable PROXY handling. It then checks to see if the local port is a server
>>>> port.
>>>>
>>>> Looking at the logs shared, 192.168.122.249:84 is the server IP:Port combo
>>>> and is also the local IP:Port from mod_h2. If h2 sets the master of this
>>>> connection, then we could skip the whole ordeal with this patch:
>>>>
>>>> Index: modules/metadata/mod_remoteip.c
>>>> ===================================================================
>>>> --- modules/metadata/mod_remoteip.c (revision 1781701)
>>>> +++ modules/metadata/mod_remoteip.c (working copy)
>>>> @@ -862,6 +862,10 @@
>>>> remoteip_conn_config_t *conn_conf;
>>>> int optional;
>>>>
>>>> + if (c->master != NULL) {
>>>> + return DECLINED;
>>>> + }
>>>> +
>>>> conf = ap_get_module_config(ap_server_conf->module_config,
>>>> &remoteip_module);
>>>>
>>>> .. but I don't know if that potentially means we are looking at the wrong
>>>> connection.
>> First I'll say that with the "Optional" mode it worked, just not with On
>> I just tried this patch and as far as I have tested this seems to work
>> fine in On mode, as well as in Optional. I do see some other issue, but
>> that is probably in my own code, I'll try to track that down later.
> This is good news and about what I was expecting to happen. I will add
> this to the commit I've got coming that incorporates a lot of Ruediger's
> feedback.
>
>>> That should be close, but need to ensure c->master is initialized for
>>> http as well
>>> where there is no master/subordinate.
>> I am not sure what this means, how should I test this?
> Hi, Bill - also hoping for a bit more input. Since PROXY protocol is not
> tied to any particular layer 7 protocol, I don't think we'd have to
> verify it is initialized for HTTP - just that there is no master at all.
> At least, that's my understanding so I appreciate any corrections.
Here are my changes by the way:
https://github.com/AntagonistHQ/httpd/commit/2d208793b4494e73289477c231c79be9e0030a2b
> Sure, to clarify, the Optional use case came from a member on one of our
> cousin projects (Tomcat) Chris Schultz as well as my own use cases. It
> is useful for internally accessing the site from behind the
> loadbalancer. When there is a publicly addressed upstream loadbalancer
> (Amazon ELB or just HAProxy itself) talking to RFC1918 addressed or
> non-routeable backend httpd servers, it becomes impossible to enable
> internal communication on the RFC1918 space to the backend instances.
> If the goal is to monitor or probe the site and (httpd proxy) backends
> internally for health, this *can* be done by duplicating the virtual
> hosts. Depending on the complexity of the virtual hosts, what resources
> those virtual hosts have (proxies and whatnot) and their general size,
> this could result in a fairly unmanageable httpd configuration having a
> vhost that requires PROXY header and a second one on a different port or
> IP that does not.
> It gets even more complicated when you are aiming to do management
> tasks. If you have balancers configured at the vhost as intended, you
> can only manage those balancers from the vhost they live in. Further,
> you may want to view server statistics, check info about the ldap cache,
> etc but permit access to those things only from a trusted network in
> addition to the user credentials protecting it.
> So for those examples, aside from creating an internal HAProxy to
> provide the header, it's not really possible to access the site
> internally when "On". With "Optional" it's possible to keep the same
> number of vhosts and enable the various management handlers and restrict
> them to the RFC1918 space (plus any other authnz mechanisms). The other
> obvious option would be to enable those handlers to the public Internet,
> but that's bad juju :-)
>
Well maybe what I am doing is wrong, but I just add a port to my vhosts,
so I have:
<VirtualHost $some_ip:80 $some_ip:83 >
and then I also have:
<VirtualHost *:83>
RemoteIPProxyProtocol On
</VirtualHost>
This way I can reach the same vhost with and without proxy protocol.
--
Sander
