Какой выбрать socks прокси и как правильно его настроить для большого количества юзеров?

Question

[Drno]

Доброго дня. Имеем необходимость запустить прокси с 30-40к юзерами. (нет все не будут сидеть одновременно, но должны хранится в конфиге)
Из требований к проксе - поддрежка socks, авторизация по логи\пассу из файла, ограничение скорости. Опенсорс

Что было попробовано - 3proxy. отлично работает до 1000 юзеров, дальше начинает глючить. Такое впечатление что он доходит до определенной строки в файле конфига, и дальше начинает читать с нуля...
Настроен - пароли в /includes, порты тоже в /includes, bandlimits - /includes - при переносе в основной конфиг ситуация не меняет.
Для каждого юзера создается отдельный порт. Почему то при использовании 1го порта с таким количество юзеров, 3proxy начинает отдавать ошибки что порт недоступен(я так и не понял почему) ...

Хочется понять какой прокси лучше ииспользовать с большим количеством портов и юзеров.
Прокси используется для передаресации на него из другого сервиса на localhost, исключительно для ограничения скорости.

Comments

[Alexey Dmitriev]

Непонятно - какой ответ ожидается.
1. 30-40к юзеров в текстовом файле - кривое решение уже с этой точки зрения. И 3proxy тут не виноват - нужно менять подход к авторизации и хранению данных.
2. Не заброшенных Socks прокси не так уж много - и быстрее попробовать другие, чем ждать тут ответа.

[Drno]

Alexey Dmitriev, какие предложения? почему не виноват 3proxy - на их сайте и в гитхаб указано что нет ограничений на количетсво строк \ юзеров в софте..

[Alexey Dmitriev]

Drno, не хранить 40 тысяч записей в текстовом файле

Answer 1

[Алексей Черемисин]

Ну, как-бы сказать. Одним инстансом, и даже одним интерфейсом тут не отделаться.
1) Есть некий предел количества портов в протоколе TCP - это разрядность поля short в заголовке IP. Всего осилите (чуть меньше конечно) 64534 коннекта на один (sic!) IP-адрес.
2) По поводу хранения 30-40к пользователей в файле - я бы так не делал, ну или это был бы не файл, а какая нибудь база данных, да пусть хотя бы файловая BerkleyDB, SQLite или еще что-то в этом роде.
3) По поводу 1000 коннектов и аут - смею предположить, что файл /etc/security/limits.conf и ulimit для вас ничего не значат....

Ну и есть еще Socks5 Dante, попробуйте его, если на все вопросы выше у вас правильные ответы.

А так - тройка IP-адресов, тройка HAProxy на каждом, ну и с пяток инстансов SOCKS5. Скорее всего и взлетит.

Comments

[Drno]

1. да я знаю про количество портов и прочее.
2. пока сложился только такой вариант, не ясно как в таком случае быть с длиннущим конфигом с тем же списоком портов...
3. про ulimit и прочее я вкурсе, это проверялось

Dante имеет планые модули ограничения скорости (

Haproxy зачем в этой схеме? я могу и анпрямую направить юзеров на нужные инстансы, это не проблема...

[Алексей Черемисин]

Drno, Ээээх...
Предположим, что один истанс 3proxy отлично работает с 1к пользователей. А дальше - беде.
Ну, так это же не проблема, поднять 40-50 инстансов!

А проблема - правильно распределить пользователей по ним!
Если бы будем каждому пользователю выдавать

я могу и анпрямую направить юзеров на нужные инстансы

, то какие-то инстансы будут простаивать, а какие-то будут перегружены.
Ну и количество инстансов регулировать уж никак не сможем.

Вот здесь нам и поможет haproxy. Пусть он обслуживает входящие соединения и раскидывает пользователей по имеющимся инстансам. Причем, каждому истансу поставим лимит в 1к коннектов. А еще получим статистику по всему этому хозяйству, ну и в prometeus+grafana все это сливать будем - мыж хотим контроля.
А еще получим возможность чекать упавшие инстансы и не посылать на них трафик...

Конфиг примерно такой (не отлаживал, набросал по памяти)

#/usr/local/etc/haproxy.conf
global
  daemon
  stats socket /var/run/haproxy.sock mode 600 level admin
  stats timeout 2m

defaults
  log     global
  mode tcp
  option tcplog
  option  dontlognull

frontend fSocks5
  mode tcp
  bind *:1080 name socks5
  log global
  option tcplog
  tcp-request inspect-delay 2s
  default_backend bSocks5

backend bSocks5
  mode tcp
  balance leastconn
  log global
  option tcplog
  option tcp-check
  tcp-check connect port 1080
  default-server inter 3s rise 2 fall 3 maxconn 1000 weight 10 check 
  server S01 172.16.50.11:3301 
  server S02 172.16.50.11:3302
# ....
  server S50 172.16.50.11:3350

listen stats 
 bind *:9000
 mode http
 stats enable
 #stats hide-version
 stats show-node
 stats realm Haproxy\ Statistics
 stats uri /

Запускаем, на порту 9000 смотрим статистику...

[Алексей Черемисин]

Drno, Ну, даже конфиг проверил

[Drno]

Алексей Черемисин, за проделанную работу спасибо, но - на 1 порту столько юзеров 3proxy не вывозит почему то, и уходит в "сервис не может обработать запрос"
во вторых - мне будет необходимо передать контейнерам ВСЕМ одинаковые конфиги с портами + логины(допустим даже из сторонней БД)
и мы опять упираемся в то, что 3proxy не обрабатывает столько строк...

пока я вижу только вариант с разбиением по 1к юзеров на контейнер, отдельные конфиги, и деплой 40 контейнеров.. чего хотелось избежать очень сильно (

[Drno]

Алексей Черемисин, или я где то ошибся и чего то недопонял?

[Алексей Черемисин]

Drno,

на 1 порту столько юзеров 3proxy не вывозит почему то

Как это понимать?
Не обрабатывает одновременное подключение больше 1к пользователей?
Или, не видит пользователей в огромном файле конфигурации?

и уходит в "сервис не может обработать запрос"

А что при этом происходит в системе, сколько файлов/потоков открыто 3proxy?

Ну и передать всем контейнерам одинаковые конфиги - вообще проблем не вижу! Шарьте единый каталог с конфигами для всех контейнеров - и будет щазтие.
Тем более все можно автоматизировать, хоть в докере, хоть в podman, не говоря про кибернетс.

Ну и вообще-то 40k пользователей нихрена не просто везде.
У меня порядка 10к устройств - тоже нихрена не просто...

Я Вам показал один из путей решения проблемы, а уж как ее решать конкретно Вам, пока не знаю.

[Алексей Черемисин]

Drno, Кстати - 3proxy умеет в RADIUS. Ставьте FreeRADIUS, держите в нем пользователей, и будет щазтие!

[Алексей Черемисин]

Drno, Ну и напоследок - это читали? https://3proxy.org/highload.asp

[Алексей Черемисин]

Итого, как я себе все вижу:
- haproxy как фронтэнд для зоопарка 3proxy
- куча контейнеров с 3proxy (40), запускается или через compose или через podman, или просто скриптом
- freeradius для общей базы клиентов, возможно с беком из mysql или ldap (тут на вкус и цвет...)
- prometheus/vicrtoriametrics + grafana для подглядывания за зоопарком.
- серверов/ip-адресов по вкусу и нагрузкам, по мере вуаерирования зоопарка :)

[Drno]

Алексей Черемисин, я буду пробовать этот вариант, и насчет Radius уже ясно. это всё поднимется. насчет портов -
почему решили каждому выделять свой отдельный порт.

тестили на 300х одновременных подключений юзеров, на 1 порт (3128 к примеру) - для юзера это выглядит как долгая загрузка \ недоступность сайта.
со стороны 3proxy это выглядит как "очередь" из запросов, которая конечно двигается, но многие коннекты падают по таймауту..

с радиус оттестирую, посмотрим что будет. я и сам понимаю что открытьвать отдельный порт под каждого юзера это бред какой то... тем более конфиг вырастает дико. тем более что 40к это только первоначальное, а дальше их будет еще больше.

вернусь, как проверю Радиус )

Да, highload читали, но не помог что в докере что на хосте... судя по вссему дело реально в длинных конфигах)

[Drno]

Алексей Черемисин, видение хорошее. часть из этого нам не требуется, балансировка происходит внешним приложением благо.. тут надо просто чтоб любой юзер из общего списка был доступен на серваке, не более)

[Алексей Черемисин]

Drno, То, что они сами пишут про 1 connect - 1 thread - это не может стоить дешево для любой системы, им бы хорошо в poll/epoll, но думается (мне, как программисту), это будет дорого стоить по разработке и переделке.

Что же, пожелаю только успехов!

[Drno]

Алексей Черемисин, ну если они реально надеются что я буду юзать 1 ядро на 1 конннект(пользователя) то я проще наберу пачку VPSок и не буду ограничивать скорость))

[Алексей Черемисин]

Drno, не, Вы неправильно поняли! 1 тред, это не одно ядро на коннект! Это программная модель обработки и работы с коннектами. Она расточительная, но менее сильно, чем порождать процесс на каждое новое соединение.
При этом, в большинстве случаев это оправдано с программной точки зрения - проще программировать.
Например сервер apache почти так и работает в версии prefork

[Drno]

Алексей Черемисин, аа.. ну примерно ясно, я просто в програмирование не особо. почитаю)

[Алексей Черемисин]

Drno, Все просто, есть три основные модели работы с сокетами (остальное - варианты этих вариантов).

Первый и самый распространенный - основной процесс ожидает подключений клиентов, после подключения порождает свою копию через вызов fork (или его аналога). Первый процесс продолжает ждать следующих соединений клиентов, а порожденный процесс работает непостедственно с соединением клиента.
Плюсы - очень быстро программировать и отлаживать.
Минусы - много накладных расходов на порождение процессов, жрет лишнюю память в системе, относительно медленно работает.
Примеры - apache prefork.

Второй вариант аналогичен первому, но вместо порождения копии процесса, порождается функция-тред для работы с соединением клиента.
Плюсы - быстро программировать и отлаживать, все быстро работает.
Минусы - требует вдумчивого подхода к программированию, если что случается - падают все соединения разом, все же жрет ресурсы системы.
Примеры - многое современное сетевое ПО, в том числе и 3proxy

Третий вариант - единственный процесс обрабатывает и подключения и соединения с клиентскими сокетами, используя вызовы select/poll/epoll.
Плюсы - все безумно быстро работает, часто сочетают со вторым методом.
Минусы - требует очень вдумчивого подхода к программированию.
Примеры - nginx, haproxy