В стандартных ситуациях мы всё же не оперируем отдельными парами, поскольку маршрутная информация распространяется в агрегированном виде. Поэтому обычно говорим о скорости реакции сети на обрывы и скорости сходимости сети.
Детектирование аварии на линке и обновление 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 услышал про неё. Почти феномен Баадера-Майнхофа, если бы я до этого совсем не слышал о Лимончелли :)
Имхо, очень сложно читать "мьюты", "зафлоадить", "статусы по эпикам", "запинил", "отпинил" и т.д. Ощущение, что нормальных русских слов не хватает.
Я в целом согласен сам. И стараюсь избегать их даже в разговорной речи. Но иногда хочется отпустить - и писать так, как мы на самом деле говорим)
По поводу способностей мозга, не совсем согласен, сам в голове держу и семейные дела, и тренировки детей, и задачи по работе, и ещё кучу технической информации по железу/особенностях настройки, ответы техподдержки и ещё много всего. Записываю только то, что требует долгого ретроспективного анализа и/или сложной калькуляции типа семейного бюджета.
Судя по окружающим, вы - скорее, исключение, нежели норма. Если есть способы, как прокачать свой мозг так, чтобы он в оперативке держал так много, или умел в нужное время нужные события извлекать из долговременного хранилища - об этом стоит рассказывать - ценные знания)
Планирование естественно есть и оно необходимо, но не ежеминутное же.
А где вы такое в посте прочитали, я вообще не понял)
Вот это, кстати, очень неочевидная вещь. Нужно прям в себе что-то сломать и дисциплину выработать, чтобы и перед любой встречей повестку готовить, и в конце минутки записать. Ну кроме стендапа. Раньше не понимал фразу "встреча без повестки не нужна, встреча без минуток - потраченное время". А потом как понял :)
Ну и начинать день с календаря - это прям обязательным стало, это правда.
В стандартных ситуациях мы всё же не оперируем отдельными парами, поскольку маршрутная информация распространяется в агрегированном виде. Поэтому обычно говорим о скорости реакции сети на обрывы и скорости сходимости сети.
Детектирование аварии на линке и обновление 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 услышал про неё. Почти феномен Баадера-Майнхофа, если бы я до этого совсем не слышал о Лимончелли :)
Я в целом согласен сам. И стараюсь избегать их даже в разговорной речи. Но иногда хочется отпустить - и писать так, как мы на самом деле говорим)
Судя по окружающим, вы - скорее, исключение, нежели норма. Если есть способы, как прокачать свой мозг так, чтобы он в оперативке держал так много, или умел в нужное время нужные события извлекать из долговременного хранилища - об этом стоит рассказывать - ценные знания)
А где вы такое в посте прочитали, я вообще не понял)
Вот так:
Ну я пишу статьи, а они обычно или в html или в markdown или в, прости господи, rst)
Вот это, кстати, очень неочевидная вещь. Нужно прям в себе что-то сломать и дисциплину выработать, чтобы и перед любой встречей повестку готовить, и в конце минутки записать. Ну кроме стендапа. Раньше не понимал фразу "встреча без повестки не нужна, встреча без минуток - потраченное время". А потом как понял :)
Ну и начинать день с календаря - это прям обязательным стало, это правда.
С девайсам всё просто: для быстрой выгрузки приходящих мыслей - то, что под рукой - телефон. Для заметок по дороге - тоже.
Для чего-то длинного обычно ноут. Но посты для инсты и телеги зачастую пишу и в телефон.
Вся вёрстка, форматирование, конечно, на ноуте :)
Ну вот для этого я и использую напоминания себе в телеге - они и потренькают, и повибрируют, и повисят ещё противным кружочком в непрочитанных)
Значит это был неправильный инструмент под ваши задачи. Если их можно было откладывать на потом, значит они были не такими уж важными)
Я хорошо понимаю, потому что у меня тоже так было. Ровно до того момента, как я не почувствовал необходимость именно срочные вещи не забывать)
Да, всё так) И про dhclient или libpcacp)
Возможно, вы блокировали его на стороне сервера - там проблем нет)