За кулисами интернета: Кабели, маршрутизаторы и дата-центры
- -
- 100%
- +
Если нужно осмотреть оборудование, сначала сверяйте номер стойки, устройства и порта со схемой и заявкой.
Если маркировка не совпадает с учётной системой, остановите работу и уточните данные. Не исправляйте карту «по ходу дела».
Если требуется заменить модуль, проверьте, что он действительно относится к проблемному интерфейсу, а резервный путь работоспособен.
Если необходимо отключить питание, убедитесь, что выбранный блок не является единственным рабочим вводом.
Если после работы связь восстановилась, зафиксируйте изменения, снимите контрольные показатели и уберите временные соединения.
Для небольшого офиса этот принцип тоже применим. Домашний или офисный роутер стоит не в запертой стойке, но его легко случайно отключить, переставить или накрыть бумагами. Если от него зависят касса, видеосвязь и доступ к рабочим системам, устройство нужно разместить в проветриваемом месте, подписать кабели и не подключать к сетевому фильтру в сомнительном состоянии.
Три сцены, три разных причины
Сцена первая: семейная квартира
Вечером у семьи пропал интернет. На роутере горят индикаторы, но сайты открываются медленно. Перезагрузка не помогает.
Если задержка одинакова на всех устройствах, проверяют подключение до домашнего шлюза и линию оператора. Если один ноутбук работает нормально, а телефон нет, проблема может быть локальной: слабый беспроводной сигнал, перегрузка устройства или настройки самого телефона. Если интернет пропадает при нагреве роутера, его размещение и вентиляция становятся частью диагностики.
Успех — это не просто появление страницы, а стабильная передача в течение нескольких минут на нескольких устройствах. Пользователю не нужно разбирать оборудование: достаточно зафиксировать время сбоя, состояние индикаторов и результат проверки по кабелю и беспроводной сети.
Сцена вторая: магазин Анны
Сайт открывается, но заказ не завершается. Внутренние сотрудники видят каталог, а часть покупателей получает ошибку на этапе оплаты.
Здесь нельзя сразу обвинять сетевой узел. Нужно сравнить несколько направлений: доступность главной страницы, службы авторизации, платёжного шлюза и административной панели. Если недоступен только один внешний сервис, сеть магазина может быть исправна. Если потери наблюдаются на всех внешних соединениях, проверяют канал оператора и резерв. Если запрос доходит до сервиса, но ответ задерживается, очередь может находиться уже на стороне серверной инфраструктуры.
Успех — это восстановление полного пользовательского сценария: открыть карточку товара, положить товар в корзину, создать заказ и получить подтверждение. Работающий интерфейс администратора не доказывает, что покупательский путь исправен.
Сцена третья: узел оператора
Илья получает сигнал о потерях на нескольких направлениях. На одном маршрутизаторе интерфейсы работают, но температура верхнего модуля растёт. В журнале есть сообщение о снижении скорости вентилятора.
Он не начинает менять оптические модули. Сначала проверяет резервный маршрут и влияние переключения, затем состояние воздушного потока и вентиляторного блока. Если резерв способен принять нагрузку, часть трафика переводят по утверждённой процедуре. После этого заменяют неисправный элемент, контролируют температуру и ошибки, а затем постепенно возвращают трафик.
Критерий успеха здесь шире: абоненты не теряют связь, ошибки перестают расти, температура стабилизируется, резерв снова готов к работе, а в журнале остаётся точное описание причины и выполненных действий.
Финальный чек-лист чтения сетевого узла
Перед тем как назвать оборудование или причину сбоя, пройдите пять уровней.
Первый уровень — помещение. Есть ли доступ, питание и вентиляция? Нет ли воды, следов перегрева или посторонних работ?
Второй уровень — стойка. Верна ли её маркировка? Не перекрыты ли воздуховоды? Нет ли незакреплённых кабелей и признаков механического повреждения?
Третий уровень — соединение. Через какой кросс проходит линия? К какому порту подключён патч-корд? Совпадают ли бирки с учётной схемой?
Четвёртый уровень — устройство. Есть ли питание? Работают ли вентиляторы? Нет ли ошибок на интерфейсе? Стабильно ли устройство обрабатывает трафик?
Пятый уровень — сервис. Доходит ли запрос до нужного приложения? Возвращается ли ответ? Сохраняется ли качество при повторной проверке?
Если проблема обнаружена на одном уровне, не перескакивайте сразу на другой. Перегретый маршрутизатор нельзя диагностировать только через веб-страницу приложения, а недоступный сайт нельзя автоматически объяснить мигающим портом в ближайшей стойке.
Комната, где живёт сеть, не обязана быть огромным залом с рядами шкафов. Это может быть закрытый узел в здании оператора, телекоммуникационный шкаф в бизнес-центре или изолированная зона дата-центра. Размер меняется, но логика остаётся прежней: физическая линия приходит на панель, активное оборудование принимает решение о передаче, питание и охлаждение поддерживают работу, мониторинг фиксирует отклонения, а режим доступа снижает риск случайного вмешательства.
Когда Анна снова проверила сайт, заказ прошёл с первого раза. Илья не сказал, что «починил сервер». Он показал ей схему: проблема возникла в сетевом узле, где перегретый модуль начал терять пакеты, а резервный маршрут временно принял нагрузку. Сервер приложения продолжал работать, но дорога к нему стала ненадёжной.
Теперь у нас есть физическая карта сети: стойки, панели, активные устройства, питание, воздух и люди, которым разрешено к ним прикасаться. Следующий вопрос возникает сам собой: как оборудование понимает, куда направлять запрос, если человеку достаточно ввести понятное имя сайта или сервиса? Для ответа придётся перейти от комнаты и кабелей к адресам, именам и настоящему пункту назначения.
5. Адрес, имя и настоящий пункт назначения
После разговора о сетевых узлах легко представить интернет как систему дорог и перекрёстков: устройство отправляет пакет, маршрутизаторы выбирают направление, сервер отвечает. Но ещё до первого маршрутизатора происходит операция, от которой зависит весь дальнейший путь: человеку нужно назвать место словами, а сети — получить числовой адрес. Здесь и возникает путаница между именем сайта, адресом компьютера, дверью конкретного сервиса и маршрутом к нему.
Один и тот же сайт может отвечать с разных адресов, один адрес — обслуживать десятки имён, а знакомое доменное имя иногда вести совсем не к тому серверу, который представляет пользователь. Чтобы увидеть разницу, разберём обычный рабочий день Анны, владелицы небольшого интернет-магазина в Екатеринбурге, и проследим, как её запрос проходит через DNS, кэш, публичные и внутренние адреса, порты и меняющуюся инфраструктуру.
Ошибка в названии
В девять утра Анна открыла ноутбук и увидела сообщение от менеджера:
«Сайт не работает. Покупатели нажимают “Оплатить”, а страница зависает».
Анна проверила соединение: новости открывались, поиск работал, видеосвязь с поставщиком подключалась. Тогда она позвонила Илье, сетевому инженеру регионального оператора.
«У нас интернет есть, но магазин недоступен», — сказала она.
«Какой адрес вы открываете?»
Анна продиктовала доменное имя магазина.
Илья попросил открыть командную строку и выполнить проверку DNS. Ответ показал, что доменное имя связано с двумя IP-адресами, причём один из них не отвечал на соединение через защищённый веб-порт.
«Значит, сайт переехал?» — спросила Анна.
«Не обязательно. Имя, IP-адрес и конкретный сервис — три разные вещи. А путь до IP-адреса — ещё одна сущность».
Для пользователя это звучало избыточно. Он вводит адрес сайта, нажимает кнопку и ждёт страницу. В обыденной речи всё это называется адресом. В сетевой системе «адрес сайта» распадается на несколько уровней.
Доменное имя — удобное для человека обозначение, например shop.example.ru. В этой книге мы будем использовать вымышленное имя магазина, чтобы не привязывать объяснение к реальному ресурсу.
IP-адрес — числовой сетевой адрес узла или точки обслуживания. В IPv4 он выглядит как четыре числа, разделённые точками, например 203.0.113.25. В IPv6 запись длиннее и состоит из групп шестнадцатеричных символов. IP-адрес сообщает сети, куда направлять пакет, но сам по себе не объясняет, какой именно сервис должен принять соединение.
Порт — числовая точка входа в конкретный сетевой сервис на узле. Один IP-адрес может принимать веб-запросы на одном порту, почту — на другом, служебные подключения — на третьем. Порт не является отдельным компьютером и не заменяет IP-адрес: он уточняет, какому процессу или службе предназначено соединение.
Маршрут — последовательность сетей и маршрутизаторов, через которую пакеты добираются от источника к IP-адресу назначения. Один и тот же адрес может быть достижим по разным маршрутам, а сам маршрут способен измениться из-за аварии, перегрузки или смены сетевой политики.
Получается следующая последовательность. Доменное имя указывает, какой сервис пользователь хочет найти. DNS помогает получить связанный с именем IP-адрес. Порт указывает, в какую сетевую службу на этом адресе нужно обратиться. Маршрутизация доставляет пакеты к выбранному IP-адресу.
Если на любом этапе возникает ошибка, фраза «интернет не работает» скрывает слишком много разных причин.
Зачем сети имена
Компьютерам несложно работать с числами. Человеку трудно помнить, что один сервис сегодня доступен по адресу 203.0.113.25, а другой — по 198.51.100.14. Ещё сложнее удерживать в памяти десятки адресов банковских сервисов, магазинов, рабочих систем и государственных порталов.
Доменное имя решает проблему запоминания и позволяет отделить название сервиса от его текущего размещения. Магазин может сменить дата-центр, провайдера, схему балансировки или набор серверов, а имя останется прежним. Пользователь продолжит открывать тот же адрес, хотя за ним изменятся числовые параметры.
Это похоже на вывеску магазина и его фактическое помещение. Вывеска должна быть узнаваемой, а помещение можно сменить. Но у аналогии есть пределы: доменное имя не «прикреплено» к одному месту навсегда. Оно хранится в распределённой системе записей, которые можно обновлять.
Анна раньше считала, что доменное имя и есть адрес сервера.
«Если имя осталось прежним, почему покупатели попадают на разные машины?» — спросила она.
Марина, руководитель инфраструктуры сервиса в российском дата-центре, объяснила это на схеме:
«Имя может возвращать несколько IP-адресов. Один адрес может вести на группу серверов. Группа — распределять запросы по стойкам и площадкам. А часть сервисов вообще не видна из интернета: веб-сервер обращается к внутреннему серверу приложений по внутреннему адресу».
Для Анны это стало первым неприятным открытием. Снаружи сайт выглядел единым объектом. Внутри он состоял из нескольких слоёв: публичной точки входа для посетителей, балансировщика, который распределял соединения, серверов приложений с логикой магазина, базы данных с товарами и заказами, а также внутренних сервисов оплаты, уведомлений и учёта остатков.
Покупатель видит доменное имя и страницу товара. Инфраструктура видит цепочку адресов, портов, правил доступа и маршрутов между компонентами.
Как имя превращается в адрес
DNS, служба доменных имён, работает как распределённый справочник. Его задача — отвечать на вопросы вроде: «Какие IP-адреса связаны с этим доменным именем?» Но DNS не является единым центральным компьютером, в котором хранится полная таблица интернета.
Когда пользователь вводит имя сайта, устройство обычно обращается к настроенному DNS-резолверу. Резолвер — сервер, который получает ответ для клиента и при необходимости запрашивает его у других DNS-серверов. Это может быть резолвер оператора связи, корпоративной сети, домашнего маршрутизатора или публичного сервиса.
Если в кэше резолвера нет свежего ответа, он проходит цепочку поиска. Сначала выясняется, какие серверы отвечают за доменную зону верхнего уровня. Затем находится сервер, авторитетный для конкретной зоны, то есть имеющий право сообщать актуальные записи. В результате резолвер получает сведения о том, какие адреса следует вернуть устройству.
Для пользователя весь процесс занимает доли секунды, но технически в нём участвуют несколько ролей: доменное имя, которое вводит человек; DNS-резолвер, принимающий запрос от устройства; авторитетный DNS-сервер, хранящий записи доменной зоны; кэш, где временно сохраняются ранее полученные ответы; и клиентское приложение, использующее найденный IP-адрес для соединения.
DNS может возвращать не только IPv4- и IPv6-адреса. В системе доменных имён хранятся разные типы записей: одни связывают имя с адресом, другие указывают, какие серверы отвечают за домен, третьи помогают направлять почту. Для обычного открытия сайта важнее всего записи, позволяющие получить IP-адрес.
Здесь скрыта первая распространённая иллюзия: DNS не проверяет, работает ли сайт как приложение. Он отвечает на вопрос о соответствии имени и адреса. Если сервер выключен, порт закрыт, сертификат настроен неправильно или приложение не подключается к базе данных, DNS может продолжать отвечать совершенно корректно.
Иными словами, успешное разрешение имени ещё не означает, что сайт откроется.
Кэш, который помогает и мешает
Анна изменила настройки магазина по рекомендации Марины: убрала неисправный IP-адрес и оставила рабочий. Через пять минут она проверила сайт — у неё всё заработало. Но менеджер из соседнего офиса по-прежнему видел ошибку.
«Я открываю то же самое имя. Почему у нас разные результаты?» — спросил он.
Причиной оказался кэш DNS.
DNS-ответ обычно сопровождается временем жизни, или TTL. Это срок, в течение которого резолвер имеет право использовать сохранённый ответ, не обращаясь заново к авторитетному серверу. Кэш сокращает задержку, уменьшает число повторных запросов и снижает нагрузку на инфраструктуру DNS. Но после изменения записи разные пользователи некоторое время могут получать разные ответы.
Представим, что магазин сменил IP-адрес в 10:00, а старый ответ имел TTL 3600 секунд. Резолвер, получивший старую запись в 9:45, может использовать её до 10:45. Другой резолвер, запросивший имя уже после изменения, сразу вернёт новый адрес. Поэтому обновление DNS не распространяется мгновенно по всем устройствам мира: старые ответы постепенно вытесняются по мере окончания срока кэширования.
В быту это выглядит так:
«У меня сайт уже открылся».
«А у меня нет».
«Значит, у тебя сломался компьютер».
Не обязательно. Устройства могут обращаться к разным резолверам, а те — хранить разные версии ответа. Дополнительный кэш бывает в домашнем маршрутизаторе, операционной системе, браузере или корпоративной сети.
Однако кэш объясняет не каждую проблему. Если сайт не открывается только через одного оператора связи, нужно проверять не только DNS, но и маршрутизацию, доступность портов и состояние самой инфраструктуры. Если имя разрешается в адрес, но соединение не устанавливается, причина может находиться уже после DNS.
Практический алгоритм в такой ситуации выглядит следующим образом.
Сначала проверьте, разрешается ли доменное имя в IP-адрес. Если ответа нет, ищите проблему в DNS, настройках домена или доступности резолвера.
Затем сравните полученные адреса из разных сетей — например, из домашнего подключения и мобильной сети. Если ответы различаются, вероятны кэширование, разные настройки DNS или политика распределения трафика.
После этого проверьте соединение именно с нужным портом. Ответ DNS не доказывает, что сервис принимает подключения.
Затем выясните, устанавливается ли сетевой маршрут к адресу. Если маршрут обрывается в сети оператора или магистральном узле, смена DNS не устранит неисправность.
Наконец, проверьте приложение: сервер мог принять соединение, но вернуть ошибку из-за проблем с базой данных, авторизацией, перегрузкой или настройками.
Этот порядок важен. Он не позволяет лечить проблему «заменой DNS», когда на самом деле повреждён кабель, перегружен маршрутизатор или остановлен сервер приложений.
Публичный адрес не означает «весь компьютер в интернете»
После устранения первой ошибки Марина показала Анне схему внутренней сети магазина. На внешней стороне находились два публичных IP-адреса. За ними размещались десятки машин с адресами вида 10.20.5.14, 10.20.5.15 и 10.20.6.21.
«Почему эти адреса нельзя открыть из интернета?» — удивилась Анна.
Внутренние адреса предназначены для локальных или частных сетей. Они не должны напрямую маршрутизироваться в глобальном интернете. В IPv4 к таким диапазонам относятся, в частности, адреса, начинающиеся с 10, а также определённые диапазоны 172.16–172.31 и 192.168. Домашний роутер часто получает от оператора один внешний адрес, а устройства внутри квартиры используют адреса вроде 192.168.1.10 и 192.168.1.11.
Чтобы несколько внутренних устройств могли пользоваться одним публичным IPv4-адресом, применяется трансляция сетевых адресов, чаще известная как NAT. Роутер изменяет параметры соединения и ведёт таблицу соответствий: какое внутреннее устройство открыло соединение, с какого временного порта и куда направился запрос. Ответные пакеты по этой таблице возвращаются нужному устройству.
Отсюда следует важное различие между исходящим и входящим соединением. Ноутбук из домашней сети обычно может сам открыть страницу в интернете. Это не означает, что любой внешний компьютер способен самовольно открыть соединение к ноутбуку через тот же роутер. Входящие подключения блокируются или требуют специального правила переадресации порта.
В инфраструктуре магазина публичный адрес принадлежал не отдельному серверу каталога, а внешнему балансировщику. Он принимал посетителей, проверял доступность внутренних компонентов и передавал запрос дальше. Снаружи был виден один адрес, а внутри за ним скрывалась целая система.
Так обеспечиваются и защита, и масштабирование. Не каждый сервер нужно выставлять в интернет. База данных может иметь только внутренний адрес и принимать подключения исключительно от сервера приложений. Служба хранения заказов может быть доступна лишь по внутреннему маршруту. Даже если кто-то узнает внутренний IP-адрес, это ещё не даст ему доступа без подходящего маршрута, открытого порта и разрешающих правил.
Но и здесь нельзя делать слишком сильный вывод: «внутренний адрес автоматически безопасен». Если злоумышленник уже находится внутри корпоративной сети или получил доступ к одному из серверов, внутренние адреса становятся частью поверхности атаки. Безопасность определяется не самим диапазоном адреса, а правилами доступа, сегментацией, обновлениями, журналированием и контролем учётных записей.
Порт — дверь, но не замок
К обеду сайт Анны уже открывался, но часть клиентов по-прежнему сообщала: «Страница есть, а оплата не проходит».
Марина проверила внешний веб-сервис. Соединение с защищённым веб-портом устанавливалось, каталог отвечал, корзина сохраняла товары. Затем приложение пыталось передать данные во внутренний сервис оплаты через другой порт, а тот оказался закрыт на межсетевом экране.
«Но мы же открыли сайт», — сказала Анна.
«Открыли только одну дверь. За ней есть другие помещения».
Порт можно представить как номер входа в конкретную службу. На одном IP-адресе могут одновременно работать веб-сервер, система удалённого администрирования, служба мониторинга и другие процессы. Для защищённого веб-доступа обычно используется порт 443, для незашифрованного — 80. Службы DNS часто используют 53-й порт, хотя конкретная реализация может применять разные транспортные протоколы и дополнительные механизмы.
Номер порта сам по себе не гарантирует, что там действительно работает ожидаемая служба. Администратор может запустить веб-приложение на нестандартном порту. Процесс может занимать порт, но отвечать ошибками. Порт может быть открыт на межсетевом экране, но приложение за ним остановлено. И наоборот: приложение может работать, но внешний доступ к порту будет запрещён.
Поэтому утверждение «сервер доступен» требует уточнения. Возможны разные состояния: IP-адрес не разрешается из имени; IP-адрес разрешается, но маршрут до него нарушен; маршрут есть, но порт закрыт; порт открыт, но служба не отвечает; служба отвечает, но приложение возвращает ошибку; приложение работает, но конкретная операция ломается на внутреннем сервисе.
При диагностике нельзя смешивать эти уровни. Проверка пинга, если она разрешена, показывает лишь возможность обмена определёнными пакетами. Она не доказывает, что веб-сайт доступен. Успешный ответ DNS не доказывает, что порт открыт. Открытый порт не доказывает, что заказ можно оформить.
Илья сформулировал это для Анны в одной фразе:
«Нужно спрашивать не “есть ли интернет”, а “на каком уровне обрывается цепочка от имени до операции”».
Что было бы, если бы адрес сменился
Через месяц Марина решила перенести часть инфраструктуры магазина на другую площадку в российском дата-центре. Причина была практической: новые серверы находились ближе к части клиентов, а резервная площадка позволяла пережить отказ основного узла. Доменное имя менять не стали.
Сначала подготовили новые серверы и проверили их внутренние связи. Затем настроили балансировщик, открыли нужные порты, установили сертификаты, проверили авторизацию и тестовые заказы. Только после этого изменили DNS-записи.
Для клиентов переход выглядел не как мгновенное перемещение, а как период смешанных результатов. Одни резолверы уже возвращали новые IP-адреса, другие ещё некоторое время использовали старые. Поэтому старую площадку нельзя было выключать сразу. Она должна была принимать запросы до завершения периода кэширования, а иногда и дольше — с учётом ошибок, некорректно настроенных резолверов и локальных кэшей.
Первое ответвление: если новый адрес настроен неправильно
Допустим, DNS обновили, но на новом IP-адресе не установили сертификат для доменного имени. Часть клиентов увидит предупреждение о небезопасном соединении или ошибку проверки. Пользователь скажет: «После смены адреса сайт сломался». На самом деле имя разрешается, маршрут работает, порт отвечает, но новый сервер не умеет корректно подтвердить свою принадлежность домену.
Другой вариант: на новом адресе запущено приложение, но оно не знает, какой сайт нужно показать. Один IP-адрес может обслуживать несколько доменных имён, и сервер выбирает нужную конфигурацию по имени, переданному в запросе. Если эта настройка потеряна, посетитель получит не тот сайт, пустой ответ или ошибку.
Третий вариант: публичный адрес доступен, но внутренний сервер приложений остался на старой площадке, а между площадками нет нужного маршрута. Внешняя страница может открываться, а оформление заказа — зависать. Здесь DNS снова ни при чём: он выполнил свою задачу, указав новый адрес.
Второе ответвление: если один адрес заменить двумя
Анна спросила, почему нельзя просто указать один IP-адрес и забыть о сложностях. Марина ответила, что один адрес создаёт единственную точку отказа. Поэтому доменное имя может возвращать несколько адресов — например, для двух площадок или нескольких балансировщиков.
Когда пользователь получает список адресов, его устройство или клиентское приложение выбирает один из них по своим правилам. Иногда DNS-система распределяет ответы между адресами, иногда применяются специализированные механизмы балансировки. Это не означает, что каждый пакет разговора прыгает между адресами. Обычно конкретное соединение устанавливается с одним выбранным адресом, а следующий пользователь может попасть на другой.
Если один из адресов неисправен, результат зависит от того, как настроены проверки доступности и переключение. Простое наличие двух IP-адресов не создаёт автоматической отказоустойчивости. Если DNS продолжает возвращать неработающий адрес, часть пользователей будет получать ошибки. Если резервный сервер не синхронизирован с базой данных, сайт может открываться, но показывать устаревшие остатки товара или не принимать заказ.
Третье ответвление: если адрес поменялся, а маршрут остался прежним
Даже после обновления DNS пакеты могут идти через те же сети, что и раньше. Доменное имя указывает на новый IP-адрес, но этот адрес объявляется в интернете через определённые сети. Оператор пользователя должен узнать, куда направлять трафик к новому диапазону. Если объявления маршрутов настроены неудачно, путь может стать длиннее, появиться перегруженный участок или возникнуть недоступность из конкретного региона.