Преминете към съдържанието
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 път, файлове и целия обратен поток. Тествайте отделно всяка необходима част на услугата.

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

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

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

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

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

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

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

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

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

Запазете проект и обичайни резултати преди включване. В обявена поддръжка проверете управление, 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/