Към съдържанието
PEERYXNETWORK
Обсъдете тази архитектура

Изисквания за внедряване

DDoS защита за хостинг и сървърни доставчици

Атаката срещу един клиент не бива да се превръща в необяснимо прекъсване на цял шкаф или клъстер. Определете споделените ресурси, политиката за всеки клиент и точката, в която защитеният трафик влиза в платформата.

Коридор между сървърни шкафове в център за данни.
Илюстративна снимка · Brett Sayles / Pexels

Започнете от хостинг границите, невидими за клиентите

Общ тесен участък зад изолирани виртуални машини
Изолацията на VM не отделя капацитета на външната връзка, NIC опашките или хипервайзора. Хостът може да изчерпи обработката на пакети при скромен трафик в битове. Разделяйте наблюденията на физически интерфейс, хост и виртуална машина.
Различни натоварвания в една мрежа
VPN, поща, игрови сървър и сайт имат различен легитимен трафик. Общо правило може да замени претоварването с погрешни блокирания. Определете засегнатия префикс или услуга и кой одобрява промените.
Отговорности по веригата на препродажба
Хостингът, крайният клиент и външният доставчик могат да отговарят за различни части от адресиране, маршрутизация и реакция. Уточнете кой проверява обявяванията, докладва погрешно блокиране и съобщава възстановяването.

Изберете кой управлява филтриращия слой

Защитена мрежова услуга може да се достави на входа на хостинг мрежата. Оператори с подходящ хардуер могат да оценят Defense Fabric за локално филтриране. Лицензът, транспортът и услугата към клиента остават отделни отговорности.

  1. Защитете общия вход

    Определете префикси или публични крайни точки, доставена пропускателна способност и обхват на външната защита.

  2. Прилагайте локална политика с ясен отговорник

    При нужда от локално филтриране проверете сървърите, разположението на портовете, разпределението на трафика и правилата.

  3. Проверете работата от гледна точка на клиента

    Тествайте реални връзки за поддържаните натоварвания и запазете възможност за връщане към предишната политика.

Примерна последователност. Офертата и приемателният протокол определят предоставената услуга.

Въпроси, които променят проекта

Искате управлявана доставка или контрол над собствени филтриращи сървъри?
Сравнете оперативния обхват, не само цените на лиценз и транзит. Локалното филтриране изисква съвместим хардуер, поддръжка, наблюдение и договорена реакция.
Кой трафик може да преминава през няколко филтриращи възела?
Определете входни и обратни пътища, отговорност за състоянието и поведение при превключване. Повече възли или интерфейси не осигуряват сами по себе си използваем капацитет при загуба на възел.
Как ще различавате клиентите при експлоатация?
Поддържайте актуално съответствие между разрешени префикси или крайни точки, отговорник и политика. Използвайте го при инциденти; споделен адрес или широко правило не идентифицира непременно един клиент.

Тествайте представителна комбинация от хоствани услуги

  • Записвайте успешни връзки за реално продаваните услуги, включително със споделени адреси на източника.
  • Наблюдавайте опашки, загуби, броячи на правила и успешни приложения за един и същ интервал.
  • Изпробвайте договореното връщане на политика и резервния път, после потвърдете услугата за незасегнатите клиенти.

Въпроси за това внедряване

Лицензът Defense Fabric включва ли защитен транзит и сървъри?

Не. Съвместимият хардуер, хостингът и транспортът се бюджетират отделно. Допълнителната мрежова услуга на Peeryx е самостоятелен компонент.

Един игрови профил покрива ли всички хоствани приложения?

Не. Използвайте документираните функции за реалния протокол и тествайте легитимния трафик. FiveM и Minecraft Java изискват собствена проверка за съвместимост.