По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
В этой статье мы рассмотрим некоторые протоколы, такие как NTP, syslog и SNMP. Все они используются для мониторинга "работоспособности" вашей сети. При правильной настройке они могут быть очень полезны...если они не работают, может быть действительно трудно выяснить, когда в сети произошло определенное событие и что его вызвало. Syslog и SNMP используются для мониторинга сети, NTP используется для обеспечения того, чтобы наша регистрационная информация имела правильное время и дату. Мы начнем с NTP - это не очень сложный протокол, но есть несколько вещей, которые могут пойти не так: Фильтрация трафика NTP: списки доступа могут блокировать трафик NTP. Проблемы аутентификации NTP: NTP поддерживает аутентификацию, клиент и сервер должны использовать одинаковые настройки. Слишком большое временное смещение: если временное смещение между клиентом и сервером слишком велико, для синхронизации потребуется очень много времени. Stratum level слишком высокий: Stratum level составляет от 1 (лучший) до 15 (худший). Stratum level 16 считается непригодным. Фильтр источника NTP-сервера: NTP-серверы можно настроить так, чтобы разрешать только клиентам с определенных IP-адресов. Давайте разберем эти вопросы. Мы будем использовать два маршрутизатора для этого: Урок 1 R1 будет нашим NTP-клиентом, а R2 будет NTP-сервером. Есть две полезные команды, с которых мы должны начать: Команды говорят нам, что R1 имеет адрес 192.168.12.2, настроенный как сервер NTP, и в настоящее время он не синхронизирован. Давайте проверим, получает ли R1 пакеты NTP, это лучше всего сделать с помощью отладки: Эта отладка говорит нам, что R1 отправляет NTP-пакеты, но мы ничего не получаем от NTP-сервера. Убедитесь, что NTP-сервер разрешен для прохождения: R1 использует UDP-порт 123, убедитесь, что он не заблокирован: R1(config)#interface FastEthernet 0/0 R1(config-if)#no ip access-group NO_TIME in После удаления списка доступа, NTP сможет использовать пакеты NTP с сервера: Вот конечный результат: Часы теперь синхронизированы. Другая проблема, которую вы можете обнаружить с помощью debugging NTP, - это несоответствие аутентификации: R1(config)#ntp server 192.168.12.2 key 1 R1(config)#ntp authentication-key 1 md5 MY_KEY Мы настроим R1 так, чтобы он принимал только NTP-пакеты от NTP-сервера, которые аутентифицированы с определенным ключом. Сервер NTP, однако, не использует никакой формы аутентификации. Мы можем найти эту ошибку с помощью следующей отладки: Это расскажет нам о: Убедитесь, что ваши настройки аутентификации NTP совпадают с обеих сторон. Когда разница во времени / дате между сервером NTP и клиентом велика, синхронизация займет много времени. Прямо сейчас часы выглядят так: Установка часов на NTP-клиенте на что-то близкое к NTP-серверу значительно ускорит процесс синхронизации: R1#clock set 18:00:00 30 January 2015 Через несколько минут часы на клиенте NTP должны быть синхронизированы. Еще одна проблема с NTP заключается в том, что stratum level ограничен, мы можем использовать значения от 1 (лучший) до 15 (худший). Если у сервера NTP есть stratum level 15, то клиент NTP не сможет синхронизировать, так как 16 считается недостижимым. Отладка пакетов NTP на клиенте покажет это: R1 никогда не сможет синхронизировать себя, поскольку NTP-сервер объявляет себя как stratum -уровень 15. Вы можете исправить это, установив более низкое значение stratum - уровня NTP на своем NTP-сервере: R2(config)#ntp master 2 Мы изменяем его на значение 2 уровня. Это позволяет R1 синхронизировать себя: И последнее, но не менее важное: NTP-серверы могут быть настроены так, чтобы разрешать NTP-клиентам только с определенных IP-адресов: Например, мы настрою его, чтобы разрешить только IP-адрес 1.1.1.1: R2(config)#ntp access-group serve 1 R2(config)#access-list 1 permit 1.1.1.1 R2(config)#ip route 1.1.1.1 255.255.255.255 192.168.12.1 В этом случае нам нужно убедиться, что NTP-клиент получает свои NTP-пакеты с правильного IP-адреса: R1(config)#interface loopback 0 R1(config-if)#ip address 1.1.1.1 255.255.255.255 R1(config)#ntp source loopback0 Команда NTP source скажет R1 использовать IP-адрес 1.1.1.1 из своего loopback интерфейса в качестве источника своих пакетов NTP. Это самые распространенные ошибки NTP. Урок 2 Давайте продолжим, посмотрев на syslog. Наиболее распространенная проблема с системным журналом - это отсутствие информации о регистрации. По умолчанию ведение журнала включено только для консоли, а не для внешних серверов системного журнала. Есть одна команда, которую вы можете использовать для проверки ее конфигурации: Это говорит нам, что системный журнал включен для консоли вплоть до уровня отладки. Если вы не видите всего на консоли, то кто-то, возможно, изменил уровень ведения журнала на более низкое значение. Вот варианты: Уровень отладки - самое высокое значение (7), поэтому он покажет все сообщения системного журнала. Если вы не видите все сообщения, убедитесь, что они установлены на уровне отладки для консоли. По умолчанию информация системного журнала не отправляется на внешний сервер. Вы должны это настроить самостоятельно: R1(config)#logging host 192.168.12.2 Это приведет к отправке регистрационной информации для всех уровней серьезности на внешний сервер по адресу 192.168.12.2. Убедитесь, что этот трафик не заблокирован, syslog использует UDP-порт 514. Другая распространенная ошибка - сообщения системного журнала не отображаются в сеансах telnet или SSH. Вы можете включить это с помощью команды terminal monitor. Урок 3 Следующий протокол, который мы обсудим, - это SNMP версии 2c и 3. Перед тем, как погрузиться в конфигурацию SNMP, убедитесь, что ваш NMS (сервер сетевого управления) может связаться с вашим устройством (агент SNMP). SNMP использует UDP-порт 161 для сообщений и UDP-порт 162 для прерываний и информирования. Убедитесь, что этот трафик разрешен. Когда дело доходит до SNMPv2c, есть несколько общих проблем: Неправильная community-string: community-string похожа на пароль, который используется для того, чтобы NMS могла читать или записывать данные на сетевое устройство. Если он не совпадает, SNMP не будет работать. Ошибки списка доступа: списки доступа могут определять, какой NMS разрешено использовать community-string. Убедитесь, что вы используете правильный IP-адрес. Перемешивание индексов: при добавлении новых интерфейсов к сетевому устройству номера интерфейсов могут больше не совпадать. Ловушки не отправлены: если вы хотите отправить SNMP-ловушки (или сообщения), то вам нужно будет настроить это, это не делается автоматически. Вот соответствующие команды SNMPv2c, которые вы должны проверить в случае, если SNMP не работает: R1(config)#snmp-server community MY_COMMUNITY ro 1 R1(config)#access-list 1 permit host 192.168.1.1 Выше мы настроили сообщество под названием MY_COMMUNITY с доступом только для чтения. Мы используем access-list 1, чтобы определить, какому устройству разрешено использовать это сообщество. Убедитесь, что в списке доступа указаны правильные операторы разрешений. Следующая команда гарантирует, что индекс интерфейса остается прежним: R1(config)#snmp-server ifindex persist И если вы хотите отправлять SNMP-ловушки, настройте его следующим образом: R1(config)#snmp-server enable traps eigrp R1(config)#snmp-server host 192.168.1.1 traps version 2c MY_COMMUNITY Это активирует ловушки SNMP для EIGRP и будет отправлено в NMS на IP-адрес 192.168.1.1 с использованием сообщества "MY_COMMUNITY". Если вы не укажете, какие ловушки вы хотите, он включит все ловушки. SNMPv3 сильно отличается от версии 2, в безопасность и аутентификацию внесено много изменений. При поиске и устранении неисправностей SNMPv3 необходимо учитывать несколько моментов, связанных с SNMPv3: Вложенность: с помощью SNMPv3 мы создаем пользователей, которые вложены в группы. Группы вложены в представления, которые предоставляют доступ к определенным MIBs на сетевом устройстве. Убедитесь, что ваш пользователь находится в правильной группе и что представление имеет правильные разрешения на просмотр. Уровень безопасности: SNMPv3 поддерживает разные уровни безопасности, они должны совпадать на сетевом устройстве и NMS: noAuthNoPriv authNoPriv authPriv Параметры безопасности: SNMPv3 предлагает несколько алгоритмов хеширования и шифрования. Убедитесь, что вы настроили одинаковые алгоритмы на сетевом устройстве и NMS. Конфигурация представлений: в представлении мы настраиваем объекты, к которым NMS разрешен доступ, убедитесь, что вы настроили правильные объекты. Ниже приеден пример конфигурации того, что мы обсуждали: Router(config)#snmp-server user MY_USER MY_GROUP v3 auth md5 MY_PASSWORD priv aes 128 MY_PASSWORD Сначала мы настраиваем пользователя с именем MY_USER, который принадлежит группе с именем MY_GROUP. Мы используем версию 3 SNMP. Для аутентификации этого пользователя мы используем MD5 и пароль "MY_PASSWORD". Для шифрования мы используем 128-битный AES и тот же пароль. Убедитесь, что на сетевом устройстве и NMS все одинаково ... Теперь мы настраиваем группу: Router(config)#snmp-server group MY_GROUP v3 priv read MY_VIEW access 1 Router(config)#access-list 1 permit host 192.168.1.1 Группа называется MY_GROUP, и мы используем уровень безопасности authPriv. Мы также присоединяем группу к представлению под названием MY_VIEW. Мы также используем список доступа, только NMS, использующая IP-адрес 192.168.1.1, может использовать эту группу. Давайте настроим view: Router(config)#snmp-server view MY_VIEW system included Router(config)#snmp-server view MY_VIEW cisco included Это представление позволяет NMS получать доступ только к объектам в системной группе MIB-II и ко всем объектам в корпоративной MIB Cisco. Убедитесь, что вы добавили все объекты, к которым вам нужен доступ. Информация о пользователе не отображается в конфигурации, если вы хотите увидеть пользователей, вам нужно использовать другую команду: Эта команда показывает нам нашу учетную запись пользователя, ее алгоритмы аутентификации и шифрования и сообщает, к какой группе она принадлежит.
img
Прямо сейчас, пока ты читаешь эту статью, в серверной комнате организации А под толстым слоем пыли, окруженная множеством переплетенных проводов мигает разноцветными лампочками офисная АТС. Но давайте будем тише - дежурный IT - специалист, скорее всего спит, поставив переадресацию на мобильный телефон - а вдруг что - то сломается? Вообще, облака, на своем старте - наделали шума. Все начали задаваться вопросом - а зачем нам сервер в офисе, когда можно арендовать VPS/VDS/SaaS в облаке и “не париться”? В статье мы ответим на вопрос - почему одни компании выносят свою телефонию в облако или покупают услугу виртуальной АТС, тем самым создавая возможность поставить вендинговую машину или настольный теннис в серверной комнате, а другие, продолжают перебирать провода, протирать пыль с серверов и наслаждаться мерцанием цветовых серверных индикаторов от офисной АТС. Бюджет: сравниваем облако и размещение в офисе Первое, что стоит спросить себя - а как мы будем платить за АТС? Что для нас важно, а что нет? Мы, как интегратор, все чаще сталкиваемся с тем, что в компаниях (SMB) идет сокращение бюджета на IT и соответствующие отделы находят выходы из этой ситуации. С точки зрения локальной (офисной) АТС - далее мы будем называть ее порой “on-premise” решение (говоря так, мы чувствуем себя немного круче), IT - отдел экономит деньги ежемесячной оплате хосту (SaaS платформе, которая дает вам услугу виртуальной АТС). Но эта экономия реальна только в том случае, если вы не меняете аппаратные компоненты сервера с АТС. В таком случае модель вы платите только за услуги провайдера, электричество и заработную плату IT’шнику. Модель “купил - запитал - работает, не трожь” работает, более чем. Однако, в случае выхода из строя того или иного компонента, компания несет определенного рода дополнительные расходы. Отметим, опять же, на нашем опыте - случается это редко. Современные сервера имеют высокое качество комплектующих, и если вы не планируете поливать сервера водой, обдавать из огнемета или выставлять на улице - скорее всего, данная неприятность вам не грозит. Не менее важный фактор - обновление ПО. Проблема в том, что если вы обновляете программное обеспечение офисной “on-premise” (да - да, мы же предупреждали) АТС, есть риск выхода из строя. Опять же, данная проблема решается простым резервированием, так называемой отказоустойчивостью, по принципу Active - Standby (один сервер активен, а второй в резерве и всегда готов выйти в активную роль). Этот нюанс требует дополнительной проработки, а следовательно, дополнительных денежных затрат. Теперь про масштабируемость. В случае, если проснувшись в один прекрасный день вы осознаете, что ваш бизнес вырос в разы (вы сходили на бизнес - тренинг, к шаману или проделали магический обряд), то офисные локально размещенные станции масштабируются несколько сложнее и затратнее, чем виртуальные. Это отражается на деньгах и стоимости масштабирования. Тут есть важный пункт - офисная АТС гораздо более гибка, чем виртуальная. Дело в том, что виртуальная АТС дается вам в неком готовом контейнере предустановок, где SaaS платформа редко дает возможность доработки станции. Да, признаем, некоторые облачные АТС имеют API, но когда вопрос заходит о масштабном изменении логики работы АТС (кастомизация скриптами, например) - тут происходит коллапс. В этом плане офисные АТС явно выигрывают перед облачными, несмотря на стоимость затрат на эту самую кастомизацию. Просто сам факт ее возможность при быстром росте бизнеса - это преимущество (поверьте, знаем о чем говорим на опыте разных проектов). Редкие, но некоторые IT - отделы предпочитают облачную телефонию. Это более предсказуемо и снимает с них часть ответственности. Например, когда директор компании задает вопрос ITшнику почему не работает телефония, тот может смело спихнуть ответственность на виртуального хостера. Модернизация и апгрейд: витаем в облаках или в офисе? Тут пальму первенства заслуженно забирают облака. Дело в том, что если у вас в офисе живет on-premise АТС, так или иначе, рано или поздно вам придётся обновлять аппаратные компоненты сервера (процессор, оперативная память, наращивать мощность RAID массивов, тем самым увеличивая пространство для хранения данных). Это происходит по двум причинам: растёт нагрузка на сервер и текущие мощности уже не справляются, или обновление программного обеспечения требует более производительных комплектующих. При облачном размещении таких проблем нет - ваш хост автоматически наращивает мощности виртуальной машины, внутри которой живет ваша АТС. Это, безусловно, сказывается на мощности, но выходит дешевле покупки комплектующих под локальных сервак. Кстати про обновление - в случае решения, размещённого в вашем офисе, обновление ПО производят ваши ITшники, тогда как при размещении в облаке, хост сам обновляет ПО и раскатывает их на боевую среду. Интеграция телефонии с внешними системами Любителям on-premise решений посвящается. Откиньтесь на диване поудобнее - в этой главе уже есть победитель. И это не облако. Дело в том, что с ростом компании, уровень технологичности неизбежно повышается. Новые направления деятельности и увеличение потока клиентов обязывают связать ИТ - узлы в единую экосистему: интеграция телефонии и CRM, справочниками, базами данных, звонки по нажатию, триггерный автоматический обзвон, предиктивный дайлер и прочие. Все эти “хотелки” так или иначе требуют доработки вашей станции, так как интеграцию со всем на свете разработчики облачный виртуальных АТС предусмотреть не могут, а открыть исходный код и раздвинув горизонт кастомизации до бесконечности, рискуют получить уязвимости в безопасности. Именно по этой причине, офисная коробка дает больше. Например: вы хотите сделать маршрутизацию на базе гороскопа клиента. В вашей CRM есть номер телефона клиента, имя и его дата рождения. При входящем звонке, телефония “смотрит” в вашу CRM и видит месяц рождения клиента (по номеру, с которого он звонит). Кастомная прослойка понимает - он рыба, а рыбам, сегодня не рекомендуется иметь деловых отношений. И на базе этого решения офисная телефонная станция терминирует вызов. Как вам? Пожалуй, надо признать, пример весьма спорный. Но посыл понятен - коробка в офисе даст больший пул возможностей, а облако, максимум, обрезанный API. Катастрофы: коробки или облако? В офисе над вами прорвало трубу и залило серверную (мы реально встречали такие кейсы). Сервера вышли из строя, не работает ничего. Есть две новости, начнем с хорошей: Сервер был на гарантии и имеется контракт на горячую замену от интегратора; Сервера больше нет. Несмотря на контракт горячей замены, просто в минимум 24 часа вам гарантирован (если не реализована схема отказоустойчивости с географически распределенными серверами по ЦОДам). В облаке, как правило, SaaS дает вам гарантию работоспособности от 90%. Облачная вычислительная мощность живет в разных ЦОДах, при отказе аппаратного сервера, виртуальная машина с вашей ВАТС переедет на другой аппаратный сервер за сотые доли секунды. Что неплохо. Тут, пожалуй, для SMB компании первенство мы отдадим облаку. Итоги Как облака, так и размещенные в офисе решения имеют свои преимущества. Если курс вашей компании на безграничную кастомизацию, интеграцию всех ИТ - систем между собой для создания экосистемы и амбициозные бизнес - процессы, у вас есть грамотный IT - специалист, то выбирайте коробку, которую вы разместите в офисе. Если вы не хотите проблем с сервером, обслуживанием, вы малый бизнес, у вас нет своего IT’шника в штате и хотите рабочую телефонию с минимумом головной боли - облако подойдет под ваши требования.
img
Оболочка bash предлагает широкий выбор сочетаний клавиш, которые вы можете использовать. Они будут работать в bash в любой операционной системе. Работа с процессами Используйте следующие сочетания клавиш для управления запущенными процессами: Ctrl + C: прервать (убить) текущий процесс, запущенный в терминале на переднем плане. Это посылает процессу сигнал SIGINT, который технически является просто запросом - большинство процессов его учтут, но некоторые могут и проигнорировать. Ctrl + Z: приостановить текущий процесс, запущенный в bash на переднем плане. Это отправляет процессу сигнал SIGTSTP. Чтобы позже вернуть процесс на передний план, используйте команду fg имя_процесса. Ctrl + D: закрыть оболочку bash. Это отправляет маркер EOF (End of file - конец файла) в bash, и bash завершает работу, когда получает этот маркер. Это похоже на команду exit. Перемещение курсора Используйте следующие сочетания клавиш, чтобы быстро перемещать курсор по текущей строке при вводе команды. Ctrl + A или Home: перейти к началу строки. Ctrl + E или End: перейти в конец строки. Alt + B: перейти на одно слово влево (назад). Ctrl + B: перейти на один символ влево (назад). Alt + F: перейти вправо (вперед) на одно слово. Ctrl + F: перейти вправо (вперед) на один символ. Ctrl + XX: перемещение между началом строки и текущей позицией курсора. То есть можно нажать Ctrl + XX, чтобы вернуться в начало строки, что-то изменить, а затем нажать Ctrl + XX, чтобы вернуться в исходную позицию курсора. Чтобы использовать этот шорткат, удерживайте клавишу Ctrl и дважды нажмите X. Исправление опечаток Эти сочетания позволяют исправлять опечатки и отменять нажатия клавиш. Alt + T: заменить текущее слово предыдущим. Ctrl + T: поменять местами два последних символа перед курсором. Можно использовать, чтобы быстро исправить опечатки, когда вы вводите два символа в неправильном порядке. Ctrl + _: отменить последнее нажатие клавиши. Можно использовать несколько раз подряд. Вырезка и склейка Bash включает в себя несколько основных функций вырезания и вставки. Ctrl + W: вырезать слово перед курсором и добавить его в буфер обмена. Ctrl + K: вырезать часть строки после курсора, добавив ее в буфер обмена. Ctrl + U: вырезать часть строки перед курсором, добавив ее в буфер обмена. Ctrl + Y: вставить последнее вырезанное из буфера обмена. Заглавные буквы Оболочка bash может быстро преобразовывать символы в верхний или нижний регистр: Alt + U: вводить каждый символ от курсора до конца текущего слова с заглавной буквы, переводя символы в верхний регистр. Alt + L: убирает заглавные буквы с каждого символа от курсора до конца текущего слова, переводя символы в нижний регистр. Alt + C: ввести заглавную букву под курсором. Ваш курсор переместится в конец текущего слова. Табуляция Завершение при помощи табуляции - очень полезная функция bash. При вводе имени файла, каталога или команды нажмите Tab, и bash автоматически завершит ввод, если это возможно. Если нет, bash покажет вам различные возможные совпадения, и вы можете продолжить вводить и нажимать Tab, чтобы закончить ввод. Tab: автоматическое заполнение файла, каталога или команды, которую вы вводите. Например, если у вас есть файл с длинным именем really_long_file_name в /home/alex/ и это единственное имя файла, начинающееся с r в этом каталоге, вы можете ввести /home/alex/r, нажать Tab, и bash автоматически заполнит /home/alex/really_long_file_name для вас. Если у вас есть несколько файлов или каталогов, начинающихся с r, bash проинформирует вас о доступных вариантах. Вы можете начать вводить один из них и нажать Tab, чтобы продолжить. Работа с историей команд Вы можете быстро просмотреть свои недавние команды, которые хранятся в файле истории bash вашей учетной записи: Ctrl + P или стрелка вверх: переход к предыдущей команде в истории команд. Нажмите ярлык несколько раз, чтобы вернуться к истории. Ctrl + N или стрелка вниз: переход к следующей команде в истории команд. Нажмите ярлык несколько раз, чтобы перейти вперед по истории. Alt + R: отменить любые изменения команды, извлеченной из истории, если вы ее редактировали. В Bash также есть специальный режим поиска, который вы можете использовать для поиска ранее выполненных команд: Ctrl + R: вспомнить последнюю команду, соответствующую указанным вами символам. Нажмите это сочетание и начните вводить символы для поиска команды в истории bash. Ctrl + O: запустите найденную команду с помощью Ctrl + R. Ctrl + G: выйти из режима поиска в истории без выполнения команды.
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59