O controle de acesso baseado em localização do proxy reverso do Apache não funciona

3

Estou executando um pequeno servidor da Web com o Ubuntu 12.05.5 LTS e o Apache 2.2.22 e corri para esse problema recentemente:

Para um servidor IIS em uma máquina virtual, tenho a seguinte configuração de proxy reverso:

<VirtualHost *:443>

    SSLEngine on

    DocumentRoot /var/www/

    <Directory />
        Options FollowSymLinks
        AllowOverride None
        Order deny,allow
        Deny from all
        Allow from 127.0.0.1
        allow from 192.168.
        allow from 10.8.0
    </Directory>

    ...

    ProxyRequests Off
    ProxyPreserveHost On
    ProxyVia On

    SSLProxyEngine on
    <Location /AutodeskDM>
        Order Deny,Allow
        Deny from all
        Allow from 192.168.
        ProxyPass https://10.8.0.131/AutodeskDM
        ProxyPassReverse https://10.8.0.131/AutodeskDM
    </Location>

    <Location /autodeskdm>
        Order Deny,Allow
        Deny from all
        Allow from 192.168.
        ProxyPass https://10.8.0.131/autodeskdm
        ProxyPassReverse https://10.8.0.131/autodeskdm
    </Location>

....

</VirtualHost>

Isso funciona perfeitamente e só permite conexões do 192.168. sub-rede, como esperado.

Agora, quando uso a mesma configuração menos o SSLProxyEngine e http em vez de https nas diretivas ProxyPass, recebo o seguinte erro:

[error] [client 127.0.0.1] client denied by server configuration: proxy:http://10.8.0.131/AutodeskDM/

Se eu adicionar

Allow from 127.0.

funciona, claro, mas o acesso é garantido de qualquer lugar.

Reprodução com a diretiva Proxy, conforme sugerido em outro lugar (por exemplo, Controle de acesso do proxy reverso do Apache ) também não tem efeito.

<Proxy *>
    Order deny,allow
    Deny from all
    Allow from 192.168.
</Proxy>

Ainda permite acesso de qualquer lugar.

O que estou perdendo aqui? Esse comportamento é esperado? Em caso afirmativo, por que é diferente com e sem SSL?

    
por Hauke 24.11.2014 / 21:16

1 resposta

0

Como sempre, outro programa estava atrapalhando. Eu tenho o OpenVPN ouvindo na porta 80 e enviando solicitações http para o apache na porta 8080. Então, naturalmente, as solicitações http parecem estar vindo do localhost para o apache.

    
por 07.12.2015 / 13:59