В Linux, учитывая этот вариант использования:
1. User initiates http request for webpage to remote server
2. Remote server answers request and sends packets
Есть ли ссылка на пользователя, запустившего процесс, который отправил запрос на удаленный сервер во входящих пакетах, которые отправляет удаленный сервер?
Я пытаюсь найти способ фильтрации входящего трафика, чтобы я мог ограничивать скорость для каждого пользователя, а не просто ограничивать скорость всей системы.
Это недостижимо изначально в протоколе TCP / IP, потому что ... ну, это просто не то, как протокол работает - он не имеет понятия о пользователях и предназначен только для передачи данных между устройствами.
Обычно это делается (ограничение скорости конкретного удаленного пользователя) за счет использования сеансов (уровень 5 в вашей сетевой модели OSI, который на 1 или 2 уровня выше, чем TCP / IP). Вы назначаете что-то уникальное для каждого пользователя, например файл cookie или токен, чтобы вы могли соотносить отдельные сеансы с конкретными пользователями, которые затем можно передать своему ограничителю скорости (в отличие от просто IP-адреса, что является простым способом сделать это).
Да, вы можете использовать Идентификационный протокол для идентификации пользователя у источника.
Ну, раньше ты умел. В настоящее время единственные люди, которые предоставляют идентификационные серверы Интернету в целом, - это пользователи IRC, которым нужен забавный ник.
Да, и люди, которые неправильно сконфигурировали свои системы.
Формирование трафика для ваших пользователей - неплохая идея, но вы делаете это неправильно - в частности, вы настаиваете на попытках формировать входящий трафик. Эта цитата взята из Linux Advanced Routing and Traffic Control HOWTO
С помощью очереди мы определяем способ, которым данные отправляются. Важно понимать, что мы можем формировать только те данные, которые передаем.
Благодаря тому, как работает Интернет, у нас нет прямого контроля над тем, что люди нам присылают. Это немного похоже на ваш (физический!) Почтовый ящик дома. Вы никак не можете повлиять на мир, чтобы изменить количество писем, которые они вам отправляют, кроме как связаться со всеми.
[...]
Если у вас есть маршрутизатор и вы хотите предотвратить слишком быструю загрузку определенных хостов в вашей сети, вам необходимо выполнить настройку на внутренний интерфейс вашего маршрутизатора, который отправляет данные на ваши компьютеры.
Как сказали voretaq7 и MikeyB в своих комментариях к ответу Hopeless Noob, вы решили выполнить основную задачу X с помощью метода Y, и вы спрашиваете всех нас о методе Y. К сожалению, метод Y - неправильный способ выполнить задачу X. Это ведет к непродуктивным ответам и общему разочарованию.
Обычно есть причины, по которым все обстоит так, как есть, а в свободных программах эти методы редко связаны с маркетингом или другими неуместными; они часто (хотя и не всегда) связаны с фактами и реальностью. Итак, сядьте и прочитайте о методах, предлагаемых для достижения того, чего вы пытаетесь достичь, а затем подумайте, как использовать эти методы для решения вашей конкретной проблемы.
редактировать: trickle вообще не работает с сетевым стеком; он вовлекается гораздо раньше, перехватывая звонки glibcсетевой код для динамически связанных двоичных файлов, которые используют TCP в качестве транспортного механизма.
Это не доказывает, что формирование трафика может использоваться для входящего трафика, это доказывает, что существуют другие подходы к ограничению пропускной способности сети, кроме работы непосредственно с сетевым стеком ядра. Вы также можете делать то, что хотите, с аутентифицирующим прокси, например squid который может устанавливать квоты на полосу пропускания для каждого пользователя.
Позвольте мне пояснить: я не говорю, что то, чего вы хотите, невозможно. Я говорю, что не верю, что вы можете или должны делать это с формированием входящего трафика.
И squid, и trickle фактически подтверждают точку зрения voretaq7 / MikeyB: если бы вы спросили, как добиться того, чего вы на самом деле хотите, вы бы получили гораздо лучшие ответы.
Если iptables правила применяются на хосте, на котором запущен клиент, тогда вы можете использовать owner модуль. Это работает только с исходящими пакетами, поэтому вам нужно будет использовать CONNMARK цель для хранения информации из исходящих пакетов, которая вам понадобится при обработке входящих пакетов.
Этот подход не работает, если пакеты проходят по сетевому каналу между клиентом и межсетевым экраном. Около 15 лет назад я услышал об исследовательском проекте, в котором пытались расширить IP-пакеты в локальной сети информацией, которая позволила бы межсетевому экрану применять правила, аналогичные owner модуль. Я не думаю, что эта реализация когда-либо использовалась в реальной производственной среде.
Придерживаясь уже развернутых протоколов, ident протокол ответ от @MikeyB может быть единственным вариантом. К сожалению, наличие у брандмауэра дополнительной связи для обработки пакета - не лучший вариант. Необходимость буферизовать пакет так, чтобы его судьба могла зависеть от пакетов, полученных в более позднее время, может потребовать фундаментального изменения конструкции фильтрации пакетов. Также вы собираетесь добавить задержку из-за необходимости пары обходов для связи с ident демон. Вы также должны позаботиться о том, чтобы избежать циклических зависимостей, потому что вы делаете пересылку пакетов (т. Е. Уровень IP) в зависимости от ident протокол, который работает поверх TCP.
Дополнительной задержки можно избежать, если к тому времени SYN пакет от клиента пересылается, ident коммуникация инициирована. Тогда он, скорее всего, будет завершен до финала. ACK рукопожатия TCP. Однако инициируя ident связь, которая рано сделает межсетевой экран очень уязвимым для SYN-флуда со стороны LAN. Инициирование ident общение позже сделает атаку немного сложнее, но при этом все еще будет иметь шанс завершить ident перед отправкой первого пакета данных. Однако вы передаете защиту от SYN-флуда из вашей локальной сети в руки случайных серверов в Интернете. Хост в вашей локальной сети может легко вступить в сговор с хостом в Интернете для выполнения флуда, от которого трудно защитить. Возможно, это не новая проблема, любой брандмауэр с отслеживанием состояния может быть уязвим для таких атак.
Важно помнить, что в любой ситуации администратор хоста, на котором запущен клиент, решает, будет ли вам доступна информация о пользователе или нет. Поэтому вы должны быть готовы к ситуациям, в которых пользовательская информация вам недоступна.