- Маршрутизация трафика на основе сервера назначения из заголовка, Аноним, 19:14 , 10-Окт-22 (1)
https://habr.com/ru/post/108690/Создаёте отдельную таблицу маршрутизации и направляете в неё трафик на основе IP назначения: ip rule add to 1.1.1.1/32 table ... Ну и маршрут по умолчанию в этой новой таблице прописать не забудьте.
- Маршрутизация трафика на основе сервера назначения из заголовка, shadow_alone, 19:22 , 10-Окт-22 (3)
Позвольте спросить - а НАХРЕНА тут отдельная таблица то? пишите просто чтоб "ляпнуть"? в main таблице прекрасно все разруливается по назначению.
- Маршрутизация трафика на основе сервера назначения из заголовка, Аноним, 19:33 , 10-Окт-22 (4)
Так правильней. Раз уж есть два провайдера, то в будущем захочется более сложной маршрутизации.А если по-быстрому на коленке для решения конкретной узкой задачи, то можно и в основной таблице прописать правила, конечно.
- Маршрутизация трафика на основе сервера назначения из заголовка, shadow_alone, 19:42 , 10-Окт-22 (5) –3
Вы прям спец, я смотрю :-) "так правильный" - сильный аргумент. Правильней потому что вы так решили? Любое "правильней" исходит из текущей задачи. И что кому захочется в будущем, будет решаться в будущем так же. А то, кто-то придет и скажет делать сразу еще одну VRF - потому что "так правильней", а кто-то посоветует сделать через прокси, потому что для него "так правильней". А кто-то вообще наКуй пошлёт, потому что по его мнению "так правильный", и ОН РЕШИЛ что в будущем, точно придется туда идти. Так что, не городите ерунды, задачу нужно решать исходя из текущих вводных.
- Маршрутизация трафика на основе сервера назначения из заголовка, shadow_alone, 19:17 , 10-Окт-22 (2)
Если исходить из твоего заголовка "сервера назначения" - то всё просто. Если они они ходят на разные api - то есть, первый клиент на свои, второй на свои только и ничего не пересекается, то это решается простой маршрутизацией, даже если разрулить надо по имени назначения (решается маркировкой пакетов по SNI). А вот если они ходят на одни и те же ресурсы, вот тут, наверное НЕТ - потому что твой 1С точно не может метить пакеты.
- Маршрутизация трафика на основе сервера назначения из заголовка, FragMaster, 19:59 , 10-Окт-22 (6)
> Если исходить из твоего заголовка "сервера назначения" - то всё просто. Если > они они ходят на разные api - то есть, первый клиент > на свои, второй на свои только и ничего не пересекается, то > это решается простой маршрутизацией, даже если разрулить надо по имени назначения > (решается маркировкой пакетов по SNI). > А вот если они ходят на одни и те же ресурсы, вот > тут, наверное НЕТ - потому что твой 1С точно не может > метить пакеты.Все верно, приложение обслуживает 2 юр лица и ходить они могут на один и тот же IP. Требуется, чтобы запрос от одного юр лица с этого приложения шел через одного провайдера, а запрос от другого юр лица - через другого
- Маршрутизация трафика на основе сервера назначения из заголовка, Сергей, 22:27 , 10-Окт-22 (7) +1
>[оверквотинг удален] >> на свои, второй на свои только и ничего не пересекается, то >> это решается простой маршрутизацией, даже если разрулить надо по имени назначения >> (решается маркировкой пакетов по SNI). >> А вот если они ходят на одни и те же ресурсы, вот >> тут, наверное НЕТ - потому что твой 1С точно не может >> метить пакеты. > Все верно, приложение обслуживает 2 юр лица и ходить они могут на > один и тот же IP. > Требуется, чтобы запрос от одного юр лица с этого приложения шел через > одного провайдера, а запрос от другого юр лица - через другого все зависит от вашего приложения, можно ли его настройки привязать на 2-а разных локальных адреса к примеру либо прописать на разные прокси, то бишь порты, если этого нет, то мне кажется никак...
- Маршрутизация трафика на основе сервера назначения из заголовка, FragMaster, 10:51 , 11-Окт-22 (8)
> все зависит от вашего приложения, можно ли его настройки привязать > на 2-а разных локальных адреса к примеру либо прописать на > разные прокси, то бишь порты, если этого нет, то мне кажется > никак...Приложение можно доработать, чтобы оно выбирало нужный прокси, в зависимости от юр лица. Я в надежде, что может быть еще какая-то магия есть, кроме проксей =)
- Маршрутизация трафика на основе сервера назначения из заголовка, ыы, 11:37 , 11-Окт-22 (9) +1
>> все зависит от вашего приложения, можно ли его настройки привязать >> на 2-а разных локальных адреса к примеру либо прописать на >> разные прокси, то бишь порты, если этого нет, то мне кажется >> никак... > Приложение можно доработать, чтобы оно выбирало нужный прокси, в зависимости от юр > лица. > Я в надежде, что может быть еще какая-то магия есть, кроме проксей > =) Инфостарт кончился, а пиво походу еще нет :) Мне не очень понятна необходимость держать два юрлица с одной базе. Они же не могут пользоваться одними и теми же счетами. И лицензии так сэкономить нельзя. Можно запустить на одной и той же серверной лицензии две базы (два сервера) от разных юзеров и управлять этими процессами как это принято в ОС.
- Маршрутизация трафика на основе сервера назначения из заголовка, FragMaster, 09:11 , 12-Окт-22 (12)
> Мне не очень понятна необходимость держать два юрлица с одной базе. Они > же не могут пользоваться одними и теми же счетами. И лицензии > так сэкономить нельзя. > Можно запустить на одной и той же серверной лицензии две базы (два > сервера) от разных юзеров и управлять этими процессами как это принято > в ОС.Бизнес логика не позволяет так сделать... Там обмены, перепродажи и т.д.
- Маршрутизация трафика на основе сервера назначения из заголовка, Licha Morada, 21:31 , 12-Окт-22 (14)
> Бизнес логика не позволяет так сделать... Там обмены, перепродажи и т.д.Ну, пусть переопределяют логику, или смиряются с тем что всем видно что они в одном и том-же доме живут.
- Маршрутизация трафика на основе сервера назначения из заголовка, ыы, 20:11 , 13-Окт-22 (17) +1
>> Мне не очень понятна необходимость держать два юрлица с одной базе. Они >> же не могут пользоваться одними и теми же счетами. И лицензии >> так сэкономить нельзя. >> Можно запустить на одной и той же серверной лицензии две базы (два >> сервера) от разных юзеров и управлять этими процессами как это принято >> в ОС. > Бизнес логика не позволяет так сделать... Там обмены, перепродажи и т.д.Ну, если бизнес логика не позволяет двум разным юрлицам вести учет в двух разных программах... то тут дело безусловно в логике. только не в "бизнес ... ", а в просто ... В 1С прекрасно все с обменами. Внешние источники данных, ODBC, вызовы данных через REST сервисы, выгрузки-загрузки через файлы... Настроить автоматический обмен данными между двумя разными системами 1С - вообще не проблема. Мне реально не понятна необходимость держать два юрлица с одной базе.
- Маршрутизация трафика на основе сервера назначения из заголовка, Аноним, 08:19 , 12-Окт-22 (10)
Купить на барахолке роутеры по 500 рублей на провайдер.
- Маршрутизация трафика на основе сервера назначения из заголовка, Licha Morada, 21:24 , 12-Окт-22 (13)
> Возможна ли реализация работы данного кейса?В принципе, да, но нетривиально. > Если да, то с помощью каких тех средств? Если это запросы ТОЛЬКО по http/https, и юр-лица можно явно отличить друг от друго по хедеру запроса, то можно хитро настроить прокси, например squid. Если это запросы вообще, то всё упирается в то как отличать одно от другого, в формате понятном дле принятия решения о маршрутизации. Как я понимаю, если бюджет позволяет, то это можно сделать с помощью DPI и реверс-инжениринга протоколов каждого из использующихся приложений. А практически, лучше не связывайтесь. В качестве мысленного эксперимента сойдёт, или если есть хобби на предмет "покопаться".
- Маршрутизация трафика на основе сервера назначения из заголовка, FragMaster, 08:46 , 13-Окт-22 (15)
>[оверквотинг удален] >> Если да, то с помощью каких тех средств? > Если это запросы ТОЛЬКО по http/https, и юр-лица можно явно отличить друг > от друго по хедеру запроса, то можно хитро настроить прокси, например > squid. > Если это запросы вообще, то всё упирается в то как отличать одно > от другого, в формате понятном дле принятия решения о маршрутизации. Как > я понимаю, если бюджет позволяет, то это можно сделать с помощью > DPI и реверс-инжениринга протоколов каждого из использующихся приложений. > А практически, лучше не связывайтесь. В качестве мысленного эксперимента сойдёт, или если > есть хобби на предмет "покопаться".Я вот тоже жизнеспособного варианта кроме прокси не вижу... Проблема только в том, что не все приложения могут поддерживать прокси и не все мы можем доработать так, чтобы поддерживали, но похоже это оправданный риск
- Маршрутизация трафика на основе сервера назначения из заголовка, Аноним, 11:16 , 13-Окт-22 (16) +1
> Проблема только в том, что не все приложения могут поддерживать прокси и > не все мы можем доработать так, чтобы поддерживали, google://проксификатор
- Маршрутизация трафика на основе сервера назначения из заголовка, ыы, 06:53 , 14-Окт-22 (18)
>[оверквотинг удален] >> Если это запросы вообще, то всё упирается в то как отличать одно >> от другого, в формате понятном дле принятия решения о маршрутизации. Как >> я понимаю, если бюджет позволяет, то это можно сделать с помощью >> DPI и реверс-инжениринга протоколов каждого из использующихся приложений. >> А практически, лучше не связывайтесь. В качестве мысленного эксперимента сойдёт, или если >> есть хобби на предмет "покопаться". > Я вот тоже жизнеспособного варианта кроме прокси не вижу... > Проблема только в том, что не все приложения могут поддерживать прокси и > не все мы можем доработать так, чтобы поддерживали, но похоже это > оправданный риск а внутри 1С:Розница много приложений?
- Маршрутизация трафика на основе сервера назначения из заголовка, FragMaster, 10:48 , 14-Окт-22 (19)
>[оверквотинг удален] >>> от другого, в формате понятном дле принятия решения о маршрутизации. Как >>> я понимаю, если бюджет позволяет, то это можно сделать с помощью >>> DPI и реверс-инжениринга протоколов каждого из использующихся приложений. >>> А практически, лучше не связывайтесь. В качестве мысленного эксперимента сойдёт, или если >>> есть хобби на предмет "покопаться". >> Я вот тоже жизнеспособного варианта кроме прокси не вижу... >> Проблема только в том, что не все приложения могут поддерживать прокси и >> не все мы можем доработать так, чтобы поддерживали, но похоже это >> оправданный риск > а внутри 1С:Розница много приложений?Приложение одно, внутри юр лиц может быть несколько Пока из идей: 1) socks proxy + проксификатор + переписание софта(где можно это сделать) на обращение к конкретному прокси в зависимости от юр лица 2) еще один комп, на котором запущена та же 1С, но со своим инетом. Оператор операции по юр лицу 1 выполняет на 1 компе, операции по 2 юр лицу - на втором. В 1 варианте не гарантированно будут работать всякие ККТ олайн с eth over usb, эквайринговые терминалы ибо , думаю не все они умеют прокси
- Маршрутизация трафика на основе сервера назначения из заголовка, Аноним, 14:29 , 14-Окт-22 (20)
> 2) еще один комп, на котором запущена та же 1С, но со > своим инетом. Оператор операции по юр лицу 1 выполняет на 1 > компе, операции по 2 юр лицу - на втором.Если рабочая машина под линуксом, то поможет network namespace. Для юрлица1 запускать прогу в одном неймспейсе, для юрица2 - во втором. Т.е. два скрипта запуска сделать. Если под виндой - сделать две копии бинарника (можно просто хардлинк на ntfs сделать) и настроить проксификатор так, чтобы каждый бинарник работал через свой прокси.
- Маршрутизация трафика на основе сервера назначения из заголовка, ыы, 09:02 , 15-Окт-22 (21)
>> 2) еще один комп, на котором запущена та же 1С, но со >> своим инетом. Оператор операции по юр лицу 1 выполняет на 1 >> компе, операции по 2 юр лицу - на втором. > Если рабочая машина под линуксом, то поможет network namespace. Для юрлица1 запускать > прогу в одном неймспейсе, для юрица2 - во втором. Т.е. два > скрипта запуска сделать. > Если под виндой - сделать две копии бинарника (можно просто хардлинк на > ntfs сделать) и настроить проксификатор так, чтобы каждый бинарник работал через > свой прокси.И в какойто острый момент он эти ярлычки перепутает...
- Маршрутизация трафика на основе сервера назначения из заголовка, Аноним, 10:22 , 15-Окт-22 (22)
Ну дык, сесть не за тот компьютер тоже есть вероятность... ¯\_(ツ)_/¯
- Маршрутизация трафика на основе сервера назначения из заголовка, ыы, 12:22 , 15-Окт-22 (23)
> Ну дык, сесть не за тот компьютер тоже есть вероятность... > ¯\_(ツ)_/¯ Сесть не за тот компьютер и открыть не ту программу -> не получить никакого ущерба если там куда ты сел нет необходимой функции. В данном случае - необходимая функция есть на обоих инсталляциях (одинаковые юрлица присутствуют и там и там) - и начать работать не от того юрлица- легко. об ошибке узнаешь уже после того как кнопка отправить сработает. Можно дописать конфигурацию, внедряя дополнительные проверки.. Но... Но... Но божежмой, сколько гемороя нужно дописывать, городить прокси, лезть в код конфигурации реализовывая чудовищно нестандартный кейс по абсолютно нелепейшей причине... правильное решение- разнести юрлица и настроить стандартную функциональность по согласованию данных в двух базах. после чего разнести эти базы по разным датацентрам- один в австралии другой в мексике... Исходную задачу не забыли еще? Чувак опасается, что в некоторых госслужбах ктото заметит что сомнительные перепродажи делаются на подставное лицо... и решать проблему он собирается.. ну вот так как собирается :)
- Маршрутизация трафика на основе сервера назначения из заголовка, FragMaster, 14:50 , 16-Окт-22 (24)
>[оверквотинг удален] > Но... > Но божежмой, сколько гемороя нужно дописывать, городить прокси, лезть в код конфигурации > реализовывая чудовищно нестандартный кейс по абсолютно нелепейшей причине... > правильное решение- разнести юрлица и настроить стандартную функциональность по согласованию > данных в двух базах. > после чего разнести эти базы по разным датацентрам- один в австралии другой > в мексике... > Исходную задачу не забыли еще? Чувак опасается, что в некоторых госслужбах ктото > заметит что сомнительные перепродажи делаются на подставное лицо... и решать проблему > он собирается.. ну вот так как собирается :) Разделить базу на 2 шт не представляется возможным в силу уже достаточно большого числа баз. Я понимаю, что этот ответ наиболее оптимален и очевиден, но у нас он невозможен. Плюс, вы недооцениваете риски, которые возникают при пересечении IP адресов.
- Маршрутизация трафика на основе сервера назначения из заголовка, FragMaster, 14:51 , 16-Окт-22 (25)
>> 2) еще один комп, на котором запущена та же 1С, но со >> своим инетом. Оператор операции по юр лицу 1 выполняет на 1 >> компе, операции по 2 юр лицу - на втором. > Если рабочая машина под линуксом, то поможет network namespace. Для юрлица1 запускать > прогу в одном неймспейсе, для юрица2 - во втором. Т.е. два > скрипта запуска сделать. > Если под виндой - сделать две копии бинарника (можно просто хардлинк на > ntfs сделать) и настроить проксификатор так, чтобы каждый бинарник работал через > свой прокси.Интересный вариант, спс
- Маршрутизация трафика на основе сервера назначения из заголовка, pavel_simple., 10:32 , 09-Ноя-22 (26)
>[оверквотинг удален] > Пример с 2 LAN портами не является обязательной реализацией и приведен для > простоты описания, вместо этого может использоваться 1 роутер с каким-то ПО. > Основные проблемы, которые я вижу: > - ККТ выгружает в ОФД чеки через usb over Ethetnet > - эквайринговые терминал через usb over Ethetnet > - всякие шлюзы оплаты, с которыми приложение взаимодействует(оплата по qr, api > банка и т.д.) > Вопрос: > Возможна ли реализация работы данного кейса? > Если да, то с помощью каких тех средств?DNAT
|