info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: Нужен прокси, но хитрый
2 views
Skip to first unread message
Eugene Berdnikov
Mar 23, 2023, 6:10:04 AM3/23/23
to
On Thu, Mar 23, 2023 at 01:26:04PM +0400, Maksim Dmitrichenko wrote:
> Хочется поиметь такой HTTP Proxy сервер, который:
> а) будет балансировать соединения из внутренней сети в Интернет по
> определенному набору внешних айпишников (к каждому из которых на хосте
> прокси имеется, например, VPN-соединение, то есть айпишники не на
> интерфейсах хоста, где запущен прокси, а до них ещё один хоп).
> б) умеет группировать айпишники по группам (с помощью конфигурации), а
> клиент имеет возможность выбрать группу (например в заголовке к методу
> CONNECT).
Ну, это всё незамысловато строгается через squid+iproute+iptables...
Даёте группе свой выходной src_ip, и через ip rule его на нужный шлюз.
Вот только установка своих заголовков может быть лишь в палате для буйных,
где каждый себе своего клиента строчит и свои заголовки в запрос вставить
может. А простые юзеры могут лишь в настройках браузера порт или ip-адрес
прокси выбрать (по порту и ip сквид разрулить трафик может).
> в) умеет гарантировать, что для отдельного взятого клиента очередной
> CONNECT поедет через такой айпи, через который данный клиент ещё не
> законнекчен или выдаст ошибку (типа 429). Идентификацию клиента можно
> делать авторизацией или каким-то уникальным значением, которое передается,
> например, опять же в одном из заголовков к методу CONNECT.
Боюсь, для столь удивительной задачи ничего готового не найти.
Тем более что статус 4xx по превышению числа коннекций это точно не для
людей, даже из палаты для буйных. :)
--
Eugene Berdnikov
> Хочется поиметь такой HTTP Proxy сервер, который:
> а) будет балансировать соединения из внутренней сети в Интернет по
> определенному набору внешних айпишников (к каждому из которых на хосте
> прокси имеется, например, VPN-соединение, то есть айпишники не на
> интерфейсах хоста, где запущен прокси, а до них ещё один хоп).
> б) умеет группировать айпишники по группам (с помощью конфигурации), а
> клиент имеет возможность выбрать группу (например в заголовке к методу
> CONNECT).
Ну, это всё незамысловато строгается через squid+iproute+iptables...
Даёте группе свой выходной src_ip, и через ip rule его на нужный шлюз.
Вот только установка своих заголовков может быть лишь в палате для буйных,
где каждый себе своего клиента строчит и свои заголовки в запрос вставить
может. А простые юзеры могут лишь в настройках браузера порт или ip-адрес
прокси выбрать (по порту и ip сквид разрулить трафик может).
> в) умеет гарантировать, что для отдельного взятого клиента очередной
> CONNECT поедет через такой айпи, через который данный клиент ещё не
> законнекчен или выдаст ошибку (типа 429). Идентификацию клиента можно
> делать авторизацией или каким-то уникальным значением, которое передается,
> например, опять же в одном из заголовков к методу CONNECT.
Боюсь, для столь удивительной задачи ничего готового не найти.
Тем более что статус 4xx по превышению числа коннекций это точно не для
людей, даже из палаты для буйных. :)
--
Eugene Berdnikov
Andrey Jr. Melnikov
Mar 23, 2023, 9:20:04 AM3/23/23
to
Maksim Dmitrichenko <dmit...@gmail.com> wrote:
> [-- text/plain, encoding base64, charset: UTF-8, 75 lines --]
> чт, 23 мар. 2023 г. в 14:01, Eugene Berdnikov <b...@protva.ru>:
> > On Thu, Mar 23, 2023 at 01:26:04PM +0400, Maksim Dmitrichenko wrote:
> > > Хочется поиметь такой HTTP Proxy сервер, который:
> > > а) будет балансировать соединения из внутренней сети в Интернет по
> > > определенному набору внешних айпишников (к каждому из которых на хосте
> > > прокси имеется, например, VPN-соединение, то есть айпишники не на
> > > интерфейсах хоста, где запущен прокси, а до них ещё один хоп).
> > > б) умеет группировать айпишники по группам (с помощью конфигурации), а
> > > клиент имеет возможность выбрать группу (например в заголовке к методу
> > > CONNECT).
> >
> > Ну, это всё незамысловато строгается через squid+iproute+iptables...
> > Даёте группе свой выходной src_ip, и через ip rule его на нужный шлюз.
> Таким образом нельзя программно-протокольным образом выбрать группу
> адресов, через которую отправится предстоящее соединение. Если я правильно
> понял предлагаемую схему.
Можно. Если ты конечно по пакету с tcp syn сможешь угадать, в что-же там
унутре такое и куда его деть.
[...]
> Нормальное поведение любой REST-овой APIшки возвращать 429, если превышен,
> например, RPS к её вызовам. Вам что-то буйные мерещатся в каждом абзаце.
А чем этот твой REST crap отличается от Васи с IE6.0 ? Тем, что Вася на
стуле и один - а твое намазано по кластеру под докером/киберентсом/чётамсейчасмодно?
> [-- text/plain, encoding base64, charset: UTF-8, 75 lines --]
> чт, 23 мар. 2023 г. в 14:01, Eugene Berdnikov <b...@protva.ru>:
> > On Thu, Mar 23, 2023 at 01:26:04PM +0400, Maksim Dmitrichenko wrote:
> > > Хочется поиметь такой HTTP Proxy сервер, который:
> > > а) будет балансировать соединения из внутренней сети в Интернет по
> > > определенному набору внешних айпишников (к каждому из которых на хосте
> > > прокси имеется, например, VPN-соединение, то есть айпишники не на
> > > интерфейсах хоста, где запущен прокси, а до них ещё один хоп).
> > > б) умеет группировать айпишники по группам (с помощью конфигурации), а
> > > клиент имеет возможность выбрать группу (например в заголовке к методу
> > > CONNECT).
> >
> > Ну, это всё незамысловато строгается через squid+iproute+iptables...
> > Даёте группе свой выходной src_ip, и через ip rule его на нужный шлюз.
> адресов, через которую отправится предстоящее соединение. Если я правильно
> понял предлагаемую схему.
Можно. Если ты конечно по пакету с tcp syn сможешь угадать, в что-же там
унутре такое и куда его деть.
[...]
> Нормальное поведение любой REST-овой APIшки возвращать 429, если превышен,
> например, RPS к её вызовам. Вам что-то буйные мерещатся в каждом абзаце.
А чем этот твой REST crap отличается от Васи с IE6.0 ? Тем, что Вася на
стуле и один - а твое намазано по кластеру под докером/киберентсом/чётамсейчасмодно?
Eugene Berdnikov
Mar 23, 2023, 10:00:03 AM3/23/23
to
On Thu, Mar 23, 2023 at 04:20:16PM +0400, Maksim Dmitrichenko wrote:
> чт, 23 мар. 2023 г. в 14:01, Eugene Berdnikov <[1]b...@protva.ru>:
Сквид умеет задавать src_ip исходящих соединений, по заданным в конфиге
критериям. В эти критерии могут входить параметры соединения, выбираемые
на стороне клиента, конкретно dst_ip и dst_port. Как вместо одного
исходящего от сквида src_ip сделать пул адресов -- задача на дом.
--
Eugene Berdnikov
> чт, 23 мар. 2023 г. в 14:01, Eugene Berdnikov <[1]b...@protva.ru>:
> Ну, это всё незамысловато строгается через squid+iproute+iptables...
> Даёте группе свой выходной src_ip, и через ip rule его на нужный шлюз.
>
> Даёте группе свой выходной src_ip, и через ip rule его на нужный шлюз.
>
> Таким образом нельзя программно-протокольным образом выбрать группу
> адресов, через которую отправится предстоящее соединение. Если я правильно
> понял предлагаемую схему.
Что значит "программно-протокольным образом"?
> адресов, через которую отправится предстоящее соединение. Если я правильно
> понял предлагаемую схему.
Сквид умеет задавать src_ip исходящих соединений, по заданным в конфиге
критериям. В эти критерии могут входить параметры соединения, выбираемые
на стороне клиента, конкретно dst_ip и dst_port. Как вместо одного
исходящего от сквида src_ip сделать пул адресов -- задача на дом.
--
Eugene Berdnikov
Andrey Jr. Melnikov
Mar 23, 2023, 11:30:03 AM3/23/23
to
Eugene Berdnikov <b...@protva.ru> wrote:
> On Thu, Mar 23, 2023 at 04:20:16PM +0400, Maksim Dmitrichenko wrote:
> > чт, 23 мар. 2023 г. в 14:01, Eugene Berdnikov <[1]b...@protva.ru>:
> > Ну, это всё незамысловато строгается через squid+iproute+iptables...
> > Даёте группе свой выходной src_ip, и через ip rule его на нужный шлюз.
> >
> > Таким образом нельзя программно-протокольным образом выбрать группу
> > адресов, через которую отправится предстоящее соединение. Если я правильно
> > понял предлагаемую схему.
> Что значит "программно-протокольным образом"?
Явно ему хочется посмотреть во внутрь протокола.
> On Thu, Mar 23, 2023 at 04:20:16PM +0400, Maksim Dmitrichenko wrote:
> > чт, 23 мар. 2023 г. в 14:01, Eugene Berdnikov <[1]b...@protva.ru>:
> > Ну, это всё незамысловато строгается через squid+iproute+iptables...
> > Даёте группе свой выходной src_ip, и через ip rule его на нужный шлюз.
> >
> > Таким образом нельзя программно-протокольным образом выбрать группу
> > адресов, через которую отправится предстоящее соединение. Если я правильно
> > понял предлагаемую схему.
> Что значит "программно-протокольным образом"?
> Сквид умеет задавать src_ip исходящих соединений, по заданным в конфиге
> критериям. В эти критерии могут входить параметры соединения, выбираемые
> на стороне клиента, конкретно dst_ip и dst_port. Как вместо одного
> исходящего от сквида src_ip сделать пул адресов -- задача на дом.
бонусная.
Eugene Berdnikov
Mar 23, 2023, 12:00:03 PM3/23/23
to
On Thu, Mar 23, 2023 at 06:15:12PM +0300, Andrey Jr. Melnikov wrote:
> > Сквид умеет задавать src_ip исходящих соединений, по заданным в конфиге
> > критериям. В эти критерии могут входить параметры соединения, выбираемые
> > на стороне клиента, конкретно dst_ip и dst_port. Как вместо одного
> > исходящего от сквида src_ip сделать пул адресов -- задача на дом.
> И почему на том-же nginx это будет сделать проще и гибчче - тоже на дом, как
> бонусная.
Nginx это реверсный прокси, он не умеет CONNECT, который товарищу очень
> > Сквид умеет задавать src_ip исходящих соединений, по заданным в конфиге
> > критериям. В эти критерии могут входить параметры соединения, выбираемые
> > на стороне клиента, конкретно dst_ip и dst_port. Как вместо одного
> > исходящего от сквида src_ip сделать пул адресов -- задача на дом.
> И почему на том-же nginx это будет сделать проще и гибчче - тоже на дом, как
> бонусная.
хочется, да ещё со своими кастомными хедерами. Хотя исходная постановка
задачи допускает разные толкования и предположения, что там хочется...
--
Eugene Berdnikov
Andrey Jr. Melnikov
Mar 24, 2023, 5:20:04 AM3/24/23
to
Eugene Berdnikov <b...@protva.ru> wrote:
> On Thu, Mar 23, 2023 at 06:15:12PM +0300, Andrey Jr. Melnikov wrote:
> > > Сквид умеет задавать src_ip исходящих соединений, по заданным в конфиге
> > > критериям. В эти критерии могут входить параметры соединения, выбираемые
> > > на стороне клиента, конкретно dst_ip и dst_port. Как вместо одного
> > > исходящего от сквида src_ip сделать пул адресов -- задача на дом.
> > И почему на том-же nginx это будет сделать проще и гибчче - тоже на дом, как
> > бонусная.
> Nginx это реверсный прокси, он не умеет CONNECT, который товарищу очень
> хочется, да ещё со своими кастомными хедерами. Хотя исходная постановка
Найти модуль на github для поддержки connect - это такое сильное google-fu?
> On Thu, Mar 23, 2023 at 06:15:12PM +0300, Andrey Jr. Melnikov wrote:
> > > Сквид умеет задавать src_ip исходящих соединений, по заданным в конфиге
> > > критериям. В эти критерии могут входить параметры соединения, выбираемые
> > > на стороне клиента, конкретно dst_ip и dst_port. Как вместо одного
> > > исходящего от сквида src_ip сделать пул адресов -- задача на дом.
> > И почему на том-же nginx это будет сделать проще и гибчче - тоже на дом, как
> > бонусная.
> Nginx это реверсный прокси, он не умеет CONNECT, который товарищу очень
> хочется, да ещё со своими кастомными хедерами. Хотя исходная постановка
> задачи допускает разные толкования и предположения, что там хочется...
Да сдаётся мне, что исходнаяя задача гораздо проще, чем попытка её описать
страшными словами ;)
Maksim Dmitrichenko
Mar 24, 2023, 1:20:06 PM3/24/23
to
пт, 24 мар. 2023 г. в 14:17, Dmitry Zhiglov <dmitry....@gmail.com>:
haproxy?
haproxy не умеет так. Если его ставить в разрыв HTTP, то без подмены сертификатов это не будет работать, так как APIшки сделаны все на HTTPS
With best regards
Maksim Dmitrichenko
Maksim Dmitrichenko
Andrey Jr. Melnikov
Mar 24, 2023, 4:30:04 PM3/24/23
to
Maksim Dmitrichenko <dmit...@gmail.com> wrote:
> [-- text/plain, encoding base64, charset: UTF-8, 44 lines --]
> чт, 23 мар. 2023 г. в 17:12, Andrey Jr. Melnikov <temno...@gmail.com>:
> > Можно. Если ты конечно по пакету с tcp syn сможешь угадать, в что-же там
> > унутре такое и куда его деть.
> >
> Какой ты искромётный шутник. Это было бы даже смешно, если бы в постановке
> задачи не было слов "HTTP Proxy"
Судя по тому, как ты не можешь описать задачу - за тебя приходиться
додумывать.
> > [...]
> >
> > > Нормальное поведение любой REST-овой APIшки возвращать 429, если
> > превышен,
> > > например, RPS к её вызовам. Вам что-то буйные мерещатся в каждом абзаце.
> > А чем этот твой REST crap отличается от Васи с IE6.0 ?
> Млять. Что за токсичность с порога? Почему мой? Вполне себе сторонний и не
Ааа, любитель новмомдного сленга...
> один. Почему сразу crap? Предъяви сообществу результаты своих трудов,
> посмотрим, что ты ваяешь так словоохотливо заочно критикуя что-то чужое.
Да-да-да, сперва добейся (С). GTFO.
> > Тем, что Вася на
> > стуле и один - а твое намазано по кластеру под
> > докером/киберентсом/чётамсейчасмодно?
> >
> Кажется, что ты задержался где-то году в 2007, оттуда и все твои вопросы и
> этот лёгких налёт брезгливости ко всему соверменному. Время было по своему
> хорошее, но на дворе 2023. Отличается, например, тем, что API и не
> предполагает того, что Васян будет вбивать URL с параметрами в строку
> браузера, а рассчитано оно на то, что к нему обращаются скрипты и прочие
> программы. И вендроские заголовки в реквестах к апишкам - это суровая быль.
> Поэтому ничего такого буйного в том, что нужно указывать дополнительные
> заголовки, которые осуждал Eugene Berdnikov, нет.
Нет, это ты не понимаешь - что HTTP оно, что с вендорскоми заголовками
HTTP, что без них. И чем их там кто сгенерил - всем наплевать. Что Вася
модулем под мозиллу, что Петя своим любимым питоном.
PS: Любой vendor lock - crap. Что HTTP, что не HTTP. И не зависит от размера
вендора, его именитости и прочих капитализаций и членства в open-source
сообществе.
> [-- text/plain, encoding base64, charset: UTF-8, 44 lines --]
> чт, 23 мар. 2023 г. в 17:12, Andrey Jr. Melnikov <temno...@gmail.com>:
> > Можно. Если ты конечно по пакету с tcp syn сможешь угадать, в что-же там
> > унутре такое и куда его деть.
> >
> задачи не было слов "HTTP Proxy"
Судя по тому, как ты не можешь описать задачу - за тебя приходиться
додумывать.
> > [...]
> >
> > > Нормальное поведение любой REST-овой APIшки возвращать 429, если
> > превышен,
> > > например, RPS к её вызовам. Вам что-то буйные мерещатся в каждом абзаце.
> > А чем этот твой REST crap отличается от Васи с IE6.0 ?
Ааа, любитель новмомдного сленга...
> один. Почему сразу crap? Предъяви сообществу результаты своих трудов,
> посмотрим, что ты ваяешь так словоохотливо заочно критикуя что-то чужое.
Да-да-да, сперва добейся (С). GTFO.
> > Тем, что Вася на
> > стуле и один - а твое намазано по кластеру под
> > докером/киберентсом/чётамсейчасмодно?
> >
> этот лёгких налёт брезгливости ко всему соверменному. Время было по своему
> хорошее, но на дворе 2023. Отличается, например, тем, что API и не
> предполагает того, что Васян будет вбивать URL с параметрами в строку
> браузера, а рассчитано оно на то, что к нему обращаются скрипты и прочие
> программы. И вендроские заголовки в реквестах к апишкам - это суровая быль.
> Поэтому ничего такого буйного в том, что нужно указывать дополнительные
> заголовки, которые осуждал Eugene Berdnikov, нет.
Нет, это ты не понимаешь - что HTTP оно, что с вендорскоми заголовками
HTTP, что без них. И чем их там кто сгенерил - всем наплевать. Что Вася
модулем под мозиллу, что Петя своим любимым питоном.
PS: Любой vendor lock - crap. Что HTTP, что не HTTP. И не зависит от размера
вендора, его именитости и прочих капитализаций и членства в open-source
сообществе.
Eugene Berdnikov
Mar 25, 2023, 3:20:03 AM3/25/23
to
On Fri, Mar 24, 2023 at 09:07:00PM +0400, Maksim Dmitrichenko wrote:
> чт, 23 мар. 2023 г. в 17:56, Eugene Berdnikov <b...@protva.ru>:
> выбранного host:port соединение будет выходить всегда с одной и той же
> группы адресов. Задача как раз в том, что первое соединение установить с
> одной группы, второе - со второй, а третье - мы вообще не указываем
> желаемую группу, и прокся, например, сама решает каким-нить
> round-robin'ом, какой src_ip выбрать. Поднимать несколько сквидов - по
> одному на каждую группу: тоже так себе вариант
Kлиент может для первого соединения использовать одну комбинацию проксевого
ip:port, для следующего -- другую, а если хочет предоставить выбор группы
проксе, то третью. Вы лишь хотите, чтобы этот выбор был реализован не в
параметрах соединения на 4-м уровне модели OSI, а в заголовках запроса,
т.е. на более высоком уровне. Не знаю, чем может быть так ограничен выбор
(может быть в вашей местности настоящих буйных мало:)), но если хотите
именно такой прокси, предложить готовый не могу.
--
Eugene Berdnikov
> чт, 23 мар. 2023 г. в 17:56, Eugene Berdnikov <b...@protva.ru>:
>
> Сквид умеет задавать src_ip исходящих соединений, по заданным в конфиге
> критериям. В эти критерии могут входить параметры соединения,
> выбираемые
> на стороне клиента, конкретно dst_ip и dst_port. Как вместо одного
> исходящего от сквида src_ip сделать пул адресов -- задача на дом.
>
> Я в курсе, как работает сквид. Но мне не нужна конфигурация, когда для
> Сквид умеет задавать src_ip исходящих соединений, по заданным в конфиге
> критериям. В эти критерии могут входить параметры соединения,
> выбираемые
> на стороне клиента, конкретно dst_ip и dst_port. Как вместо одного
> исходящего от сквида src_ip сделать пул адресов -- задача на дом.
>
> выбранного host:port соединение будет выходить всегда с одной и той же
> группы адресов. Задача как раз в том, что первое соединение установить с
> одной группы, второе - со второй, а третье - мы вообще не указываем
> желаемую группу, и прокся, например, сама решает каким-нить
> round-robin'ом, какой src_ip выбрать. Поднимать несколько сквидов - по
> одному на каждую группу: тоже так себе вариант
Kлиент может для первого соединения использовать одну комбинацию проксевого
ip:port, для следующего -- другую, а если хочет предоставить выбор группы
проксе, то третью. Вы лишь хотите, чтобы этот выбор был реализован не в
параметрах соединения на 4-м уровне модели OSI, а в заголовках запроса,
т.е. на более высоком уровне. Не знаю, чем может быть так ограничен выбор
(может быть в вашей местности настоящих буйных мало:)), но если хотите
именно такой прокси, предложить готовый не могу.
--
Eugene Berdnikov
0 new messages