Содержание статьи
Когда в офисе пропал интернет, идите снизу вверх: питание, кабель, порт, индикаторы, потом адресация, шлюз, служба имён и канал провайдера. Такой порядок закрывает большинство офисных аварий за четверть часа. Честная рамка: часть сбоев вы не почините вовсе, потому что они лежат за стеной здания.
Дальше в статье собран рабочий порядок действий:
- какие инструменты и доступы держать наготове до аварии;
- последовательность проверок от розетки до канала провайдера;
- какие параметры смотреть в настройках и что в них должно быть;
- ошибки, которые растягивают простой на часы, и границы самой диагностики.
С чего начать, если интернет пропал во всём офисе?
Кратко по делу: первым делом очертите границы аварии, и только потом трогайте оборудование. Спросите двух коллег в разных концах офиса, проверьте проводного клиента и беспроводного, откройте любой сайт с телефона по мобильной сети. Запишите время, когда связь пропала. Эти четыре факта сужают поиск с десятка гипотез до одной или двух.
Масштаб решает всё. Если связи нет у одного человека, оборудование офиса почти наверняка живо, и разбираться нужно с его машиной. Если легли все проводные клиенты, а беспроводные работают, вы уже знаете этаж проблемы: коммутатор или сегмент кабельной системы.
Отдельно проверьте, отвалился ли только выход наружу. Внутренние ресурсы часто продолжают отвечать: файловый сервер открывается, печать идёт, корпоративный портал грузится. Пользователи этого не замечают и приносят вам жалобу «ничего не работает», хотя лежит один участок. Полезно заранее понимать, как устроена работа серверов и что происходит с запросом внутри сети, иначе такие жалобы приходится расшифровывать наугад.
Время начала сбоя записывайте всегда. Провайдер спросит его первым вопросом, и «где-то после обеда» его не устроит. Заодно посмотрите, не совпало ли падение с плановой работой: обновлением прошивки, переездом стойки, грозой, отключением питания на этаже. Совпадение по времени экономит вам полчаса гипотез.
Ещё один быстрый признак: индикаторы. Погасший порт на коммутаторе, оранжевый вместо зелёного, мигающая аварийная лампа на маршрутизаторе. Такое видно за двадцать секунд и сразу отправляет вас в нужную сторону. Тема сетевых отказов вообще шире офиса, и общий разбор того, почему ломается интернет и какими способами это чинится, помогает не изобретать каждый раз новую логику.
Что нужно держать под рукой?
Кратко по делу: набор диагноста собирается заранее, в спокойный день. Минимум: ноутбук с портом Ethernet, заведомо рабочий кабель, телефон с мобильным интернетом, актуальные пароли от сетевого оборудования, схема сети и номер договора с провайдером. Если хотя бы один пункт приходится искать по ящикам, простой удлиняется на десятки минут.
Список ниже проверен практикой: он закрывает почти любую офисную аварию без поездки в магазин.
| Что держать наготове | Зачем нужно | Что проверить заранее |
|---|---|---|
| Ноутбук с портом Ethernet | Подключиться прямо в коммутатор или в порт провайдера, минуя офисную сеть | Порт живой, драйвер сетевой карты на месте |
| Запасной кабель Ethernet | Исключить обрыв и плохой обжим за одну минуту | Кабель заведомо рабочий и лежит отдельно от хлама |
| Смартфон с мобильным интернетом | Понять, лежит внешний ресурс или только ваш канал | Трафик есть, раздача включается |
| Пароли от маршрутизатора и коммутаторов | Зайти в панель управления без поиска стикеров под столом | Пароли актуальны и хранятся в менеджере паролей |
| Схема сети и список адресов | Знать, где шлюз, где служба имён, какие подсети живут в офисе | Схема обновлена после последнего переезда и замены железа |
| Договор и телефон провайдера | Открыть заявку с номером договора и точным временем сбоя | Номер под рукой, порядок эскалации известен |
| Резервный канал | Поднять работу офиса, пока основной канал лежит | Переключение проверялось реальным тестом хотя бы раз в квартал |
Пароли заслуживают отдельной строчки. Учётные записи на сетевом железе живут годами и переживают нескольких администраторов, поэтому порядок отзыва доступов после ухода сотрудника стоит навести до того, как вам понадобится срочный вход в маршрутизатор.
Как найти причину за пятнадцать минут?
Кратко по делу: двигайтесь по уровням снизу вверх и меняйте по одному параметру за раз. Физика, питание, адресация, шлюз, служба имён, внешний канал. На каждом шаге фиксируйте результат письменно. Такой обход даёт понятный ответ даже тогда, когда починить сбой своими силами невозможно: вы точно знаете, чей это участок.
- Зафиксируйте масштаб и время. Сколько машин затронуто, какие сегменты, когда началось. Одна строчка в блокноте.
- Проверьте питание. Маршрутизатор, коммутатор, оптический терминал, источник бесперебойного питания. Севшая батарея источника роняет стойку тихо и без предупреждения.
- Проверьте физику. Переткните кабель в другой порт, замените патч кабель на заведомо рабочий, посмотрите на индикаторы линка. Сломанная защёлка на разъёме встречается чаще, чем отказ железа.
- Перезагрузите оборудование по одному устройству. Сначала оконечное, потом маршрутизатор, с паузой в минуту. Массовая перезагрузка всего сразу лишает вас информации о том, что именно помогло.
- Посмотрите адресацию на клиенте. В Windows это
ipconfig /all, в Linuxip a. Адрес вида 169.254.x.x означает, что раздача адресов не отвечает, и проблема где угодно, но не в интернете. - Пингуйте по слоям. Сначала шлюз, потом публичный адрес вида 1.1.1.1, потом любое доменное имя. Шлюз молчит, значит дело в локальной сети. Адрес отвечает, а имя нет, значит легла служба имён.
- Постройте трассировку.
tracertилиtracerouteдо внешнего узла показывает, на каком переходе маршрут обрывается. Обрыв на первом переходе указывает внутрь офиса, на третьем и дальше в сторону провайдера. - Звоните провайдеру с фактами. Время начала, номер договора, результаты пингов и трассировки, состояние индикаторов на терминале. Такой звонок обрабатывают быстрее общего «у нас ничего не работает».
Записывайте каждый шаг. Через сорок минут поиска память сама подкидывает ложные воспоминания о том, что вы уже перезагрузили коммутатор, хотя перезагружали точку доступа. Журнал действий спасает и от повторов, и от разговора с руководителем после аварии. Постепенно эти записи превращаются в собственную базу типовых поломок, а рутинные проверки из неё выносятся в автоматизацию ежедневных задач администратора.
Какие параметры проверять в настройках сети?
Кратко по делу: смотрите адрес и маску, шлюз по умолчанию, адреса службы имён, срок аренды у раздачи адресов, принадлежность порта к нужному сегменту и время на самом устройстве. Начинайте с проблемной машины и двигайтесь к коммутатору. Большинство «внезапных» офисных аварий рождается там же, где вчера правили настройку своими руками.
Начните с адреса и маски. Две машины с одинаковым адресом устраивают весёлую картину: связь то есть, то нет, причём у обеих сразу. Операционная система обычно пишет об этом в журнал, и полминуты чтения журнала экономят час догадок.
Шлюз по умолчанию проверяйте на самом клиенте, глазами. Он мог уехать после смены маршрутизатора, после ручной правки настроек на конкретной машине, после подключения туннеля VPN, который перехватил весь трафик на себя. Туннели вообще часто виноваты в «интернете, который есть, но сайты не открываются».
Служба имён ломается тише всего. Адреса пингуются, сайты не грузятся, почтовый клиент ругается на сервер. Пропишите проверку явно: запросите любое известное имя у своего сервера имён и у публичного. Разный ответ сразу показывает виновника.
Отдельная категория параметров живёт на коммутаторе: принадлежность порта к сегменту, режим работы порта, ограничение скорости, списки доступа. После перестановки рабочих мест порт нередко остаётся в старом сегменте, и человек садится в сеть, из которой наружу выхода просто нет. Такие вещи входят в базовый набор навыков, который сегодня ожидают от системного администратора.
Время на устройстве проверяйте последним, но обязательно. Сбитые часы ломают проверку сертификатов, авторизацию по домену и туннели. Симптом выглядит пугающе, лечится одной строчкой.
Какие ошибки затягивают поиск причины?
Кратко по делу: чаще всего время съедают три привычки. Перезагрузка всего оборудования разом, одновременное изменение нескольких параметров и вера пользователю на слово без собственной проверки. Каждая из них уничтожает связь между действием и результатом, после чего диагностика превращается в перебор наугад и растягивается с пятнадцати минут на половину рабочего дня.
Массовая перезагрузка выглядит эффектно и почти всегда вредит. Сеть поднимается, все радуются, причина остаётся неизвестной, авария повторяется через неделю в то же время. Перезагружайте по одному устройству и записывайте, после какого связь вернулась.
Вторая ошибка: правка нескольких настроек за один заход. Поменяли адрес службы имён, заодно пересадили порт в другой сегмент, попутно обновили прошивку. Заработало. Что именно помогло, теперь уже не выяснить, и откатывать нечего.
Третья: доверие к описанию пользователя. «Я ничего не трогал» означает лишь то, что человек не считает свои действия изменениями. Отключённый кабель под столом, включённая раздача с телефона, установленный вчера защитный клиент с собственным туннелем. Проверяйте сами, спокойно и без обвинений.
Дальше по списку идут вещи помельче, но они тоже стоят времени:
- звонок провайдеру до собственной проверки, когда авария на самом деле в офисе;
- правка конфигурации без сохранённой резервной копии;
- игнорирование журналов на маршрутизаторе, где сбой уже описан словами;
- диагностика одним браузером у одного пользователя вместо проверки на второй машине;
- отсутствие мониторинга, когда об аварии вам сообщает бухгалтерия.
Мониторинг стоит поднять до того, как случится первая громкая авария. Простая проверка доступности шлюза и внешнего узла раз в минуту даёт вам фору в десятки минут. Навык этот приходит с практикой, и в программах обучения на системного администратора сетевой диагностике отводят заметную часть времени.
Чего ждать от диагностики не стоит
Кратко по делу: алгоритм находит причину, но чинит далеко не каждую. Обрыв магистрали, авария на узле провайдера, деградация канала, проблемы у самого внешнего ресурса лежат вне вашей зоны. В этих случаях результат диагностики другой: точный адрес проблемы, аргументы для заявки и понимание, сколько офис проживёт на резервном канале.
Провайдер не всегда признаёт аварию сразу. Поддержка первой линии работает по своему списку вопросов и часто отвечает «у нас всё в порядке», пока заявок мало. Собранные вами факты, особенно трассировка с обрывом на их узле, переводят разговор на другой уровень и ускоряют эскалацию.
Резервный канал сам собой тоже не включится. Если переключение никогда не проверялось, в момент аварии выясняется, что маршрут прописан неверно, а лимит трафика закончился в прошлом месяце. Проверяйте переключение планово, в спокойное время.
И последнее ожидание, которое не сбывается: удалённый доступ во время сетевой аварии. Когда канал офиса лежит, зайти снаружи вы не сможете, и до стойки придётся дойти ногами. Это ограничение стоит держать в голове всем, кто рассматривает удалённый формат работы системным администратором: часть задач всё равно требует присутствия.
Вопросы читателей
Что делать, если интернет пропал только у одного сотрудника?
Проверьте кабель и порт, затем адресацию на его машине. Адрес вида 169.254.x.x говорит о молчащей раздаче адресов, отсутствие шлюза о ручных правках. Дальше смотрите защитное программное обеспечение и туннели: они перехватывают трафик и создают ровно такую картину.
Почему перезагрузка маршрутизатора помогает так часто?
Она сбрасывает переполненные таблицы соединений, зависшие процессы и просроченные аренды адресов. Помогает симптоматически: если перезагрузка требуется каждую неделю, устройство работает на пределе по памяти или нагрузке, и лечится это заменой либо разгрузкой, а не расписанием перезагрузок.
Как понять, что проблема на стороне провайдера?
Соберите три факта: шлюз пингуется, внешний публичный адрес нет, трассировка обрывается за пределами вашего оборудования. Добавьте проверку с ноутбука, подключённого напрямую в порт провайдера. Если картина повторяется без вашей сети в цепочке, вопрос закрыт.
Нужно ли менять оборудование, если сбои повторяются каждую неделю?
Сначала соберите статистику: время, длительность, что помогало. Повторяющийся отказ в одно и то же время суток указывает на нагрузку или чужое расписание, и железо тут ни при чём. Замена оправдана, когда устройство греется, теряет порты или не тянет текущий объём трафика.
Источники
- Справочник сетевых команд Windows Server, Microsoft Learn: learn.microsoft.com
- Страницы руководства Linux по утилитам ping, traceroute и ip: man7.org
- RFC 2131, Dynamic Host Configuration Protocol: datatracker.ietf.org
- RFC 1918, Address Allocation for Private Internets: datatracker.ietf.org