Как настроить обратный прокси

Настройка обратного прокси Nginx

Обратный прокси-сервер — это служба, которая принимает запрос клиента, отправляет запрос одному или нескольким прокси-серверам, получает ответ и доставляет ответ сервера клиенту.

Благодаря своей производительности и масштабируемости NGINX часто используется в качестве обратного прокси-сервера для HTTP-серверов и серверов, отличных от HTTP. Типичная конфигурация обратного прокси-сервера — поставить Nginx перед приложениями Node.js , Python или Java .

Использование Nginx в качестве обратного прокси дает вам несколько дополнительных преимуществ:

• Балансировка нагрузки — Nginx может выполнять балансировку нагрузки для распределения запросов клиентов по прокси-серверам, что повышает производительность, масштабируемость и надежность.
• Кеширование. Используя Nginx в качестве обратного прокси-сервера, вы можете кэшировать предварительно обработанные версии страниц, чтобы ускорить загрузку страницы. Он работает путем кэширования содержимого, полученного от ответов прокси-серверов, и использования его для ответа клиентам без необходимости каждый раз связываться с прокси-сервером для получения одного и того же содержимого.
• Завершение SSL — Nginx может выступать в качестве конечной точки SSL для соединений с клиентами. Он будет обрабатывать и расшифровывать входящие SSL-соединения и шифровать ответы прокси-сервера.
• Сжатие — если прокси-сервер не отправляет сжатые ответы, вы можете настроить Nginx для сжатия ответов перед их отправкой клиентам.
• Смягчение DDoS-атак — вы можете ограничить входящие запросы и количество подключений на один IP-адрес до значения, типичного для обычных пользователей. Nginx также позволяет блокировать или ограничивать доступ в зависимости от местоположения клиента и значения заголовков запроса, таких как «User-Agent» и «Referer».

В этой статье описаны шаги, необходимые для настройки Nginx в качестве обратного прокси.

Подготовка

Мы предполагаем, что у вас установлен Nginx на вашем сервере Ubuntu , CentOS или Debian .

Использование Nginx в качестве обратного прокси

Чтобы настроить Nginx в качестве обратного прокси для HTTP-сервера, откройте файл конфигурации блока сервера домена и укажите в нем расположение и прокси-сервер:

URL-адрес проксируемого сервера устанавливается с proxy_pass директивы proxy_pass и может использовать HTTP или HTTPS качестве протокола, доменного имени или IP-адреса, а также необязательного порта и URI в качестве адреса.

Приведенная выше конфигурация указывает Nginx передавать все запросы в /app прокси-серверу по адресу http://127.0.0.1:8080 .

Чтобы лучше проиллюстрировать, как proxy_pass директивы location и proxy_pass , рассмотрим следующий пример:

Если посетитель обращается к http://example.com/blog/my-post , Nginx передаст этот запрос по прокси на http://node1.com:8000/wordpress/my-post .

Когда адрес проксируемого сервера содержит URI, ( /wordpress/ ), URI запроса, который передается на проксируемый сервер, заменяется URI, указанным в директиве. Если адрес прокси-сервера указан без URI, полный URI запроса передается на прокси-сервер.

Передача заголовков запроса

Когда Nginx проксирует запрос, он автоматически определяет два поля заголовка в проксируемых запросах от клиента, Host и Connection , и удаляет пустые заголовки. Host установлен на переменную $proxy_host , а Connection установлено на закрытие.

Чтобы настроить или установить заголовки для прокси-соединений, используйте директиву proxy_set_header , за которой следует значение заголовка. Вы можете найти список всех доступных заголовков запросов и их разрешенные значения здесь . Если вы хотите предотвратить передачу заголовка на прокси-сервер, установите для него пустую строку «» .

В следующем примере мы меняем значение поля заголовка Host на $host и удаляем поле заголовка Accept-Encoding , устанавливая его значение в пустую строку.

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

Настройка Nginx в качестве обратного прокси для прокси-сервера без HTTP

Чтобы настроить Nginx в качестве обратного прокси-сервера для прокси-сервера, отличного от HTTP, вы можете использовать следующие директивы:

• fastcgi_pass — обратный прокси к серверу FastCGI.
• uwsgi_pass — обратный прокси к серверу uwsgi.
• scgi_pass — обратный прокси к серверу SCGI.
• memcached_pass — обратный прокси к серверу Memcached .

Один из наиболее распространенных примеров — использование Nginx в качестве обратного прокси для PHP-FPM :

Общие параметры обратного прокси Nginx

В настоящее время обслуживание контента через HTTPS стало стандартом. В этом разделе мы дадим вам пример конфигурации обратного прокси-сервера HTTPS Nginx, включая рекомендуемые параметры и заголовки прокси-сервера Nginx.

• proxy_http_version 1.1 — определяет версию протокола HTTP для проксирования, по умолчанию она установлена на 1.0. Для Websockets и keepalive соединений вам необходимо использовать версию 1.1.
• proxy_cache_bypass $http_upgrade — Устанавливает условия, при которых ответ не будет взят из кеша.
• Upgrade $http_upgrade и Connection «upgrade» — эти поля заголовка необходимы, если ваше приложение использует веб-сокеты.
• Host $host — Переменная $host в следующем порядке приоритета содержит: имя хоста из строки запроса, или имя хоста из поля заголовка запроса Host , или имя сервера, соответствующее запросу.
• X-Real-IP $remote_addr — перенаправляет удаленный IP-адрес реального посетителя на прокси-сервер.
• X-Forwarded-For $proxy_add_x_forwarded_for — список, содержащий IP-адреса каждого сервера, через который клиент прошел проксирование.
• X-Forwarded-Proto $scheme — при использовании внутри блока HTTPS-сервера каждый HTTP-ответ от проксируемого сервера перезаписывается на HTTPS.
• X-Forwarded-Host $host — определяет исходный хост, запрошенный клиентом.
• X-Forwarded-Port $server_port — определяет исходный порт, запрошенный клиентом.

Если у вас нет существующего сертификата SSL / TLS, используйте certbot для получения бесплатного SSL-сертификата Let’s Encrypt на вашем сервере Ubuntu 18.04 , CentOS 7 или Debian .

Выводы

Вы узнали, как использовать Nginx в качестве обратного прокси. Мы также показали вам, как передавать дополнительные параметры на сервер, а также изменять и устанавливать различные поля заголовка в проксированных запросах.

Если у вас есть какие-либо вопросы или отзывы, не стесняйтесь оставлять комментарии.

Источник

Пробы и ошибки при выборе HTTP Reverse Proxy

Сегодня мы хотим рассказать о том, как команда сервиса бронирования отелей Ostrovok.ru решала проблему роста микросервиса, задачей которого является обмен информацией с нашими поставщиками. О своем опыте рассказывает undying, DevOps Team Lead в Ostrovok.ru.

Сначала микросервис был мал и выполнял следующие функции:

• принять запрос от локального сервиса;
• сделать запрос партнеру;
• нормализовать ответ;
• вернуть результат вопрошающему сервису.

Однако время шло, сервис рос вместе с количеством партнеров и запросов к ним.

По мере роста сервиса стали всплывать разного рода проблемы. Разные поставщики выдвигают свои правила работы: кто-то ограничивает максимальное количество соединений, кто-то ограничивает клиентов белыми списками.

В итоге нам предстояло решить следующие задачи:

• желательно иметь несколько фиксированных внешних IP адресов, чтобы можно было предоставлять их партнерам для добавления их в белые списки,
• иметь единый пул соединений ко всем поставщикам, чтобы при масштабировании нашего микросервиса количество соединений оставалось минимальным,
• терминировать SSL и держать keepalive в одном месте, тем самым снижая нагрузку для самих партнеров.

Долго думать не стали и сразу задались вопросом, что выбрать: Nginx или Haproxy.
Сперва маятник качнулся в сторону Nginx, так как большую часть проблем, связанных с HTTP/HTTPS, я решал с его помощью и всегда оставался доволен результатом.

Схема была простой: делался запрос в наш новый Proxy Server на Nginx с доменом вида

.domain.local , в Nginx был map , где

соответствовал адресу партнера. Из map брался адрес и делался proxy_pass на этот адрес.

Вот пример map , которым мы парсим домен и выбираем апстрим из списка:

А вот как выглядит “ snippet.d/upstreams_map ”:

Тут у нас сам server<> :

Все классно, все работает. Можно на этом закончить статью, если бы не один нюанс.

При использовании proxy_pass прямиком на нужный адрес запрос идет, как правило, по протоколу HTTP/1.0 без keepalive и закрывается сразу после завершения ответа. Даже если мы выставим proxy_http_version 1.1 , без апстрима ничего не изменится (proxy_http_version).

Что делать? Первая мысль – завести всех поставщиков в апстримы, где в качестве server будет нужный нам адрес поставщика, а в map держать «tag» «upstream_name» .

Добавляем еще один map для парсинга схемы:

И создаем upstreams с именами тегов:

Сам сервер немного видоизменяем, чтобы учитывать схему и вместо адреса использовать имя апстрима:

Отлично. Решение работает, добавляем в каждый апстрим директиву keepalive , выставляем proxy_http_version 1.1 , – теперь у нас есть пул соединений, и все работает как надо.

На этот раз точно можно заканчивать статью и идти пить чай. Или нет?

Ведь пока мы пьем чай, у кого-то из поставщиков может под тем же доменом измениться IP адрес или группа адресов (привет, Амазон), тем самым один из поставщиков может отвалиться в самый разгар нашего чаепития.

Ну что же, как быть? Есть у Nginx интересный нюанс: во время reload он может отрезолвить сервера внутри upstream в новые адреса и пустить трафик на них. В целом, тоже решение. Закидываем в cron reload nginx раз в 5 минут и продолжаем пить чай.

Но все же это показалось мне так себе решением, поэтому я стал косо посматривать в сторону Haproxy.

У Haproxy есть возможность указать dns resolvers и настроить dns cache . Тем самым Haproxy будет сам обновлять dns cache , если записи в нем истекли, и заменять адреса для апстримов в том случае, если они изменились.

Отлично! Теперь осталось дело за настройками.

Вот краткий пример конфигурации для Haproxy:

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

У меня уже был map из Nginx с форматом «tag» «upstream» , поэтому я решил взять его за основу, парсить и генерировать на основании этих значений haproxy backend.

Теперь все, что нам нужно, это добавить новый хост в nginx_map, запустить генератор и получить готовый haproxy конфиг.

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

В следующей статье я расскажу подробнее о том, какие подводные камни нам встречались при использовании Haproxy, какие метрики оказалось полезно мониторить и что точно стоит оптимизировать в системе, чтобы выжать максимум производительности из серверов.

Источник

Fast Reverse Proxy как альтернатива Ngrok

Создание общедоступного URL в сети интернет к вашему локальному проекту

Что такое Ngrok, наверное знает каждый разработчик web приложений, и многие им пользуются.

Присоединившись к новому большому проекту, над которым работают десятки разработчиков и QA специалистов, я столкнулся с тем, что разработка ведется удаленно на специально выделенных серверах.

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

Думаю все, кто более менее освоил работу в докере, уже не мыслят как можно разрабатывать без него. Причин на это много. Конечно, как и везде у докера есть своя цена и это тоже уже много раз обсуждалось.

Итак, новый проект не похож на предыдущие. Он имеет много зависимостей с другими сервисами, как внутренними так и внешними.

Большое количество внешних интерграций порождало проблему связи локального приложения с внешним миром. И если объединить внутренние сервисы используя docker netwokr не вызывало каких либо проблем, то необходимость связать внешний сервис уже требовал дополнительных инструментов.

Интеграции платежных систем всегда подразумевает, что будут callback (notification).

При такой необходимости, часто выбирают Ngrok. Хорошее решение, но в удобном варианте — платное. Особенно это ощущается, когда разработчиков много.

Т.к. Ngrok не подходил, первое что пришло в голову, создать виртуалку, на нее завести домен, и создавать ssh туннель с ним.

где Dockerfile callback-tunnel выглядел вот так

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

Дальше — больше, при локальной разработке, бывает необходимость проверить приложение на другом устройстве, например на телефоне или планшете, или в определенной версии браузера поведение фронта не адекватное. И снова мысли об Ngrok.

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

Fast Reverse Proxy

Сервер написан на Go
JS, Vue для Dashboard

Схема

Как поднимал

Подготовил на github репозиторий

Создал дроплет на Digital Ocean (5$ docker)

Установил туда nginx

Установил letsencript и создал Wildcard SSL Certificate по этой доке. Wildcard нужен для того чтоб public URL были https

Настроил nginx, он выступает как первый proxy server. Можно обойтись без него, но мне так было проще

Создал .env из .env-example и прописал необходимые переменные

запустил client-ский docker-compose

В зависимости от того какой указал REVERSE_PROXY_PERSONAL_ALIAS, будет мой URL.

В моем примере есть 3 хоста (обычно нужно для проекта), и в зависимости какой PERSONAL_ALIAS указан, будут доступны по URLs. К примеру PERSONAL_ALIAS=project, тогда

Источник

Перерастая reverse proxy — технология удаленной защиты и оптимизации сайтов без изменения А-записей DNS

За последний месяц средняя нагрузка на интернет ресурсы сильно выросла из-за повсеместного перехода на дистанционную работу и обучение (как именно читайте в нашем материале «Пандемия и трафик — взгляд со стороны оператора связи». Особым спросом пользуются онлайн кинотеатры и игры, платформы для онлайн обучения, сервисы по заказу доставки еды. В таких условиях потенциальный экономический ущерб от недоступности ресурса, в том числе из-за DDoS-атак, особенно высок. Какое решение выбрать для защиты своего проекта?

В материале вас ждут:

• Ограничения защиты через классический reverse proxy со сменой А-записей DNS, о которых часто умалчивают провайдеры.
• Какое решение выбрать, чтобы избежать связанных с этими ограничениями рисков?
• Реальный кейс с защитой крупного проекта, без переезда и смены A-записей.
• Общие рекомендации по организации защиты интернет ресурса.

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

Скорее всего, первое решение, которое вам попадется, будет основано на технологии reverse proxy со сменой A-записей DNS. Поэтому сначала мы рассмотрим принцип работы технологии, ее возможности (если вы хорошо знакомы с reverse proxy — смело пропускайте эти два подраздела) и ограничения, связанные с доставкой трафика (это пропускать не стоит). Затем мы покажем, как эти ограничения можно обойти на примере реального кейса. В конце мы дадим несколько общих рекомендаций по организации защиты интернет ресурса.

Reverse proxy — принцип работы

Здесь мы рассмотрим reverse proxy, как средство доставки трафика. Схема ее работы всем хорошо знакома, но не упомянуть ее здесь просто нельзя.

1. Изменение А-записей DNS — вместо IP адреса веб-сервера указывается IP адрес прокси сервера. Распространение внесенных изменений по миру (DNS propagation).
2. ОС посетителя запрашивает IP-адрес, соответствующий доменному имени сайта (DNS resolution).
3. DNS сервер отвечает на запрос, сообщая IP-адрес прокси сервера.
4. Браузер посетителя открывает HTTP(s) сессию и отправляет запросы прокси серверу, который, переустанавливает соединение с целевым веб-сервером и передает запросы ему.

Reverse proxy — возможности

Какие возможности предоставляют решения работающие через reverse proxy со сменой А-записей?

• Мониторинг запросов и защита сайта от атак на уровне приложений. Технология позволяет обработать каждый запрос уровня приложений, поступающий к целевому серверу.
• Снижение нагрузки на целевой веб-сервер и ускорение сайта. На проксирующих серверах можно сжимать и кэшировать данные — это является основой работы сетей доставки контента CDN (Content Delivery Network).
• Гибкое распределение нагрузки между несколькими целевыми веб-серверами. Технология позволяет распределить нагрузку по обработке запросов между несколькими машинами. Это повышает отказоустойчивость и производительность системы.
• Простота подключения. Чтобы подключить защиту достаточно поменять А-записи DNS и дождаться, когда изменения вступят в силу. Переезд, новое оборудование и ПО — не требуются.
• Сокрытие реального IP-адреса целевого веб-сервера. Посетитель используют IP-адрес проксирующего сервера для обращения, и с него же получают ответы, что обеспечивает анонимность целевого веб-ресурса.

Reverse proxy — ограничения

У данной технологии есть ряд подводных камней, о которых не очень-то принято говорить. К ее ограничениям можно отнести:

• Отсутствие защиты от прямых DDoS-атак для самого веб-сервера и инфраструктуры. Если известен IP-адрес целевого веб-сервера, злоумышленники могут провести атаку напрямую, не обращаясь к DNS-серверу. Настройка файрвола на защищаемом сервере не спасает от пакетных DDoS-атак и атак на переполнение каналов.
• Изменение IP-адресов, используемых для доступа к веб сайтам. Если одних интересует анонимность, то для других сохранение собственных IP-адресов является принципиально важным. Например если компания обладает собственными IP-адресами или целой автономной системой и не хочет ассоциировать себя с компанией, которой принадлежат IP адреса проксирующих серверов.
• Ощутимые задержки при включении/отключении защиты. Задержки связаны со скоростью обновления информации на DNS серверах по всему миру (DNS propagation). При лучшем сценарии это занимает несколько часов, но может затянутся и на несколько суток. Длительность DNS propagation зависит от времени жизни TTL (Time to Live) DNS-записей, которое определяет через какое время сервер обновит кэш записей.
• Нельзя защитить сайты и веб-приложения, использующие TCP-порты, отличные от стандартных 80 и 443. Если веб-приложение использует, например, UDP-порт, защитить его не получится. Запросы не будут проксироваться и легитимные пользователи просто не смогут воспользоваться приложением.

Недостатки решений по защите от DDoS-атак на базе “классической” Reverse Proxy начинают ощущаться, по мере того как растущий проект упирается во все большее число ограничений технологии. Какие технические решения способны нивелировать или значительно снизить риски недоступности сайта из-за перечисленных недостатков? — читайте ниже.

Перерастая reverse proxy

Давайте рассмотрим проблему на реальном примере из нашей практики. В прошлом году к нам обратился крупный клиент, с конкретным списком требований к услугам по защите. Мы не можем раскрыть название компании по понятным причинам, а вот потребности клиента — пожалуйста:

• Обеспечить защиту сайтов от атак на уровне приложений.
• Снять часть нагрузки с целевых веб-серверов и ускорить загрузку сайтов — у клиента много статического контента, и он заинтересован в кэшировании и сжатии данных на узлах CDN.
• Обеспечить защиту от прямых атак на IP-адрес/сеть (защита от DDoS-атак на уровнях L3-L4 OSI).
• Сервисы должны подключаться без изменения внешних IP-адресов ресурсов. У клиента своя AS и блоки адресов.
• Управление сервисами обработки трафика и переключение на резервные каналы должно происходить в режиме реального времени — уровень доступности ресурса критически важен для клиента.

Решения на основе “классической” reverse proxy с изменением А-записей DNS позволяют закрыть первые два пункта из спиcка.

Услуги вроде защищенного хостинга, виртуальных и выделенных серверов позволяют защититься от атак на уровнях L3-L7 OSI, но требуют переезда и означают использование единственного провайдера защиты. Что делать?

Защита от DDoS внутри сети с защищаемыми сервисами

Установка фильтрующего оборудования в своей сети позволяет защитить сервисы на уровнях L3-L7 OSI и свободно управлять правилами фильтрации. Вы несете существенные капитальные (CaPex) и операционные расходы (OpEx), выбирая такое решение. Это расходы на:

• оборудование для фильтрации трафика + лицензии на ПО (CapEx);
• продление лицензий на ПО (OpEx);
• штатные специалисты для настройки оборудования и контроля его работы (OpEx);
• каналы доступа в сеть Интернет, достаточные для приема атак (CapEx + OpEx);
• оплата входящего «мусорного» трафика (OpEx).

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

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

Проксирование без смены А-записей.

Чтобы удовлетворить потребности таких клиентов, мы разработали технологию перехвата веб-трафика и реализовали ее в рамках услуги удаленной защиты без смены А-записей. В основе решения лежит принцип: Все соединения между АС клиента и публичными сетями должны быть защищены. Клиент передает нам анонсы своих IP адресов/сетей по BGP, а мы анонсируем их в Интернет.

Весь трафик, предназначенный защищаемым ресурсам, проходит через нашу сеть. Клиент может оставить несколько резервных подключений и использовать их в случае непредвиденных обстоятельств, сняв анонсы с сети DDoS-GUARD. В штатном режиме мы советуем использовать только наши подключения для выхода в сеть Интренет, чтобы мы могли гарантировать защиту клиентских сервисов.

На схеме ниже показано, как организована обработка трафика в нашей сети на примере веб-трафика.

1. Клиент указывает IP-адреса, подсети и домены, которые он хочет защитить на уровне L7. Это можно сделать для анонсируемых сетей в личном кабинете или при помощи API
2. В сеть провайдера услуги из сети Интернет попадает клиентский трафик. В первую очередь он проходит базовый анализ и очистку от «мусора» на уровнях L3-4 модели OSI.
3. Система перехвата сепарирует и обрабатывает трафик на основании используемых протоколов уровня приложений. В данном случае TCP пакеты на 80 и 443 порты, содержащие HTTP заголовки, направляются на анализ веб-трафика, остальной трафик доставляется в сеть клиента как легитимный.
4. Веб-трафик проверяется на принадлежность защищаемой подсети. Пакеты с адресом назначения отличным от указанных клиентом проходят дополнительную проверку по имени домена.
5. Весь трафик указанных клиентом IP адресов/доменов проходит обработку на уровне L7. На проксирующих серверах осуществляется фильтрация трафика, оптимизация контента и его кеширование.

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

Заключение

Теперь давайте проверим удовлетворяет ли разработанное DDoS-GUARD решение списку требований из раздела «Перерастая reverse proxy».

• Клиент получает защиту от атак на уровнях L3-L7 OSI.
• Контент сжимается и кэшируется на узлах нашей CDN, что уменьшает нагрузку на целевые веб-серверы.
• Управление защитой происходит в реальном времени. Клиент управляет правилами фильтрации трафика для подсетей, IP-адресов и отдельных доменов через личный кабинет или API. Изменения вступают в силу пределах 1 минуты. В экстренной ситуации клиент может перенаправить весь трафик в обход сети DDoS-GUARD, просто сняв анонсы по BGP.
• IP-адреса, принадлежащие компании, остались неизменными. Клиенту не нужно закупать новое оборудование, программное обеспечение, нанимать дополнительный персонал и платить за неочищенный трафик.

В добавок появляется возможность защитить сервисы и приложения, работающие на нестандартных портах.

Общие рекомендации по организации защиты вашего проекта:

• Избегайте туннелей, в т.ч. при доставке очищенного трафика через сеть провайдера — это снижает MTU (Maximum Transmission Unit). Чем ниже MTU, тем больше пакетов приходится фрагментировать, т.е. разбивать, понижая тем самым скорость передачи данных) и ставит ваш сервис в зависимость от политик по приоритезации трафика транзитных операторов.
• Обращайте внимание на связность сети поставщика услуг — нерационально строить маршрут Красная площадь — ВДНХ, через Рязань или Франкфурт.
• Резервируйте все подключения (каналы), операторов, оборудование, персонал. В случае с защитой от DDoS предусмотрите «стоп-кран», который позволит экстренно отключать влияние на трафик.
• Вне зависимости от особенностей используемой схемы защиты веб-сайта, сервис должен предоставлять возможность управлять защитой в реальном времени. Учитывая, что 100% точность фильтрации недостижима, система должна быть управляемой для снижения ошибок I и II рода.

Источник