Преминете към съдържанието
DDoS защита · Peeryx · 15 Tbps+
Всички ръководства

GRE, reverse proxy или BGP: правилният път за защита

GRE, reverse proxy и BGP решават различни части от пътя на трафика. Не са взаимозаменяеми бутони за DDoS защита. Изборът зависи от протоколи, управление на адреси, първоначален достъп и възможност за промяна на маршрута без загуба на разрешени връзки.

← Всички ръководстваCubixServ

Преди да започнете

Избройте адреси, портове и протоколи и уточнете кой управлява двата края. Потвърдете права за префикси и източници. Пазете правила, достъп и първоначални маршрути; планирайте промените с оператора и подгответе безопасно връщане.

Proxy трябва да съответства на протокола

HTTP reverse proxy обработва настроен HTTP, не автоматично UDP на всяка игра. NGINX stream може да предава TCP или UDP с подходяща конфигурация; това не е еднакво с приложна HTTP филтрация. Проверете модул, портове, timeout и публични адреси. Достъпна страница или TCP връзка не доказват игровия UDP път, файлове и целия обратен поток. Тествайте отделно всяка необходима част на услугата.

За FiveM отделни крайни точки на връзка, файлове и игра. Проверете рекламираните адреси и услуги, които остават директни. Установете дали клиентските адреси се запазват, каква информация достига до източника и кои правила за доверие отговарят на вашата версия.

GRE добавя капсулиране

GRE пренася пакети в допълнителна мрежова обвивка. GRE през IPv4 използва IP протокол 47, не TCP порт 47. Сам не осигурява шифроване или удостоверяване на другия край. Потвърдете разрешени краища, филтри и маршрути от двете страни. Произволен TCP порт не създава тунел или защита; проверете възможности на хоста и права за мрежови правила. Управлявайте тунела отделно от публичния игрови достъп.

Проверете дали оборудването и мрежите позволяват GRE. В IPv4 той използва номер на протокол IP, а не просто TCP или UDP порт за отваряне. Капсулирането добавя заглавки: адаптирайте и тествайте ефективния MTU, маршрути и обратен път. Връзка, работеща с малки пакети, все още може да се провали с по-големи пакети.

BGP обявява разрешени префикси

BGP обменя маршрутна информация, не филтрира сам всяко приложение. Изисква права върху префикси, отношения с оператор и уговорени политики. Разпределена VPS IP не дава право да обявявате целия блок или собствена BGP сесия. Уточнете отговорности и обхват на защитения транзит преди промяна. Не експериментирайте с чужди префикси и не предполагайте автономна система само от търговското име или администраторския достъп.

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

Запазете връщане и адреси на източника

Предаването включва двата пътя, състояние на връзката и адреси, видими за приложението. Асиметрия може да наруши stateful филтри. Преди ограничаване документирайте разрешени адреси, управление и здравни проверки. Широко доверие позволява заобикаляне, тесни правила блокират клиенти. Тествайте вход, отговори и дълги връзки с възможност за първоначални правила. Смяна на публичната IP сама не определя правилен обратен маршрут или всички нужни източници.

Идентифицирайте и заобикалящи пътища: стари адреси, вторични DNS, файлове, глас или административни инструменти. Преди да ограничите произход, проверете законните източници и необходимите услуги. Дистанционната защита не премахва необходимостта да се контролира пряката експозиция на дестинацията.

Проверете MTU и големи пакети

Капсулиране намалява мястото за първоначалния пакет. Малък тест може да работи при неуспешно голямо прехвърляне. Проверете MTU на пътя, фрагментация и нужни грешки за протокола. TCP MSS сам не решава всички UDP проблеми. Не копирайте стойност от чужд пример: използвайте реален маршрут, тунел и измервания, след което проверете файловете и играта. Пазете предишни стойности за сравнение и възстановяване.

Променете един по един компонент с налична конфигурация за връщане назад. Координирайте и ограничете всяко тестово натоварване. Едновременната промяна на DNS, прокси, тунел и защитна стена затруднява идентифицирането защо даден тест е неуспешен.

Тествайте по една промяна

Запазете проект и обичайни резултати преди включване. В обявена поддръжка проверете управление, HTTP, TCP, UDP и разрешени източници. Работещ ping не тества цялото приложение. Timeout не е автоматично атака. Дайте конкретен час и протокол на оператора и използвайте разрешени проверки; интензивен трафик не бива да засяга други услуги или клиенти без уговорка. Накрая проверете реални разрешени потребители след всяка важна промяна.

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

Какво да направите във вашия случай

СитуацияСледваща стъпка
Само web услугаОценете HTTP proxy, разрешени източници и приложните настройки.
UDP игра на външен сървърПотвърдете подходящо предаване или тунел, обратен път и MTU.
Разрешен мрежов префиксУговорете BGP и защитен транзит с оператора. Разпределена VPS IP не стига.

Официални източници

Източниците обясняват протоколите и настройките. Проверете документацията за използваната версия.

  1. RFC Editor / IETF/rfc/rfc2784
  2. RFC Editor / IETF/rfc/rfc4271
  3. NGINX/en/docs/stream/ngx_stream_proxy_module.html
  4. Cfx.re/docs/server-manual/proxy-setup/