С помощью существующего протокола единого входа OpenID Connect 6 страница

ким образом, блок с if применяется, только чтобы отказать в доступе лицам не из США или России.

Обсуждение

Это короткий, но простой пример того, как разрешить доступ только лицам из двух стран. Его можно развить в зависимости от ваших по- требностей. Можно использовать этот же метод, чтобы разрешить или заблокировать доступ на основе любой из встраиваемых переменных, доступных из модуля GeoIP.

3.4. Поиск исходного клиента

Задача

Вам необходимо найти исходный IP-адрес клиента, поскольку перед сервером NGINX находятся прокси-сервера.

Решение

Используйте директиву geoip_proxy для определения диапазона IP-ад- ресов прокси-сервера и директиву geoip_proxy_recursive для поиска ис- ходного IP-адреса:

load_module "/usr/lib64/nginx/modules/ngx_http_geoip_module.so";

 

http {

geoip_country /etc/nginx/geoip/GeoIP.dat; geoip_city /etc/nginx/geoip/GeoLiteCity.dat; geoip_proxy 10.0.16.0/26; geoip_proxy_recursive on;

...

}

 

Директива geoip_proxy определяет диапазон бесклассовой адресации, в котором находятся наши прокси-серверы, и указывает NGINX исполь- зовать заголовок X-Forwarded-For, чтобы найти клиентский IP-адрес. Ди- ректива geoip_proxy_recursive дает NGINX указание рекурсивно просмат- ривать заголовок X-Forwarded-For, чтобы найти последний известный IP-адреса клиента.

Обсуждение

Вы можете обнаружить, что при использовании прокси-сервера перед

NGINX NGINX будет выбирать IP-адрес прокси, а не клиента. Для этого

 

                                                                    3.5. Ограничение подключений v 45

можно использовать директиву geoip_proxy, чтобы указать NGINX взять заголовок X-Forwarded-For, когда соединения открываются из заданного диапазона. Директива geoip_proxy принимает адрес или диапазон бес- классовой адресации. Когда есть несколько прокси, передающих тра- фик перед NGINX, можно использовать директиву geoip_proxy_recursive для рекурсивного поиска по адресам X-Forwarded-For, чтобы найти исхо- дящего клиента. Возможно, вы захотите использовать нечто подобное при использовании балансировщиков нагрузки, таких как AWS ELB, ба- лансировщик нагрузки Google или Azure перед NGINX.

3.5. Ограничение подключений

Задача

Вам необходимо ограничить количество подключений на основе пред- определенного ключа, такого как IP-адрес клиента.

Решение

Создайте зону общей памяти для удержания метрик подключений и используйте директиву limit_conn для ограничения открытых соедине- ний:

http {

limit_conn_zone $binary_remote_addr zone=limitbyaddr:10m; limit_conn_status 429;

...

server {

...

limit_conn limitbyaddr 40;

...

}

}

 

В этой конфигурации мы создаем зону общей памяти с именем limit byaddr. В качестве предопределенного ключа используется IP-адрес кли- ента в двоичном виде. Размер зоны общей памяти установлен на 10 Мб. Директива limit_conn принимает два параметра: имя limit_conn_zone и ко- личество разрешенных соединений. Директива limit_conn_status устанав- ливает ответ, когда соединения ограничены статусом 429, что указывает на слишком большое количество запросов. Директивы limit_conn и limit_ conn_status действительны в контексте HTTP, сервера и местоположения.

 

46 v Глава 3. Управление трафиком                                                                      

Обсуждение

Ограничение количества соединений на основе ключа может быть использовано для защиты от злоупотреблений и справедливого рас- пределения ресурсов между всеми вашими клиентами. Важно быть осторожным с предопределенным ключом. Использование IP-адреса, как мы это делали в предыдущем примере, может быть опасным, если в одной сетевой среде, происходящей из одного и того же IP-адреса, на- ходится большое количество пользователей, например когда речь идет о преобразовании сетевых адресов. Вся группа клиентов будет огра- ничена. Директива limit_conn_zone  действует только в контексте HTTP. Вы можете использовать любое количество переменных, доступных для NGINX в контексте HTTP, чтобы создать строку, применяемую для ограничения. Использование переменной, которая может идентифи- цировать пользователя на уровне приложения, например куки-файла сессии, может быть более чистым решением в зависимости от вари- анта использования. Директива limit_conn_status по умолчанию выдает ошибку 503, service unavailable. Возможно, вы предпочтете использо- вать 429, поскольку служба доступна и ответы с кодом 5xx указывают на ошибку сервера, тогда как ответы с кодом 4xx указывают на ошибку клиента.

3.6. Ограничение скорости

Задача

Вам необходимо ограничить скорость запросов с помощью предва- рительно определенного ключа, такого как IP-адрес клиента.

Решение

Используйте модуль ограничения скорости, чтобы ограничить ско- рость запросов:

http {

limit_req_zone $binary_remote_addr zone=limitbyaddr:10m rate=1r/s;

limit_req_status 429;

...

server {

...

limit_req zone=limitbyaddr burst=10 nodelay;

 

3.6. Ограничение скорости v 47

...

}

}

 

В этом примере конфигурации мы создаем зону общей памяти с именем limitbyaddr. Предопределенный ключ – это IP-адрес клиента в двоичной форме. Размер зоны общей памяти установлен на 10 Мб. Зона устанавливает скорость с помощью аргумента ключевого слова. Директива limit_req принимает два необязательных аргумента ключе- вого слова: zone и burst. zone необходим, чтобы указать директиве, какую зону ограничения запросов к общей памяти использовать. Когда ско- рость запросов для данной зоны превышена, запросы задерживаются, до тех пор пока не будет достигнут их максимальный размер пакета, обозначенный аргументом ключевого слова burst. Аргумент ключевого слова burst по умолчанию равен нулю. limit_req также принимает третий необязательный параметр, nodelay. Этот параметр позволяет клиенту использовать свой пакет без задержки до ограничений. limit_req_status устанавливает состояние, возвращаемое клиенту как определенный код состояния HTTP; по умолчанию это 503. limit_req_status и limit_req действительны в контексте HTTP, сервера и местоположения. Директи- ва limit_req_zone действительна только в контексте HTTP. Ограничение скорости поддерживает кластеры в NGINX Plus, новая функция в версии R16.

Обсуждение

Модуль ограничения скорости – очень мощное средство для защи- ты от чрезмерно быстрых запросов, в то же время он предоставляет качественное обслуживание всем. Есть много причин для ограниче- ния скорости запроса, и одна из них – это безопасность. Можно отбить атаку методом полного перебора, установив очень строгое ограниче- ние на своей странице входа. Можно установить разумный лимит для всех запросов, тем самым нарушив планы злоумышленников, которые могут попытаться нарушить обслуживание вашего приложения или растратить ресурсы. По конфигурации модуль ограничения скорости очень похож на предыдущий модуль ограничения соединений, описан- ный в рецепте 3.5, и большая часть этих концепций применима и здесь. Можно указать скорость, с которой ограничиваются запросы, в запро- сах в секунду или в минуту. Когда ограничение скорости достигнуто, инцидент регистрируется. Существует также директива, которой нет в примере, limit_req_log_level, – она по умолчанию выдает ошибку, но это

 

48 v Глава 3. Управление трафиком                                                                             

может быть и информационное сообщение, уведомление или преду- преждение. Новинка: в версии R16 NGINX Plus ограничение скорости теперь поддерживает кластеры (см. рецепт 12.5, где приводится пример синхронизации зоны).

3.7. Ограничение пропускной способности

Задача

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

Решение

Используйте директивы limit_rate и limit_rate_after, чтобы ограни- чить скорость ответа клиенту:

location /download/ { limit_rate_after 10m; limit_rate 1m;

}

 

Конфигурация этого блока местоположения указывает, что для URI c префиксом download скорость, с которой ответ отправится клиенту, бу- дет ограничена после 10 Мб до скорости 1 Мб/с. Ограничение пропуск- ной способности осуществляется для каждого соединения, поэтому вы можете захотеть установить ограничение соединения, а также ограни- чение пропускной способности, где это применимо.

Обсуждение

Ограничение пропускной способности для определенных соедине- ний позволяет NGINX распределять пропускную способность загрузки между всеми клиентами таким образом, который вы указываете. Все это делают две директивы: limit_rate_after и limit_rate. Директиву limit_ rate_after можно установить практически в любом контексте: HTTP, сер- вер, местоположение и оператор if, если он находится внутри место- положения. Директива limit_rate применима в тех же контекстах, что и limit_rate_after; однако ее также можно настроить путем установки переменной с именем $limit_rate. Директива limit_rate_after указывает, что скорость соединения не должна ограничиваться, до тех пор пока не будет передан определенный объем данных. Директива limit_rate опре-

 

                                                      3.7. Ограничение пропускной способности v 49

деляет ограничение скорости для данного контекста в байтах в секунду по умолчанию. Однако вы можете указать m для обозначения мегабайт или g для обозначения гигабайт. В обеих директивах по умолчанию установлено значение 0 – оно означает, что скорость скачивания во- обще не ограничивается. Этот модуль позволяет программно изменять ограничение скорости клиентов.

 

 

 

Глава 4

Массивно масштабируемое кеширование контента

4.0. Введение

Кеширование ускоряет обслуживание контента, сохраняя ответы на за- просы, которые будут снова обслуживаться в будущем. Кеширование контента снижает нагрузку на вышестоящие серверы, кешируя полный ответ, вместо того чтобы выполнять вычисления и снова делать один и тот же запрос. Кеширование повышает производительность и снижает нагрузку, а это означает, что вы можете выполнять обслуживание бы- стрее с меньшим количеством ресурсов. Масштабирование и распре- деление серверов кеширования в стратегических местах может оказать существенное влияние на пользовательский опыт. Это оптимально – размещать контент ближе к потребителю для обеспечения лучшей про- изводительности. Вы также можете кешировать свой контент рядом со своими пользователями. Это шаблон сетей доставки содержимого или CDN. С помощью NGINX вы кешируете свой контент везде, где мож- но разместить сервер NGINX, что позволяет вам эффективно создавать собственную сеть доставки содержимого. С помощью кеширования в NGINX вы также можете пассивно кешировать и обслуживать кеширо- ванные ответы в случае отказа восходящего потока.

4.1. Кеширование зон

Задача

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

 

 

Решение

4.1. Кеширование зон v 51

Используйте директиву proxy_cache_path, чтобы определить зоны кеша общей памяти и расположение контента:

proxy_cache_path /var/nginx/cache

keys_zone=CACHE:60m levels=1:2 inactive=3h max_size=20g;

proxy_cache CACHE;

 

В этом примере определения кеша мы создаем каталог для кеширо- ванных ответов в файловой системе в /var/nginx/cache и пространство общей памяти с именем CACHE с 60 Мб памяти. Мы устанавливаем уров- ни структуры каталогов, определяем выпуск кешированных ответов после того, как они не были запрошены в течение 3 ч, и определяем максимальный размер кеша в 20 Гб. Директива proxy_cache сообщает конкретному контексту использовать зону кеширования. Директи- ва proxy_cache_path действительна в контексте HTTP, а директива proxy_ cache – в контексте HTTP, сервера и местоположения.

Обсуждение

Чтобы настроить кеширование в NGINX, необходимо объявить путь и зону для использования. Зона кеширования в NGINX создается с помо- щью директивы proxy_cache_path. Она обозначает местоположение, где будет храниться кешированная информация, и пространство общей памяти, где будут храниться активные ключи и метаданные ответа. Не- обязательные параметры для этой директивы обеспечивают больший контроль над тем, как поддерживается кеш и как к нему выполняет- ся доступ. Параметр levels определяет, как создается структура файла. Значение – это разделенная двоеточиями величина, которая объявляет длину имен подкаталогов, с максимумом в три уровня. NGINX осущест- вляет кеширование на основе ключа кеша, который представляет собой хешированное значение. Затем NGINX сохраняет результат в предо- ставленной файловой структуре, используя ключ кеша в качестве пути к файлу и разбивая каталоги на основе значения levels. Параметр inac- tive позволяет контролировать время, в течение которого элемент кеша будет размещаться после его последнего использования. Размер кеша настраивается с использованием параметра max_size. Другие параметры

 

52 v Глава 4. Массивно масштабируемое кеширование контента                                

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

 

4.2. Хеш-ключи кеширования

Задача

Вам необходимо контролировать, как ваш контент кешируется и про- сматривается.

Решение

Используйте директиву proxy_cache_key наряду с переменными, чтобы определить, на чем основывается кеширование – на попадании или на промахе:

proxy_cache_key "$host$request_uri $cookie_user";

 

Этот хеш-ключ будет указывать NGINX кешировать страницы на основе запрашиваемого хоста и URI, а также куки, который опреде- ляет пользователя. При этом вы можете кешировать динамические страницы, не обслуживая контент, созданный для другого пользова- теля.

Обсуждение

По умолчанию директива proxy_cache_key, которая подходит для боль- шинства случаев использования, – это "$scheme$proxy_host$request_uri". Используемые переменные включают в себя схему, протокол HTTP или HTTPS, proxy_host, куда отправляется запрос, и URI запроса. Все это вме- сте отражает URL-адрес, на который NGINX передает запрос. Вы можете обнаружить, что существует множество других факторов, определяю- щих уникальный запрос для каждого приложения, например аргумен- ты запроса, заголовки, идентификаторы сеанса и т. д., для которых вам понадобится создать собственный хеш-ключ1. Выбор подходящего хеш-ключа очень важен и должен быть продуман c пониманием прило- жения. Выбрать ключ кеша для статического контента обычно довольно просто – достаточно использовать имя хоста и URI. Выбор ключа кеша для довольно динамичного содержимого, такого как страницы, для

1 Любая комбинация текста или переменных, доступных для NGINX, может быть использована для формирования ключа кеша. Список переменных доступен на странице: http://nginx.org/en/ docs/varindex.html.

 

4.3. Обход кеширования v 53

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

---

Дата добавления: 2021-01-21; просмотров: 115; Мы поможем в написании вашей работы!

Поделиться с друзьями:

---

---

Мы поможем в написании ваших работ!