nginx resolver что это

Nginx resolver explained

Nginx resolver is playing very important part in creating fault tolerant setups, especially when it comes to the free open source version. In this article I’ll explain why we need Nginx resolver and how it works.

I remember the moment about a year or so ago when I came to the office and found people screaming that one of our sites was hacked. When I opened it in my browser I saw completely different site, definitely not ours..

After spending hours trying to figure out the problem, I was finally able to identify the root cause. It wasn’t a hack attack after all, it was something much more simple.. Turned out AWS load balancer changed IP and Nginx cached the old one (we used static reverse proxy configuration).

Let me remind how we usually configure Nginx as reverse proxy:

This super simple configuration will work just fine until one day / week / month later it will stop. Yes it will stop when AWS changes IP behind ELB DNS record.

But what exactly happens? Turns out when you specify hostname for proxy_pass like we did in our example, Nginx will resolve it once on startup or reload and then cache resulting IP address. For us Nginx was sending requests to the IP that was re-assigned from ELB to someone else EC2 instance. Fun right?

What can we do to avoid the problem?

Well, there are multiple ways:

Then there is Nginx Plus which provides special resolve flag that you can set on your upstream servers. It will honor DNS TTL and update them automatically if the pointer changes (as per official documentation). I’ve yet to try it. The problem with Nginx Plus that it costs 2.5K / per instance / per year..

There is a module on GitHub called nginx-upstream-dynamic-servers, but it doesn’t have recent updates at the time of writing.. (but do have opened Issues). Please let me know in the comments below if you use it.

Some time ago I stumbled upon an interesting free Nginx resolver alternative which I’ll describe below.

Free Nginx resolver alternative

Normally in Nginx if we put trailing slash / at the end of the static proxy_pass directive, it will remove the part matched by the location and only proxy remaining part of the URI:

Now request to /test/path will proxy only / which is not what we would expect.

This post turned out a bit more technical than I expected, but it’s well worth spending extra bit of time to understand all the examples above. If you plan to use Nginx in the environment with changing ips behind DNS pointers (which is almost everywhere), then you need to either get Nginx Plus, or learn Nginx resolver secrets.

Wake up, Neo. The matrix has you.

Join our growing UNDERGROUND MOVEMENT of Rain Makers. Just drop your email below and your life will never be the same again.

Feel free to reach out on Twitter, Facebook or Instagram.

Ha, great! Thanks for signing to my list. Don’t forget to subscribe to social channels for «real-time» stuff and lets rock together!

Источник

Модуль ngx_http_upstream_module

Модуль ngx_http_upstream_module позволяет описывать группы серверов, которые могут использоваться в директивах proxy_pass, fastcgi_pass, uwsgi_pass, scgi_pass, memcached_pass и grpc_pass.

Пример конфигурации

Динамически настраиваемая группа с периодическими проверками работоспособности доступна как часть коммерческой подписки:

Директивы

Описывает группу серверов. Серверы могут слушать на разных портах. Кроме того, можно одновременно использовать серверы, слушающие на TCP- и UNIX-сокетах.

По умолчанию запросы распределяются по серверам циклически (в режиме round-robin) с учётом весов серверов. В вышеприведённом примере каждые 7 запросов будут распределены так: 5 запросов на backend1.example.com и по одному запросу на второй и третий серверы. Если при попытке работы с сервером происходит ошибка, то запрос передаётся следующему серверу, и так далее до тех пор, пока не будут опробованы все работающие серверы. Если не удастся получить успешный ответ ни от одного из серверов, то клиенту будет возвращён результат работы с последним сервером.

Задаёт адрес и другие параметры сервера. Адрес может быть указан в виде доменного имени или IP-адреса, и необязательного порта, или в виде пути UNIX-сокета, который указывается после префикса “ unix: ”. Если порт не указан, используется порт 80. Доменное имя, которому соответствует несколько IP-адресов, задаёт сразу несколько серверов.

Могут быть заданы следующие параметры:

weight = число задаёт вес сервера, по умолчанию 1. max_conns = число ограничивает максимальное число одновременных активных соединений к проксируемому серверу (1.11.5). Значение по умолчанию равно 0 и означает, что ограничения нет. Если группа не находится в зоне разделяемой памяти, то ограничение работает отдельно для каждого рабочего процесса.

Начиная с версии 1.5.9 и до версии 1.11.5 этот параметр был доступен как часть коммерческой подписки.

Параметр нельзя использовать совместно с методами балансировки нагрузки hash, ip_hash и random.

Кроме того, следующие параметры доступны как часть коммерческой подписки:

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

Для работы этого параметра директива resolver должна быть задана в блоке http или в соответствующем блоке upstream.

route = строка задаёт имя маршрута к серверу. service = имя включает преобразование SRV-записей DNS и задаёт имя сервиса (1.9.13). Для работы параметра необходимо указать параметр resolve для сервера и не указывать порт сервера.

Если имя сервиса содержит одну и более точек, то имя составляется при помощи соединения префикса службы и имени сервера. Например, для получения SRV-записей _http._tcp.backend.example.com и server1.backend.example.com необходимо указать директивы:

SRV-записи с наивысшим приоритетом (записи с одинаковым наименьшим значением приоритета) преобразуются в основные серверы, остальные SRV-записи преобразуются в запасные серверы. Если в конфигурации сервера указан параметр backup, высокоприоритетные SRV-записи преобразуются в запасные серверы, остальные SRV-записи игнорируются.

Параметр нельзя использовать совместно с методами балансировки нагрузки hash, ip_hash и random.

До версии 1.13.6 параметр мог быть изменён только при помощи модуля API.

Эта директива появилась в версии 1.9.0.

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

Дополнительно, как часть коммерческой подписки, в таких группах для изменения состава группы или настроек отдельных серверов нет необходимости перезапускать nginx. Конфигурация доступна через модуль API (1.13.3).

До версии 1.13.3 конфигурация была доступна только через специальный location, в котором указана директива upstream_conf.

Эта директива появилась в версии 1.9.7.

В данный момент состояние ограничено списком серверов с их параметрами. Файл читается при парсинге конфигурации и обновляется каждый раз при изменении конфигурации группы. Изменение содержимого файла напрямую не рекомендуется. Директиву нельзя использовать совместно с директивой server.

Эта директива появилась в версии 1.7.2.

Задаёт для группы метод балансировки нагрузки, при котором запросы распределяются по серверам на основе IP-адресов клиентов. В качестве ключа для хэширования используются первые три октета IPv4-адреса клиента или IPv6-адрес клиента целиком. Метод гарантирует, что запросы одного и того же клиента будут всегда передаваться на один и тот же сервер. Если же этот сервер будет считаться недоступным, то запросы этого клиента будут передаваться на другой сервер. С большой долей вероятности это также будет один и тот же сервер.

IPv6-адреса поддерживаются начиная с версий 1.3.2 и 1.2.2.

Эта директива появилась в версии 1.1.4.

Задействует кэш соединений для группы серверов.

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

Следует особо отметить, что директива keepalive не ограничивает общее число соединений с серверами группы, которые рабочие процессы nginx могут открыть. Параметр соединения следует устанавливать достаточно консервативно, чтобы серверы группы по-прежнему могли обрабатывать новые входящие соединения.

Пример конфигурации группы серверов memcached с постоянными соединениями:

Для HTTP директиву proxy_http_version следует установить в “ 1.1 ”, а поле заголовка “Connection” — очистить:

Хоть это и не рекомендуется, но также возможно использование постоянных соединений с HTTP/1.0, путём передачи поля заголовка “Connection: Keep-Alive” серверу группы.

Для работы постоянных соединений с FastCGI-серверами потребуется включить директиву fastcgi_keep_conn:

Протоколы SCGI и uwsgi не определяют семантику постоянных соединений.

Эта директива появилась в версии 1.15.3.

Задаёт максимальное число запросов, которые можно сделать по одному постоянному соединению. После того как сделано максимальное число запросов, соединение закрывается.

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

До версии 1.19.10 по умолчанию использовалось значение 100.

Эта директива появилась в версии 1.19.10.

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

Эта директива появилась в версии 1.15.3.

Задаёт таймаут, в течение которого неактивное постоянное соединение с сервером группы не будет закрыто.

Эта директива появилась в версии 1.9.2.

Позволяет проксировать запросы с проверкой подлинности NTLM. Соединение с сервером группы привязывается к клиентскому соединению как только клиент отправляет запрос, в заголовке которого есть поле “Authorization” со значением, начинающимся с “ Negotiate ” или “ NTLM ”. Последующие запросы клиента будут проксироваться через это же соединение с сервером группы, сохраняя контекст аутентификации.

Для работы проверки подлинности NTLM необходимо разрешить постоянные соединения с серверами группы. Директиву proxy_http_version следует установить в “ 1.1 ”, а поле заголовка “Connection” — очистить:

Эта директива появилась в версиях 1.3.1 и 1.2.2.

Задаёт для группы метод балансировки нагрузки, при котором запрос передаётся серверу с наименьшим числом активных соединений, с учётом весов серверов. Если подходит сразу несколько серверов, они выбираются циклически (в режиме round-robin) с учётом их весов.

Эта директива появилась в версии 1.7.10.

Задаёт для группы метод балансировки нагрузки, при котором запрос передаётся серверу с наименьшими средним временем ответа и числом активных соединений с учётом весов серверов. Если подходит сразу несколько серверов, то они выбираются циклически (в режиме round-robin) с учётом их весов.

До версии 1.11.6 незавершённые запросы учитывались по умолчанию.

Эта директива появилась в версии 1.5.12.

По умолчанию параметр timeout равен 60 секундам.

Эта директива появилась в версии 1.15.1.

Задаёт для группы метод балансировки нагрузки, при котором запрос передаётся случайно выбранному серверу, с учётом весов серверов.

Эта директива появилась в версии 1.17.5.

Задаёт серверы DNS, используемые для преобразования имён вышестоящих серверов в адреса, например:

Адрес может быть указан в виде доменного имени или IP-адреса, и необязательного порта. Если порт не указан, используется порт 53. Серверы DNS опрашиваются циклически.

По умолчанию nginx кэширует ответы, используя значение TTL из ответа. Необязательный параметр valid позволяет это переопределить:

Для предотвращения DNS-спуфинга рекомендуется использовать DNS-серверы в защищённой доверенной локальной сети.

Эта директива появилась в версии 1.17.5.

Задаёт таймаут для преобразования имени в адрес, например:

Эта директива появилась в версии 1.5.7.

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

При использовании метода cookie информация о назначенном сервере передаётся в HTTP-куке:

Запрос от клиента, ещё не привязанного к определённому серверу, передаётся на сервер, выбранный согласно настроенному методу балансировки. Дальнейшие запросы от этого клиента передаются на тот же сервер. Если назначенный сервер не может обработать запрос, выбирается новый сервер как если бы клиент не имел привязки к серверу.

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

Первый параметр задаёт имя куки, которую необходимо установить или проверить. Значением куки является MD5-хэш IP-адреса и порта (или пути UNIX-сокета) в шестнадцатеричном виде. Однако если указан параметр “ route ” директивы server, то значением куки будет значение параметра “ route ”:

Дополнительные параметры могут быть следующими:

Если пропущен тот или иной параметр, то соответствующего поля в куке не будет.

При использовании метода route проксируемый сервер назначает клиенту маршрут по получении первого запроса. Все последующие запросы от этого клиента будут содержать информацию о маршруте в куке или URI. Эта информация сравнивается с параметром “ route ” директивы server для идентификации сервера, на который следует проксировать запрос. Если параметр “ route ” не задан, то именем маршрута будет являться MD5-хэш IP-адреса и порта (или пути UNIX-сокета) в шестнадцатеричном виде. Если назначенный сервер не может обработать запрос, выбирается новый сервер согласно настроенному методу балансировки как если бы в запросе не было информации о маршруте.

Параметры метода route задают переменные, которые могут содержать информацию о маршруте. Первая непустая переменная используется для поиска соответствующего сервера.

В этом примере маршрут берётся из куки “ JSESSIONID ”, если она присутствует в запросе. В противном случае используется маршрут из URI.

При использовании метода learn (1.7.1) nginx анализирует ответы от вышестоящего сервера и запоминает начатые им сессии, которые обычно передаются в HTTP-куке.

В примере выше сервер группы создаёт сессию путём установки куки “ EXAMPLECOOKIE ” в своём ответе. Последующие запросы с этой кукой будут передаваться на этот же сервер. Если сервер не может обработать запрос, выбирается новый сервер как если бы клиент не имел привязки к серверу.

Параметры create и lookup задают переменные, в которых соответственно указывается способ создания новых и поиска существующих сессий. Оба параметра могут быть указаны больше одного раза (в этом случае используется первая непустая переменная).

Параметр header (1.13.1) позволяет создавать сессию сразу после получения заголовков ответа от сервера группы.

Параметр sync (1.13.8) разрешает синхронизацию данной зоны разделяемой памяти.

Эта директива устарела начиная с версии 1.5.7. Вместо неё следует использовать аналогичную директиву sticky с изменённым синтаксисом:

sticky cookie имя [ expires= время ] [ domain= домен ] [ path= путь ];

Встроенные переменные

Модуль ngx_http_upstream_module поддерживает следующие встроенные переменные:

Источник

Nginx и https. Получаем класс А+

Недавно вспомнилось мне, что есть такой сервис — StartSsl, который совершенно бесплатно раздаёт trusted сертификаты владельцам доменов для личного использования. Да и выходные попались свободные. В общем сейчас напишу, как в nginx настроить HTTPS, чтобы при проверке в SSL Labs получить рейтинг А+ и обезопасить себя от последних багов с помощью выпиливания SSL.

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

Вот что у меня получилось:

В первой секции всё вроде понятно, любой вход по http с любым URI редиректит с этим-же URI в схему https.

Начнём разбор секции server для https. Директивой listen 443 ssl spdy; сразу включаем spdy. Вот на картинке разница:

Следущим шагом включаем ssl_stapling on; — позволяем серверу прикреплять OCSP-ответы, тем самым уменьшая время загрузки страниц у пользователей. Цепочка сертификатов (доменный — промежуточный центр авторизации — корневой центр авторизации) может содержать 3-4 уровня. И на каждый уровень браузер должен устанавливать соединение и получать сертификат. Можно отправить все сертификаты (включая промежуточный: именно за этим была настройка TCP-окон отправки, чтобы цепочка сертификатов гарантированно поместилась в в одну пересылку пакетов) разом, тогда браузер проверит всю цепочку локально, а запросит только корневой (который в большинстве случаев уже находится на клиенте). Для работы этой функции обязательно описать resolver — у меня поднят свой собственный DNS сервер, поэтому в качестве значения указан 127.0.0.1, Вы можете указать 8.8.8.8, но многие в последнее время на него ругаются. Что такое ssl on; я думаю нет смысла рассказывать.

Далее директивами ssl_certificate и ssl_certificate_key указываем пути к полученным через StartSsl сертификатам. У вас уже есть 3 файла: domain.ru.key, domain.ru.crt и sub.class1.server.ca.pem. Копируем ключи в ( моём случае ) /etc/pki/nginx.

Не забываем, что pem файл для nginx должен быть смержен с сертификатом CA ( Должно получиться из 3х — 2 файла. ):

Теперь о ssl_dhparam /etc/pki/nginx/dhparam.pem; — это нужно, чтобы у нас заработал Forward Secrecy. Прямая секретность означает, что если третья сторона узнает какой-либо сеансовый ключ, то она сможет получить лишь доступ к данным, защищенным лишь этим ключом. Для сохранения совершенной прямой секретности ключ, используемый для шифрования передаваемых данных, не должен использоваться для получения каких-либо дополнительных ключей. Также, если ключ, используемый для шифрования передаваемых данных, был получен (derived) на базе какого-то еще ключевого материала, этот материал не должен использоваться для получения каких-либо других ключей.

Сгенерировать ключ можно так:

Далее несложные настройки ssl_session_timeout 24h; и ssl_session_cache shared:SSL:2m;, которые не требуют особенных описаний — срок истечения сессии и размер памяти, выделяемой для хранения кеша — у меня бложик маленький, поэтому 2 Мб вполне достаточно.

Дальше — важные параметы: ssl_protocols TLSv1 TLSv1.1 TLSv1.2; и ssl_ciphers kEECDH+AES128:kEECDH:kEDH:-3DES:kRSA+AES128:kEDH+3DES:DES-CBC3-SHA:!RC4:!aNULL:!eNULL:!MD5:!EXPORT:!LOW:!SEED:!CAMELLIA:!IDEA:!PSK:!SRP:!SSLv2; — тут мы указываем, что мы желаем только TLS и второй строкой выжигаем калёным железом все SSL. В свете последних фейлов с SSL — очень актуально, что и Вам советую. Ну и директивой ssl_prefer_server_ciphers on; принуждаем nginx это всё строго соблюдать.

Директива add_header Strict-Transport-Security «max-age=31536000;»; указывает браузерам сколько они должны помнить данные требования безопасности для моего домена. В данном случае — 1 год. Кстати, если директиву написать вот так: add_header Strict-Transport-Security «max-age=31536000; includeSubDomains; preload»;, то данные условия будут применимы ко всем доменам третьего и выше уровня вашего домена. Тут будте осторожны! Я изначально описал именно так, но так, как StartSsl выдаёт сертификаты на ограниченное количество поддоменов, я наткнулся на невозможность даже попасть на свои поддомены, которые обслуживают разнообразные админки, работали только те, на которые были выписаны trusted сертификаты. Поэтому я для себя выбрал первый вариант.

Далее — add_header Content-Security-Policy-Report-Only «default-src https:; script-src https: ‘unsafe-eval’ ‘unsafe-inline’; style-src https: ‘unsafe-inline’; img-src https: data:; font-src https: data:; report-uri /csp-report»; — я толком глубоко ещё не изучил свойства данного заголовка. Content Security Policy (CSP) — новый стандарт, определяющий HTTP-заголовки Content-Security-Policy и Content-Security-Policy-Report-Only, которые сообщают браузеру белый список хостов, с которых он может загружать различные ресурсы.

Временно я взял данную строку из статьи Яндекса про применение у них CSP, почитать подробно можно тут: http://www.html5rocks.com/en/tutorials/security/content-security-policy/.

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

Источник