Некоторые вендоры заморачиваются по поводу дизайна устройств. У Cisco даже были какие-то публикации по этому поводу. Но большинство просто находит себе оптимальных поставщиков корпусов.
Коммутаторы мы использовали управляемые. Стоят они намного больше, чем 10 тысяч рублей. Плюс ещё блоки питания и ИБП, плюс, колллеги, обеспечивающие безопасность периметра могут что-то своё туда устанавливать. Всё содержимое точно будет в несколько раз дороже, чем сам ящик.
Если же будет взрыв, проложить заново кабели намного дешевле и быстрее, чем купить новое оборудование, дождаться его приезда, выслать инженера, который настроит и т.д.
Цикл эксплуатации обычных коммутаторов Cisco составляет 5-7 лет, для промышленных коммутаторов он в 2-3 раза больше. Там и схемотехника надёжнее и вендор сохраняет поддержку в течение таких сроков. Это совсем не "одноразовое" оборудование.
С Моха мы тоже работаем, но это тема отдельного поста. Беглое сравнение было бы некорректно. Возможно, сделаю в будущем, но пока взял за образец вендора с наиболее богатым портфолио и документацией по решениям.
В офисных и производственных сетях задачи чаще всего ставятся по-разному. Если в офисной сети часто проектировщик приходит к заказчику и говорит «за Х долларов мы можем обеспечить пользователям 10часов простоя в год, а за X+N долларов — 30 минут простоя в год», то в промышленности обычно производство приходит к проектировщику и говорит: «Нам нужно подключить вот такую линию, вот с такими ПЛК и исполнительными устройствами. Простой на ней с технологической точки зрения недопустим». Это само по себе подразумевает, что ПЛК и исполнительные устройства поддерживают какие-то технологии и протоколы, позволяющие обеспечить нулевой простой. Задача в том, чтобы построить сеть, которая обеспечит работу этих протоколов.
У всех вендоров ценовая политика разная — кто-то за компоненты управления денег не берёт, но это не значит, что совокупно его решение во всех случаях окажется дешевле, дороже могут оказаться оконечные устройства или лицензии на них. А могут и не оказаться.
Лучше всегда сравнивать общую цену решения для конкретной задачи — конкретного количества филиалов, производительности устройств, которые там нужны, функционала этих устройств и компонентов управления. Причём, и разовое вложение — при покупке, и ежегодные — обновления, техподдержка, подписки.
Здесь речь о том, что у вас идёт TCP-сессия из точки А в точку Б, а обратный трафик не разрешён правилами межсетевого экрана, но он пропускается, так как принадлежит к TCP-сессии, открытой изнутри (классический Stateful Firewall). При этом сессия сохраняется с указанием входящего и исходящего интерфейсов межсетевого экрана. А потом вдруг обратный трафик приходит не на тот же интерфейс, с которого ушёл исходящий, а значит не на тот, который записан в таблице сессий. Этот трафик блокируется. Чтобы такого не происходило, можно включить Auxiliary-сессию, тогда межсетевой экран будет открывать сессию и по второму интерфейсу тоже, просто чтобы она была в таблице и обратный трафик, приходящий на другой интерфейс, разрешался.
Это скорее про ситуацию, когда нам важно, чтобы трафик дошёл и мы готовы тратить на это в два раза больше пропускной способности. Например транзакция от банковского терминала — если мы её потеряем, то клиенту придётся второй раз прикладывать карту. При этом данных там килобайты, поэтому их не жалко передать два раза одновременно по разным каналам.
Если для какого-то трафика это принципиально, то я бы сделал это с помощью SD-WAN Policy. Заматчил трафик по L3-L4-критериям или по приложению, а в Action-части задал бы SD-WAN-туннели с одинаковым приоритетом с обеих сторон.
Но на самом деле не факт, что это всегда нужно. Если вдруг у вас канал выдаёт не одинаковое качество на Upstream и Downstream (и Probe это покажут), с точки зрения качества работы приложения, лучше будет передать одно из направлений через другой канал.
Мы делали аудит не информационной безопасности, а только сетевой безопасности.
Аудит информационной безопасности он очень комплексный, там много всего.
Мы же сделали тот аудит, который нас попросил сделать заказчик, исходя из его финансовых возможностей.
Согласен. Грамотный админ должен быть всегда. Другое дело, что не каждая компания может позволить себе платить 100+ в месяц, что бы его содержать. А так админ должен быть всегда и постоянно работать с инфраструктурой.
Хорошие конфиги, это конфиги которые позволяют максимально обезопасить само устройство от атак и непосредственно сетевую инфраструктуру.
Если речь идет о коммутаторах – то это в первую очередь отключение неиспользуемых интерфейсов, добавление description для всех портов, сегментирование трафика на разные вланы, настройка STP BPDU Guard и STP Root Guard, настройка storm control и port-security. В идеале использование dot1x. Использование безопасных протоколов удаленного доступа – https, ssh, snmpv3. Отключение всех неиспользуемых сервисов Использование централизованной аутентификации и авторизации, в крайнем случае – использование нескольких разных локальных учеток с разным уровнем привилегий. Использование логгирования и синхронизации времени. Подходящая архитектура, это устройства и ПО, поддерживающие данный перечисленный функционал.
В данном случае, уменьшаются капитальные расходы, но увеличиваются операционные. Появляется плата за содержание каждого абонента и за вызовы, в зависимости от тарифов операторов.
Проект сейчас передаётся на эксплуатацию сотрудникам компании. Сложностей с поддержкой не вижу, конфликтов по оборудованию тоже не должно быть. Естественно, в общей сети есть некоторое количество негетерогенного оборудования, но оно архитектурно не имеет отношения к телефонии в принципе.
Некоторые вендоры заморачиваются по поводу дизайна устройств. У Cisco даже были какие-то публикации по этому поводу. Но большинство просто находит себе оптимальных поставщиков корпусов.
Документацию выдают инженеры вендора. Её оригиналы все на китайском, но уже всё переведено на английский.
Коммутаторы мы использовали управляемые. Стоят они намного больше, чем 10 тысяч рублей. Плюс ещё блоки питания и ИБП, плюс, колллеги, обеспечивающие безопасность периметра могут что-то своё туда устанавливать. Всё содержимое точно будет в несколько раз дороже, чем сам ящик.
Если же будет взрыв, проложить заново кабели намного дешевле и быстрее, чем купить новое оборудование, дождаться его приезда, выслать инженера, который настроит и т.д.
Цикл эксплуатации обычных коммутаторов Cisco составляет 5-7 лет, для промышленных коммутаторов он в 2-3 раза больше. Там и схемотехника надёжнее и вендор сохраняет поддержку в течение таких сроков. Это совсем не "одноразовое" оборудование.
Лучше всегда сравнивать общую цену решения для конкретной задачи — конкретного количества филиалов, производительности устройств, которые там нужны, функционала этих устройств и компонентов управления. Причём, и разовое вложение — при покупке, и ежегодные — обновления, техподдержка, подписки.
Но на самом деле не факт, что это всегда нужно. Если вдруг у вас канал выдаёт не одинаковое качество на Upstream и Downstream (и Probe это покажут), с точки зрения качества работы приложения, лучше будет передать одно из направлений через другой канал.
Аудит информационной безопасности он очень комплексный, там много всего.
Мы же сделали тот аудит, который нас попросил сделать заказчик, исходя из его финансовых возможностей.
Если речь идет о коммутаторах – то это в первую очередь отключение неиспользуемых интерфейсов, добавление description для всех портов, сегментирование трафика на разные вланы, настройка STP BPDU Guard и STP Root Guard, настройка storm control и port-security. В идеале использование dot1x. Использование безопасных протоколов удаленного доступа – https, ssh, snmpv3. Отключение всех неиспользуемых сервисов Использование централизованной аутентификации и авторизации, в крайнем случае – использование нескольких разных локальных учеток с разным уровнем привилегий. Использование логгирования и синхронизации времени. Подходящая архитектура, это устройства и ПО, поддерживающие данный перечисленный функционал.