Название в значительной степени соответствует. Есть ли какое-либо конкретное поведение, указывающее на наличие балансировщика нагрузки на определенном сайте?
Определенного способа не существует, но есть набор подсказок, которые вы можете найти.
- nmap это. Nmap может дать некоторые подсказки об ОС любого устройства, с которым вы разговариваете. Если там написано BSD, а URL-адрес оканчивается на .aspx, вы на что-то натолкнулись.
- куки: многие балансировщики нагрузки добавляют (или могут добавлять) сессионные куки. Поищите какие-нибудь странные и погуглите, если попадете на форумы поддержки F5, viola.
- различные другие заголовки: многие из них добавляют заголовки в зависимости от того, был ли элемент кэширован или нет (и по другим причинам). Найдите интересные заголовки и погуглите.
- на странице или закопанный в html-комментарий, разработчики часто добавляют «обслуживается web7», чтобы помочь им в устранении неполадок.
- быстро запрашивать один и тот же контент с нескольких разных IP-адресов и сравнивать заголовки ETag. Apache по умолчанию основывает etag на индексе файловой системы, и многие администраторы никогда не пытаются его настроить, поэтому, если вы видите другой Etag для одного и того же контента, вы можете догадаться, что он исходит с разных серверов (работает только с apache, работает только если не настроен, работает только в том случае, если файловая система не используется совместно).
Честно говоря, я бы ожидал, что все это даст вам осмысленный ответ, как 1 раз из 4, хотя в целом вы не можете точно знать, если, как сказала Кэтрин, «что-то не так».
РЕДАКТИРОВАТЬ: это будет очень сложно сделать, если не невозможно (не нравится это слово), поскольку весь смысл LoadBalancer состоит в том, чтобы сделать взаимодействие клиента с ним прозрачным и в основном невидимым. При этом вот мой оригинальный пост:
Я администрирую балансировщик нагрузки для довольно большого сайта. Единственным признаком того, что наши посетители посещают какой-либо конкретный сервер приложений, является то, что мы фактически указываем конкретное имя сервера внизу их страницы входа. Это помогает нам устранять проблемы, которые у них есть.
Помимо этого, я могу придумать только одну вещь, которая «подтолкнет» вас к тому факту, что мы запускаем балансировщик нагрузки, если бы мы не следовали этой политике. Вот как можно сказать, но для этого потребуется немного удачи.
Предположим, что балансировщик нагрузки настроен на пересылку всего трафика на тот или иной сервер. Или, по крайней мере, перенаправляет трафик ssh между одним сервером на другой. Даже если у вас, вероятно, нет кредита для входа в любое поле, оба предоставят вам другой ключ, если вы попытаетесь войти в систему. Поэтому, если вы попытаетесь войти через ssh в первый раз, вас спросят, вы хотите принять ключ. Затем, если вам повезет со вторым или третьим запросом, вам сообщат, что есть другой ключ (т.е. это другое поле). В системе * nix вас часто предупреждают, что это могло произойти из-за атаки человека посередине.
Итак, должны быть выполнены две вещи:
Так что, если вы получаете два ключа за относительно короткий период времени, вы, вероятно, можете предположить, что системный администратор не изменил их, а скорее, что вы только что связались с двумя отдельными машинами за балансировщиком нагрузки.
Примечание: есть еще один предмет, но это настоящий снимок в темноте. Вы можете попытаться выяснить, с каким блоком IP-адресов был сгруппирован этот сервер. Затем предположим, что один из этих IP-адресов размещен на LB (фактически, он находится на одном из этих IP-адресов).
Например, балансировщик нагрузки расположен по адресу XXX.XXX.XXX.5. После этого LB будет настроен на захват всего трафика как минимум для одного дополнительного IP-адреса. Обычно он не пересылает трафик для XXX.XXX.XXX.5 (коммерческое оборудование, которое у меня есть, определенно не делает этого). Так что вы можете рассчитывать на то, что там есть и админский адрес.
Если LB настроен на разрешение администратора со всех внешних хостов, вы можете добавить что-то вроде / admin к IP-адресам, пока не найдете LB. Это предполагает, что LB использует этот путь для администрирования.
IP ID изменяется для каждого IP-стека, таким образом, IP-хост находится «позади» балансировщика нагрузки. Такой инструмент, как hping, даст вам именно это: следите за идентификаторами, которые НЕ принадлежат к тому же диапазону, или - даже если по некоторому странному совпадению достаточно близко - не увеличиваются:
hping3 www.yoursite.com -S -p 80 (or whatever)
Вышеупомянутый захватывает несколько хостов за LB «под» уровнем приложения.
Итак, я думаю, что вопрос был в том, можете ли вы случайно определить по поведению веб-сайта, есть ли балансировщик нагрузки, и я бы рискнул, что ответ будет «нет, если что-то не так» (например, серверы не синхронизированы). Однако по крайней мере теоретически возможно выяснить, есть ли между вами и сервером, отвечающим на запрос, дополнительное «невидимое» устройство. Этим устройством может быть прокси-сервер, перенаправитель портов, статическое устройство NAT, балансировщик нагрузки или, возможно, что-то еще, что я пропустил. В основном все, что отвечает на пинг по IP, но в конечном итоге не обслуживает HTTP-запрос. По сути, вы выясняете, сколько переходов между вами и общедоступным IP-адресом сайта, используя что-то вроде traceroute. Затем вы выполняете некоторую проверку пакетов, чтобы определить TTL пакета, поступающего от хоста. Поскольку возможные начальные значения TTL ограничены и четко определены (если только кто-то не занимается серьезным взломом своего сетевого стека), вы можете определить, есть ли дополнительный переход. Не уверен, что это вам вообще поможет, но я, по крайней мере, думаю, что это интересная мысль.
Если балансировщик нагрузки выполняет постоянство на основе файлов cookie тогда просмотр печенья может дать вам ключ к разгадке.
Обратите особое внимание на заголовки HTTP.
wget --save-заголовки
может помочь вам захватить их ... (есть также плагины Firefox, которые отслеживают заголовки)
Повторяйте одну и ту же страницу снова и снова и ищите чередующиеся заголовки «Last-Modified или Expires».
Многие сайты также кодируют свои серверные серверы в заголовках. Это должно выделяться, если оно есть.
Удачи.
Возможно, стоит попробовать идентифицировать разные стеки IP (если есть) с помощью поля идентификации IP. Вы можете узнать больше о том, как это сделать, на Scapy Demo страницу (найдите строку со словами «поле IPID»).