Есть: приложение, пускай будет 1С:Розница, оно может обращаться к интернет ресурсам, например, api банков, других гос организаций и т.д. через интернет. Приложение обслуживает 2 юр лица.Задача:
Хочется чтобы каждое юр лицо использовало свой интернет для связи со всем внешними миром(эквайринг, какие-то api, ОФД и т.д)Например, 1 комп с приложением обслуживает 2 юр лица и имеет 2 LAN порта, в каждый будет воткнут свой роутер для внешнего инета, все запросы на все внешние ресурсы от одного юр лица должны будут ходить по Lan1, все запросы от другого юр лица должны будут ходить через Lan2. Т.е. для внешних сайтом это будет выглядеть, как 2 независимых друг от друга компа.
Пример с 2 LAN портами не является обязательной реализацией и приведен для простоты описания, вместо этого может использоваться 1 роутер с каким-то ПО.
Основные проблемы, которые я вижу:
- ККТ выгружает в ОФД чеки через usb over Ethetnet
- эквайринговые терминал через usb over Ethetnet
- всякие шлюзы оплаты, с которыми приложение взаимодействует(оплата по qr, api банка и т.д.)Вопрос:
Возможна ли реализация работы данного кейса?
Если да, то с помощью каких тех средств?
https://habr.com/ru/post/108690/Создаёте отдельную таблицу маршрутизации и направляете в неё трафик на основе IP назначения:
ip rule add to 1.1.1.1/32 table ...Ну и маршрут по умолчанию в этой новой таблице прописать не забудьте.
Позвольте спросить - а НАХРЕНА тут отдельная таблица то? пишите просто чтоб "ляпнуть"?
в main таблице прекрасно все разруливается по назначению.
Так правильней. Раз уж есть два провайдера, то в будущем захочется более сложной маршрутизации.А если по-быстрому на коленке для решения конкретной узкой задачи, то можно и в основной таблице прописать правила, конечно.
Вы прям спец, я смотрю :-) "так правильный" - сильный аргумент.
Правильней потому что вы так решили?
Любое "правильней" исходит из текущей задачи.
И что кому захочется в будущем, будет решаться в будущем так же.
А то, кто-то придет и скажет делать сразу еще одну VRF - потому что "так правильней", а кто-то посоветует сделать через прокси, потому что для него "так правильней". А кто-то вообще наКуй пошлёт, потому что по его мнению "так правильный", и ОН РЕШИЛ что в будущем, точно придется туда идти.
Так что, не городите ерунды, задачу нужно решать исходя из текущих вводных.
Если исходить из твоего заголовка "сервера назначения" - то всё просто. Если они они ходят на разные api - то есть, первый клиент на свои, второй на свои только и ничего не пересекается, то это решается простой маршрутизацией, даже если разрулить надо по имени назначения (решается маркировкой пакетов по SNI).
А вот если они ходят на одни и те же ресурсы, вот тут, наверное НЕТ - потому что твой 1С точно не может метить пакеты.
> Если исходить из твоего заголовка "сервера назначения" - то всё просто. Если
> они они ходят на разные api - то есть, первый клиент
> на свои, второй на свои только и ничего не пересекается, то
> это решается простой маршрутизацией, даже если разрулить надо по имени назначения
> (решается маркировкой пакетов по SNI).
> А вот если они ходят на одни и те же ресурсы, вот
> тут, наверное НЕТ - потому что твой 1С точно не может
> метить пакеты.Все верно, приложение обслуживает 2 юр лица и ходить они могут на один и тот же IP.
Требуется, чтобы запрос от одного юр лица с этого приложения шел через одного провайдера, а запрос от другого юр лица - через другого
>[оверквотинг удален]
>> на свои, второй на свои только и ничего не пересекается, то
>> это решается простой маршрутизацией, даже если разрулить надо по имени назначения
>> (решается маркировкой пакетов по SNI).
>> А вот если они ходят на одни и те же ресурсы, вот
>> тут, наверное НЕТ - потому что твой 1С точно не может
>> метить пакеты.
> Все верно, приложение обслуживает 2 юр лица и ходить они могут на
> один и тот же IP.
> Требуется, чтобы запрос от одного юр лица с этого приложения шел через
> одного провайдера, а запрос от другого юр лица - через другоговсе зависит от вашего приложения, можно ли его настройки привязать на 2-а разных локальных адреса к примеру либо прописать на разные прокси, то бишь порты, если этого нет, то мне кажется никак...
> все зависит от вашего приложения, можно ли его настройки привязать
> на 2-а разных локальных адреса к примеру либо прописать на
> разные прокси, то бишь порты, если этого нет, то мне кажется
> никак...Приложение можно доработать, чтобы оно выбирало нужный прокси, в зависимости от юр лица.
Я в надежде, что может быть еще какая-то магия есть, кроме проксей =)
>> все зависит от вашего приложения, можно ли его настройки привязать
>> на 2-а разных локальных адреса к примеру либо прописать на
>> разные прокси, то бишь порты, если этого нет, то мне кажется
>> никак...
> Приложение можно доработать, чтобы оно выбирало нужный прокси, в зависимости от юр
> лица.
> Я в надежде, что может быть еще какая-то магия есть, кроме проксей
> =)Инфостарт кончился, а пиво походу еще нет :)
Мне не очень понятна необходимость держать два юрлица с одной базе. Они же не могут пользоваться одними и теми же счетами. И лицензии так сэкономить нельзя.
Можно запустить на одной и той же серверной лицензии две базы (два сервера) от разных юзеров и управлять этими процессами как это принято в ОС.
> Мне не очень понятна необходимость держать два юрлица с одной базе. Они
> же не могут пользоваться одними и теми же счетами. И лицензии
> так сэкономить нельзя.
> Можно запустить на одной и той же серверной лицензии две базы (два
> сервера) от разных юзеров и управлять этими процессами как это принято
> в ОС.Бизнес логика не позволяет так сделать... Там обмены, перепродажи и т.д.
> Бизнес логика не позволяет так сделать... Там обмены, перепродажи и т.д.Ну, пусть переопределяют логику, или смиряются с тем что всем видно что они в одном и том-же доме живут.
>> Мне не очень понятна необходимость держать два юрлица с одной базе. Они
>> же не могут пользоваться одними и теми же счетами. И лицензии
>> так сэкономить нельзя.
>> Можно запустить на одной и той же серверной лицензии две базы (два
>> сервера) от разных юзеров и управлять этими процессами как это принято
>> в ОС.
> Бизнес логика не позволяет так сделать... Там обмены, перепродажи и т.д.Ну, если бизнес логика не позволяет двум разным юрлицам вести учет в двух разных программах... то тут дело безусловно в логике. только не в "бизнес ... ", а в просто ...
В 1С прекрасно все с обменами. Внешние источники данных, ODBC, вызовы данных через REST сервисы, выгрузки-загрузки через файлы... Настроить автоматический обмен данными между двумя разными системами 1С - вообще не проблема.
Мне реально не понятна необходимость держать два юрлица с одной базе.
Купить на барахолке роутеры по 500 рублей на провайдер.
> Купить на барахолке роутеры по 500 рублей на провайдер.Интересно. Продолжайте...
> Возможна ли реализация работы данного кейса?В принципе, да, но нетривиально.
> Если да, то с помощью каких тех средств?
Если это запросы ТОЛЬКО по http/https, и юр-лица можно явно отличить друг от друго по хедеру запроса, то можно хитро настроить прокси, например squid.
Если это запросы вообще, то всё упирается в то как отличать одно от другого, в формате понятном дле принятия решения о маршрутизации. Как я понимаю, если бюджет позволяет, то это можно сделать с помощью DPI и реверс-инжениринга протоколов каждого из использующихся приложений.А практически, лучше не связывайтесь. В качестве мысленного эксперимента сойдёт, или если есть хобби на предмет "покопаться".
>[оверквотинг удален]
>> Если да, то с помощью каких тех средств?
> Если это запросы ТОЛЬКО по http/https, и юр-лица можно явно отличить друг
> от друго по хедеру запроса, то можно хитро настроить прокси, например
> squid.
> Если это запросы вообще, то всё упирается в то как отличать одно
> от другого, в формате понятном дле принятия решения о маршрутизации. Как
> я понимаю, если бюджет позволяет, то это можно сделать с помощью
> DPI и реверс-инжениринга протоколов каждого из использующихся приложений.
> А практически, лучше не связывайтесь. В качестве мысленного эксперимента сойдёт, или если
> есть хобби на предмет "покопаться".Я вот тоже жизнеспособного варианта кроме прокси не вижу...
Проблема только в том, что не все приложения могут поддерживать прокси и не все мы можем доработать так, чтобы поддерживали, но похоже это оправданный риск
> Проблема только в том, что не все приложения могут поддерживать прокси и
> не все мы можем доработать так, чтобы поддерживали,google://проксификатор
>[оверквотинг удален]
>> Если это запросы вообще, то всё упирается в то как отличать одно
>> от другого, в формате понятном дле принятия решения о маршрутизации. Как
>> я понимаю, если бюджет позволяет, то это можно сделать с помощью
>> DPI и реверс-инжениринга протоколов каждого из использующихся приложений.
>> А практически, лучше не связывайтесь. В качестве мысленного эксперимента сойдёт, или если
>> есть хобби на предмет "покопаться".
> Я вот тоже жизнеспособного варианта кроме прокси не вижу...
> Проблема только в том, что не все приложения могут поддерживать прокси и
> не все мы можем доработать так, чтобы поддерживали, но похоже это
> оправданный риска внутри 1С:Розница много приложений?
>[оверквотинг удален]
>>> от другого, в формате понятном дле принятия решения о маршрутизации. Как
>>> я понимаю, если бюджет позволяет, то это можно сделать с помощью
>>> DPI и реверс-инжениринга протоколов каждого из использующихся приложений.
>>> А практически, лучше не связывайтесь. В качестве мысленного эксперимента сойдёт, или если
>>> есть хобби на предмет "покопаться".
>> Я вот тоже жизнеспособного варианта кроме прокси не вижу...
>> Проблема только в том, что не все приложения могут поддерживать прокси и
>> не все мы можем доработать так, чтобы поддерживали, но похоже это
>> оправданный риск
> а внутри 1С:Розница много приложений?Приложение одно, внутри юр лиц может быть несколько
Пока из идей:
1) socks proxy + проксификатор + переписание софта(где можно это сделать) на обращение к конкретному прокси в зависимости от юр лица
2) еще один комп, на котором запущена та же 1С, но со своим инетом. Оператор операции по юр лицу 1 выполняет на 1 компе, операции по 2 юр лицу - на втором.В 1 варианте не гарантированно будут работать всякие ККТ олайн с eth over usb, эквайринговые терминалы ибо , думаю не все они умеют прокси
> 2) еще один комп, на котором запущена та же 1С, но со
> своим инетом. Оператор операции по юр лицу 1 выполняет на 1
> компе, операции по 2 юр лицу - на втором.Если рабочая машина под линуксом, то поможет network namespace. Для юрлица1 запускать прогу в одном неймспейсе, для юрица2 - во втором. Т.е. два скрипта запуска сделать.
Если под виндой - сделать две копии бинарника (можно просто хардлинк на ntfs сделать) и настроить проксификатор так, чтобы каждый бинарник работал через свой прокси.
>> 2) еще один комп, на котором запущена та же 1С, но со
>> своим инетом. Оператор операции по юр лицу 1 выполняет на 1
>> компе, операции по 2 юр лицу - на втором.
> Если рабочая машина под линуксом, то поможет network namespace. Для юрлица1 запускать
> прогу в одном неймспейсе, для юрица2 - во втором. Т.е. два
> скрипта запуска сделать.
> Если под виндой - сделать две копии бинарника (можно просто хардлинк на
> ntfs сделать) и настроить проксификатор так, чтобы каждый бинарник работал через
> свой прокси.И в какойто острый момент он эти ярлычки перепутает...
Ну дык, сесть не за тот компьютер тоже есть вероятность...
¯\_(ツ)_/¯
> Ну дык, сесть не за тот компьютер тоже есть вероятность...
> ¯\_(ツ)_/¯Сесть не за тот компьютер и открыть не ту программу -> не получить никакого ущерба если там куда ты сел нет необходимой функции.
В данном случае - необходимая функция есть на обоих инсталляциях (одинаковые юрлица присутствуют и там и там) - и начать работать не от того юрлица- легко. об ошибке узнаешь уже после того как кнопка отправить сработает.
Можно дописать конфигурацию, внедряя дополнительные проверки.. Но...
Но...
Но божежмой, сколько гемороя нужно дописывать, городить прокси, лезть в код конфигурации реализовывая чудовищно нестандартный кейс по абсолютно нелепейшей причине...
правильное решение- разнести юрлица и настроить стандартную функциональность по согласованию данных в двух базах.
после чего разнести эти базы по разным датацентрам- один в австралии другой в мексике...
Исходную задачу не забыли еще? Чувак опасается, что в некоторых госслужбах ктото заметит что сомнительные перепродажи делаются на подставное лицо... и решать проблему он собирается.. ну вот так как собирается :)
>[оверквотинг удален]
> Но...
> Но божежмой, сколько гемороя нужно дописывать, городить прокси, лезть в код конфигурации
> реализовывая чудовищно нестандартный кейс по абсолютно нелепейшей причине...
> правильное решение- разнести юрлица и настроить стандартную функциональность по согласованию
> данных в двух базах.
> после чего разнести эти базы по разным датацентрам- один в австралии другой
> в мексике...
> Исходную задачу не забыли еще? Чувак опасается, что в некоторых госслужбах ктото
> заметит что сомнительные перепродажи делаются на подставное лицо... и решать проблему
> он собирается.. ну вот так как собирается :)Разделить базу на 2 шт не представляется возможным в силу уже достаточно большого числа баз.
Я понимаю, что этот ответ наиболее оптимален и очевиден, но у нас он невозможен.
Плюс, вы недооцениваете риски, которые возникают при пересечении IP адресов.
>> 2) еще один комп, на котором запущена та же 1С, но со
>> своим инетом. Оператор операции по юр лицу 1 выполняет на 1
>> компе, операции по 2 юр лицу - на втором.
> Если рабочая машина под линуксом, то поможет network namespace. Для юрлица1 запускать
> прогу в одном неймспейсе, для юрица2 - во втором. Т.е. два
> скрипта запуска сделать.
> Если под виндой - сделать две копии бинарника (можно просто хардлинк на
> ntfs сделать) и настроить проксификатор так, чтобы каждый бинарник работал через
> свой прокси.Интересный вариант, спс
>[оверквотинг удален]
> Пример с 2 LAN портами не является обязательной реализацией и приведен для
> простоты описания, вместо этого может использоваться 1 роутер с каким-то ПО.
> Основные проблемы, которые я вижу:
> - ККТ выгружает в ОФД чеки через usb over Ethetnet
> - эквайринговые терминал через usb over Ethetnet
> - всякие шлюзы оплаты, с которыми приложение взаимодействует(оплата по qr, api
> банка и т.д.)
> Вопрос:
> Возможна ли реализация работы данного кейса?
> Если да, то с помощью каких тех средств?DNAT