- Когда мои пользователи ЛС хотят посекретничать, я их прошу не морочить голову се,
 Licha Morada (ok), 00:02 , 07-Янв-21 (1) +1 Когда мои пользователи ЛС хотят посекретничать, я их прошу не морочить голову сетевикам, а заворачивать траффик в SSL/TLS и аутентицировать сообщения на 7-ом уровне.Если таким образом решить задачу приемлемо не получается, то настраиваю оверлейную сеть между конкретными заинтересованными хостами, отдельными группами.
До настоящего времени использовал Tinc, теперь, наверное, буду WireGuard пробовать. Похоже? (Такая вот глубокая неприязнь к решениям с потрохами зависящим от мутного функционала "божественных ящиков")
- нууууу, а при чем тут божественные ящики Есть подозрение, что почти любой мар, Andy1e (ok), 12:05 , 07-Янв-21 (2)
> (Такая вот глубокая неприязнь к решениям с потрохами зависящим от мутного функционала
> "божественных ящиков") нууууу, а при чем тут божественные ящики? Есть подозрение, что [почти] любой маршрутизатор будет подобным образом себя вести. Если не любой - то в любом случае, коробчонки уже есть, не менять же их теперь. Или вы что, предлагаете, агрегировать несколько тыщ юзеров linux-роутерами? Или все в один l2? > Когда мои пользователи ЛС хотят посекретничать, я их прошу не морочить голову
> сетевикам, а заворачивать траффик в SSL/TLS и аутентицировать сообщения на 7-ом
> уровне. "Послать" юзеров - самое простое решение, им мы воспользоваться всегда успеем :) Они не "посекретничать" хотят, а отработать свою задачу, связанную именно с мандатными метками, которая потом будет реализована в другой сети, нужно чтоб работала и тут и там. Да, возможно это не лучшее решение, и его можно оспорить, но есть такая штука как ТЗ, к которому я, как сетевой администратор, вообще никакого отношения не имею. Могу, наверное, влезть и насоветовать, но мне оно надо? Наверняка существует примерно миллион обстоятельств непреодолимой силы, из-за которых ни я, ни исполнители не смогут повлиять на предложенную схему (или вообще, или по крайней мере в разумные сроки). > Если таким образом решить задачу приемлемо не получается, то настраиваю оверлейную сеть
> между конкретными заинтересованными хостами, отдельными группами.
> До настоящего времени использовал Tinc, теперь, наверное, буду WireGuard пробовать. Да, идея с туннелями интересная, спасибо, сам почему-то не подумал; но, опять же, трудоемкая и костыльная. Трудоемкость, возможно, получилось бы спихнуть на юзеров (с группами, в силу структуры сети, не выйдет; по крайней мере если не превращать клиентские машины в серверы для этих самых групп, или не ставить дополнительное железо; короче. костыль на костыле), но могут возникнуть проблемы с итоговой реализацией, когда туннели будут уже совсем не в тему. WireGuard я как раз недавно трогал, можно было бы заморочиться, но вообще, как администратор божественных ящиков, я хотел бы решить проблему именно на их уровне (коль уж они ее и создают), а не перекладывать с больной головы на здоровую.
- Разделяю я ваши подозрения Продавец ваших коробочек будет счаслив их обожествить, Licha Morada (ok), 00:34 , 08-Янв-21 (3)
>> (Такая вот глубокая неприязнь к решениям с потрохами зависящим от мутного функционала
>> "божественных ящиков")
> нууууу, а при чем тут божественные ящики? Есть подозрение, что [почти] любой
> маршрутизатор будет подобным образом себя вести. Если не любой - то
> в любом случае, коробчонки уже есть, не менять же их теперь. Разделяю я ваши подозрения.
Продавец ваших коробочек будет счаслив их обожествить, т.е. предложить необходимые модули по сотне нефти, с лицензиями и поддержкой ещё за полсотни в год. И будет потирать ручки потому что это почти вендор лок и хрен теперь вы теперь с его решения слезите. > Или вы что, предлагаете, агрегировать несколько тыщ юзеров linux-роутерами? Или все
> в один l2? Решение с оверлеем которое я описал работало хорошо для N групп по < 10 хостов, которые друг для друга публиковали сервисы не умеющие шифровать и аутентифицироваться (например, MongoDB в юзерспейс с дефолтными настройками). Несколько тыщ, и не серверов а юзеров с своими зоопарками, это, конечно, другое.
>> Когда мои пользователи ЛС хотят посекретничать, я их прошу не морочить голову
>> сетевикам, а заворачивать траффик в SSL/TLS и аутентицировать сообщения на 7-ом
>> уровне.
> "Послать" юзеров - самое простое решение, им мы воспользоваться всегда успеем :)
Во первых, сначала надавать авансов а потом послать, это хуже чем сразу послать.
Во вторых, я не про не "послать", а отвести за руку, усадить, проверить удобно ли. И если нет, то привести обратно и продолжить искать решение. > Они не "посекретничать" хотят, а отработать свою задачу, связанную именно с
> мандатными метками, которая потом будет реализована в другой сети, нужно чтоб
> работала и тут и там. Да, возможно это не лучшее решение,
> и его можно оспорить, но есть такая штука как ТЗ, к
> которому я, как сетевой администратор, вообще никакого отношения не имею. Неправда, имеете. ТЗ формализирует требования. Которые бывают функциональные, /что/ решение должно делать, и нефункциональные, /как/ оно должно это делать. По функциональным решают заказчик и спонсор, а разработчик их одёргивает. По нефункциональным сложнее, потому что там решают больше разработчики и одёргивать их надо эксплоатационникам, а тех к участию на раннем этапе проекта привлекают нечасто. Поэтому бывает, что внедрение срывается по вине каких-нибудь инфраструктурных инженеров, которые не сумели достать слюны единорога, о потребности в которй узнали накануне сдачи. Так что по уму, вы как сетевой администратор имеете непосредственное отношение к составлению ТЗ, именно к его части про нефункциональные требования и технологические ограничения. Лезте и советуйте. Ваши аргументы это "по грубым прикидкам слюна единорога нам будет стоить столько-то на хост по деньгам, и анального рабства у короля троллей" и "там в другой сети единороги не водятся вообще и придётся везти наших". А то потом они ещё в облако захотят, и понадобится очень специальноe эльфийское облако, куда нельзя, потому что санкции, и, кроме того, разоримся. Я про мандатные метки знаю очень по наслышке, у меня сложилось впечатление что они:
- Хорошо ходят по специализированным сетям, но плохо по общим, и надо специально заморачиваться.
- Решают какую-то задачу специфичную для приложения, а не для инфраструктуры сети общего назначения.
(может быть, это впечатление неверное) Из первого следует что придётся лезть что-то менять во всю сеть, и если не перестраивать вообще, то, по меньшей мере, достаточно инвазивно курочить.
Второе означает что хозяева приложения норовят переложить свои неучтённые риски на инфраструктуру, у которой может не быть ресурсов чтобы их как следует переварить.
- Если не вдаваться в способы усаживания, штука как бы в том, что аванс уже есть , Andy1e (ok), 01:37 , 08-Янв-21 (4)
> Во первых, сначала надавать авансов а потом послать, это хуже чем сразу
> послать.Если не вдаваться в способы усаживания, штука как бы в том, что аванс уже есть: доказательство принципиальной работоспособности мы наблюдали вместе, его я добиться смог, делов-то на одну команду, пусть и размноженную по интерфейсам. > Неправда, имеете.
> ТЗ формализирует требования. Которые бывают функциональные, /что/ решение должно делать,
> и нефункциональные, /как/ оно должно это делать. По функциональным решают заказчик
> и спонсор, а разработчик их одёргивает. По нефункциональным сложнее, потому что
> там решают больше разработчики и одёргивать их надо эксплоатационникам, а тех
> к участию на раннем этапе проекта привлекают нечасто. Поэтому бывает, что
> внедрение срывается по вине каких-нибудь инфраструктурных инженеров, которые не сумели
> достать слюны единорога, о потребности в которй узнали накануне сдачи.
> Так что по уму, вы как сетевой администратор имеете непосредственное отношение к
> составлению ТЗ То-то и оно, что если "по уму". Бальзам для глаз/ушей такие рассуждения, но объективная реальность такая объективная. Опять же, если уйти от ненужных подробностей - это всё понятно, в данном случае вопрос не в том, как "жить не по лжи", а как решить конкретную задачу, если это возможно, в объективной реальности, данной нам в ощущениях^W железе. > Я про мандатные метки знаю очень по наслышке, у меня сложилось впечатление
> что они:
> - Хорошо ходят по специализированным сетям, но плохо по общим, и надо
> специально заморачиваться.
> - Решают какую-то задачу специфичную для приложения, а не для инфраструктуры сети
> общего назначения.
> (может быть, это впечатление неверное) Я до сих пор тоже сам не общался, но впечатление вполне верное. Однако в целом - чему там "ходить", это всего лишь лишние байты в заголовке пакета (причём, вполне соответствующие стандартам), из-за которых эти самые пакеты почему-то по дефолту дропаются. "Специализированность" сети упирается тупо в тот факт, что межсетевые экраны эти пакеты либо фильтруют по меткам, либо снимают/вешают метки, опционально упихивая всё в туннели. В продакшне, я надеюсь, с этим будет всё ок (насколько всё может быть ок с "Рубиконами", конечно...), проверим, это отдельная история, там цискам (или что там будет вместо них), кажется, ничего маршрутизировать между такими сетями не придётся. > Из первого следует что придётся лезть что-то менять во всю сеть, и
> если не перестраивать вообще, то, по меньшей мере, достаточно инвазивно курочить.
> Второе означает что хозяева приложения норовят переложить свои неучтённые риски на инфраструктуру,
> у которой может не быть ресурсов чтобы их как следует переварить. Собственно я думаю, что если решение существует, то скорее всего из всех заморочек на общей сети - конфиг L3 коммутаторов на пару строчек, просто не тех (или не только тех), что я сходу нашёл в гугле.
Странно валить всё на нехватку ресурсов, когда всего лишь требуется пустить немного нестандартный трафик. Перекладывание рисков на сетевую инфраструктуру я уже видел (интерфейс программы, отрисовывающийся только после сотни последовательных SQL запросов, когда между юзером и сервером не <1мc, а половина России, мммм...!), это не тот случай :) Видимо (надеюсь) нужно или заставить железки пропускать этот трафик какой-то другой настройкой, или зафильтровать то, что их перегружает при ее включении.
|
Свернуть нити
Пометить прочитанным
Создать тему
