Сеть на вырост: Как проектировать надежную и масштабируемую IT-инфраструктуру

4. Политики и транспорт. Пакет проходит через межсетевой экран, который проверяет, разрешено ли этому источнику соединяться с сервером на TCP-порт 443. В отличие от простого маршрутизатора, экран может отслеживать состояние соединения и учитывать правила доступа. Затем устанавливается TCP-соединение: ноутбук и сервер обмениваются служебными пакетами, прежде чем передавать данные приложения. Если политика запрещает TCP 443, браузер не дойдёт до проверки сертификата.

5. TLS и приложение. После установления TCP браузер и сервер начинают TLS-обмен: согласуют параметры шифрования, проверяют сертификат и только затем могут защищённо передавать HTTP-запрос. У Марины TCP работает, сервер отвечает, но браузер отклоняет сертификат из-за неверного времени. Значит, наблюдаемая ошибка возникла выше, чем физическая передача и IP-маршрут. После восстановления доступа к серверу времени и синхронизации часов тот же запрос проходит проверку и портал открывается.

Типовая цепочка выглядит так:

```text

Ноутбук

│ Wi-Fi: радиоканал, кадры 802.11

▼ Точка доступа │ VLAN 118: Ethernet или туннель к контроллеру ▼ Коммутатор доступа ▼ Шлюз VLAN / L3-коммутатор │ IP-маршрутизация ▼ Межсетевой экран │ проверка политик, при необходимости NAT ▼ Маршрутизатор / магистральная сеть ▼ Серверная сеть ▼ Сервер портала: TCP 443 → TLS → HTTPS-приложение

Это пример, а не универсальный шаблон: в другой сети шлюз и экран могут быть совмещены, между кампусом и сервером может находиться WAN, а точка доступа может передавать трафик через контроллер. Архитектура должна описывать реальные границы и переходы, а не идеализированную картинку.

Инкапсуляция: почему у каждого уровня свои улики

Когда браузер отправляет данные, каждый уровень добавляет к ним информацию, необходимую следующему участнику пути. HTTP-данные помещаются в TLS, TLS — в TCP-сегмент, тот — в IP-пакет, а IP-пакет — в кадр для конкретного канального участка. Это называется инкапсуляцией.

Упрощённо один фрагмент обмена выглядит так:

```text

Кадр Wi-Fi/Ethernet

└── IP-пакет: ноутбук → сервер

└── TCP-сегмент: временный порт → 443

└── TLS-данные

└── HTTP-запрос

Название единицы данных меняется вместе с уровнем: кадр на канальном, пакет на сетевом, сегмент TCP или датаграмма UDP на транспортном. Это не просто терминологическая аккуратность. Она помогает понять, где искать сбой. Коммутатор доступа обычно принимает решения по канальным адресам; маршрутизатор — по IP и таблице маршрутов; межсетевой экран может учитывать адреса, порты и состояние соединения; приложение — содержание запроса.

Заголовки также показывают, почему одного «адреса устройства» недостаточно. MAC-адрес нужен для доставки в пределах локального канального участка. IP-адрес помогает доставлять пакеты между подсетями. Порт указывает на конкретный сетевой процесс на конечном узле. Имя DNS удобно человеку и приложению, но само по себе не пересылает пакеты. При диагностике полезно спрашивать не «какой адрес у сервера?», а «какой тип адреса, на каком участке и для какой задачи?».

Физическая инфраструктура — не декорация

Логическая схема может выглядеть безупречно и всё равно опираться на плохое соединение. В проводной сети медные кабели, патч-панели, розетки, порты и трансиверы должны соответствовать скорости и типу линии. Оптика соединяет устройства световым сигналом; тип волокна и оптических модулей должен быть совместим. PoE позволяет питать точки доступа и телефоны через Ethernet, но при проектировании нужно учитывать бюджет питания коммутатора.

Индикатор порта показывает, что устройства установили связь, а не то, что линия безошибочна. Счётчики CRC-ошибок, отбрасываний и повторных передач могут указать на повреждённый кабель, неудачную оптику или перегруженный интерфейс. В Wi-Fi проверяют не только уровень сигнала, но и отношение сигнал/шум, загрузку канала, потери и повторы. Полезно записывать, где находится физический порт, куда ведёт кабель, к какой VLAN он относится и кто отвечает за этот участок.

Физический уровень задаёт ограничения для всех верхних. Например, максимальный размер IP-пакета на пути ограничен MTU участков. Если отправитель считает, что может передать крупные пакеты, а где-то по пути они не проходят и обнаружение Path MTU работает некорректно, некоторые приложения могут «зависать» странным образом: короткие обмены идут, а передача больших объёмов — нет. Значит, осмысленная диагностика связывает оптику и кабель с IP и приложением, а не считает их разными мирами.

Кто за что отвечает

Послойная модель полезна и организационно. Команда Wi-Fi отвечает за радиопокрытие, точки доступа и их контроллеры; команда кампусной сети — за коммутаторы, VLAN и шлюзы; команда безопасности — за правила межсетевого экрана; команда платформы — за DNS, DHCP и синхронизацию времени; команда приложения — за службу и её конечную точку. В небольшой организации эти роли могут принадлежать одним людям, но границы систем всё равно существуют.

Для каждой границы стоит документировать контракт: какой интерфейс соединён с каким устройством, какая VLAN и подсеть используются, кто является шлюзом, какие протоколы и порты разрешены, где находится сервис и кто его сопровождает. Это особенно важно при изменениях. Запись «точка доступа подключена к порту 17» мало помогает, если неизвестно, куда ведёт порт, как настроен trunk и какая VLAN выдаётся клиентам.

Наконец, исправный путь в одну сторону ещё не гарантирует исправный обмен. Ответ сервера должен вернуться к клиенту; обратный маршрут и политики могут отличаться. Проверка только исходящего направления не обнаружит асимметричную маршрутизацию или правило, блокирующее ответы.

Упражнение: нарисуйте путь конкретного пакета

Выберите приложение, которым пользуетесь на работе. Не рисуйте «сеть офиса целиком»: проследите один конкретный запрос — например, открытие внутренней страницы.

1. Запишите имя приложения и IP-адрес, который возвращает DNS. Уточните, откуда устройство получает DNS-сервер.

2. Зафиксируйте адрес клиента, маску, шлюз и VLAN. Если данных нет — найдите их командами ipconfig /all в Windows или ip address и ip route в Linux.

3. Нарисуйте физический путь: устройство → точка доступа или розетка → коммутатор → шлюз → межсетевой экран → серверная сеть → сервер.

4. На каждом переходе подпишите, что передаётся: радиокадр или Ethernet, локальный MAC-адрес назначения, IP-источник и IP-назначение, транспорт и порт.

5. Отдельно отметьте DNS, DHCP и синхронизацию времени. Они могут быть необходимы для работы приложения, но не обязаны находиться в пути каждого его пакета.

6. Для каждого участка задайте проверяемый вопрос: есть ли линк и нет ли ошибок? Правильно ли выдан адрес? Разрешается ли имя? Достижим ли шлюз? Установилось ли TCP-соединение? Проходит ли TLS-проверка? Получило ли приложение ответ?

Сверять нужно не только схему, но и наблюдения: состояние интерфейсов, таблицы MAC-адресов и маршрутов, журналы межсетевого экрана, DNS-ответы и ошибки приложения. Цель не в том, чтобы выполнить все возможные команды. Цель — найти границу, за которой успешная передача сменяется неуспешной.

Сеть перестаёт быть магией, когда у каждого симптома появляется место в цепочке. Wi-Fi — не то же самое, что IP-доступность. IP-доступность — не то же самое, что открытый TCP-порт. Открытый порт — не гарантия успешного TLS, а успешный TLS — ещё не подтверждение, что приложение обработало запрос. Слои не заменяют архитектуру, но дают ей общий язык: из набора коробок и кабелей сеть превращается в систему с понятными интерфейсами, зависимостями и точками проверки.

Топологии и архитектурные модели: кампус, филиалы, дата-центр и распределённая сеть

В понедельник в девять утра головной офис компании «Северный контур» не мог открыть CRM. Сама CRM работала — в облаке, быстро и без ошибок. Не работала дорога к ней: запросы из филиалов шли сначала в головной офис, затем в корпоративный дата-центр, проходили через общий шлюз и только после этого выходили в интернет. Один путь, много поворотов и слишком много машин на одной развязке.

Когда-то такая схема была разумной. У компании было три офиса, собственный сервер и одна главная площадка. Теперь — головной офис, дата-центр, двадцать восемь филиалов, облачная CRM и план открыть ещё десять точек за год. Сеть выросла не просто в размере: у неё изменился характер движения. И проблема оказалась не в том, что «не хватает скорости», а в том, что прежняя форма сети больше не соответствовала жизни компании.

На архитектурной сессии директор по инфраструктуре развернул карту площадок и спросил: «Какую топологию нам выбрать?» Инженер ответил вопросом: «Для какого трафика, какого масштаба и какого отказа?» Это был более полезный вопрос. Топология — не модный рисунок из презентации и не обещание, что «всё будет резервировано». Это устройство дорог, по которым данные попадут к своим целям, и правила, по которым сеть переживёт поломку одной из этих дорог.

Сначала понять, кто куда едет

На карте «Северного контура» было три основных типа трафика.

•Пользователи в филиалах обращались к облачной CRM и видеосервису.

•Торговые приложения филиалов связывались с системами в дата-центре.

•Сотрудники головного офиса обменивались данными с внутренними сервисами и друг с другом.

Это не три одинаковых потока. Облаку важен быстрый и надёжный выход в интернет. Торговому приложению — предсказуемый доступ к дата-центру. Видеозвонку — стабильная задержка и отсутствие потерь, а не просто высокая пропускная способность на бумаге. Если отправлять весь трафик по одной и той же дороге только потому, что она уже проложена, сеть будет устроена удобно для схемы, но не обязательно для бизнеса.

Полезно различать физическую и логическую топологии. Физическая показывает, где проходят кабели и линии связи, к каким коммутаторам подключены устройства и какие площадки соединены напрямую. Логическая — какие сети видят друг друга, где проходят маршруты, какие туннели связывают площадки и через какие политики проходит трафик.

Эти карты могут не совпадать. Физически филиалы могут подключаться к двум региональным узлам, а логически — к десяткам других площадок через защищённую оверлейную сеть. И наоборот: несколько отдельных физических линий могут предоставлять один логический путь. Такое расхождение полезно, но его нельзя считать волшебством: логический резерв не поможет, если оба «разных» маршрута идут по одному кабельному каналу или зависят от одного оператора.

Поэтому хорошая архитектура начинается с нескольких простых вопросов:

1. Какие приложения и площадки должны взаимодействовать?

2. Какой путь для каждого взаимодействия приемлем по задержке и пропускной способности?

3. Что должно продолжать работать при отказе устройства, линии, площадки или оператора?

4. Сколько сложных связей команда сможет надёжно настроить, проверить и поддерживать?

Ответы постепенно проявляют подходящую форму сети.

Кампус: порядок вместо бесконечных перемычек

Головной офис «Северного контура» занимал два здания. В каждом были этажные коммутаторы доступа: к ним подключались компьютеры, телефоны, точки Wi-Fi и принтеры. Эти коммутаторы сходились к уровню распределения, где объединялись сети этажей, применялись политики и маршрутизировался трафик. Выше находилось ядро — быстрый транзит к дата-центру, интернету и другим частям кампуса.

Так устроена иерархическая модель: доступ — распределение — ядро. Её сила не в том, что три уровня обязательны, а в разделении ролей. Доступ подключает пользователей и устройства; распределение объединяет локальные сегменты и задаёт правила; ядро быстро переносит трафик между крупными блоками.

Для большой площадки такая структура похожа на городской транспорт: местные улицы не должны по отдельности вести к каждому зданию города, а магистрали не должны разбираться с каждым дворовым выездом. Разделение упрощает диагностику и позволяет добавлять новые корпуса, не переплетая соединения между всеми коммутаторами.

Но иерархия не означает, что нужно строить три этажа ради красоты. Небольшому офису или компактному кампусу может хватить модели collapsed core, где функции распределения и ядра объединены. Это дешевле и проще в управлении. Цена — меньший запас для роста и более крупная область воздействия при отказе центрального оборудования. Пара резервных устройств не снимает это ограничение автоматически: надо ещё продумать питание, соединения, маршрутизацию и переключение.

Для «Северного контура» выбрали кампусную иерархию с парой узлов распределения, независимыми линиями от крупных блоков и чёткими границами маршрутизации. Там, где отказ одного этажного коммутатора допустим до приезда техника, сделали менее дорогой резерв. Там, где отключение корпуса останавливало важную операцию, предусмотрели более независимые пути и оборудование.

Именно так следует относиться к резервированию: не как к флажку «есть/нет», а как к ответу на вопрос, какие последствия отказа организация согласна принять. Две линии в одном кабельном лотке дают резерв от поломки порта, но не обязательно от строительных работ. Два коммутатора в одной стойке могут пережить отказ устройства, но не потерю питания в серверной.

Филиалы: лучи, кольца и управляемые обходы

С филиалами картина другая. В небольшой точке обычно не нужен сложный кампус: несколько пользовательских устройств, кассовое или производственное оборудование, беспроводная сеть и канал к центральным сервисам. Классическая модель — hub-and-spoke, или «звезда»: филиалы подключаются к одному или нескольким центральным узлам.

У такой схемы есть достоинства. Её легко объяснить, контролировать и защищать: политика доступа задаётся в центральных точках, а число связей не превращается в клубок. Она хорошо работает, если приложения действительно размещены в центре и филиалам не нужно интенсивно общаться друг с другом.

Слабое место очевидно: центральный узел становится важным перекрёстком. Если через него идёт и доступ к дата-центру, и интернет-трафик филиалов, и связь между площадками, его отказ или перегрузка затрагивает всех. Даже без отказа такой маршрут может быть неразумным: филиал в Казани отправляет запрос в облачный сервис через центральный офис в Москве и получает ответ по длинной дороге.

Первый шаг к устойчивости — два центральных узла с независимыми подключениями. Но «независимость» надо проверять, а не рисовать: разные ли у каналов операторы, трассы и точки входа? Работают ли оба узла при потере одного? Не зависит ли переключение от единственного устройства или специалиста, который помнит пароль?

Следующий вариант — частичная mesh-связность: напрямую соединяются только те площадки, которым это действительно нужно. Например, два региональных центра получают пути друг к другу, а малые филиалы подключаются к ближайшему узлу. Такая модель уменьшает число обходных маршрутов и может снизить задержку для выбранных потоков, не превращая каждую площадку в отдельный проект.

Полная mesh-связность соединяет каждую площадку с каждой. Для небольшого числа критичных узлов это может быть оправдано. Но количество возможных пар быстро растёт: при \(n\) площадках их \(n(n-1)/2\). Для тридцати филиалов это уже 435 пар. На практике не каждую из них обязательно строить отдельной линией, однако логические связи, маршруты, политики и сценарии проверки всё равно требуют внимания. Полная mesh — не «резерв на всякий случай», а выбранная цена за прямые пути и дополнительные возможности обхода.

Программно-определяемая WAN, или SD-WAN, может упростить управление такими связями: централизованно задавать политики, выбирать канал по условиям и создавать защищённые туннели поверх разных транспортов. Но SD-WAN — не топология сама по себе. Это способ управлять связностью. Он не создаст второй физический путь, если у филиала есть только один канал, и не избавит от необходимости разбираться, куда в итоге пойдёт трафик.

Для «Северного контура» малые филиалы подключили к двум региональным узлам, а критичные площадки получили дополнительные прямые или резервные связи. Для облачной CRM предусмотрели локальный выход в интернет там, где это разрешали требования безопасности. Так запрос перестал делать крюк через штаб-квартиру. Трафик к внутренним системам по-прежнему шёл по контролируемому пути в дата-центр.

Это разделение особенно важно при выборе локального выхода в интернет. Он уменьшает задержку и нагрузку на центральные каналы, но переносит на филиал часть требований к защите, фильтрации, мониторингу и резервированию. Экономия на маршруте не должна обернуться десятью разными и непроверенными правилами безопасности.

Дата-центр: когда большинство разговоров происходит внутри

В кампусе много трафика направлено к общим сервисам. В современном дата-центре серверы и приложения часто активно обмениваются данными между собой: фронтенд обращается к базе, микросервис — к очереди, система аналитики — к хранилищу. Это называют восточно-западным трафиком. Он делает архитектуру, рассчитанную только на «серверы в центре и пользователей по краям», недостаточной.

Для таких задач подходит модель leaf-spine. Каждый коммутатор leaf подключён ко всем коммутаторам spine, а серверы и другие конечные устройства подключаются к leaf. Путь между двумя leaf проходит через spine. Это даёт предсказуемую структуру и позволяет распределять потоки по нескольким путям с помощью равностоимостной маршрутизации — ECMP.

Модель удобна, когда много систем обменивается трафиком внутри дата-центра и нужно расширять сеть добавлением узлов соответствующего уровня. Но leaf-spine не означает автоматически «без блокировок» или «неограниченную скорость». Всё зависит от числа и пропускной способности соединений, возможностей оборудования и профиля нагрузки. Отношение суммарной пропускной способности серверных портов к пропускной способности восходящих соединений называют коэффициентом переподписки. Если нагрузка одновременно пойдёт по всем потокам, узкие восходящие каналы могут стать бутылочным горлышком.

Эта модель также требует дисциплины в маршрутизации, адресации и эксплуатации. Больше путей дают больше возможностей распределять трафик, но неверная настройка может ухудшить предсказуемость или затруднить поиск неисправности. Если в небольшом дата-центре почти весь трафик идёт от серверов к внешним пользователям, сложность leaf-spine может быть избыточна. Архитектуру выбирают под обмен данными, а не под привлекательность схемы.

Дальность — тоже элемент топологии

Карта площадок — это не только точки, но и расстояния между ними. По оптоволокну свет распространяется примерно со скоростью 200 тысяч километров в секунду. Это значит, что только физическое прохождение 1000 километров добавляет около 5 миллисекунд в одну сторону. Реальный маршрут может быть длиннее прямого, а оборудование и обработка пакетов добавляют свою задержку.

Пять миллисекунд не всегда заметны пользователю. Но к ним добавляются путь обратно, серверная обработка, перегруженные каналы и дополнительные сетевые переходы. Для веб-страницы такая сумма может стать ощутимой; для синхронной транзакции или интерактивного приложения — критичной. Поэтому близость на карте важна, но важнее фактический маршрут и требования приложения.

В облачной архитектуре это приводит к нескольким практическим решениям: выходить к облаку из ближайшего региона, использовать частное подключение там, где оправданы его стоимость и профиль трафика, или оставить резервный защищённый путь через интернет. Нет смысла покупать выделенный канал для редких некритичных обращений, если обычный защищённый доступ удовлетворяет требованиям. И нет смысла экономить на пути для транзакции, от которой зависит ежедневная работа филиала.

Архитектурная сессия: сравнить не моды, а последствия

На встрече инженеры нанесли на карту четыре модели. В таблице они оценивали не «хорошо» или «плохо», а примерную цену, устойчивость, задержку и сложность эксплуатации. Оценки относятся к типичным сценариям: конкретный проект может изменить их в любую сторону.

Модель

Цена

Устойчивость

Задержка

Сложность эксплуатации

Иерархический кампус

Средняя; растёт с резервированием

Хорошая при независимых путях и продуманной архитектуре

Предсказуемая внутри площадки

Средняя; роли уровней облегчают поиск проблем

Филиалы «звездой» к одному узлу

Низкая или средняя

Центральная точка — общий риск

Может быть высокой для удалённых сервисов

Низкая; просто контролировать, но легко перегрузить центр

Два региональных узла и выборочная mesh-связь

Средняя или высокая

Хорошая при независимых каналах и корректном переключении

Ниже для выбранных прямых путей

Средняя или высокая; растёт число сценариев

Полная mesh между площадками

Высокая

Много возможных путей, но результат зависит от общей инфраструктуры

Потенциально низкая между узлами

Высокая; много связей и политик

Leaf-spine в дата-центре

Средняя или высокая

Хорошая при нескольких независимых путях

Предсказуемая между стойками

Средняя или высокая; нужна дисциплина маршрутизации и измерений

Таблица помогла не найти единственного победителя, а увидеть, где именно компании нужна каждая модель. Кампусу — иерархия. Небольшим филиалам — управляемая связь с региональными узлами. Критичным площадкам — выборочные прямые маршруты. Дата-центру — leaf-spine там, где интенсивность внутреннего обмена оправдывает эту архитектуру. Облаку — близкий и контролируемый выход, не зависящий от единственной центральной дороги.

В результате схема выглядела примерно так:

```text

┌──────────── Облачные сервисы

│ ↑

Интернет / частный канал

│ ┌────────────────┴────────────────┐ │ │ Региональный узел A ─── Резерв ─── Региональный узел B ↑ ↑ ↑ ↑ │ └── прямая связь критичных площадок ─┘ Филиалы малого размера Критичные филиалы │ └──── локальный защищённый выход к разрешённым сервисам

Головной кампус

доступ → распределение → ядро

│ Дата-центр leaf ↔ spine │ внутренние приложения

Это не готовый чертёж для копирования. На нём не показаны все маршруты, зоны безопасности, резервные каналы и ограничения конкретных сервисов. Его польза в другом: видно, кто к кому подключается, где сосредоточены зависимости и какие потоки обходят центральную площадку.

Как выбрать модель для своей сети

Попробуйте провести собственную короткую архитектурную сессию.

1. Нарисуйте площадки и расстояния. Отметьте число филиалов, дата-центр, регионы облачных сервисов и каналы связи. Не ограничивайтесь логическими соединениями: запишите операторов, физические трассы и точки входа, если эти данные доступны.

2. Добавьте поверх карты потоки приложений. Для каждого важного приложения укажите источник, цель, направление трафика и допустимую задержку. Разделите потоки между площадками и внутри дата-центра.

3. Опишите отказ, а не только резерв. Что произойдёт при потере линии, центрального узла, электропитания или всего региона? Какую работу нужно сохранить немедленно, а какую можно восстановить позже?

4. Сравните цену владения. Учитывайте не только каналы и оборудование, но и мониторинг, тестирование переключения, сопровождение политик, обучение сотрудников и время диагностики.

5. Проверьте, что резерв действительно независим. Два маршрута, проходящие через одну шахту, одного оператора или одну точку питания, могут оказаться одним маршрутом под разными именами.