Varnish desarmando tudo, exceto último x-encaminhado para o endereço IP ... bug?

Question

Enquanto tentava descobrir por que nossa instalação do Varnish 4.1 (no CentOS7 via repo do varnish-cache.org) não estava seguindo as regras do vcl definidas para registrar o endereço IP do cliente em um cabeçalho X-Forwarded-For (veja: < href="https://stackoverflow.com/questions/42566529/varnish-4-logging-proxy-load-balancer-instead-of-client-ip-addresses"> Varnish 4 logging proxy / load balancer em vez de cliente IP endereços Aconteceu de eu notar algo estranho enquanto procurava por arquivos varnishlog:

- Begin        req 9353447 rxreq
- Timestamp    Start: 1488771709.337974 0.000000 0.000000
- Timestamp    Req: 1488771709.337974 0.000000 0.000000
- ReqStart     172.25.20.65 19903
- ReqMethod    GET
- ReqURL       /about-us/
- ReqProtocol  HTTP/1.1
- ReqHeader    host: www.<notreallythishost>.com
- ReqHeader    Accept: */*
- ReqHeader    Accept-Encoding: gzip, deflate
- ReqHeader    Cache-Control: no-cache
- ReqHeader    From: bingbot(at)microsoft.com
- ReqHeader    Pragma: no-cache
- ReqHeader    User-Agent: Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)
- ReqHeader    X-Forwarded-For: 40.77.167.41
- ReqHeader    X-Forwarded-Port: 80
- ReqHeader    X-Forwarded-Proto: http
- ReqHeader    Connection: keep-alive
- ReqUnset     X-Forwarded-For: 40.77.167.41
- ReqHeader    X-Forwarded-For: 40.77.167.41, 172.25.20.65
- VCL_call     RECV
- ReqUnset     X-Forwarded-For: 40.77.167.41, 172.25.20.65
- ReqHeader    X-Forwarded-For: 172.25.20.65
- ReqUnset     Accept-Encoding: gzip, deflate
- ReqHeader    Accept-Encoding: gzip
- ReqUnset     User-Agent: Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)
- VCL_return   hash
- VCL_call     HASH
- VCL_return   lookup
- VCL_call     MISS
- VCL_return   fetch
- Link         bereq 9353449 fetch
- Timestamp    Fetch: 1488771709.338395 0.000421 0.000421
- RespProtocol HTTP/1.1

Isso explica totalmente o motivo de nunca conseguirmos obter nada além do endereço IP do balanceador de carga registrado no vernizncsa em qualquer momento, independentemente da técnica de registro usada.

Parece que, no processamento da solicitação, ele cria o cabeçalho X-Forwarded-For adicionando o endereço IP do Balanceador de carga do AWS ao cabeçalho, mas como vc_call é chamado resume-o novamente e remove o endereço IP do cliente original. Então, como faço para manter intacto o X-Forwarded-For e por que o Varnish está mudando os IPs para o lado esquerdo, em vez de apenas adicioná-los ao cabeçalho X-Forwarded-For como deveria? Bug?

    

Answer 1

Portanto, a solução alternativa para isso (possível bug em 4.1.3-1.el7.x86_64) foi uma pista que encontrei enquanto procurava outras questões de registro de verniz, especificamente uma sobre desabilitando o cabeçalho x-forwarded-for completamente .

Embora isso não seja o que eu queria fazer, ele forneceu a dica sobre como evitar que o verniz anexasse seu próprio conteúdo vcl_recv ao buttom da minha definição de função vcl_recv. Especificamente, forneça seu próprio retorno (pesquisa) (embora seja o verniz < = 3) ou o retorno (hash) (verniz 4.x).

Então agora eu tenho isso no topo do vcl_recv ():

# ensure proper logging of x-forwarded-for IP addresses
std.collect(req.http.x-forwarded-for);
set req.http.x-forwarded-for = regsub ( req.http.x-forwarded-for, "^(([0-9]{1,3}\.){3}[0-9]{1,3})(.*)", "" );
if (req.http.x-forwarded-for) {
    std.log("ip:" + req.http.x-forwarded-for);
} else {
    std.log("ip:" + client.ip);
}

Então, no final da função, tenho, claro, como mencionei:

return (hash);

Portanto, agora é log de sucesso apenas o endereço IP do cliente como deveria ser com a adição de uma opção de varnishncsa de:

-F "%%{VCL_Log:ip}x %%l %%u %%t \"%%r\" %%s %%b \"%%{Referer}i\" \"%%{User-agent}i\""

Espero que alguém encontre essa informação útil.

UPDATE: Apenas como uma nota, encontrei este postar sobre spoofing nesta resposta nginx e seria legal ter uma espécie de real_ip_from ou trusted_ip_from cabeçalhos em verniz como bem, mas não parece nativamente no momento. Minha solução inicial selecionará o endereço falsificado nesse caso. Portanto, seria melhor ter um regex com IPs conhecidos removidos e, em vez disso, você pegaria o primeiro IP do cliente não manipulado. Algo assim funcionaria:

set req.http.x-forwarded-for = regsub ( req.http.x-forwarded-for, "(([0-9]{1,3}\.){3}[0-9]{1,3})(, (172.25.20.65|172.25.10.228),?)+$", "" );

em que 172.25.20.65 e 172.25.10.228 são meus IPs confiáveis (proxies ou balanceadores de carga captados e adicionados ao X-Forwarded-For, etc). Dependendo se você espera ver um proxy / LB na frente dele, seu regex pode ser isso se você espera que sempre haja pelo menos um balanceador de carga / proxy no seu cabeçalho:

(([0-9]{1,3}\.){3}[0-9]{1,3})(, (<trustedip1>|<trustedip2>|...),?)+$

ou isto se for permitido não ter nada antes do seu servidor de verniz:

(([0-9]{1,3}\.){3}[0-9]{1,3})(, (<trustedip1>|<trustedip2>|...),?)*$

Embora este seja o caso, por que você estaria olhando para o cabeçalho x-forwarded-for ...