По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
В этой статье мы расскажем как исправить ошибку «System logs are stored on non-persistent storage» (Ваши события не будут сохранены при отключении сервера) в VMware ESXi Решение Проверка местоположения системных событий в vSphere Client (HTML5) В навигаторе vSphere Client выберите Hosts and Clusters view. Выберите хост-объект в навигаторе vSphere Client. Нажмите на вкладку Configure, затем System expander. В разделе System выберите Advanced System Settings. Убедитесь в том, что параметр Syslog.global.logDir в качестве местонахождения указывает постоянное хранилище. Если поле Syslog.global.logDir пустое или указывает на scratch partition, убедитесь, что поле ScratchConfig.CurrentScratchLocation в качестве местонахождения указывает постоянное хранилище. Если папка используется в качестве хранилища scratch, которое является общим для большого количества ESXi хостов, вам также необходимо установить поле Syslog.global.logDirUnique,чтобы избежать конкуренции лог-файлов. Примечание: Чтобы войти в datastore, запись Syslog.global.logDir должна быть в формате [Datastorename]/foldername. Чтобы войти в scratch partition в ScratchConfig.CurrentScratchLocation введите пустой формат или []/foldername. Версии ESXi 6.5, 6.7 и выше реагируют на изменения незамедлительно. Более старым версиям для этого может потребоваться перезагрузка. Проверка местоположения системных событий в vSphere Web Client Перейдите к хосту в навигаторе vSphere Web Client. Нажмите вкладку Manage, затем Settings. В разделе System выберите Advanced System Settings. Убедитесь в том, что параметр Syslog.global.logDir в качестве местонахождения указывает постоянное хранилище. Если поле Syslog.global.logDir пустое или указывает на scratch partition, убедитесь, что поле ScratchConfig.CurrentScratchLocation в качестве местонахождения указывает постоянное хранилище. Если папка используется в качестве хранилища scratch, которое является общим для большого количества ESXi хостов, вам также необходимо установить поле Syslog.global.logDirUnique,чтобы избежать конкуренции лог-файлов. Проверка местоположения системных событий в vSphere Client (vSphere 6.0 и более ранние версии) В программе vSphere Client выберите хост на инвентарной панели. Нажмите на вкладку Configuration, затем – на Advanced Settings в разделе Software. Убедитесь в том, что параметр Syslog.global.logDir в качестве местонахождения указывает постоянное хранилище. У каталога должны быть название и путь к хранилищу данных [datastorename] path_to_file. Например, [datastore1] /systemlogs. Если поле Syslog.global.logDir пустое или указывает scratch partition в качестве хранилища, убедитесь, что поле ScratchConfig.CurrentScratchLocation указывает в качестве местонахождения постоянное хранилище. Дополнительная информация Если вы видите, что работающий хост сохраняет информацию в хранилище scratch в формате >UUID (/vmfs/volumes/xxxxxxxx-xxxxxxxx-xxxx-xxxxxxxxxxxx/foldername) и хотите, чтобы имя «friendly» отобразилось в вашем vCenter или host client view, вы можете: Подключиться к рабочему хосту через сеанс SSH и войти в систему с учетными данными root Использовать команду: # esxcli storage filesystem list. Выход будет приблизительно таким: /vmfs/volumes/ad495351-37d00fe1-c498-a82a72e0c050 abc-lun3 ad495351-37d00fe1-c498-a82a72e0c050 true VMFS-5 805037932544 400613703680 В этом примере abc-lun3 – это имя «friendly» хранилища данных, которое вы найдете в вашем vCenter или host client, и запись Syslog.global.logDir должна быть в формате [abc-lun3]/foldername.
img
Безопасность личных данных стоит почти наравне с физической безопасностью людей. Развитие Интернет технологий создало возможность мгновенного доступа ко всей информации не выходя из дома. Государственные организации создают электронный порталы, где можно получить любую информацию о себе. Финансовые организации оказывают онлайн услуги клиентам в виде интернет-банкинга. Публичные сети же сделали все это более доступным. Сидя в любом кафе можем проверить свой банковский счет, получить нужную справку в электронном формате, занять онлайн очередь в разных структурах. Но зачастую подключаясь к открытым, бесплатным беспроводным сетям мы даже не задумываемся, а на самом ли деле на том конце стоит маршрутизатор и наши данные не попадают в руки тех, кто не должен их видеть. В публичных сетях много угроз, одной из которых является атака MITM Man-in-the-Middle "Человек посередине" или атака посредника. Вкратце это такой тип атаки когда хакеры, подключившись к точке доступа, могут поместить себя в качестве посредника между двумя пользователями, у которых нет протоколов взаимной аутентификации. Как только злоумышленники полностью завладевают соединением, они могут читать и даже изменять любую передаваемую информацию. Опытные хакеры могут даже извлечь из потока данных информацию о вашей банковской карте. Последствия утраты таких данных очевидны. Такой вид атаки легче организовать в беспроводных сетях, хотя и проводные сети не застрахованы от этой атаки. Но в проводных сетях можно настроить сетевые устройства таким образом, чтобы она реагировала на смену связки IP и MAC-адреса и при обнаружении заблокировать доступ к сети подозрительному устройству. В проводных же сетях, особенно если это публичные сети, всё немного сложнее. Поэтому пользователям придется самим позаботиться о безопасности своих личных данных. Приготовиться к атаке! Чтобы не стать жертвой атаки типа MITM, нужно знать всего несколько правил безопасности. Первое правило - Firewall Во-первых, включите на своём устройстве межсетевой экран. В системе Windows это Windows Defender Firewall. Он по умолчанию включён, если у вас не установлено стороннее ПО, выполняющее ту же функцию. Проверить и включить Firewall можно на панели управления перейдя по одноимённому пункту меню и выбрав Включить/выключить Windows Defender Firewall: Это защитит ваш компьютер от вторжения злоумышленника и кражи ваших электронных данных. Также не помещает установить какой-нибудь антивирус, даже бесплатный, который способен защитить ваше устройство от заражения сетевым червем, который тоже занимается кражей данных и не только. Никакого HTTP! Во-вторых, в публичных сетях лучше избегать пользования услугами онлайн-банкинга. Но если есть сильная необходимость, то убедитесь, что ваш банк обеспечивает шифрованное соединение между вами и сервером. Проверить это легко. При шифрованном соединении в строке браузера перед адресом отображается значок замка, а перед адресом сайта отображается https://. HTTPS это защищенный протокол передачи данных в сети. Hypertext Transfer Protocol основной протокол связи в интернете. Когда пользователь вводит адрес в строке браузера, последний создает соединение с веб-сервером по этому протоколу. Позже была разработана защищенная версия данного протокола, которая отправляет данные поверх SSL или TLS. Такое соединение позволяет шифровать данные перед отправкой на сервер. Шифрование происходит на устройстве пользователя методом асимметричного шифрования с помощью публичного ключа, который сайт отправляет вам вместе с сертификатом. Посмотреть сертификат сайта и публичный ключ можно в том же браузере. В Google Chrome кликаем на значок замка и выбираем Certificate. В открывшемся окне можно увидеть всю информацию о сертификате включая срок действия и подписавшую сертификат центра сертификации. Расшифровать данные сможет только веб-сервер где имеется вторая приватная часть ключа шифрования. И даже если ваши зашифрованные данные попадут в руки злоумышленников, расшифровать их им придется долго. Правда, атака посредника имеет несколько векторов развития и при наличии необходимых навыков злоумышленник может получить доступ даже к шифрованной информации. Например, он может взломать сервера центра сертификации и заполучить все ключи, которые выданы клиентам. Но это уже больше забота самих центров сертификации. Некоторые сайты имеют две версии, защищенную и обычную через http-протокол. Чтобы всегда пользоваться только защищенным соединением, можете устанавливать специальные расширения для браузеров. Шифрование через VPN В-третьих, при подключении к публичным сетям рекомендуется пользоваться VPN сервисами. VPN сервисы создают защищенный туннель между вами и серверами поставщика VPN услуг. Все данные в таком туннеле тоже шифруются надежными алгоритмами шифрования. Услуги VPN предоставляют даже некоторые браузеры, например Opera или Яндекс.Браузер. Так же есть специальные расширения для браузеров и настольные приложения. Правда, при работе через VPN скорость ощутимо падает, но безопасность данных того стоит. Кстати, о том, что такое VPN и как он обходит блокировки можно почитать в нашей статье Ну а напоследок, просто быть повнимательнее. Не нужно подключаться к первой попавшейся беспроводной сети с подозрительным названием. Если вы сидите в кафе, то название точки доступа обычно совпадает с названием объекта. Правда, подмену SSID никто не отменял, но для этого нужно вырубить роутер, безопасность которого забота сотрудников ИТ отдела данного объекта. Безопасного интернет-серфинга!
img
Теперь мы можем продолжить поиск и устранение неисправностей. В большинстве случаев вы ожидаете увидеть определенную сеть в таблице маршрутизации, но ее там нет. Далее рассмотрим несколько сценариев неправильной (или полностью не рабочей) работы EIGRP и как исправить наиболее распространенные ошибки. Ниже перечислены часто встречающиеся ошибки: Первую часть статьи про траблшутинг EIGRP можно почитать здесь. Кто-то настроил distribute-list, чтобы информация о маршрутах фильтровалась. Было настроено автосуммирование или кто-то настроил суммирование вручную Split-horizon блокирует объявление маршрутной информации. Перераспределение было настроено, но информация из EIGRP не используется. Перераспределение было настроено, но никакие внешние маршруты EIGRP не отображаются. Case #1 Давайте начнем с простой топологии. OFF1 и OFF2 работают под управлением EIGRP, и каждый маршрутизатор имеет интерфейс обратной связи. Вот конфигурация обоих маршрутизаторов: OFF1(config)#router eigrp 12 OFF1(config-router)#no auto-summary OFF1(config-router)#network 1.1.1.0 0.0.0.255 OFF1(config-router)#network 192.168.12.0 0.0.0.255 OFF2(config)#router eigrp 12 OFF2(config-router)#no auto-summary OFF2(config-router)#network 2.2.2.0 0.0.0.255 OFF2(config-router)#network 192.168.12.0 0.0.0.255 Все работает нормально, пока через пару недель один из пользователей не пожаловался на то, что ему не удалось подключиться к сети 2.2.2.0 / 24 из-за OFF1. Посмотрите на таблицу маршрутизации на OFF1, и вот что вы видите: По какой-то причине нет сети 2.2.2.0 / 24 в таблице маршрутизации. Видно, что на OFF1 не настроен distribute lists. OFF2 содержит сеть 1.1.1.0 / 24 в своей таблице маршрутизации. Давайте выполним быструю отладку, чтобы увидеть, что происходит. Отладка показывает нам, что происходит. Прежде чем вы увидите это сообщение, придется немного подождать, или вы можете сбросить соседство EIGRP, чтобы ускорить процесс. Как видите, в сети 2.2.2.0 / 24 отказано из-за distribute list. Другой быстрый способ проверить это - использовать команду show ip protocol. В этом случае использование show run могло бы быстрее обнаружить distribute-list. Вот список доступа, доставляющий нам неприятности. OFF2(config)#router eigrp 12 OFF2(config-router)#no distribute-list 1 out Удалим distribute-list. Задача решена! Извлеченный урок: если команды network верны, проверьте, есть ли у вас distribute-list, который запрещает объявлять префиксы или устанавливать их в таблицу маршрутизации. Имейте в виду, distribute-list могут быть настроены как входящие или исходящие, как список доступа. Case #2 В следующем сценарии те же 2 маршрутизатора, но разные сети в loopback. Вот конфигурация: OFF1(config)#router eigrp 12 OFF1(config-router)#network 192.168.12.0 OFF1(config-router)#network 10.0.0.0 OFF2(config)#router eigrp 12 OFF2(config-router)#network 192.168.12.0 OFF2(config-router)#network 10.0.0.0 Как вы видите - это довольно базовая конфигурация. Глядя на таблицы маршрутизации, не видно сети 10.1.1.0 / 24 или 10.2.2.0 / 24. Видна запись для сети 10.0.0.0/8, указывающую на интерфейс null0. Эта запись отображается только при настройке суммирования и используется для предотвращения циклов маршрутизации. Давайте включим отладку и посмотрим, что мы можем найти. OFF2#clear ip eigrp 12 neighbors Этой командой мы сделаем сброс соседства EIGRP, чтобы ускорить процесс. Имейте в виду, что это, вероятно, не самое лучшее, что можно сделать в производственной сети, пока вы не узнаете, что не так, но это действительно помогает ускорить процесс. Вот наш ответ. Отладка говорит нам, что сеть 10.2.2.0 / 24 не следует объявлять, а сеть 10.0.0.0 / 8 нужно объявлять (это вкратце). Это может произойти по двум причинам: Суммирование было кем-то настроено Авто-суммирование включено для EIGRP. Как вы видите, авто-суммирование включено для EIGRP. В зависимости от версии IOS авто-суммирование включено или отключено по умолчанию. OFF1(config)#router eigrp 12 OFF1(config-router)#no auto-summary OFF2(config)#router eigrp 12 OFF2(config-router)#no auto-summary Отключение автоматического суммирования должно помочь. Ну что, наши сети появились в таблице маршрутизации. Извлеченный урок: если включена автоматическое суммирование EIGRP, вы можете столкнуться с нестабильными сетями. Case #3 Очередная проблема. В приведенном выше примере у нас есть 2 маршрутизатора, но разные сети. OFF1 содержит сеть 172.16.1.0 / 24 на интерфейсе обратной связи, а OFF2 содержит сеть 172.16.2.0 / 24 и 172.16.22.0 / 24 на своих интерфейсах обратной связи. Посмотрим конфигурацию EIGRP обоих маршрутизаторов: Как вы видите, что все сети объявляются. Обратите внимание, что в OFF1 включено автоматическое суммирование, а в OFF2 отключено автоматическое суммирование. Кто-то настроил суммирование на OFF2 и отправляет ее на OFF1. Суммирование создана для сети 172.16.0.0 / 16. Однако, если посмотреть на таблицу маршрутизации OFF1, она не появится. Мы видим запись для сети 172.16.0.0 / 16, но она указывает на интерфейс null0, а не на OFF2. Что здесь происходит? OFF2#clear ip eigrp 12 neighbors Давайте сделаем отладку на OFF2, чтобы увидеть, объявляется ли суммирование. Выполним команду clear ip eigrp neighbors, просто чтобы ускорить процесс. Глядя на отладку, видно, что OFF2 работает правильно. Он объявляет сводный маршрут 172.16.0.0 / 16 так, как должен. Это означает, что проблема должна быть в OFF1. Давайте проведем отладку OFF1. Мы можем видеть, что OFF1 получает сводный маршрут от OFF2, но решает не использовать его. Это хороший момент для проверки таблицы топологии EIGRP. Вы видите, что он имеет суммирование сети 172.16.0.0 / 16 от OFF2 в своей таблице топологии EIGRP, но OFF1 решает не использовать ее, потому что вход через интерфейс null0 является лучшим путем. OFF1(config)#router eigrp 12 OFF1(config-router)#no auto-summary Решение состоит в том, что нам нужно избавиться от записи null0 в таблице маршрутизации. Единственный способ сделать это - отключить автоматическое суммирование. Отключение автоматического суммирования удаляет запись null0, и теперь суммирование OFF2 установлено проблема решена! Извлеченный урок: автоматическое суммирование EIGRP создает запись через интерфейс null0, которая может помешать установке суммирования, которые вы получаете от соседних маршрутизаторов. Case #4 Есть еще одна проблема с суммированием, которую сейчас и разберем. Мы используем топологию, которую вы видите выше, и ниже конфигурация EIGRP обоих маршрутизаторов. Все сети объявлены, и автоматическое суммирование отключено на обоих маршрутизаторах. Суммирование было настроено на OFF2 и должно быть объявлено к OFF1. К сожалению, ничего не видно на OFF1. Давайте проверим OFF2, чтобы посмотреть, что не так. Когда дело доходит до устранения неполадок с сетью, вашими друзьями являются не Google или Яндекс, а команды Debug и show. Странно, это единственная сеть, которую OFF2 объявляет. Одно из золотых правил маршрутизации: вы не можете объявлять то, чего у вас нет. Очевидно, OFF2 знает только о сети 192.168.12.0 / 24. Вот это ошибка! Кто-то выполнил команду отключения на интерфейсах обратной связи. OFF2(config)#interface loopback 0 OFF2(config-if)#no shutdown OFF2(config)#interface loopback 1 OFF2(config-if)#no shutdown Включим интерфейсы. Теперь мы видим, что суммирование объявляется. Теперь мы видим суммирование в таблице маршрутизации OFF1- проблема решена! Извлеченный урок: вы не можете объявлять то, чего у вас нет в таблице маршрутизации. ВАЖНО. Последняя проблема может быть показаться простой, но есть важный момент, который вы не должны забывать: для объявления итогового маршрута в таблице маршрутизации объявляемого маршрутизатора должен быть указан хотя бы один префикс, попадающий в итоговый диапазон! Case #5 Давайте посмотрим на другую топологию. На рисунке выше у нас есть концентратор Frame Relay и соответствующая топология. Каждый из OFF1 и OFF2 имеет интерфейс обратной связи, который мы будем объявлять в EIGRP. Вот соответствующая конфигурация всех маршрутизаторов: CONC(config)#router eigrp 123 CONC(config-router)#no auto-summary CONC(config-router)#network 192.168.123.0 OFF1(config-if)#router eigrp 123 OFF1(config-router)#no auto-summary OFF1(config-router)#network 192.168.123.0 OFF1(config-router)#network 2.2.2.0 0.0.0.255 OFF2(config)#router eigrp 123 OFF2(config-router)#no auto-summary OFF2(config-router)#network 192.168.123.0 OFF2(config-router)#network 3.3.3.0 0.0.0.255 Видно, что все сети объявлены. Наш концентратор-маршрутизатор видит сети из двух OFF-маршрутизаторов. К сожалению, наши маршрутизаторы не видят ничего ... Похоже, что маршрутизатор-концентратор не объявляет сети, которые он изучает с помощью OFF-маршрутизаторов. Давайте включим отладку, чтобы увидеть, что происходит. CONC#clear ip eigrp 123 neighbors Сбросим соседство EIGRP, чтобы ускорить процесс. В отладке мы видим, что наш маршрутизатор-концентратор узнает о сети 2.2.2.0 / 24 и 3.3.3.0 / 24, но объявляет только сеть 192.168.123.0 / 24 для OFF-маршрутизаторов. Разделение горизонта не позволяет размещать объявление от одного маршрутизатора на другой. CONC(config)#interface serial 0/0 CONC(config-if)#no ip split-horizon eigrp 123 Давайте отключим разделение горизонта на последовательном интерфейсе маршрутизатора-концентратора. Теперь мы видим, что маршрутизатор-концентратор объявляет все сети. OFF-маршрутизаторы теперь могут узнавать о сетях друг друга, поскольку split horizon отключено. Это хорошо, но это еще не все. Извлеченный урок: RIP и EIGRP являются протоколами маршрутизации на расстоянии и используют split horizon. Split horizon предотвращает объявление префикса вне интерфейса, на котором мы его узнали. Хотя сети отображаются в таблицах маршрутизации мы не можем пропинговать от одного OFF-маршрутизатора к другому. Это не проблема EIGRP, но она связана с Frame Relay. Мы должны это исправить. Когда OFF1 отправляет IP-пакет на OFF2, IP-пакет выглядит следующим образом: Давайте пока подумаем, как роутер, и посмотрим, что здесь происходит. Сначала нам нужно проверить, знает ли OFF1, куда отправить 3.3.3.3: Существует запись для 3.3.3.3, а IP-адрес следующего перехода - 192.168.123.1 (маршрутизатор-концентратор). Можем ли мы достичь 192.168.123.1? Нет проблем, кажется, OFF1 может пересылать пакеты, предназначенные для сети 3.3.3.0/24. Давайте перейдем к маршрутизатору CONC. У маршрутизатора-концентратора нет проблем с отправкой трафика в сеть 3.3.3.0 / 24, поэтому на данный момент мы можем сделать вывод, что проблема должна быть в маршрутизаторе OFF2. Это IP-пакет, который получает маршрутизатор OFF2, и когда он отвечает, он создает новый IP-пакет, который выглядит следующим образом: Способен ли OFF2 достигать IP-адрес 192.168.123.2 Давайте узнаем! Теперь мы знаем проблему ... OFF2 не может достичь IP-адреса 192.168.123.2 Если мы посмотрим на таблицу маршрутизации OFF2, то увидим, что сеть 192.168.123.0 / 24 подключена напрямую. С точки зрения третьего уровня у нас нет никаких проблем. Пришло время перейти вниз по модели OSI и проверить уровень 2 ... или, может быть, между уровнем 2 и 3. Frame Relay использует Inverse ARP для привязки уровня 2 (DLCI) к уровню 3 (IP-адрес). Вы можете видеть, что нет сопоставления для IP-адреса 192.168.123.2. OFF2(config)#int s0/0 OFF2(config-if)#frame-relay map ip 192.168.123.2 301 Давайте frame-relay map сами. Теперь роутер OFF2 знает, как связаться с роутером OFF1 Наконец, маршрутизатор OFF1 может пропинговать интерфейс обратной связи маршрутизатора OFF2. Когда мы пытаемся пропинговать от маршрутизатора OFF2 к интерфейсу обратной связи маршрутизатора OFF1, у нас возникает та же проблема, поэтому мы также добавим туда оператор frame-relay map: OFF1(config)#int s0/0 OFF1(config-if)#frame-relay map ip 192.168.123.3 201 Теперь у нас есть extra frame-relay map на маршрутизаторе OFF1. И наш пинг проходит!
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59