Ну справедливости ради, я в публикации об этом говорю: "Не совсем, конечно, из ничего". И в подкасте тоже. И даже сам Шеннон говорил про частоту дискретизации сигнала, что это "a fact which is common knowledge in the communication art".
Ну и про Котельникова и приоритет в теореме об отсчётах отдельный выпуск подкаста был)
У обоих, кстати: и Шеннона, и Котельникова был талант объяснять сложные вещи простыми словами. И, естественно, упрощать любые запутанные вопросы до самого ядра, откидывая несущественное.
Понятие энтропии информации совсем не очевидное, кстати, пока не ознакомишься поподробнее)
В стандартных ситуациях мы всё же не оперируем отдельными парами, поскольку маршрутная информация распространяется в агрегированном виде. Поэтому обычно говорим о скорости реакции сети на обрывы и скорости сходимости сети.
Детектирование аварии на линке и обновление FIB происходит за единицы миллисекунд. Из-за наличия нескольких путей при трафик переключается на альтернативные примерно в это же время. Перекоммутаций как таковых никаких не происходит.
не способна соединить абонентов совсем уж в произвольные пары
Этот тезис не понял. Что Клоз, что Драгонфлай по сути представляет связность между любой парой хостов - вопрос только в диаметре. А так же в том, что нахождение пути не означает нахождение полосы.
Осилил и дочитал - огромное спасибо за такую колоссальную работу! :)
Спасибо) Это было интересно
А это тянет за собой IPv6 и так или иначе работу с хостами (чтобы переписывали Flow Label)... вообщем если вы не Яндекс - можно забыть :)
На самом деле нет. Я описал решение, которое мы делаем в Яндексе - довольно простой контроллер, который следит за утилизация на основе собираемых метрик, плюс динамическое управление политиками ликинга маршрутов. Никакого SR или тем более SRv6. Если есть система управления конфигурацией, то в целом довольно доступно.
И вот тогда это решение не то что "пробовать" в лабе, но и внедрять многие пойдут - просто потому что это более экономично с точки зрения CAPEX на сеть!
А вот тут нет факт совсем. Потому что помимо CAPEX на железо, есть ещё ФОТ команд это разрабатывающих и поддерживающих, плюс более высокие эксплуатационные расходы.
Что ещё более важно, неизвестно на самом деле насколько Dragonfly подходит под задачи обычных ДЦ (публичные облака, baremetal и подобное), где очень неравномерный трафик, а управлять размещением пользовательских ресурсов и объёмом трафика мы не можем.
Получается, что он его пароль лежит не только в секретном бумажном конверте, но и где-то в системе мониторинга?
Пароль лежит в секретнице (типа vault) - и при каждом запуске крона забирает его оттуда без локального хранения. Это, соответственно, позволяет нам не думать о его смене при ротации пароля - крон просто работает.
Секретница - manged сервис с контролем доступа. А так - да, пароль breakglass ещё записан на бумажке и лежит в "сейфе" (в Новосибисрке).
Сложно спорить) Всё в целом так. Но всё ещё никакого весомого аргумента в пользу RADIUS нет (кроме того, что микротики не поддерживают TACACS)).
А если историю брать не с самого начала, а с момента, когда мы в Облаке решили делать централизованную авторизацию, что такакс уже был, а радиус - нет. Выбор очевиден)
все зависит от используемого зоопарка - если поддерживается DIAMETER лучше использовать его, если у вас все на Cisco - то будет TACACS, но как правило есть еще и что-то, что поддерживает только RADIUS
И да, и нет. Если ты выбираешь отдельный механизм под условно каждого вендора (пусть и из соображений абстрактной безопасности), ты должен поддерживать их все. И ломаться они будут не одновременно и непредсказуемо.
Почему "абстрактной безопасности" - потому что реализации TACACS с этой точки зрения нам более чем достаточно - TOTP, ротация секретов, разные секреты для разных окружений, основная аутентификация на бастионе по сертификатам - позволяют снять или сильно снизить все риски.
TOTP на самом деле не одноразовый
Технически, ничто не мешает сделать его одноразовым. Например, после использования пароля менять соль. Но это в некотором смысле дуть на воду, учитывая короткий срок жизни пароля.
Если используется общий ключ, а не генерируется отдельный ключ на каждый девайс, то пароль можно переиспользовать, т.е. если потроянлено одно конечное устройство - на нем можно получить TOTP в момент входа и через него доступ к другому девайсу
Сделать это через Bastion - практически невозможно. Нужно ломать систему в нескольких местах.
Чтобы сделать это в обход бастиона, нужно завладеть актуальным секретом TACACS, знать механизм генерации TOTP, знать соль и попасть в нужный момент времени.
При этом, мы этот факт заметим, потому что мониторим логи подключения и поднимаем аварии, когда оно произошло в обход бастиона. Плюс мы мониторим дрейф конфигурации сети и снуляем его автоматически, если изменения безопасны (ААА - безопасны).
Это осознанное решение - нам важно, чтобы на конечном хосте - неважно сетевом или серверном операции были персонифицированными, чтобы в аудит-логах видеть конкретного пользователя. Иначе корреляция между событиями на бастионе и на конечном хосте неявная - нет чёткого критерия для сопоставления - и это точно полуручная работа. И даже глазами зайти посмотреть на свитч, посмотреть, кто коммиты делал последние :)
При этом он принципиально не усложняет схему, поскольку аутентификацию всё равно нужно делать, управлять ротациями паролей/секретов.
DIAMETER не поддерживается практически никаких сетевым оборудованием. Голый RADIUS не только не даёт преимуществ перед TACACS, так к тому же и плейн-текстом передаёт пароли?
К тому же в TACACS поддерживает не только парольную аутентификацию - просто для нас это наиболее простой и в то же время подходящий способ.
Для линукса есть уже нативные инструменты. Мы решили не делать два разных способа аутентификации на одном и том же типе устройств. Тем более, что на облачных хостах у нас OSLogin и довольно естественная интеграция с IAM.
Претензия к сервису бастион? К сервису TACACS? Откуда RDP/VNC в устройствах без UI?
Модерируемая сессия с красной кнопкой уже есть.
коих на рынке - десятки.
И это почти принципиальная позиция Яндекса - не использовать рыночные решения, поскольку у нас есть ресурсы для того, чтобы не зависеть от вендора там, где это возможно. И как показали два последние года, не самое плохое решение.
Ну и важная ремарка - вся статья о сетевом оборудовании, где нет возможности поставить и настроить ничего за пределами интерфейса и синтаксиса, предоставляемого вендора.
Да, пора бы, похоже. За сегодняшний день уже раза 4 услышал про неё. Почти феномен Баадера-Майнхофа, если бы я до этого совсем не слышал о Лимончелли :)
Имхо, очень сложно читать "мьюты", "зафлоадить", "статусы по эпикам", "запинил", "отпинил" и т.д. Ощущение, что нормальных русских слов не хватает.
Я в целом согласен сам. И стараюсь избегать их даже в разговорной речи. Но иногда хочется отпустить - и писать так, как мы на самом деле говорим)
По поводу способностей мозга, не совсем согласен, сам в голове держу и семейные дела, и тренировки детей, и задачи по работе, и ещё кучу технической информации по железу/особенностях настройки, ответы техподдержки и ещё много всего. Записываю только то, что требует долгого ретроспективного анализа и/или сложной калькуляции типа семейного бюджета.
Судя по окружающим, вы - скорее, исключение, нежели норма. Если есть способы, как прокачать свой мозг так, чтобы он в оперативке держал так много, или умел в нужное время нужные события извлекать из долговременного хранилища - об этом стоит рассказывать - ценные знания)
Планирование естественно есть и оно необходимо, но не ежеминутное же.
А где вы такое в посте прочитали, я вообще не понял)
Ну справедливости ради, я в публикации об этом говорю: "Не совсем, конечно, из ничего". И в подкасте тоже.
И даже сам Шеннон говорил про частоту дискретизации сигнала, что это "a fact which is common knowledge in the communication art".
Ну и про Котельникова и приоритет в теореме об отсчётах отдельный выпуск подкаста был)
У обоих, кстати: и Шеннона, и Котельникова был талант объяснять сложные вещи простыми словами. И, естественно, упрощать любые запутанные вопросы до самого ядра, откидывая несущественное.
Понятие энтропии информации совсем не очевидное, кстати, пока не ознакомишься поподробнее)
Сделал "похитрее", выложил видео в телегу: https://t.me/donasdoshlo/107
Ну у меня проба. Решил первый раз всё же не пытаться во все тяжкие, не понимая базы.
Почти в самом начале: DeepSeek R1 Thinking
Картинка же и правда хороша)
В стандартных ситуациях мы всё же не оперируем отдельными парами, поскольку маршрутная информация распространяется в агрегированном виде. Поэтому обычно говорим о скорости реакции сети на обрывы и скорости сходимости сети.
Детектирование аварии на линке и обновление FIB происходит за единицы миллисекунд. Из-за наличия нескольких путей при трафик переключается на альтернативные примерно в это же время.
Перекоммутаций как таковых никаких не происходит.
Этот тезис не понял. Что Клоз, что Драгонфлай по сути представляет связность между любой парой хостов - вопрос только в диаметре. А так же в том, что нахождение пути не означает нахождение полосы.
Спасибо) Это было интересно
На самом деле нет. Я описал решение, которое мы делаем в Яндексе - довольно простой контроллер, который следит за утилизация на основе собираемых метрик, плюс динамическое управление политиками ликинга маршрутов. Никакого SR или тем более SRv6. Если есть система управления конфигурацией, то в целом довольно доступно.
А вот тут нет факт совсем. Потому что помимо CAPEX на железо, есть ещё ФОТ команд это разрабатывающих и поддерживающих, плюс более высокие эксплуатационные расходы.
Что ещё более важно, неизвестно на самом деле насколько Dragonfly подходит под задачи обычных ДЦ (публичные облака, baremetal и подобное), где очень неравномерный трафик, а управлять размещением пользовательских ресурсов и объёмом трафика мы не можем.
Один и тот же, только ротируется иногда.
Все инстансы бастиона симметрично сконфигурированы, чтобы добавлять новые при случае было очень простой операцией.
Пароль лежит в секретнице (типа vault) - и при каждом запуске крона забирает его оттуда без локального хранения. Это, соответственно, позволяет нам не думать о его смене при ротации пароля - крон просто работает.
Секретница - manged сервис с контролем доступа. А так - да, пароль breakglass ещё записан на бумажке и лежит в "сейфе" (в Новосибисрке).
Сложно спорить) Всё в целом так. Но всё ещё никакого весомого аргумента в пользу RADIUS нет (кроме того, что микротики не поддерживают TACACS)).
А если историю брать не с самого начала, а с момента, когда мы в Облаке решили делать централизованную авторизацию, что такакс уже был, а радиус - нет. Выбор очевиден)
Да, про пароль я не прав. Имел в виду сообщение.
И да, и нет. Если ты выбираешь отдельный механизм под условно каждого вендора (пусть и из соображений абстрактной безопасности), ты должен поддерживать их все. И ломаться они будут не одновременно и непредсказуемо.
Почему "абстрактной безопасности" - потому что реализации TACACS с этой точки зрения нам более чем достаточно - TOTP, ротация секретов, разные секреты для разных окружений, основная аутентификация на бастионе по сертификатам - позволяют снять или сильно снизить все риски.
Технически, ничто не мешает сделать его одноразовым. Например, после использования пароля менять соль. Но это в некотором смысле дуть на воду, учитывая короткий срок жизни пароля.
Сделать это через Bastion - практически невозможно. Нужно ломать систему в нескольких местах.
Чтобы сделать это в обход бастиона, нужно завладеть актуальным секретом TACACS, знать механизм генерации TOTP, знать соль и попасть в нужный момент времени.
При этом, мы этот факт заметим, потому что мониторим логи подключения и поднимаем аварии, когда оно произошло в обход бастиона. Плюс мы мониторим дрейф конфигурации сети и снуляем его автоматически, если изменения безопасны (ААА - безопасны).
Это осознанное решение - нам важно, чтобы на конечном хосте - неважно сетевом или серверном операции были персонифицированными, чтобы в аудит-логах видеть конкретного пользователя. Иначе корреляция между событиями на бастионе и на конечном хосте неявная - нет чёткого критерия для сопоставления - и это точно полуручная работа.
И даже глазами зайти посмотреть на свитч, посмотреть, кто коммиты делал последние :)
При этом он принципиально не усложняет схему, поскольку аутентификацию всё равно нужно делать, управлять ротациями паролей/секретов.
q1. Нет) Мы это не выкладывали в OSS
q2. RADIUS :(
q3. Дайте отойти от линкмитапа в нск :)
Спасибо)
DIAMETER не поддерживается практически никаких сетевым оборудованием. Голый RADIUS не только не даёт преимуществ перед TACACS, так к тому же и плейн-текстом передаёт пароли?
К тому же в TACACS поддерживает не только парольную аутентификацию - просто для нас это наиболее простой и в то же время подходящий способ.
Для линукса есть уже нативные инструменты. Мы решили не делать два разных способа аутентификации на одном и том же типе устройств.
Тем более, что на облачных хостах у нас OSLogin и довольно естественная интеграция с IAM.
Извините, тут был чей-то комментарий. Но, похоже, я нажал “отклонить” вместо “одобрить”.
Как-то вы намешали, кажется.
Претензия к сервису бастион? К сервису TACACS? Откуда RDP/VNC в устройствах без UI?
Модерируемая сессия с красной кнопкой уже есть.
И это почти принципиальная позиция Яндекса - не использовать рыночные решения, поскольку у нас есть ресурсы для того, чтобы не зависеть от вендора там, где это возможно. И как показали два последние года, не самое плохое решение.
Ну и важная ремарка - вся статья о сетевом оборудовании, где нет возможности поставить и настроить ничего за пределами интерфейса и синтаксиса, предоставляемого вендора.
Да, пора бы, похоже. За сегодняшний день уже раза 4 услышал про неё. Почти феномен Баадера-Майнхофа, если бы я до этого совсем не слышал о Лимончелли :)
Я в целом согласен сам. И стараюсь избегать их даже в разговорной речи. Но иногда хочется отпустить - и писать так, как мы на самом деле говорим)
Судя по окружающим, вы - скорее, исключение, нежели норма. Если есть способы, как прокачать свой мозг так, чтобы он в оперативке держал так много, или умел в нужное время нужные события извлекать из долговременного хранилища - об этом стоит рассказывать - ценные знания)
А где вы такое в посте прочитали, я вообще не понял)