Название в целом верное. Есть ли какое-то конкретное поведение, указывающее на наличие балансировщика нагрузки на определенном сайте?
решение1
EDIT: Это будет очень трудно сделать, если не невозможно (не люблю это слово), поскольку весь смысл наличия LoadBalancer заключается в том, чтобы сделать взаимодействие клиента с ним прозрачным и в основном невидимым. С учетом сказанного, вот мой оригинальный пост:
Я администрирую балансировщик нагрузки для довольно большого сайта. Единственное указание на то, что наши посетители посещают какой-то конкретный сервер приложений, — это то, что мы фактически помещаем конкретное имя сервера в нижнюю часть их страницы входа. Это помогает нам устранять неполадки, которые у них возникают.
Кроме этого, я могу придумать только одну вещь, которая "подтолкнула бы" вас к тому факту, что мы используем балансировщик нагрузки, если бы мы не следовали этой политике. Вот как вы могли бы это определить, но это потребует некоторой удачи.
Допустим, что балансировщик нагрузки настроен на пересылку всего трафика либо на один сервер, либо на другой. Или, по крайней мере, он пересылает трафик ssh между одним сервером и другим. Даже если у вас, вероятно, нет учетных данных для входа в любой из серверов, оба сервера предоставят вам другой ключ, если вы попытаетесь войти. Поэтому, если вы попытаетесь войти через ssh в первый раз, вас спросят, хотите ли вы принять ключ. Затем, если вам повезет со вторым или третьим запросом, вам сообщат, что есть другой ключ (т. е. это другой сервер). В системе *nix вы часто получаете предупреждение о том, что это может быть связано с атакой man in the middle.
Поэтому необходимо выполнить две вещи:
- SSH на удаленном сервере
- LB SSH
Поэтому, если вы получили два ключа за относительно короткий промежуток времени, вы, вероятно, можете предположить, что системный администратор их не менял, а просто взаимодействовал с двумя отдельными машинами за балансировщиком нагрузки.
Примечание: есть еще один пункт, но это настоящий выстрел в темноте. Вы можете попытаться выяснить, с каким блоком IP-адресов был сгруппирован этот сервер. Затем предположим, что на одном из этих IP-адресов размещен LB (фактически он находится на одном из этих IP-адресов).
Например, балансировщик нагрузки размещается на XXX.XXX.XXX.5. Затем LB будет настроен на захват всего трафика по крайней мере для одного дополнительного IP-адреса. Обычно он не пересылает трафик для XXX.XXX.XXX.5 (коммерческое оборудование, которое у меня есть, определенно этого не делает). Поэтому вы можете рассчитывать на наличие административного адреса.
Если LB настроен на разрешение администрирования со всех внешних хостов, вы можете добавить что-то вроде /admin к IP-адресам, пока не найдете LB. Это предполагает, что LB использует этот путь для администрирования.
решение2
Определенного способа нет, но есть набор подсказок, которые вы можете поискать.
- nmap это. nmap может дать некоторые подсказки об ОС любого устройства, с которым вы общаетесь. Если там написано BSD и URL заканчивается на .aspx, вы на верном пути.
- файлы cookie: многие балансировщики нагрузки добавляют (или могут добавлять) сеансовые файлы cookie. Ищите любые странные и гуглите их, если вы попадете на форумы поддержки F5, вуаля.
- различные другие заголовки: многие из них добавляют заголовки на основе таких вещей, как был ли элемент кэширован или нет (и других причин). Ищите любые интересные заголовки и гуглите их.
- на странице или в html-комментарии разработчики обычно добавляют «обслуживается web7», чтобы помочь им устранять неполадки.
- быстро запрашивайте один и тот же контент с нескольких разных IP-адресов и сравнивайте заголовки ETag. Apache по умолчанию основывает etag на inode файловой системы, и многие администраторы никогда не удосуживаются его настраивать, поэтому, если вы видите другой Etag для одного и того же контента, вы можете предположить, что он поступает с разных серверов (работает только с Apache, работает только если не настроен, работает только если файловая система не является общей).
Честно говоря, я ожидаю, что все это даст вам осмысленный ответ только в одном случае из четырех, в целом вы не можете знать наверняка, если только, как сказала Кэтрин, «что-то не так».
решение3
IP ID меняется для каждого IP-стека, таким образом IP-хост "позади" балансировщика нагрузки. Инструмент вроде hping даст вам именно это: отслеживайте ID, которые НЕ принадлежат одному диапазону или - даже если по странному совпадению достаточно близки - не увеличиваются:
hping3 www.yoursite.com -S -p 80 (or whatever)
Вышеуказанный пример перехватывает несколько хостов за LB «под» прикладным уровнем.
решение4
Если балансировщик нагрузки делаетсохранение на основе файлов cookieто, взглянув на печенье, вы, возможно, найдете подсказку.