>> (Такая вот глубокая неприязнь к решениям с потрохами зависящим от мутного функционала
>> "божественных ящиков")
> нууууу, а при чем тут божественные ящики? Есть подозрение, что [почти] любой
> маршрутизатор будет подобным образом себя вести. Если не любой - то
> в любом случае, коробчонки уже есть, не менять же их теперь. Разделяю я ваши подозрения.
Продавец ваших коробочек будет счаслив их обожествить, т.е. предложить необходимые модули по сотне нефти, с лицензиями и поддержкой ещё за полсотни в год. И будет потирать ручки потому что это почти вендор лок и хрен теперь вы теперь с его решения слезите.
> Или вы что, предлагаете, агрегировать несколько тыщ юзеров linux-роутерами? Или все
> в один l2?
Решение с оверлеем которое я описал работало хорошо для N групп по < 10 хостов, которые друг для друга публиковали сервисы не умеющие шифровать и аутентифицироваться (например, MongoDB в юзерспейс с дефолтными настройками). Несколько тыщ, и не серверов а юзеров с своими зоопарками, это, конечно, другое.
>> Когда мои пользователи ЛС хотят посекретничать, я их прошу не морочить голову
>> сетевикам, а заворачивать траффик в SSL/TLS и аутентицировать сообщения на 7-ом
>> уровне.
> "Послать" юзеров - самое простое решение, им мы воспользоваться всегда успеем :)
Во первых, сначала надавать авансов а потом послать, это хуже чем сразу послать.
Во вторых, я не про не "послать", а отвести за руку, усадить, проверить удобно ли. И если нет, то привести обратно и продолжить искать решение.
> Они не "посекретничать" хотят, а отработать свою задачу, связанную именно с
> мандатными метками, которая потом будет реализована в другой сети, нужно чтоб
> работала и тут и там. Да, возможно это не лучшее решение,
> и его можно оспорить, но есть такая штука как ТЗ, к
> которому я, как сетевой администратор, вообще никакого отношения не имею.
Неправда, имеете.
ТЗ формализирует требования. Которые бывают функциональные, /что/ решение должно делать, и нефункциональные, /как/ оно должно это делать. По функциональным решают заказчик и спонсор, а разработчик их одёргивает. По нефункциональным сложнее, потому что там решают больше разработчики и одёргивать их надо эксплоатационникам, а тех к участию на раннем этапе проекта привлекают нечасто. Поэтому бывает, что внедрение срывается по вине каких-нибудь инфраструктурных инженеров, которые не сумели достать слюны единорога, о потребности в которй узнали накануне сдачи.
Так что по уму, вы как сетевой администратор имеете непосредственное отношение к составлению ТЗ, именно к его части про нефункциональные требования и технологические ограничения. Лезте и советуйте. Ваши аргументы это "по грубым прикидкам слюна единорога нам будет стоить столько-то на хост по деньгам, и анального рабства у короля троллей" и "там в другой сети единороги не водятся вообще и придётся везти наших". А то потом они ещё в облако захотят, и понадобится очень специальноe эльфийское облако, куда нельзя, потому что санкции, и, кроме того, разоримся.
Я про мандатные метки знаю очень по наслышке, у меня сложилось впечатление что они:
- Хорошо ходят по специализированным сетям, но плохо по общим, и надо специально заморачиваться.
- Решают какую-то задачу специфичную для приложения, а не для инфраструктуры сети общего назначения.
(может быть, это впечатление неверное)
Из первого следует что придётся лезть что-то менять во всю сеть, и если не перестраивать вообще, то, по меньшей мере, достаточно инвазивно курочить.
Второе означает что хозяева приложения норовят переложить свои неучтённые риски на инфраструктуру, у которой может не быть ресурсов чтобы их как следует переварить.
Вариант для распечатки
