Вариант для распечатки		Пред. тема | След. тема
Форум Настройка Squid, Tor и прокси серверов (Разное)
Изначальное сообщение		[ Отслеживать ]

"Маршрутизация трафика на основе сервера назначения из заголовка"	+1 +/–
Сообщение от FragMaster (ok), 10-Окт-22, 14:54
Есть: приложение, пускай будет 1С:Розница, оно может обращаться к интернет ресурсам, например, api банков, других гос организаций и т.д. через интернет. Приложение обслуживает 2 юр лица. Задача: Хочется чтобы каждое юр лицо использовало свой интернет для связи со всем внешними миром(эквайринг, какие-то api, ОФД и т.д) Например, 1 комп с приложением обслуживает 2 юр лица и имеет 2 LAN порта, в каждый будет воткнут свой роутер для внешнего инета, все запросы на все внешние ресурсы от одного юр лица должны будут ходить по Lan1, все запросы от другого юр лица должны будут ходить через Lan2. Т.е. для внешних сайтом это будет выглядеть, как 2 независимых друг от друга компа. Пример с 2 LAN портами не является обязательной реализацией и приведен для простоты описания, вместо этого может использоваться 1 роутер с каким-то ПО. Основные проблемы, которые я вижу: - ККТ выгружает в ОФД чеки через  usb over Ethetnet - эквайринговые терминал через  usb over Ethetnet - всякие шлюзы оплаты, с которыми приложение взаимодействует(оплата по qr, api банка и т.д.) Вопрос: Возможна ли реализация работы данного кейса? Если да, то с помощью каких тех средств?
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

1. Сообщение от Аноним (1), 10-Окт-22, 19:14	+/–
https://habr.com/ru/post/108690/ Создаёте отдельную таблицу маршрутизации и направляете в неё трафик на основе IP назначения: ip rule add to 1.1.1.1/32 table ... Ну и маршрут по умолчанию в этой новой таблице прописать не забудьте.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #3

2. Сообщение от shadow_alone (ok), 10-Окт-22, 19:17	+/–
Если исходить из твоего заголовка "сервера назначения" - то всё просто. Если они они ходят на разные api - то есть, первый клиент на свои, второй на свои только и ничего не пересекается, то это решается простой маршрутизацией, даже если разрулить надо по имени назначения (решается маркировкой пакетов по SNI). А вот если они ходят на одни и те же ресурсы, вот тут, наверное НЕТ - потому что твой 1С точно не может метить пакеты.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #6

3. Сообщение от shadow_alone (ok), 10-Окт-22, 19:22	+/–
Позвольте спросить - а НАХРЕНА тут отдельная таблица то? пишите просто чтоб "ляпнуть"? в main таблице прекрасно все разруливается по назначению.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #4

4. Сообщение от Аноним (1), 10-Окт-22, 19:33	+/–
Так правильней. Раз уж есть два провайдера, то в будущем захочется более сложной маршрутизации. А если по-быстрому на коленке для решения конкретной узкой задачи, то можно и в основной таблице прописать правила, конечно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #5

5. Сообщение от shadow_alone (ok), 10-Окт-22, 19:42	–3 +/–
Вы прям спец, я смотрю :-) "так правильный" - сильный аргумент. Правильней потому что вы так решили? Любое "правильней" исходит из текущей задачи. И что кому захочется в будущем, будет решаться в будущем так же. А то, кто-то придет и скажет делать сразу еще одну VRF - потому что "так правильней", а кто-то посоветует сделать через прокси, потому что для него "так правильней". А кто-то вообще наКуй пошлёт, потому что по его мнению "так правильный", и ОН РЕШИЛ что в будущем, точно придется туда идти. Так что, не городите ерунды, задачу нужно решать исходя из текущих вводных.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

6. Сообщение от FragMaster (ok), 10-Окт-22, 19:59	+/–
> Если исходить из твоего заголовка "сервера назначения" - то всё просто. Если > они они ходят на разные api - то есть, первый клиент > на свои, второй на свои только и ничего не пересекается, то > это решается простой маршрутизацией, даже если разрулить надо по имени назначения > (решается маркировкой пакетов по SNI). > А вот если они ходят на одни и те же ресурсы, вот > тут, наверное НЕТ - потому что твой 1С точно не может > метить пакеты. Все верно, приложение обслуживает 2 юр лица и ходить они могут на один и тот же IP. Требуется, чтобы запрос от одного юр лица с этого приложения шел через одного провайдера, а запрос от другого юр лица - через другого
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #7

7. Сообщение от Сергей (??), 10-Окт-22, 22:27	+1 +/–
>[оверквотинг удален] >> на свои, второй на свои только и ничего не пересекается, то >> это решается простой маршрутизацией, даже если разрулить надо по имени назначения >> (решается маркировкой пакетов по SNI). >> А вот если они ходят на одни и те же ресурсы, вот >> тут, наверное НЕТ - потому что твой 1С точно не может >> метить пакеты. > Все верно, приложение обслуживает 2 юр лица и ходить они могут на > один и тот же IP. > Требуется, чтобы запрос от одного юр лица с этого приложения шел через > одного провайдера, а запрос от другого юр лица - через другого   все зависит от вашего приложения, можно ли его настройки привязать на 2-а разных локальных адреса к примеру  либо прописать на разные прокси, то бишь порты, если этого нет, то мне кажется никак...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #8

8. Сообщение от FragMaster (ok), 11-Окт-22, 10:51	+/–
>   все зависит от вашего приложения, можно ли его настройки привязать > на 2-а разных локальных адреса к примеру  либо прописать на > разные прокси, то бишь порты, если этого нет, то мне кажется > никак... Приложение можно доработать, чтобы оно выбирало нужный прокси, в зависимости от юр лица. Я в надежде, что может быть еще какая-то магия есть, кроме проксей =)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #9

9. Сообщение от ыы (?), 11-Окт-22, 11:37	+1 +/–
>>   все зависит от вашего приложения, можно ли его настройки привязать >> на 2-а разных локальных адреса к примеру  либо прописать на >> разные прокси, то бишь порты, если этого нет, то мне кажется >> никак... > Приложение можно доработать, чтобы оно выбирало нужный прокси, в зависимости от юр > лица. > Я в надежде, что может быть еще какая-то магия есть, кроме проксей > =) Инфостарт кончился, а пиво походу еще нет  :) Мне не очень понятна необходимость держать два юрлица с одной базе. Они же не могут пользоваться одними и теми же счетами. И лицензии так сэкономить нельзя. Можно запустить на одной и той же серверной лицензии две базы (два сервера) от разных юзеров и управлять этими процессами как это принято в ОС.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #12

10. Сообщение от Аноним (10), 12-Окт-22, 08:19	+/–
Купить на барахолке роутеры по 500 рублей на провайдер.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #11

11. Сообщение от ыы (?), 12-Окт-22, 08:48	+/–
> Купить на барахолке роутеры по 500 рублей на провайдер. Интересно. Продолжайте...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

12. Сообщение от FragMaster (ok), 12-Окт-22, 09:11	+/–
> Мне не очень понятна необходимость держать два юрлица с одной базе. Они > же не могут пользоваться одними и теми же счетами. И лицензии > так сэкономить нельзя. > Можно запустить на одной и той же серверной лицензии две базы (два > сервера) от разных юзеров и управлять этими процессами как это принято > в ОС. Бизнес логика не позволяет так сделать... Там обмены, перепродажи и т.д.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #14, #17

13. Сообщение от Licha Morada (ok), 12-Окт-22, 21:24	+/–
> Возможна ли реализация работы данного кейса? В принципе, да, но нетривиально. > Если да, то с помощью каких тех средств? Если это запросы ТОЛЬКО по http/https, и юр-лица можно явно отличить друг от друго по хедеру запроса, то можно хитро настроить прокси, например squid. Если это запросы вообще, то всё упирается в то как отличать одно от другого, в формате понятном дле принятия решения о маршрутизации. Как я понимаю, если бюджет позволяет, то это можно сделать с помощью DPI и реверс-инжениринга протоколов каждого из использующихся приложений. А практически, лучше не связывайтесь. В качестве мысленного эксперимента сойдёт, или если есть хобби на предмет "покопаться".
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #15

14. Сообщение от Licha Morada (ok), 12-Окт-22, 21:31	+/–
> Бизнес логика не позволяет так сделать... Там обмены, перепродажи и т.д. Ну, пусть переопределяют логику, или смиряются с тем что всем видно что они в одном и том-же доме живут.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12

15. Сообщение от FragMaster (ok), 13-Окт-22, 08:46	+/–
>[оверквотинг удален] >> Если да, то с помощью каких тех средств? > Если это запросы ТОЛЬКО по http/https, и юр-лица можно явно отличить друг > от друго по хедеру запроса, то можно хитро настроить прокси, например > squid. > Если это запросы вообще, то всё упирается в то как отличать одно > от другого, в формате понятном дле принятия решения о маршрутизации. Как > я понимаю, если бюджет позволяет, то это можно сделать с помощью > DPI и реверс-инжениринга протоколов каждого из использующихся приложений. > А практически, лучше не связывайтесь. В качестве мысленного эксперимента сойдёт, или если > есть хобби на предмет "покопаться". Я вот тоже жизнеспособного варианта кроме прокси не вижу... Проблема только в том, что не все приложения могут поддерживать прокси и не все мы можем доработать так, чтобы поддерживали, но похоже это оправданный риск
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #16, #18

16. Сообщение от Аноним (1), 13-Окт-22, 11:16	+1 +/–
> Проблема только в том, что не все приложения могут поддерживать прокси и > не все мы можем доработать так, чтобы поддерживали, google://проксификатор
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15

17. Сообщение от ыы (?), 13-Окт-22, 20:11	+1 +/–
>> Мне не очень понятна необходимость держать два юрлица с одной базе. Они >> же не могут пользоваться одними и теми же счетами. И лицензии >> так сэкономить нельзя. >> Можно запустить на одной и той же серверной лицензии две базы (два >> сервера) от разных юзеров и управлять этими процессами как это принято >> в ОС. > Бизнес логика не позволяет так сделать... Там обмены, перепродажи и т.д. Ну, если бизнес логика не позволяет двум разным юрлицам вести учет в двух разных программах... то тут дело безусловно в логике. только не в "бизнес ... ", а в просто ... В 1С прекрасно все с обменами. Внешние источники данных, ODBC, вызовы данных через REST сервисы, выгрузки-загрузки через файлы... Настроить автоматический обмен данными между двумя разными системами 1С - вообще не проблема. Мне реально не понятна необходимость держать два юрлица с одной базе.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12

18. Сообщение от ыы (?), 14-Окт-22, 06:53	+/–
>[оверквотинг удален] >> Если это запросы вообще, то всё упирается в то как отличать одно >> от другого, в формате понятном дле принятия решения о маршрутизации. Как >> я понимаю, если бюджет позволяет, то это можно сделать с помощью >> DPI и реверс-инжениринга протоколов каждого из использующихся приложений. >> А практически, лучше не связывайтесь. В качестве мысленного эксперимента сойдёт, или если >> есть хобби на предмет "покопаться". > Я вот тоже жизнеспособного варианта кроме прокси не вижу... > Проблема только в том, что не все приложения могут поддерживать прокси и > не все мы можем доработать так, чтобы поддерживали, но похоже это > оправданный риск а внутри 1С:Розница много приложений?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #19

19. Сообщение от FragMaster (ok), 14-Окт-22, 10:48	+/–
>[оверквотинг удален] >>> от другого, в формате понятном дле принятия решения о маршрутизации. Как >>> я понимаю, если бюджет позволяет, то это можно сделать с помощью >>> DPI и реверс-инжениринга протоколов каждого из использующихся приложений. >>> А практически, лучше не связывайтесь. В качестве мысленного эксперимента сойдёт, или если >>> есть хобби на предмет "покопаться". >> Я вот тоже жизнеспособного варианта кроме прокси не вижу... >> Проблема только в том, что не все приложения могут поддерживать прокси и >> не все мы можем доработать так, чтобы поддерживали, но похоже это >> оправданный риск > а внутри 1С:Розница много приложений? Приложение одно, внутри юр лиц может быть несколько Пока из идей: 1) socks proxy + проксификатор + переписание софта(где можно это сделать) на обращение к конкретному прокси в зависимости от юр лица 2) еще один комп, на котором запущена та же 1С, но со своим инетом. Оператор операции по юр лицу 1 выполняет на 1 компе, операции по 2 юр лицу - на втором. В 1 варианте не гарантированно будут работать всякие ККТ олайн с eth over usb, эквайринговые терминалы ибо , думаю не все они умеют прокси
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #20

20. Сообщение от Аноним (1), 14-Окт-22, 14:29	+/–
> 2) еще один комп, на котором запущена та же 1С, но со > своим инетом. Оператор операции по юр лицу 1 выполняет на 1 > компе, операции по 2 юр лицу - на втором. Если рабочая машина под линуксом, то поможет network namespace. Для юрлица1 запускать прогу в одном неймспейсе, для юрица2 - во втором. Т.е. два скрипта запуска сделать. Если под виндой - сделать две копии бинарника (можно просто хардлинк на ntfs сделать) и настроить проксификатор так, чтобы каждый бинарник работал через свой прокси.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #21, #25

21. Сообщение от ыы (?), 15-Окт-22, 09:02	+/–
>> 2) еще один комп, на котором запущена та же 1С, но со >> своим инетом. Оператор операции по юр лицу 1 выполняет на 1 >> компе, операции по 2 юр лицу - на втором. > Если рабочая машина под линуксом, то поможет network namespace. Для юрлица1 запускать > прогу в одном неймспейсе, для юрица2 - во втором. Т.е. два > скрипта запуска сделать. > Если под виндой - сделать две копии бинарника (можно просто хардлинк на > ntfs сделать) и настроить проксификатор так, чтобы каждый бинарник работал через > свой прокси. И в какойто острый момент он эти ярлычки перепутает...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #22

22. Сообщение от Аноним (1), 15-Окт-22, 10:22	+/–
Ну дык, сесть не за тот компьютер тоже есть вероятность... ¯\_(ツ)_/¯
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #23

23. Сообщение от ыы (?), 15-Окт-22, 12:22	+/–
> Ну дык, сесть не за тот компьютер тоже есть вероятность... > ¯\_(ツ)_/¯ Сесть не за тот компьютер и открыть не ту программу -> не получить никакого ущерба если там куда ты сел нет необходимой функции. В данном случае - необходимая функция есть на обоих инсталляциях (одинаковые юрлица присутствуют и там и там) - и начать работать не от того юрлица- легко. об ошибке  узнаешь уже после того как кнопка отправить сработает. Можно дописать конфигурацию, внедряя дополнительные проверки.. Но... Но... Но божежмой, сколько гемороя нужно дописывать, городить прокси, лезть в код конфигурации реализовывая чудовищно нестандартный кейс по абсолютно нелепейшей причине... правильное решение- разнести юрлица и настроить стандартную функциональность по согласованию данных в двух базах. после чего разнести эти базы по разным датацентрам- один в австралии другой в мексике... Исходную задачу не забыли еще? Чувак опасается, что в некоторых госслужбах ктото заметит что сомнительные перепродажи делаются на подставное лицо... и решать проблему он собирается.. ну вот так как собирается :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #24

24. Сообщение от FragMaster (ok), 16-Окт-22, 14:50	+/–
>[оверквотинг удален] > Но... > Но божежмой, сколько гемороя нужно дописывать, городить прокси, лезть в код конфигурации > реализовывая чудовищно нестандартный кейс по абсолютно нелепейшей причине... > правильное решение- разнести юрлица и настроить стандартную функциональность по согласованию > данных в двух базах. > после чего разнести эти базы по разным датацентрам- один в австралии другой > в мексике... > Исходную задачу не забыли еще? Чувак опасается, что в некоторых госслужбах ктото > заметит что сомнительные перепродажи делаются на подставное лицо... и решать проблему > он собирается.. ну вот так как собирается :) Разделить базу на 2 шт не представляется возможным в силу уже достаточно большого числа баз. Я понимаю, что этот ответ наиболее оптимален и очевиден, но у нас он невозможен. Плюс, вы недооцениваете риски, которые возникают при пересечении IP адресов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23

25. Сообщение от FragMaster (ok), 16-Окт-22, 14:51	+/–
>> 2) еще один комп, на котором запущена та же 1С, но со >> своим инетом. Оператор операции по юр лицу 1 выполняет на 1 >> компе, операции по 2 юр лицу - на втором. > Если рабочая машина под линуксом, то поможет network namespace. Для юрлица1 запускать > прогу в одном неймспейсе, для юрица2 - во втором. Т.е. два > скрипта запуска сделать. > Если под виндой - сделать две копии бинарника (можно просто хардлинк на > ntfs сделать) и настроить проксификатор так, чтобы каждый бинарник работал через > свой прокси. Интересный вариант, спс
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20

26. Сообщение от pavel_simple. (?), 09-Ноя-22, 10:32	+/–
>[оверквотинг удален] > Пример с 2 LAN портами не является обязательной реализацией и приведен для > простоты описания, вместо этого может использоваться 1 роутер с каким-то ПО. > Основные проблемы, которые я вижу: >  - ККТ выгружает в ОФД чеки через  usb over Ethetnet >  - эквайринговые терминал через  usb over Ethetnet >  - всякие шлюзы оплаты, с которыми приложение взаимодействует(оплата по qr, api > банка и т.д.) > Вопрос: > Возможна ли реализация работы данного кейса? > Если да, то с помощью каких тех средств? DNAT
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема