В сетевой DDoS-защите нужно сначала выбрать режим маршрутизации, затем способ доставки трафика и только после этого читать обещания скорости и цены. Этот разбор фиксирует один публично описанный вариант Servicepipe: On-Demand, собственная AS, постоянный IP-транзит и доставка по GRE. По результату получится рабочий лист предварительной готовности; клиентский стенд, реальный договор и эффективность не проверялись.
Один вариант сетевой услуги
| Поле | Выбранный предмет |
|---|---|
| Продукт | Servicepipe Network DDoS Protection, L3–L4 |
| Схема | On-Demand: входящий трафик постоянно проходит через инфраструктуру поставщика |
| Доставка | GRE-туннель к сети клиента с собственной AS и IPv4-префиксами |
| Цена | Общий опубликованный минимум от 50 000 ₽ в месяц без НДС; индивидуальная цена варианта не установлена |
| Регион и договор | Для конкретного заказчика не установлены; поле с московским адресом в анкете не считается подтверждением региона |
| Дата среза | 24 октября 2026 года; без подключения услуги и испытаний |
| Вне предмета | Cloud Signaling, L2, арендуемые адреса, Web DDoS, WAF, AntiBot и локальные аппаратные решения |
Автор — Избаенков Артем Игоревич, эксперт по информационной безопасности и директор продукта Solar Space в ГК «Солар». До 14.06.2022 работал генеральным директором ООО «Сервиспайп». Эти связи следует учитывать при чтении. Разбор основан на открытых первоисточниках; внутренние материалы и сведения работодателей в качестве доказательств не используются. «Атлас защиты» не является отдельной независимой лабораторией или сертификацией.
Маршрут через поставщика и включение очистки
Сначала нужно согласовать смысл названия режима. В текущей сетевой документации Servicepipe On-Demand означает, что трафик постоянно идёт через инфраструктуру поставщика. При обычной нагрузке он доставляется в сеть клиента, а при аномалии дополнительно проходит через систему фильтрации. По завершении аномалии очистка прекращается. Постоянство маршрута и постоянство фильтрации описывают разные условия.
В схеме выбранного обзора входящий трафик проходит через Servicepipe и по GRE приходит на внешнюю конечную точку клиента. GRE добавляет служебный заголовок; клиентское оборудование снимает его и передаёт исходные пакеты дальше. В публичной документации отдельно описан Cloud Signaling: там локальный анализатор подаёт BGP-сигнал и атакуемые префиксы временно анонсируются через поставщика. Эта схема в паспорт выбранного On-Demand не включена.
Фразы о доставке «напрямую» на страницах профиля и принципа работы следует читать вместе со схемой интеграции: для выбранного On-Demand обход системы фильтрации сохраняет постоянный транзит через поставщика. Из этих страниц нельзя вывести, что в обычном режиме сеть клиента полностью обходит инфраструктуру Servicepipe.
Что подтверждает анкета GRE со своей AS
Публичный опросный лист называется «GRE-туннель, своя AS» и относит услугу к фильтрации L3–L4. В нём отдельно предусмотрены AS201706 поставщика, AS клиента, необязательный AS-SET, анонсируемые клиентом префиксы и запрашиваемая полоса. Документация подключения указывает минимальный защищаемый префикс /24 для собственной AS. Этот минимум установлен источником о подключении, а не расчётной единицей биллинга.
Для туннеля нужен публично доступный /32, находящийся вне защищаемого диапазона. В анкете уточняется, что его не выделяет Servicepipe. Такой адрес нужно рассматривать как отдельную зависимость доставки: наличие защищаемого префикса само по себе не обеспечивает доступность конечной точки GRE.
Форма предлагает варианты получаемой клиентом таблицы маршрутизации, поле резервирования на двух пограничных маршрутизаторах и дополнительной BGP-сессии, а также запрос полосы с возможностью commit + burst. Отметка default в пустом шаблоне не доказывает, что резервирование уже организовано или входит в любой договор. Варианты таблицы маршрутизации не определяют автоматически исходящий путь конкретной сети.
Это незаполненный шаблон. Вписанные в него образцы имени и московского адреса не являются данными заказчика, фактической точкой предоставления услуги или подтверждением региона обработки. Полоса, BGP-политика и резерв должны быть определены в согласованной конфигурации.
Какие вопросы остаются у канала GRE
Для GRE документация называет передачу поверх публичного интернета и технический ориентир до 10 Гбит/с. Это не подтверждённая договорная полоса конкретного заказчика. Анкета отдельно спрашивает требуемую пропускную способность; клиентские pps, burst, условия перегрузки и резервирования в прочитанных источниках не установлены.
Поставщик рекомендует L2-канал для постоянной работы: выделенное соединение не зависит от маршрутов публичного интернета. GRE в документации предложен для аварийного подключения, пока физический стык не организован, либо как резерв; отдельно отмечены возможные задержки, потери и флапы сессий. Поэтому рассмотренный здесь GRE-вариант нужно выбирать с учётом этой оговорки.
MTU, симметрия и ответный маршрут выбранной реальной сети также не установлены. Перед выбором нужно согласовать размеры полезных пакетов, обработку фрагментации и путь ответов. Это особенно существенно, поскольку стандартный защитный профиль содержит ограничения фрагментов и ряда протоколов. Число MTU для всех клиентов из этих документов не выводится.
На странице интеграции аварийное подключение GRE описано как работа поставщика до 30 минут после получения нужных данных. Там же оговорены дополнительные согласования и внешние подрядчики. Это заявление об условиях части работ, а не измеренное время подключения, готовности вашей сети или восстановления приложения.
Порог обнаружения и правило фильтрации
Объект мониторинга задаёт адреса, векторы и пороги для анализа нагрузки. Защитный профиль содержит упорядоченные правила обработки пакетов. В документации они создаются и сопровождаются инженерами Servicepipe. Составление профиля на основании опросника и наличие статистики не подтверждают, что нужное клиенту исключение уже действует.
Документация отдельно описывает согласование штатных пиков и корректировку настроек, если полезный трафик деградирует или атака проходит. Поэтому перечень прикладных сервисов, нестандартных протоколов и ожидаемых изменений нагрузки нужен до начала эксплуатации. Заявление поставщика об отсутствии блокировки легитимных пользователей не является измеренным результатом этого разбора.
Наличие Cloud Firewall на продуктовой странице не устанавливает его включение в выбранный договор. Аналогично упоминание blackhole в профиле не подтверждает клиентское управление RTBH или FlowSpec. Возможности соседних продуктов и локальных компонентов сюда не переносятся.
Три составляющих счёта и два разных представления трафика
Опубликованный минимум Network DDoS Protection — от 50 000 ₽ в месяц без НДС, с индивидуальным расчётом. Это начальная цена семейства услуги; из неё нельзя получить стоимость выбранной полосы, транспорта, срока и условий GRE-подключения.
Сетевая документация описывает три расчётных параметра: легитимный трафик, защищаемые адреса в эквивалентах /24 и количество защитных профилей. Для трафика используются минутные средние значения в бит/с: из выборки месяца исключаются верхние 5%, затем берётся максимальное оставшееся значение. Это показатель скорости потока, а не число скачанных байтов и не полоса атаки.
Часовой график в биллинге показывает максимумы внутри каждого часа и не является подробной минутной расчётной выборкой. Для проверки счёта важно знать, какие исходные данные доступны. Адресная расчётная /24 и минимум BGP-префикса — разные условия, хотя в выбранном варианте документация подключения также указывает /24.
Профили, существовавшие хотя бы часть месяца, учитываются в описанном расчёте. Удаление добавленного профиля внутри месяца само по себе не исключает его из тарификации. Индивидуальные ставки, полный счёт с налогами, превышения и срок договора в этом обзоре не установлены.
Четырнадцать общих критериев
«Документировано» означает, что указанное условие найдено в открытом источнике применительно к выбранной схеме. «Заявлено» сохраняет атрибуцию поставщику. «Нет данных» обозначает границу проверки и не доказывает отсутствие функции. Наблюдений клиентского кабинета и измерений эффективности в обзоре нет.
| Критерий | Результат среза | Что определить перед выбором |
|---|---|---|
| C01. Задача и границы продукта | Документировано: Network DDoS Protection, облачный IP-транзит и шаблон L3–L4. Функции WAF, AntiBot и соседних продуктов не включены. | Какие сетевые сервисы и адреса требуется сохранить доступными? |
| C02. Способ развёртывания и подключения | Постоянный входящий транзит через Servicepipe; GRE доставляет трафик в сеть клиента. Own AS, префиксы и BGP-сессия описаны. | Кто отвечает за BGP, GRE endpoint и проверку обоих состояний маршрута? |
| C03. Активы, протоколы и технические лимиты | Для своей AS указан минимум /24; GRE endpoint — внешний /32 вне защищаемого диапазона. IPv6, MTU и клиентский pps не установлены. | Какие протоколы, IPv6 и размеры пакетов обязательны для вашей сети? |
| C04. Внедрение, миграция и откат | Известны исходные данные и роли при подключении. Процедура приёмки и согласованный откат конкретного клиента не установлены. | Какие проверки и возврат маршрутов будут записаны до начала работ? |
| C05. Политики и управляемость | Правила профиля формируют и изменяют инженеры Servicepipe; действия пропустить/сбросить/аутентифицировать описаны. Самообслуживание и Cloud Firewall в выбранном договоре не подтверждены. | Как согласовать исключения и кто вправе менять правила? |
| C06. Полезный трафик и пользовательский опыт | Стандартные правила ограничивают ряд пакетов и протоколов. Требуется учесть полезные пики и нестандартный трафик; ложные ограничения не измерялись. | Как заметить деградацию полезного сервиса и передать её на разбор? |
| C07. Журналы, метрики и объяснимость | Описаны объекты мониторинга, метки профиля и расчёт 95-го процентиля. Часовой график не является минутной расчётной выборкой; общий экспорт и хранение логов неизвестны. | Каких данных хватит для инцидента и проверки счёта? |
| C08. Надёжность и зависимости | GRE зависит от публичного интернет-пути. Анкета содержит выбор резервирования на двух пограничных маршрутизаторах; фактическая схема и отказы не проверялись. | Какой отказ закрывает резерв и кто отвечает за доступность endpoint? |
| C09. SLA, поддержка и эскалация | Заявлены SLA 99,99% и реакция SOC 10 минут. Применимый договор, формула, исключения, компенсации и время устранения не установлены. | Какие обязательства и порядок эскалации войдут в договор? |
| C10. Регионы, данные и доступность услуги | Регион обработки, журналов и условия услуги для конкретного заказчика не установлены. Московский адрес в пустой анкете является шаблонным полем. | Где пройдёт трафик и будут храниться данные по вашему договору? |
| C11. Интеграции и автоматизация | Для выбранного варианта описана BGP-сессия. Cloud Signaling — отдельная схема; API, SIEM, IaC и RBAC выбранного договора не установлены. | Какая автоматизация действительно нужна и каким условием она подтверждена? |
| C12. Цена и совокупная стоимость | От 50 000 ₽/месяц без НДС; расчёт учитывает легитимный трафик, /24-эквиваленты и профили. Цена полосы, burst, транспорта, срок и полный счёт неизвестны. | Как выглядит полный расчёт при вашем трафике и наборе адресов? |
| C13. Команда и эксплуатационная нагрузка | Заказчик предоставляет сетевые данные и согласует подключение; поставщик создаёт мониторинг и профили. Трудозатраты сторон не измерялись. | Кто сопровождает BGP/GRE, полезные пики, инциденты и счёт? |
| C14. Переносимость и выход | Возврат маршрутов, срок прекращения договора, экспорт и удаление данных в прочитанных условиях не определены. | Как сохранить адреса, доступность и данные при отключении услуги? |
Семь специальных вопросов сетевой DDoS-защиты
| Вопрос сетевой когорты | Результат среза | Практическая проверка |
|---|---|---|
| N01. Маршрутизация и возврат трафика | Документированы BGP/собственная AS, минимум /24 и доставка GRE на отдельный /32. Обратный маршрут, MTU и симметрия для реальной сети не установлены. | Запишите входящий, ответный и аварийный пути отдельно. |
| N02. Режим включения очистки | On-Demand у Servicepipe сохраняет постоянный транзит через поставщика; по аномалии включается очистка. Cloud Signaling меняет внешний маршрут временно и здесь не выбран. | Согласуйте, что именно постоянно: маршрут или фильтрация. |
| N03. Профиль защищаемых протоколов | Форма указывает L3–L4. Профиль содержит ограничения фрагментов и протоколов; поддержка нужного клиентского потока не следует из общего названия продукта. | Сопоставьте полезные протоколы с применимыми правилами профиля. |
| N04. Доставка очищенного трафика | Документация указывает GRE до 10 Гбит/с; в форме запрашивается полоса, возможен commit+burst. Договорные clean-pipe, pps, burst и ответственность за underlay не установлены. | Разделите технический предел GRE, заказанную полосу и гарантированную доставку. |
| N05. Совместимость с сетью заказчика | Своя AS/адреса, BGP и минимум /24 подтверждены. Форма перечисляет AS-SET и резервирование; IPv6, мультихоминг и принятая конфигурация неизвестны. | Уточните адресную пригодность и фактическое резервирование. |
| N06. Управление инцидентом | Объект задаёт пороги, профиль — правила; изменения выполняют инженеры. Клиентское управление FlowSpec/RTBH, сроки снятия ограничений и доставка событий не установлены. | Кто фиксирует проблему полезного трафика и подтверждает восстановление? |
| N07. Ёмкость с правильным знаменателем | Продуктовая страница приводит исторические показатели атак. Они не доказывают клиентский clean-pipe, результат этого обзора или преимущество по ёмкости. | У каждого числа подпишите объект, единицы, период и статус доказательства. |
Где заканчивается документальное подтверждение
Продуктовая страница заявляет SLA 99,99% и десятиминутную реакцию SOC. Договорная формула доступности, исключения, компенсации и обязательство устранения проблемы в этом срезе не установлены. Реакция, переключение маршрута, фильтрация и восстановление полезного действия требуют отдельных критериев.
Не установлены фактические страны обработки клиентского трафика и хранения журналов, сроки общего хранения и экспорта данных, а также условия завершения конкретного договора. Адрес поставщика или заполнителя в анкете не заменяет подтверждение этих параметров.
Исторические показатели атак на странице продукта являются заявлениями Servicepipe. Они не используются как оценка ёмкости клиентского канала, доказательство отсутствия ложных блокировок или результат испытаний в «Атласе защиты». Сопоставимость с другим поставщиком требует отдельной проверки сценария, режима, региона и технических условий; общий победитель по таким числам не определяется.
Рабочий лист предварительной готовности
Практический результат обзора — перечень условий, с которым сетевой владелец может решить, подходит ли ему этот вариант для дальнейшей проработки. Заполнять его следует по данным своей сети и применимым условиям; пустая публичная анкета не является принятой конфигурацией.
| Что зафиксировать | Критерий готовности для дальнейшего выбора |
|---|---|
| Адреса и AS | Есть собственная AS и применимые префиксы; минимум /24 подтверждён для этого варианта. |
| Конечная точка GRE | Отдельный публичный /32 вне защищаемых адресов; известны владелец, доступность и резерв underlay. |
| Маршруты | Раздельно описаны входящий и ответный пути, обычный режим, очистка и согласованный возврат. |
| Полоса и пакеты | Раздельно указаны договорные бит/с, pps, burst, MTU и полезные протоколы. |
| Резервирование | Выбран фактический вариант пограничных маршрутизаторов и BGP-сессий; поле default не считается проверкой. |
| Полезная нагрузка | Известны штатные пики, нестандартные сервисы, канал разбора ложного ограничения и критерий восстановления. |
| Данные и договор | Определены обработка/журналы, SLA/эскалация, счёт, срок, экспорт и выход. |
| Выбор транспорта | Осознанно выбран GRE с учётом рекомендации поставщика использовать L2 для постоянной работы; назначение GRE и требования к underlay зафиксированы. |
Документированные предварительные условия позволяют рассматривать вариант On-Demand/GRE/собственная AS. Если отдельного адреса туннеля, нужной адресной пригодности или владельца маршрутизации нет, предварительный выбор ещё не завершён. Это вывод о готовности конкретной сети к рассмотренной схеме, а не оценка качества поставщика. Разбор не подтверждает фактическое подключение и не заменяет авторизацию приложения или другие необходимые уровни защиты.
Первоисточники
- Защита сети: схемы интеграции и доставка очищенного трафика
Два режима маршрутизации, требования к собственной AS и описание доставки через GRE и L2.
Проверено .
- Опросный лист GRE-туннель, своя AS
Поля сетевого подключения: внешний адрес туннеля, AS, защищаемые префиксы, таблица маршрутизации, резервирование и запрашиваемая полоса.
Проверено .
- Защита сети: принцип работы
Разделение анализа и фильтрации, порог аномалии и завершение очистки.
Проверено .
- Защита сети: объект мониторинга
Адреса, векторы, пороги и согласование полезных пиков нагрузки.
Проверено .
- Защита сети: защитный профиль
Порядок правил, обработка протоколов и изменение профиля через инженеров поставщика.
Проверено .
- Тарификация защиты сети
Минутные средние для 95-го процентиля, расчётные /24, профили и отдельный часовой график.
Проверено .
- Информация о стоимости: Network DDoS Protection
Опубликованный нижний порог месячной стоимости и условия индивидуального расчёта без НДС.
Проверено .
- Network DDoS Protection
Границы L3–L4, описание AS201706/BGP Anycast и отдельно атрибутированные заявления о поддержке и SLA.
Проверено .
