Лак client.ip говорит 127.0.0.1

VLAN является, по существу, виртуальным коммутатором. Если у Вас будут VLAN с другим IP netblocks на них, то Вам будет нужно устройство Уровня 3 для обеспечения возможности соединения между VLAN. Если у Вас будут они все на том же диапазоне IP, то Вам будет нужна возможность соединения Уровня 2 между VLAN, и разделение VLAN бессмысленно.

Наличие VLAN с различными подсетями и никакой маршрутизацией между ними работало бы над переключателями L2, пока у Вас есть магистрали VLAN между ними, но в том сценарии, Вы выделяете различные VLAN и лишаете возможности связываться между ними.

3
задан 28 February 2018 в 11:45
3 ответа

Значение client.ip равно ] 127.0.0.1 , потому что nginx является клиентом. Для Varnish было бы бессмысленно маскировать это значение - даже в ситуациях, подобных вашей, когда Varnish находится за прокси-сервером, вы часто хотите принимать решения на основе IP-адреса того, что действительно подключается к Varnish.

На самом деле вы хотите, чтобы nginx поместил IP-адрес удаленного клиента в специальный заголовок (который вы он уже работает с X-Real-IP ) и используйте его для принятия решений о подключении. Мы делаем именно это в нашей среде, где Apache предоставил SSL-соединение перед varnish , а затем мы используем этот заголовок для принятия решений о доступе.

Это не так хорошо, как использование клиента . ip (вы не можете сопоставить его с помощью acl s), но он работает. Мы делаем что-то вроде этого:

if (! (
        req.http.X-Real-IP ~ "^10\." ||
        req.http.X-Real-IP ~ "^100\.100\." ||
        req.http.X-Real-IP ~ "^200\.200\."
)) {
        error 403 "Forbidden";
}

Varnish не предоставляет собственный механизм для замены client.ip настраиваемым заголовком, но возможно решить проблему в любом случае, потому что вы может вставлять произвольный код C. в вашу конфигурацию.

Здесь - это пример, который точно соответствует вашей ситуации, который включает пример замены клиента.

3
ответ дан 3 December 2019 в 05:46

If you're using Varnish as your front-end webserver (our backend is NGINX) behind a Rackspace Cloud Load Balancer, then you need to use a pattern like the following:

if (!(
    req.http.X-Forwarded-For ~ "1\.2\.3\.4" || 
    req.http.X-Forwarded-For ~ "2\.3\.4\.5" 
    )) {
    # IP-based Rules
}

Rackspace Cloud Load Balancer won't pass anything but 127.0.0.1 to Varnish as client.ip. Also, I tried using a more restrictive pattern, like ^2\.3\.4\.5$ but it wouldn't match. I think the load balancer was adding extra characters to the X-Forwarded-For header.

1
ответ дан 3 December 2019 в 05:46

Если в вашем запросе доступен req.http.X-Real-IP, то вы можете использовать функцию ip () модуля std для преобразования строку (например, req.http.X-Real-IP) в тип IP, а затем используйте оператор ~, чтобы сравнить ее со списком ACL. Это более эффективно, чем сравнение нескольких значений времени с некоторыми строками IP. acl aclRestricted { «1.1.1.1»; «2.2.2.2»; } if (std.ip (req.http.X-Real-IP, "0.0.0.0") ~ aclRestricted) { ... }

Эталонный лак V4.1: https://varnish-cache.org/docs/4.1/reference/vmod_std.generated.html#func-ip

1
ответ дан 3 December 2019 в 05:46

Теги

Похожие вопросы