У меня есть небольшая некоммерческая организация, которой я помогаю, у которой есть концентратор и оптоволоконная сеть на управляемых коммутаторах Netgear. У них есть возможность подключения как T1, так и DSL, разделенных VLAN с простой запущенной системой VoIP. Происходят странные вещи, и сеть периодически тормозит, а затем зависает. Повторное включение и выключение основного оборудования восстанавливает его работоспособность до следующего раза (обычно через несколько дней). Сеть на самом деле довольно проста (обслуживает около 15 пользователей), и у них нет выделенного ИТ-специалиста, хотя один из наиболее технически подкованных генеральных сотрудников выполняет большую часть обычных ИТ-вещей.
Организация расположена в сельской местности, и у нее возникли проблемы с поиском местной поддержки с достаточными знаниями для диагностики проблемы (предположение, что они систематически заменяют все оборудование до тех пор, пока проблема не исчезнет, не является диагнозом, ИМХО).
Все коммутаторы управляются, и мы могли бы настроить машину для перехвата пакетов, чтобы подключаться непосредственно к настройке порта для мониторинга. Реально ли предположить, что сетевой гуру, входящий в систему удаленно, скорее всего, сможет провести детективную работу, чтобы определить источник проблемы?
Если предположить, что это жизнеспособно, любое направление на сайтах для поиска гуру также будет оценено. Кроме того, если какие-либо сетевые фанаты, читающие это, готовы подрабатывать по разумным ценам, прокомментируйте.
Я бы начал с мониторинга. Если у вас периодически возникают проблемы, которые не исчезают сами по себе, но их решает перезагрузка, проверьте уровень ваших ресурсов. Это признак того, что / что-то / расходует ваши свободные ресурсы определенного типа.
Вы можете настроить управляемый коммутатор для отслеживания предупреждений или странного поведения через SNMP (временно установите выделенный компьютер Linux в их сети с доступом по SSH, если необходимо), но чтобы ответить на ваш вопрос, это зависит ...
Когда у них проблемы с сетью, это медленный, или мертвые?
Это слишком медленно для правильной работы удаленного доступа?
Если сеть все еще работает, вы можете настроить доступ извне к машине Linux, упомянутой выше, чтобы попытаться получить доступ к коммутатору и посмотреть, что он говорит. Я не знаю полной функциональности этого коммутатора, поэтому я не знаю, что он делает или не предупреждает и регистрирует, но это даст вам некоторую точку доступа для мониторинга сетевого трафика, а также для входа в коммутатор (я ' d настроил его для доступа к порту извне, кроме 22).
Если бы вы могли, вы могли бы просто временно отключить переключатель с помощью временного устройства (я знаю, что вы сказали о том, что это не диагностика), но если включение и выключение питания переключателя устранит проблему, это может очень сузить проблему для вы, но только если у вас есть возможность получить временное заменяющее оборудование.
В противном случае коммутатор или маршрутизатор могут перегружаться. У них последняя прошивка?
Многие коммутаторы поддерживают сеть «управления», которая может быть полностью изолирована от вашей производственной сети. Это позволяет вам войти в свои системы через некоторый внеполосный интерфейс, такой как модем, подключенный к хосту-бастиону, а затем оттуда вы можете связаться со всеми своими сетевыми устройствами через сеть управления и выполнить диагностику оттуда.
Тем не менее, этого часто не происходит, потому что это удваивает количество сетей, которые вы должны поддерживать и тестировать, но при правильном выполнении удаленное администрирование может быть почти таким же эффективным, как устранение неполадок в режиме реального времени.
Реально ли предположить, что сетевой гуру, входящий в систему удаленно, скорее всего, сможет провести детективную работу, чтобы определить источник проблемы?
Большинство из них, конечно же, должны это сделать. Немногие организации имеют такой опыт на каждом объекте, и даже посещение не позволяет легко решить проблемы, поскольку проблемы часто носят временный или непредсказуемый характер.
Например, мониторинг трафика на портах и хостах коммутатора (например, входящие / исходящие байты, количество входящих / исходящих пакетов; широковещательные и многоадресные входящие / исходящие сообщения, входящие / исходящие ошибки) может дать первый обзор нормального поведения и любых изменений в условиях сбоя. . Обычно интервалы составляют каждые 5 минут и объединяются за более длительные периоды, в идеале они отображаются на веб-страницах. Данные должны храниться как локально, так и удаленно на случай потери доступа из-за неисправности.
Предупреждения SNMP полезно собирать.
Помимо этого, сетевые трассировки, поступающие на машину, часто основанную на BSD или GNU / Linux, обычно подключенную к одному или нескольким портам диапазона на локальных коммутаторах, полезны, хотя, если не отфильтрованы узко, могут быть огромными. Могут потребоваться несколько источников (например, трафик к / от локальных серверов; к / от WAN-соединений). Полезно, если можно снимать несколько трасс одновременно.
Все это можно просматривать и интерпретировать удаленно, хотя необходимо разумное понимание исследуемой сети, а некоторые объемы данных (особенно необработанные трассировки или трассировки в течение времени в ожидании неисправности) могут быть огромными.
Оценка риска потребуется перед тем, как позволить третьей стороне получить доступ к сетям или отправить сетевые трассировки из-под контроля вашей организации. Полная сетевая трассировка позволяет восстановить любой незашифрованный контент. Даже если данные зашифрованы и трассировка исключает большую часть содержимого, полная запись томов с источниками и приемниками все еще доступна. Он также может включать в себя веб-сайты и страницы, к которым осуществляется доступ и кем, например. Шифрование дисков с трассировочной информацией, отправляемой по почте, будет минимальной защитой, и вам потребуется соответствующий уровень доверия к тому, кому они отправляются. Внешней стороне, получившей доступ, могут потребоваться пароли оборудования: убедитесь, что вы знаете, какие из них можно изменить, и уделите внимание проверке оборудования, имеющего внешний доступ. Внешний доступ в сети должен осуществляться по защищенным каналам (например, с использованием ssh), если это вообще возможно.
Настройте локальный мониторинг (возможно, SNMP коммутаторов), который должен продолжать работать, когда сеть находится в плохом состоянии. После следующей перезагрузки неисправного устройства выполните удаленный доступ и просмотрите журналы за указанное время.
Да, хороший специалист по сети в конечном итоге сумеет что-то выяснить таким образом, хотя это может быть медленнее, чем если бы он был локальным в системе.