Иногда я вижу некоторую схему движения, которую не совсем понимаю, и надеюсь, что смогу получить помощь.
Допустим, у меня есть веб-сайт. Я смотрю журналы, поступающие для моего http-сайта, и вижу запрос, проксируемый squid (заголовок Via говорит мне про кальмара). Нет проблем, кто-то проксируется через squid.
Но потом я смотрю на IP. IP-адрес подключения (1.2.3.4) соответствует фактическому физическому местонахождению конечного пользователя. Однако X-Forwarded-For заголовок показывает IP, который - для обсуждения - EC2 (2.3.4.5).
Это может сказать мне, что кто-то, использующий 2.3.4.5, проксируется на squid, работающий на 1.2.3.4. Но это не имеет смысла, потому что я знаю, что этот человек находится в 1.2.3.4. В общем, похоже, что кто-то в 1.2.3.4 использует на EC2 squid, который что-то делает (может быть, безопасность?), Добавляет заголовки XFF и Via, а затем туннелирует обратно в 1.2.3.4 и выходит в Интернет.
Этот последний сценарий кажется запутанным (и очень медленным добавлением дополнительного «прыжка»), но, возможно, мне не хватает какого-то варианта использования или настройки, которые некоторые ИТ-специалисты могут решить.
Кто-нибудь знает, что происходит? Спасибо!
PS: предположим, что никто не подделывает заголовки! Поскольку это действительно происходит регулярно, хотя я бы назвал это крайним случаем.
Я могу вспомнить два случая.
И третий, объединяющий два вышеуказанных:
В X-Forwarded-For может отображать клиента вместе с IP-адресом прокси, например: X-Forwarded-For: client, proxy1, proxy2. Обычно этот заголовок полезен для анализаторов журналов и тому подобного, чтобы иметь исходный IP-адрес для аналитики или других целей, если у вас есть обратный прокси-сервер, вы должны настроить его правильно, чтобы вы не регистрировали все как исходящие от него. Последний IP в этой строке должен быть предпоследним прокси. Если вы получаете только один IP-адрес, он либо плохо настроен, либо только один переход.
В случае, если запрос уже поступает от корпоративного прокси (случай 2), в зависимости от конфигурации он может поступить на ваш обратный прокси (случай 1) и заканчиваться запутанными заголовками (случай 3), если обратный прокси не очистил заголовки. перед добавлением собственных заголовков.
На мой взгляд, наиболее вероятным случаем может быть использование экземпляра EC2 (если вы имели в виду службу Amazon, но подойдет любой VPS) в качестве прокси, чтобы избежать какой-либо блокировки.
Источники:
Покопавшись, я могу сделать вывод, что такого сценария обычно не существует, и это связано с неправильной конфигурацией сети или squid: