One place for hosting & domains

      Server

      Настройка Nginx для использования в качестве веб-сервера и обратного прокси-сервера для Apache в One Ubuntu 18.04 Server


      Автор выбрал фонд Electronic Frontier Foundation для получения пожертвований в рамках программы Write for DOnations.

      Введение

      Apache и Nginx — два популярных веб-сервера с открытым исходным кодом, часто используемые с PHP. Одновременный запуск обоих серверов на одной виртуальной машине может быть полезным в ситуации с хостингом нескольких сайтов с разными требованиями. Обычно для запуска двух веб-серверов на одной системе используются разные IP-адреса или разные номера портов.

      Серверы, имеющие адреса IPv4 и IPv6, можно настроить для обслуживания сайтов Apache через один протокол и сайтов Nginx через другой протокол, однако это не самый практичный вариант, поскольку еще не все провайдеры поддерживают протокол IPv6. Другое решение заключается в использовании разных номеров портов (напрмер, 81 или 8080) для второго веб-серверна, однако публикация URL-адресов с номерами портов (в формате http://example.com:81) не всегда является разумным или идеальным решением.

      В этом руководстве вы настроите Nginx как веб-сервер и обратный прокси-сервер для Apache — все на одном сервере.

      В зависимости от веб-приложения для обеспечения осведомленности Apache о присутствии обратного прокси-сервера могут потребоваться изменения кода, особенно если настроены сайты SSL. Чтобы избежать этого, нужно установить модуль Apache под названием mod_rpaf, который перезаписывает определенные переменные среды так, что все выглядит, как если бы Apache напрямую обрабатывал запросы веб-клиентов.

      Мы разместим четыре доменных имени на одном сервере. Два из них будут обслуживаться Nginx: example.com (виртуальный хост по умолчанию) и sample.org. Остальные два, foobar.net и test.io, будут обслуживаться Apache. Также мы настроим Apache для обслуживания приложений PHP с использованием PHP-FPM, что обеспечивает более высокую производительность по сравнению с mod_php.

      Предварительные требования

      Для прохождения данного обучающего руководства вам потребуется следующее:

      • Новый сервер Ubuntu 18.04, настроенный в соответствии с указаниями документа «Начальная настройка сервера с Ubuntu 18.04», с пользователем sudo non-root и брандмауэром.
      • Четыре полностью квалифицированных доменных имени, настроенных на указание на IP-адрес вашего сервера. В разделе «Шаг 3. Настройка имени хоста с DigitalOcean» показано, как можно это сделать. Если вы размещаете DNS ваших доменов в других местах, нужно создать соответствующие записи уровня A именно там.

      Шаг 1 — Установка Apache и PHP-FPM

      Начнем с установки Apache и PHP-FPM.

      Помимо Apache и PHP-FPM мы также установим модуль PHP FastCGI Apache, libapache2-mod-fastcgi, для поддержки веб-приложений FastCGI.

      Вначале обновите свой список пакетов и убедитесь, что у вас установлены последние версии пакетов.

      Затем выполните установку пакетов Apache и PHP-FPM:

      • sudo apt install apache2 php-fpm

      Модуль FastCGI Apache недоступен в хранилище Ubuntu, и поэтому вам следует загрузить его с kernel.org и установить с помощью команды dpkg.

      • wget https://mirrors.edge.kernel.org/ubuntu/pool/multiverse/liba/libapache-mod-fastcgi/libapache2-mod-fastcgi_2.4.7~0910052141-1.2_amd64.deb
      • sudo dpkg -i libapache2-mod-fastcgi_2.4.7~0910052141-1.2_amd64.deb

      Далее изменим конфигурацию Apache по умолчанию для использования PHP-FPM.

      Шаг 2 — Настройка Apache и PHP-FPM

      На этом шаге мы изменим номер порта Apache на 8080 и настроим его для работы с PHP-FPM с использованием модуля mod_fastcgi. Переименуйте файл конфигурации Apache ports.conf:

      • sudo mv /etc/apache2/ports.conf /etc/apache2/ports.conf.default

      Создайте новый файл ports.conf и установите в нем порт 8080:

      • echo "Listen 8080" | sudo tee /etc/apache2/ports.conf

      Примечание. Веб-серверы обычно настраиваются на прослушивание адреса 127.0.0.1:8080 при настройке в качестве обратного прокси-сервера, однако при этом для переменной среды PHP SERVER_ADDR будет установлено значение циклического IP-адреса, а не публичного IP-адреса сервера. Наша цель — настроить сервер Apache так, чтобы сайты не видели обратный прокси-сервер перед ним. Поэтому мы настроим его для прослушивания порта 8080 на всех IP-адресах.

      Далее мы создадим файл виртуального хоста для Apache. Директива <VirtualHost> этого файла будет установлена для обслуживания только сайтов на порту 8080.

      Отключите виртуальный хост по умолчанию:

      • sudo a2dissite 000-default

      Затем создайте новый файл виртуального хоста, используя существующий сайт по умолчанию:

      • sudo cp /etc/apache2/sites-available/000-default.conf /etc/apache2/sites-available/001-default.conf

      Откройте новый файл конфигурации:

      • sudo nano /etc/apache2/sites-available/001-default.conf

      Измените порт прослушивания на 8080:

      /etc/apache2/sites-available/000-default.conf

      <VirtualHost *:8080>
          ServerAdmin webmaster@localhost
          DocumentRoot /var/www/html
          ErrorLog ${APACHE_LOG_DIR}/error.log
          CustomLog ${APACHE_LOG_DIR}/access.log combined
      </VirtualHost>
      

      Сохраните файл и активируйте новый файл конфигурации:

      • sudo a2ensite 001-default

      Затем перезагрузите Apache:

      • sudo systemctl reload apache2

      Убедитесь, что Apache прослушивает порт 8080:

      Результат должен выглядеть как в следующем примере, где apache2 прослушивает порт 8080:

      Output

      Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1086/sshd tcp6 0 0 :::8080 :::* LISTEN 4678/apache2 tcp6 0 0 :::22 :::* LISTEN 1086/sshd

      Убедившись, что Apache прослушивает правильный порт, вы можете настроить поддержку PHP и FastCGI.

      Шаг 3 — Настройка Apache для использования mod_fastcgi

      По умолчанию Apache обслуживает страницы PHP с помощью модуля mod_php, однако для работы с PHP-FPM ему требуется дополнительная настройка.

      Примечание. Если вы пытаетесь использовать это обучающее руководство в существующей системе LAMP с mod_php, вначале выполните отключение с помощью команды sudo a2dismod php7.2.

      Мы добавим блок конфигурации для mod_fastcgi, зависящий от mod_action. По умолчанию mod_action отключен, и предварительно его нужно включить:

      Переименуйте существующий файл конфигурации FastCGI:

      • sudo mv /etc/apache2/mods-enabled/fastcgi.conf /etc/apache2/mods-enabled/fastcgi.conf.default

      Создайте новый файл конфигурации:

      • sudo nano /etc/apache2/mods-enabled/fastcgi.conf

      Добавьте в файл следующие директивы для передачи запросов файлов .php в сокет PHP-FPM UNIX:

      /etc/apache2/mods-enabled/fastcgi.conf

      <IfModule mod_fastcgi.c>
        AddHandler fastcgi-script .fcgi
        FastCgiIpcDir /var/lib/apache2/fastcgi
        AddType application/x-httpd-fastphp .php
        Action application/x-httpd-fastphp /php-fcgi
        Alias /php-fcgi /usr/lib/cgi-bin/php-fcgi
        FastCgiExternalServer /usr/lib/cgi-bin/php-fcgi -socket /run/php/php7.2-fpm.sock -pass-header Authorization
        <Directory /usr/lib/cgi-bin>
          Require all granted
        </Directory>
      </IfModule>
      

      Сохраните изменения и проведите тест конфигурации:

      Если отображается Syntax OK, перезагрузите Apache:

      • sudo systemctl reload apache2

      Если отображается предупреждение Could not reliably determine the server's fully qualified domain name, using 127.0.1.1. Set the 'ServerName' directive globally to suppress this message., его можно игнорировать. Мы настроим имена серверов позднее.

      Теперь убедимся, что мы можем обслуживать PHP из Apache.

      Шаг 4 — Проверка функционала PHP

      Чтобы убедиться, что PHP работает, мы создадим файл phpinfo() и получим к нему доступ к через браузер.

      Создайте файл /var/www/html/info.php, содержащий вызов функции phpinfo:

      • echo "<?php phpinfo(); ?>" | sudo tee /var/www/html/info.php

      Чтобы просмотреть файл в браузере, откройте адрес http://your_server_ip:8080/info.php. На странице появится перечень параметров конфигурации, используемых PHP. Результат будет выглядеть примерно так:

      phpinfo Server API

      phpinfo PHP Variables

      Убедитесь, что в Server API вверху страницы указано значение FPM/FastCGI. Раздел «Переменные PHP» в нижней трети страницы покажет, что параметр SERVER_SOFTWARE имеет значение Apache на Ubuntu. Это подтверждает, что модуль mod_fastcgi активен, и что Apache использует PHP-FPM для обработки файлов PHP.

      Шаг 5 — Создание виртуальных хостов для Apache

      Давайте создадим файлы виртуальных хостов Apache для доменов foobar.net и test.io. Для этого мы вначале создадим корневые каталоги документов document root для обоих сайтов и разместим в эти каталоги файлы, чтобы можно было легко протестировать нашу конфигурацию.

      Вначале создайте корневые каталоги документа:

      • sudo mkdir -v /var/www/foobar.net /var/www/test.io

      Затем создайте файл index для каждого сайта:

      • echo "<h1 style='color: green;'>Foo Bar</h1>" | sudo tee /var/www/foobar.net/index.html
      • echo "<h1 style='color: red;'>Test IO</h1>" | sudo tee /var/www/test.io/index.html

      Далее создайте файл phpinfo() для каждого сайта, чтобы мы могли протестировать правильность конфигурации PHP.

      • echo "<?php phpinfo(); ?>" | sudo tee /var/www/foobar.net/info.php
      • echo "<?php phpinfo(); ?>" | sudo tee /var/www/test.io/info.php

      Теперь создайте файл виртуального хоста для домена foobar.net:

      • sudo nano /etc/apache2/sites-available/foobar.net.conf

      Добавьте в файл следующий код для определения хоста:

      /etc/apache2/sites-available/foobar.net.conf

          <VirtualHost *:8080>
              ServerName foobar.net
              ServerAlias www.foobar.net
              DocumentRoot /var/www/foobar.net
              <Directory /var/www/foobar.net>
                  AllowOverride All
              </Directory>
          </VirtualHost>
      

      Строка AllowOverride All активирует поддержку .htaccess.

      Это только базовые указания. Полное руководство по по настройке виртуальных хостов в Apache можно найти в документе «Настройка виртуальных хостов Apache в Ubuntu 16.04».

      Сохраните и закройте файл. Затем создайте аналогичную конфигурацию для test.io. Сначала создайте файл:

      • sudo nano /etc/apache2/sites-available/test.io.conf

      Затем добавьте в файл конфигурацию:

      /etc/apache2/sites-available/test.io.conf

          <VirtualHost *:8080>
              ServerName test.io
              ServerAlias www.test.io
              DocumentRoot /var/www/test.io
              <Directory /var/www/test.io>
                  AllowOverride All
              </Directory>
          </VirtualHost>
      

      Сохраните файл и выйдите из редактора.

      Теперь, когда вы создали оба виртуальных хоста Apache, разрешите сайтам использовать команду a2ensite. Это создаст символическую связь с файлом виртуального хоста в каталоге sites-enabled:

      • sudo a2ensite foobar.net
      • sudo a2ensite test.io

      Снова проверьте Apache на наличие ошибок конфигурации:

      При отсутствии ошибок появится сообщение Syntax OK. Если появится любое другое сообщение, проверьте конфигурацию и повторите попытку.

      Когда в конфигурации не останется ошибок, перезагрузите Apache, чтобы применить изменения:

      • sudo systemctl reload apache2

      Чтобы подтвердить работу сайтов, откройте в браузере адреса http://foobar.net:8080 и http://test.io:8080 и убедитесь, что для каждого из сайтов отображается файл index.html.

      Вы увидите следующие результаты:

      страница индекса foobar.net

      страница индекса test.io

      Также попробуйте получить доступ к файлам info.php files каждого сайта, чтобы убедиться в работе PHP. Откройте адреса http://foobar.net:8080/info.php и http://test.io:8080/info.php в браузере.

      Для каждого сайта вы увидите такой же перечень настроек PHP, что и на шаге 4.

      Мы разместили два сайта на сервере Apache на порту 8080. Теперь давайте настроим Nginx.

      Шаг 6 — Установка и настройка Nginx

      На этом шаге мы выполним установку Nginx и настроим домены example.com и sample.org как виртуальные хосты Nginx. Полное руководство по настройке виртуальных хостов в Nginx можно найти в документе «Настройка блоков сервера Nginx (виртуальных хостов) в Ubuntu 18.04».

      Установите Nginx с помощью диспетчера пакетов:

      Затем удалите соединение symlink по умолчанию виртуального хоста, поскольку мы больше не будем его использовать:

      • sudo rm /etc/nginx/sites-enabled/default

      Позднее мы создадим собственный сайт по умолчанию (example.com).

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

      • sudo mkdir -v /usr/share/nginx/example.com /usr/share/nginx/sample.org

      Мы будем хранить сайты Nginx в каталоге /usr/share/nginx, где Nginx требуется хранить их по умолчанию. Вы можете поместить их в каталог /var/www/html с сайтами Apache, но разделение поможет привязать сайты к Nginx.

      Как и в случае с виртуальными хостами Apache, после завершения настройки следует создать файлы index и phpinfo() для тестирования:

      • echo "<h1 style='color: green;'>Example.com</h1>" | sudo tee /usr/share/nginx/example.com/index.html
      • echo "<h1 style='color: red;'>Sample.org</h1>" | sudo tee /usr/share/nginx/sample.org/index.html
      • echo "<?php phpinfo(); ?>" | sudo tee /usr/share/nginx/example.com/info.php
      • echo "<?php phpinfo(); ?>" | sudo tee /usr/share/nginx/sample.org/info.php

      Теперь создайте файл виртуального хоста для домена example.com:

      • sudo nano /etc/nginx/sites-available/example.com

      Nginx вызывает области серверных блоков файла конфигурации server {. . .}. Создайте серверный блок для главного виртуального хоста, example.com. Директива default_server configuration делает его виртуальным хостом по умолчанию для обработки запросов HTTP, не соответствующих никакому другому виртуальному хосту.

      /etc/nginx/sites-available/example.com

      server {
          listen 80 default_server;
      
          root /usr/share/nginx/example.com;
          index index.php index.html index.htm;
      
          server_name example.com www.example.com;
          location / {
              try_files $uri $uri/ /index.php;
          }
      
          location ~ .php$ {
              fastcgi_pass unix:/run/php/php7.2-fpm.sock;
              include snippets/fastcgi-php.conf;
          }
      }
      

      Сохраните и закройте файл. Создайте файл виртуального хоста для второго домена Nginx, sample.org:

      • sudo nano etc/nginx/sites-available/sample.org

      Добавьте в файл следующее:

      /etc/nginx/sites-available/sample.org

      server {
          root /usr/share/nginx/sample.org;
          index index.php index.html index.htm;
      
          server_name sample.org www.sample.org;
          location / {
              try_files $uri $uri/ /index.php;
          }
      
          location ~ .php$ {
              fastcgi_pass unix:/run/php/php7.2-fpm.sock;
              include snippets/fastcgi-php.conf;
          }
      }
      

      Сохраните и закройте файл.

      Затем активируйте оба сайта, создав символические ссылки на каталог sites-enabled:

      • sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/example.com
      • sudo ln -s /etc/nginx/sites-available/sample.org /etc/nginx/sites-enabled/sample.org

      Протестируйте конфигурацию Nginx и убедитесь в отсутствии проблем с конфигурацией:

      При обнаружении ошибок перезагрузите Nginx:

      • sudo systemctl reload nginx

      Получите доступ к файлу phpinfo() виртуальных хостов Nginx через браузер по адресам http://example.com/info.php и http://sample.org/info.php. Снова изучите разделы PHP Variables.

      Переменные Nginx PHP Variables

      [SERVER_SOFTWARE] должен иметь значение nginx, указывая, что файлы обслуживались Nginx напрямую. [DOCUMENT_ROOT] должен указывать на каталог, ранее созданный на этом шаге для каждого из сайтов Nginx.

      К настоящему моменту мы установили Nginx и создали два виртуальных хоста. Далее мы настроим Nginx на запросы прокси-сервера, предназначенные для доменов Apache.

      Шаг 7 — Настройка Nginx для виртуальных хостов Apache

      Создадим дополнительный виртуальный хост Nginx с несколькими именами доменов в директивах server_name. Запросы этих доменных имен будут перенаправляться через прокси-сервер в Apache.

      Создайте новый файл виртуального хоста Nginx для перенаправления запросов в Apache:

      • sudo nano /etc/nginx/sites-available/apache

      Добавьте следующий блок кода, указывающий имена доменов виртуального хоста Apache и перенаправляющий их запросы в Apache. Обязательно используйте публичный IP-адрес в proxy_pass:

      /etc/nginx/sites-available/apache

      server {
          listen 80;
          server_name foobar.net www.foobar.net test.io www.test.io;
      
          location / {
              proxy_pass http://your_server_ip:8080;
              proxy_set_header Host $host;
              proxy_set_header X-Real-IP $remote_addr;
              proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
              proxy_set_header X-Forwarded-Proto $scheme;
          }
      }
      

      Сохраните файл и активируйте новый файл виртуального хоста, создав символическую ссылку:

      • sudo ln -s /etc/nginx/sites-available/apache /etc/nginx/sites-enabled/apache

      Протестируйте конфигурацию и убедитесь в отсутствии ошибок:

      Если ошибок нет, перезагрузите Nginx:

      • sudo systemctl reload nginx

      Откройте в браузере URL-адрес http://foobar.net/info.php. Перейдите в раздел PHP Variables и проверьте отображаемые значения.

      phpinfo для Apache через Nginx

      Переменные SERVER_SOFTWARE и DOCUMENT_ROOT подтверждают, что запрос был обработан Apache. Переменные HTTP_X_REAL_IP и HTTP_X_FORWARDED_FOR были добавлены Nginx и должны показывать публичный IP-адрес компьютера, используемого для доступа к URL-адресу.

      Мы успешно настроили Nginx для перенаправления запросов определенных доменов в Apache через прокси-сервер. Теперь настроим Apache для установки переменной REMOTE_ADDR, как если бы эти запросы обрабатывались напрямую.

      Шаг 8 — Установка и настройка mod_rpaf

      На этом шаге вы установите модуль Apache под названием mod_rpaf, который перезаписывает значения REMOTE_ADDR, HTTPS и HTTP_PORT на базе значений, предоставленных обратным прокси-сервером. Без этого модуля для некоторых приложений PHP потребуется изменение кода для бесшовной работы из-за прокси-сервера. Этот модуль представлен в хранилище Ubuntu как libapache2-mod-rpaf, однако он устарел и не поддерживает некоторые директивы конфигурации. Поэтому мы установим его из источника.

      Установите пакеты, необходимые для построения модуля:

      • sudo apt install unzip build-essential apache2-dev

      Загрузите последний стабильный выпуск из GitHub:

      • wget https://github.com/gnif/mod_rpaf/archive/stable.zip

      Выполните извлечение загруженного файла:

      Перейдите в новый каталог, содержащий файлы:

      Скомпилируйте и установите модуль:

      Затем создайте в каталоге mods-available файл, который будет загружать модуль rpaf,

      • sudo nano /etc/apache2/mods-available/rpaf.load

      Добавьте в файл следующий код для загрузки модуля:

      /etc/apache2/mods-available/rpaf.load

      LoadModule rpaf_module /usr/lib/apache2/modules/mod_rpaf.so
      

      Сохраните файл и выйдите из редактора.

      Создайте в этом каталоге другой файл с именем rpaf.conf, который будет содержать директивы конфигурации для mod_rpaf:

      • sudo nano /etc/apache2/mods-available/rpaf.conf

      Добавьте следующий блок кода для настройки mod_rpaf и обязательно укажите IP-адрес своего сервера:

      /etc/apache2/mods-available/rpaf.conf

          <IfModule mod_rpaf.c>
              RPAF_Enable             On
              RPAF_Header             X-Real-Ip
              RPAF_ProxyIPs           your_server_ip
              RPAF_SetHostName        On
              RPAF_SetHTTPS           On
              RPAF_SetPort            On
          </IfModule>
      

      Здесь приведено краткое описание каждой директивы. Дополнительную информацию можно найти в файле README по модулю mod_rpaf.

      • RPAF_Header — заголовок, используемый для реального IP-адреса клиента.
      • RPAF_ProxyIPs — IP-адрес прокси-сервера для корректировки запросов HTTP.
      • RPAF_SetHostName — обновляет имя vhost так, чтобы работали параметры ServerName и ServerAlias.
      • RPAF_SetHTTPS — задает переменную среды HTTPS на основе значения, содержащегося в X-Forwarded-Proto.
      • RPAF_SetPort — задает переменную среды SERVER_PORT. Полезна для использования, когда сервер Apache находится за прокси-сервером SSL.

      Сохраните rpaf.conf и активируйте модуль:

      При этом создаются символические ссылки файлов rpaf.load и rpaf.conf в каталоге mods-enabled. Теперь протестируем конфигурацию:

      Если ошибок нет, перезагрузите Apache:

      • sudo systemctl reload apache2

      Откройте в браузере страницы phpinfo() по адресам http://foobar.net/info.php и http://test.io/info.php и проверьте раздел PHP Variables. Переменная REMOTE_ADDR также будет использоваться для публичного IP-адрса вашего локального компьютера.

      Теперь настроим шифрование TLS/SSL для каждого сайта.

      Шаг 9 — Настройка сайтов HTTPS с Let’s Encrypt (опционально)

      На этом шаге мы настроим сертификаты TLS/SSL для обоих доменов, размещенных в Apache. Мы получим сертификаты посредством Let’s Encrypt. Nginx поддерживает конечные узлы SSL, и поэтому мы можем настроить SSL без изменения файлов конфигурации Apache. Модуль mod_rpaf обеспечивает установку в Apache переменных среды, необходимых для бесшовной работы приложений за обратным прокси-сервером SSL.

      Вначале мы разделим блоки server {...} обоих доменов так, что у каждого из них будет собственный сертификат SSL. Откройте в своем редакторе файл /etc/nginx/sites-available/apache:

      • sudo nano /etc/nginx/sites-available/apache

      Измените файл, чтобы он выглядел следующим образом, сайты foobar.net и test.io должны находиться в собственных server блоках:

      /etc/nginx/sites-available/apache

          server {
              listen 80;
              server_name foobar.net www.foobar.net;
      
              location / {
                  proxy_pass http://your_server_ip:8080;
                  proxy_set_header Host $host;
                  proxy_set_header X-Real-IP $remote_addr;
                  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                  proxy_set_header X-Forwarded-Proto $scheme;
              }
          }
          server {
              listen 80;
              server_name test.io www.test.io;
      
              location / {
                  proxy_pass http://your_server_ip:8080;
                  proxy_set_header Host $host;
                  proxy_set_header X-Real-IP $remote_addr;
                  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                  proxy_set_header X-Forwarded-Proto $scheme;
              }
          }
      

      Мы используем Certbot для генерирования сертификатов TLS/SSL. Плагин Nginx изменит конфигурацию Nginx и перезагрузит ее, когда это потребуется.

      Прежде всего, добавьте официальное хранилище Certbot:

      • sudo add-apt-repository ppa:certbot/certbot

      Нажмите ENTER в диалоге, чтобы подтвердить добавление нового хранилища. Обновите список пакетов, чтобы получить данные пакета нового хранилища:

      Установите пакет Certbot’s Nginx с apt:

      • sudo apt install python-certbot-nginx

      После установки используйте команду certbot для генерирования сертификатов для foobar.net и www.foobar.net:

      • sudo certbot --nginx -d foobar.net -d www.foobar.net

      Эта команда указывает Certbot, что нужно использовать плагин nginx, а параметр -d задает имена, для которых должен действовать сертификат.

      Если это первый запуск certbot, вам будет предложено указать адрес эл. почты и принять условия обслуживания. После этого certbot свяжется с сервером Let’s Encrypt и отправит запрос с целью подтвердить, что вы контролируете домен, для которого запрашиваете сертификат.

      Далее Certbot запросит желаемый вариант настройки HTTPS:

      Output

      Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access. ------------------------------------------------------------------------------- 1: No redirect - Make no further changes to the webserver configuration. 2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for new sites, or if you're confident your site works on HTTPS. You can undo this change by editing your web server's configuration. ------------------------------------------------------------------------------- Select the appropriate number [1-2] then [enter] (press 'c' to cancel):

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

      Теперь выполните команду для второго домена:

      • sudo certbot --nginx -d test.io -d www.test.io

      Откройте один из доменов Apache в браузере с помощью префикса https://; откройте https://foobar.net/info.php, и вы увидите следующее:

      phpinfo ssl

      Посмотрите раздел PHP Variables. Для переменной SERVER_PORT задано значение 443 и протокол HTTPS включен, как если бы осуществлялся прямой доступ к Apache через HTTPS. При такой настройке переменных не нужно специально настраивать приложения PHP для работы за обратным прокси-сервером.

      Теперь отключим прямой доступ к Apache.

      Шаг 10 — Блокировка прямого доступа к Apache (опционально)

      Поскольку Apache прослушивает порт 8080 на публичном IP-адресе, он доступен кому угодно. Его можно заблокировать с помощью следующей команды IPtables в наборе правил брандмауэра.

      • sudo iptables -I INPUT -p tcp --dport 8080 ! -s your_server_ip -j REJECT --reject-with tcp-reset

      Обязательно используйте IP-адрес своего сервера вместо выделенного красным адреса в примере. Когда ваш брандмауэр заблокирует порт 8080, убедитесь в недоступности Apache через этот порт. Для этого откройте браузер и попробуйте получить доступ к любому из доменных имен Apache через порт 8080. Например: http://example.com:8080

      Браузер должен вывести сообщение об ошибке Unable to connect (Не удается подключиться) или Webpage is not available (Страница недоступна). Если используется опция IPtables tcp-reset, сторонний наблюдатель не увидит разницы между портом 8080 и портом, где отсутствует какое-либо обслуживание.

      Примечание. По умолчанию правила IPtables теряют силу после перезагрузки системы. Существует несколько способов сохранения правил IPtables, но проще всего использовать параметр iptables-persistent в хранилище Ubuntu. Прочитайте эту статью, чтобы узнать больше о настройке IPTables.

      Теперь настроим Nginx для обслуживания статических файлов для сайтов Apache.

      Шаг 11 — Обслуживание статических файлов с помощью Nginx (необязательно)

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

      Откройте в своем редакторе файл /etc/nginx/sites-available/apache:

      • sudo nano /etc/nginx/sites-available/apache

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

      Если вы решили не использовать сертификаты SSL и TLS, измените свой файл, чтобы он выглядел следующим образом:

      /etc/nginx/sites-available/apache

      server {
          listen 80;
          server_name test.io www.test.io;
          root /var/www/test.io;
          index index.php index.htm index.html;
      
          location / {
              try_files $uri $uri/ /index.php;
          }
      
          location ~ .php$ {
              proxy_pass http://your_server_ip:8080;
              proxy_set_header Host $host;
              proxy_set_header X-Real-IP $remote_addr;
              proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
              proxy_set_header X-Forwarded-Proto $scheme;
          }
      
          location ~ /.ht {
              deny all;
          }
      }
      
      server {
          listen 80;
          server_name foobar.net www.foobar.net;
          root /var/www/foobar.net;
          index index.php index.htm index.html;
      
          location / {
              try_files $uri $uri/ /index.php;
          }
      
          location ~ .php$ {
              proxy_pass http://your_ip_address:8080;
              proxy_set_header Host $host;
              proxy_set_header X-Real-IP $remote_addr;
              proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
              proxy_set_header X-Forwarded-Proto $scheme;
          }
      
          location ~ /.ht {
              deny all;
          }
      }
      

      Если вы также хотите обеспечить доступность HTTPS, используйте следующую конфигурацию:

      /etc/nginx/sites-available/apache

      server {
          listen 80;
          server_name test.io www.test.io;
          root /var/www/test.io;
          index index.php index.htm index.html;
      
          location / {
              try_files $uri $uri/ /index.php;
          }
      
          location ~ .php$ {
              proxy_pass http://your_server_ip:8080;
              proxy_set_header Host $host;
              proxy_set_header X-Real-IP $remote_addr;
              proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
              proxy_set_header X-Forwarded-Proto $scheme;
          }
      
          location ~ /.ht {
              deny all;
          }
      
          listen 443 ssl;
          ssl_certificate /etc/letsencrypt/live/test.io/fullchain.pem;
          ssl_certificate_key /etc/letsencrypt/live/test.io/privkey.pem;
          include /etc/letsencrypt/options-ssl-nginx.conf;
          ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
      }
      
      server {
          listen 80;
          server_name foobar.net www.foobar.net;
          root /var/www/foobar.net;
          index index.php index.htm index.html;
      
          location / {
              try_files $uri $uri/ /index.php;
          }
      
          location ~ .php$ {
              proxy_pass http://your_ip_address:8080;
              proxy_set_header Host $host;
              proxy_set_header X-Real-IP $remote_addr;
              proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
              proxy_set_header X-Forwarded-Proto $scheme;
          }
      
          location ~ /.ht {
              deny all;
          }
      
          listen 443 ssl;
          ssl_certificate /etc/letsencrypt/live/foobar.net/fullchain.pem;
          ssl_certificate_key /etc/letsencrypt/live/foobar.net/privkey.pem;
          include /etc/letsencrypt/options-ssl-nginx.conf;
          ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
      }
      

      Директива try_files указывает Nginx искать файлы в корне документа document root и выводить их напрямую. Если файл имеет расширение .php, запрос перенаправляется в Apache. Даже если файл отсутствует в document root, запрос перенаправляется в Apache, чтобы функции приложения (например, постоянные ссылки) работали без проблем.

      Предупреждение. Директива location ~ /.ht очень важна, поскольку она не дает Nginx выводить содержимое файлов конфигурации Apache с важными данными, таких как .htaccess и .htpasswd.

      Сохраните файл и проведите тест конфигурации:

      Если тест завершается успешно, перезагрузите Nginx:

      • sudo service nginx reload

      Чтобы убедиться, что все работает, вы можете просмотреть файлы журнала Apache в каталоге /var/log/apache2 и посмотреть запросы GET для файлов info.php сайтов test.io и foobar.net. Используйте команду tail для просмотра последних нескольких строк файла и параметр -f для просмотра изменений файла:

      • sudo tail -f /var/log/apache2/other_vhosts_access.log

      Теперь откройте в браузере http://test.io/info.php и посмотрите на результаты вывода журнала. Вы увидите ответ Apache:

      Output

      test.io:80 your_server_ip - - [01/Jul/2016:18:18:34 -0400] "GET /info.php HTTP/1.0" 200 20414 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.111 Safari/537.36"

      Затем откройте страницы index.html каждого сайта, и вы не увидите записи журнала Apache. Их обслуживает Nginx.

      Завершив изучение файла журнала, нажмите CTRL+C, чтобы остановить отслеживание.

      При такой настройке Apache не сможет ограничивать доступ к статическим файлам. Контроль доступа к статическим файлам должен быть настроен в файле apache виртуального хоста Nginx, однако это не входит в содержание настоящего обучающего руководства.

      Заключение

      Вы настроили один сервер Ubuntu, где Nginx обслуживает сайты example.com и sample.org, а Apache обслуживает сайты foobar.net и test.io. Хотя Nginx выступает в качестве обратного прокси-сервера Apache, прокси-служба Nginx невидима, и подключение к доменам Apache выглядит так, как если бы оно напрямую обслуживалось Apache. Вы можете использовать этот метод для вывода защищенных и статичных сайтов.



      Source link

      Check This Overlooked Setting to Troubleshoot ‘Strange’ Microsoft SQL Server Performance Issues


      As a SQL DBA or a system admin of highly transactional, performance demanding SQL databases, you may often find yourself perplexed by “strange” performance issues reported by your user base. By strange, I mean any issue where you are out of ideas, having exhausted standard troubleshooting tactics and when spending money on all-flash storage is just not in the budget.

      Working under pressure from customers or clients to resolve performance issues is not easy, especially when C-Level, sales and end users are breathing down your neck to solve the problem immediately. Contrary to popular belief from many end users, we all know that these types of issues are not resolved with a magic button or the flip of a switch.

      But what if there was a solution that came close?

      Let’s review the typical troubleshooting process, and an often-overlooked setting that may just be your new “magic button” for resolving unusual SQL server performance issues.

      Resolving SQL Server Performance Issues: The Typical Process

      Personally, I find troubleshooting SQL related performance issues very interesting. In my previous consulting gigs, I participated in many white boarding sessions and troubleshooting engagements as a highly paid last-resort option for many clients. When I dug into their troubleshooting process, I found a familiar set of events happening inside an IT department specific to SQL Server performance issues.

      Here are the typical steps:

      • Review monitoring tools for CPU, RAM, IO, Blocks and so on
      • Start a SQL Profiler to collect possible offending queries and get a live view of the slowness
      • Check underlying storage for latency per IO, and possible bottle necks
      • Check if anyone else is running any performance intensive processes during production hours
      • Find possible offending queries and stop them from executing
      • DBAs check their SQL indexes and other settings

      When nothing is found from the above process, the finger pointing starts. “It’s the query.” “No, it’s the index.” “It’s the storage.” “Nope. It’s the settings in your SQL server.” And so it goes.

      Sound familiar?

      An Often-Forgotten Setting to Improve SQL Server Performance

      Based on the typical troubleshooting process, IT either implements a solution to prevent identical issues from coming back or hope to fix the issue by adding all flash and other expensive resources. These solutions have their place and are all equally important to consider.

      There is, however, an often-forgotten setting that you should check first—the block allocation size of your NTFS partition in the Microsoft Windows Server.

      The block allocation setting of the NTFS partition is set at formatting time, which happens very early in the process and is often performed by a sysadmin building the VM or bare metal server well before Microsoft SQL is installed. In my experience, this setting is left as the default (4K) during the server build process and is never looked at again.

      Why is 4K a bad setting? A Microsoft SQL page is 8KB in size. With a 4K block, you are creating two IO operations for every page request. This is a big deal. The Microsoft recommended block size for SQL server is 64K. This way, the page is collected in one IO operation.

      In bench tests of highly transactional databases on 64K block allocation in the NTFS partition, I frequently observe improved database performance by as much as 50 percent or more. The more IO intensive your DB is, the more this setting helps. Assuming your SQL server’s drive layout is perfect, for many “strange performance” issues, this setting was the magic button. So, if you are experiencing unexplained performance issues, this simple formatting setting maybe just what you are looking for.

      A word of caution: We don’t want to confuse this NTFS block allocation with your underlying storage blocks. This storage should be set to the manufacturer’s recommended block size. For example, as of recently, Nimble storage bock allocation at 8k provided best results with medium and large database sizes. This could change depending on the storage vendor and other factors, so be sure to check this with your storage vendor prior to creating LUNs for SQL servers.

      How to Check the NTFS Block Allocation Setting

      Here is a simple way to check what block allocation is being used by your Window Server NTFS partition:

      Open the command prompt as administrator and run the following command replacing the C: drive with a drive letter of your database data files. Repeat this step for your drives containing the logs and TempDB files:

      • fsutil fsinfo ntfsinfo c:

      Look for the reading “Bytes Per Cluster.”  If it’s set to 4096, that is the undesirable 4K setting.

      The fix is easy but could be time consuming with large database sizes. If you have an AlwaysOn SQL cluster, this can be done with no downtime. If you don’t have an AlwaysOn MSSQL cluster, then a downtime window will be required. Or, perhaps it’s time to build an AlwaysOn SQL cluster and kill two birds with one stone.

      To address the issue, you will want to re-format the disks containing SQL data with 64K blocks.

      Concluding Thoughts

      If your NTFS block setting is at 4K right now, moving the DB files to 64K formatted disks will immediately improve performance. Don’t wait to check into this one.

      Explore INAP Cloud.

      LEARN MORE

      Rob Lerner


      READ MORE



      Source link

      How To Configure BIND as a Private Network DNS Server on Ubuntu 18.04


      Introdução

      Uma parte importante do gerenciamento da configuração e infraestrutura de servidores inclui a manutenção de maneira fácil de verificar as interfaces de rede e endereços IP por nome, através da configuração de um Sistema de Nome de Domínio (DNS). Ao usar os nomes de domínio totalmente qualificados (FQDNs), ao invés de endereços IP para especificar os endereços de rede, facilita-se a configuração de serviços e aplicativos e aumenta-se a capacidade de manutenção dos arquivos de configuração. Configurar seu próprio DNS para sua rede privada é uma ótima maneira de melhorar o gerenciamento dos seus servidores.

      Neste tutorial, veremos como configurar um servidor DNS interno usando o software de servidor de nomes BIND (BIND9) no Ubuntu 18.04, que pode ser usado pelos seus servidores para resolver nomes de host e endereços IP privados. Isso fornece uma maneira central de gerenciamento dos seus nomes de host e endereços IP privados internos, o que é indispensável quando seu ambiente se expande para mais de alguns poucos hosts.

      A versão CentOS deste tutorial pode ser encontrada aqui.

      Pré-requisitos

      Para completar este tutorial, você precisará das seguinte infraestrutura. Crie cada servidor no mesmo datacenter com o modo de rede privada habilitado:

      • Um servidor Ubuntu 18.04 para servir como o servidor DNS primário, o ns1
      • (Recomendado) Um segundo servidor Ubuntu 18.04 para servir como um servidor DNS secundário, o ns2
      • Servidores adicionais no mesmo datacenter que usarão seus servidores DNS

      Em cada um desses servidores, configure o acesso administrativo por um usuário sudo e um firewall seguindo nosso guia de configuração inicial do servidor Ubuntu 18.04.

      Se você não estiver familiarizado com os conceitos do DNS, é recomendável que você leia pelo menos as três primeiras partes da nossa Introdução ao gerenciamento do DNS.

      Exemplo de infraestrutura e objetivos

      Para os fins deste artigo, vamos assumir o seguinte:

      • Temos dois servidores que serão designados como nossos servidores de nome DNS. Vamos nos referir a eles como ns1 e ns2 neste guia.
      • Temos dois servidores de cliente adicionais que irão usar a infraestrutura DNS que criamos. Vamos chamá-los host1 e host2 neste guia. Você pode adicionar quantos quiser para sua infraestrutura.
      • Todos esses servidores existem no mesmo datacenter. Vamos assumir que este datacenter chama-se nyc3.
      • Todos esses servidores têm o modo de rede privada habilitado (e estão na sub-rede 10.128.0.0/16. É provável que você tenha que ajustar isso para seus servidores).
      • Todos os servidores estão conectados a um projeto executado em “example.com”. Como nosso sistema DNS será totalmente interno e privado, você não precisa comprar um nome de domínio. No entanto, usar um domínio que você possui pode ajudar a evitar conflitos com domínios de encaminhamento público.

      Com essas suposições, decidimos que é sensato usar um esquema de nomeação que usa “nyc3.example.com” para se referir à nossa sub-rede ou zona privada. Portanto, o Nome de domínio totalmente qualificado (FQDN) privado do host1 será host1.nyc3.example.com. Consulte a tabela a seguir com os detalhes relevantes:

      Host Função FQDN privado Endereço IP privado
      ns1 Servidor DNS primário ns1.nyc3.example.com 10.128.10.11
      ns2 Servidor DNS secundário n2.nyc3.example.com 10.128.20.12
      host1 Host genérico 1 host1.nyc3.example.com 10.128.100.101
      host2 Host genérico 2 host2.nyc3.example.com 10.128.200.102

      Nota: A sua configuração existente será diferente, mas os nomes dos exemplos e endereços IP serão usados para demonstrar como configurar um servidor DNS para fornecer um DNS interno funcional. Você consegue adaptar essa configuração ao seu ambiente com facilidade, pela substituição dos nomes de host e endereços IP privados pelos seus. Não é necessário usar o nome regional do datacenter no seu esquema de nomeação, mas usamos ele aqui para denotar que esses hosts pertencem a uma rede privada de um datacenter particular. Se você usar vários datacenters, é possível configurar um DNS interno dentro de cada datacenter respectivo.

      Ao final deste tutorial, teremos um servidor DNS primário, ns1, e opcionalmente um servidor DNS secundário, ns2, que servirá como backup.

      Vamos começar pela instalação do nosso servidor DNS primário, o ns1.

      Como instalar o BIND nos servidores DNS

      Nota: As passagens que estiverem destacadas em vermelho são importantes! Normalmente, elas serão usadas para denotar algo que precisa ser substituído pelas suas próprias configurações ou que deve ser modificado ou adicionado a um arquivo de configuração. Por exemplo, se você ver algo como host1.nyc3.example.com, substitua-o pelo FQDN do seu próprio servidor. De forma similar, se você ver host1_private_IP, substitua-o pelo endereço IP privado do seu próprio servidor.

      Em ambos os servidores DNS, ns1 e ns2, atualize o cache de pacotes apt digitando:

      Agora, instale o BIND:

      • sudo apt-get install bind9 bind9utils bind9-doc

      Como configurar o Bind para o modo IPv4

      Antes de continuar, vamos colocar o BIND no modo IPv4, já que nossa rede privada usa exclusivamente o IPv4. Nos dois servidores, edite o arquivo de configuração padrão bind9 digitando:

      • sudo nano /etc/default/bind9

      Adicione “-4” ao final do parâmetro OPTIONS. Ele deve se parecer com o seguinte:

      /etc/default/bind9

      . . .
      OPTIONS="-u bind -4"
      

      Salve e feche o arquivo quando você terminar.

      Reinicie o BIND para implementar as alterações:

      • sudo systemctl restart bind9

      Agora que o BIND está instalado, vamos configurar o servidor DNS primário.

      Como configurar o servidor DNS primário

      A configuração do BIND consiste em vários arquivos, que estão incluídos no arquivo de configuração principal, o named.conf. Estes nomes de arquivos começam com named porque este é o nome do processo que o BIND executa (abreviação de “domain name daemon”). Vamos começar configurando o arquivo de opções.

      Como configurar o arquivo de opções

      No ns1, abra o arquivo named.conf.options para edição:

      • sudo nano /etc/bind/named.conf.options

      Acima do bloco options existente, crie um bloco ALC (lista de controle de acesso) new chamado “confiáveis”. É aqui que vamos definir uma lista de clientes para os quais consultas recursivas DNS serão permitidas (ou seja, seus servidores que estão no mesmo datacenter que o ns1). Usando nosso exemplo de endereço IP privado, serão adicionados o ns1, ns2, host1 e host2 à nossa lista de clientes confiáveis:

      /etc/bind/named.conf.options — 1 of 3

      acl "trusted" {
              10.128.10.11;    # ns1 - can be set to localhost
              10.128.20.12;    # ns2
              10.128.100.101;  # host1
              10.128.200.102;  # host2
      };
      
      options {
      
              . . .
      

      Agora que temos nossa lista de clientes DNS confiáveis, queremos editar o bloco options. Atualmente, o início do bloco se parece com o seguinte:

      /etc/bind/named.conf.options — 2 of 3

              . . .
      };
      
      options {
              directory "/var/cache/bind";
              . . .
      }
      

      Abaixo da diretriz directory, adicione as linhas de configuração destacadas (e substitua no endereço IP do ns1 apropriado) para que fique dessa forma:

      /etc/bind/named.conf.options — 3 of 3

              . . .
      
      };
      
      options {
              directory "/var/cache/bind";
      
              recursion yes;                 # enables resursive queries
              allow-recursion { trusted; };  # allows recursive queries from "trusted" clients
              listen-on { 10.128.10.11; };   # ns1 private IP address - listen on private network only
              allow-transfer { none; };      # disable zone transfers by default
      
              forwarders {
                      8.8.8.8;
                      8.8.4.4;
              };
      
              . . .
      };
      

      Quando você terminar, salve e feche o arquivo named.conf.options. A configuração acima especifica que apenas seus próprios servidores (os “confiáveis”) poderão consultar seu servidor DNS para domínios externos.

      Em seguida, vamos configurar o arquivo local para especificar nossas zonas de DNS.

      Como configurar o arquivo local

      No ns1, abra o arquivo named.conf.local para edição:

      • sudo nano /etc/bind/named.conf.local

      Com exceção de alguns comentários, o arquivo deve estar vazio. Aqui, vamos especificar nossa zona de encaminhamento e nossa zona inversa. As zonas de DNS designam um escopo específico para o gerenciamento e definição dos registros de DNS. Como todos nossos domínios estarão dentro do sub-domínio “nyc3.example.com”, usaremos ele como nossa zona de encaminhamento. Como os endereços IP privados dos nossos servidores estão no espaço de IP 10.128.0.0/16, uma zona inversa será configurada para que possamos definir pesquisas inversas dentro desse intervalo.

      Adicione a zona de encaminhamento com as linhas a seguir, substituindo o nome da zona pelo seu próprio e o endereço IP privado do servidor DNS secundário na diretriz allow-transfer:

      /etc/bind/named.conf.local — 1 of 2

      zone "nyc3.example.com" {
          type master;
          file "/etc/bind/zones/db.nyc3.example.com"; # zone file path
          allow-transfer { 10.128.20.12; };           # ns2 private IP address - secondary
      };
      

      Supondo que nossa sub-rede privada seja 10.128.0.0/16, adicione a zona reversa com as linhas a seguir (note que nosso nome da zona reversa inicia com “128.10”, que é a reversão do octeto reverso de “10.128”):

      /etc/bind/named.conf.local — 2 of 2

          . . .
      };
      
      zone "128.10.in-addr.arpa" {
          type master;
          file "/etc/bind/zones/db.10.128";  # 10.128.0.0/16 subnet
          allow-transfer { 10.128.20.12; };  # ns2 private IP address - secondary
      };
      

      Se seus servidores se estendem por várias sub-redes privadas mas estão no mesmo datacenter, certifique-se de especificar uma zona adicional e um arquivo de zona para cada sub-rede distinta. Quando terminar de adicionar todas as suas zonas desejadas, salve e saia do arquivo named.conf.local.

      Agora que nossas zonas estão especificadas em BIND, precisamos criar os arquivos correspondentes da zona de encaminhamento e da zona reversa.

      Como criar o arquivo da zona de encaminhamento

      O arquivo da zona de encaminhamento está onde definimos os registros DNS para pesquisas de encaminhamentos de DNS. Isso é, quando o DNS receber um nome de consulta, “host1.nyc3.example.com”, por exemplo, ele olhará no arquivo da zona de encaminhamento para resolver o endereço IP privado correspondente do host1.

      Vamos criar o diretório onde nossos arquivos de zona irão permanecer. De acordo com nossa configuração named.conf.local, esse local deve ser o /etc/bind/zones:

      • sudo mkdir /etc/bind/zones

      Vamos basear nosso arquivo da zona de encaminhamento no arquivo de zona amostral db.local. Copie-o para o local correto com os seguintes comandos:

      • sudo cp /etc/bind/db.local /etc/bind/zones/db.nyc3.example.com

      Agora, vamos editar nosso arquivo da zona de encaminhamento:

      • sudo nano /etc/bind/zones/db.nyc3.example.com

      Inicialmente, ele se parecerá com o seguinte:

      /etc/bind/zones/db.nyc3.example.com — original

      $TTL    604800
      @       IN      SOA     localhost. root.localhost. (
                                    2         ; Serial
                               604800         ; Refresh
                                86400         ; Retry
                              2419200         ; Expire
                               604800 )       ; Negative Cache TTL
      ;
      @       IN      NS      localhost.      ; delete this line
      @       IN      A       127.0.0.1       ; delete this line
      @       IN      AAAA    ::1             ; delete this line
      

      Primeiro, vamos editar o registro do SOA. Substitua o primeiro “localhost” pelo FQDN do ns1 e então substitua “root.localhost” por “admin.nyc3.example.com”. Toda vez que você editar um arquivo de zona, será necessário aumentar o valor serial antes de reiniciar o processo named. Vamos incrementá-lo para “3”. Agora, ele deve se parecer com isso:

      /etc/bind/zones/db.nyc3.example.com — updated 1 of 3

      @       IN      SOA     ns1.nyc3.example.com. admin.nyc3.example.com. (
                                    3         ; Serial
      
                                    . . .
      

      Em seguida, delete os três registros ao final do arquivo (depois do registro do SOA). Se não tiver certeza sobre quais linhas excluir, elas estão marcadas acima com um comentário “delete this line”.

      Ao final do arquivo, adicione os registros do servidor do seu nome com as linhas a seguir (substitua os nomes pelos seus próprios). Note que a segunda coluna especifica que esses registros são “NS”:

      /etc/bind/zones/db.nyc3.example.com — updated 2 of 3

      . . .
      
      ; name servers - NS records
          IN      NS      ns1.nyc3.example.com.
          IN      NS      ns2.nyc3.example.com.
      

      Agora, adicione os registros A para seus hosts que pertencem a esta zona. Isso inclui qualquer servidor cujo nome queremos que termine com “.nyc3.example.com” (substitua os nomes e endereços IP privados). Usando nossos nomes de exemplo e endereços IP privados, vamos adicionar registros A para o ns1, ns2, host1 e host2 desta forma:

      /etc/bind/zones/db.nyc3.example.com — updated 3 of 3

      . . .
      
      ; name servers - A records
      ns1.nyc3.example.com.          IN      A       10.128.10.11
      ns2.nyc3.example.com.          IN      A       10.128.20.12
      
      ; 10.128.0.0/16 - A records
      host1.nyc3.example.com.        IN      A      10.128.100.101
      host2.nyc3.example.com.        IN      A      10.128.200.102
      

      Salve e feche o arquivo db.nyc3.example.com.

      Nosso arquivo de exemplo final da zona de encaminhamento se parece com o seguinte:

      /etc/bind/zones/db.nyc3.example.com — updated

      $TTL    604800
      @       IN      SOA     ns1.nyc3.example.com. admin.nyc3.example.com. (
                        3     ; Serial
                   604800     ; Refresh
                    86400     ; Retry
                  2419200     ; Expire
                   604800 )   ; Negative Cache TTL
      ;
      ; name servers - NS records
           IN      NS      ns1.nyc3.example.com.
           IN      NS      ns2.nyc3.example.com.
      
      ; name servers - A records
      ns1.nyc3.example.com.          IN      A       10.128.10.11
      ns2.nyc3.example.com.          IN      A       10.128.20.12
      
      ; 10.128.0.0/16 - A records
      host1.nyc3.example.com.        IN      A      10.128.100.101
      host2.nyc3.example.com.        IN      A      10.128.200.102
      

      Agora, vamos seguir para o(s) arquivo(s) da zona reversa.

      Como criar o(s) arquivo(s) da zona reversa

      Os arquivos da zona reverso estão onde definimos os registros DNS PTR para pesquisas de DNS reverso. Isso é, quando o DNS recebe uma consulta pelo endereço IP, “10.128.100.101”, por exemplo, ele olhará no(s) arquivo(s) da zona reversa para resolver o FQDN correspondente, sendo ele, o “host1.nyc3.example.com” neste caso.

      No ns1, para cada zona reversa especificada no arquivo named.conf.local, crie um arquivo de zona reversa. Vamos basear nosso(s) arquivo(s) de zona reversa no arquivo de zona amostral db.127. Copie-o para o local correto com os seguintes comandos (subtituindo o nome do arquivo de destino para que ele corresponda à definição da sua zona reversa):

      • sudo cp /etc/bind/db.127 /etc/bind/zones/db.10.128

      Edite o arquivo de zona reversa que corresponde à(s) zona(s) reversa(s) definida(s) em named.conf.local:

      • sudo nano /etc/bind/zones/db.10.128

      Inicialmente, ele se parecerá com o seguinte:

      /etc/bind/zones/db.10.128 — original

      $TTL    604800
      @       IN      SOA     localhost. root.localhost. (
                                    1         ; Serial
                               604800         ; Refresh
                                86400         ; Retry
                              2419200         ; Expire
                               604800 )       ; Negative Cache TTL
      ;
      @       IN      NS      localhost.      ; delete this line
      1.0.0   IN      PTR     localhost.      ; delete this line
      

      De maneira similar ao arquivo de zona de encaminhamento, edite o registro do SOA e aumente o valor serial. Ela deve se parecer com isto:

      /etc/bind/zones/db.10.128 — updated 1 of 3

      @       IN      SOA     ns1.nyc3.example.com. admin.nyc3.example.com. (
                                    3         ; Serial
      
                                    . . .
      

      Agora, delete os dois registros ao final do arquivo (depois do registro do SOA). Se não tiver certeza sobre quais linhas excluir, elas estão marcadas acima com um comentário “delete this line”.

      Ao final do arquivo, adicione os registros do servidor do seu nome com as linhas a seguir (substitua os nomes pelos seus próprios). Note que a segunda coluna especifica que esses registros são “NS”:

      /etc/bind/zones/db.10.128 — updated 2 of 3

      . . .
      
      ; name servers - NS records
            IN      NS      ns1.nyc3.example.com.
            IN      NS      ns2.nyc3.example.com.
      

      Então, adicione os registros PTR para todos os seus servidores cujos endereços IP estão na sub-rede do arquivo de zona que está editando. No nosso exemplo, isso inclui todos os nossos hosts porque eles estão todos na sub-rede 10.128.0.0/16. Note que a primeira coluna consiste nos dois últimos octetos dos endereços IP privados dos seus servidores em reversed order. Certifique-se de substituir os nomes e endereços IP privados para corresponder aos seus servidores:

      /etc/bind/zones/db.10.128 — updated 3 of 3

      . . .
      
      ; PTR Records
      11.10   IN      PTR     ns1.nyc3.example.com.    ; 10.128.10.11
      12.20   IN      PTR     ns2.nyc3.example.com.    ; 10.128.20.12
      101.100 IN      PTR     host1.nyc3.example.com.  ; 10.128.100.101
      102.200 IN      PTR     host2.nyc3.example.com.  ; 10.128.200.102
      

      Salve e feche o arquivo de zona reversa (repita essa seção caso precise adicionar mais arquivos de zona reversa).

      Nosso arquivo de exemplo final de zona reversa se parece com o seguinte:

      /etc/bind/zones/db.10.128 — updated

      $TTL    604800
      @       IN      SOA     nyc3.example.com. admin.nyc3.example.com. (
                                    3         ; Serial
                               604800         ; Refresh
                                86400         ; Retry
                              2419200         ; Expire
                               604800 )       ; Negative Cache TTL
      ; name servers
            IN      NS      ns1.nyc3.example.com.
            IN      NS      ns2.nyc3.example.com.
      
      ; PTR Records
      11.10   IN      PTR     ns1.nyc3.example.com.    ; 10.128.10.11
      12.20   IN      PTR     ns2.nyc3.example.com.    ; 10.128.20.12
      101.100 IN      PTR     host1.nyc3.example.com.  ; 10.128.100.101
      102.200 IN      PTR     host2.nyc3.example.com.  ; 10.128.200.102
      

      Agora que terminamos de editar nossos arquivos, podemos verificá-los à procura de erros.

      Verificando a sintaxe de configuração do BIND

      Execute o comando a seguir para verificar a sintaxe dos arquivos named.conf*:

      Se seus arquivos de configuração nomeados não tiverem erros de sintaxe, você retornará ao seu prompt do shell e não verá nenhuma mensagem de erro. Se houver problemas com seus arquivos de configuração, reveja a mensagem de erro e a seção “Como configurar o servidor DNS primário”, e então tente o named-checkconf novamente.

      O comando named-checkzone pode ser usado para verificar a correção dos arquivos da sua zona. Seu primeiro argumento especifica um nome de zona e o segundo especifica o arquivo da zona correspondente, sendo que ambos estão definidos em named.conf.local.

      Por exemplo, para verificar a configuração da zona de encaminhamento “nyc3.example.com”, execute o seguinte comando (mude os nomes para que correspondam à sua zona de encaminhamento e arquivo):

      • sudo named-checkzone nyc3.example.com db.nyc3.example.com

      E para verificar a configuração da zona reversa “128.10.in-addr.arpa”, execute o seguinte comando (mude os números para que correspondam à sua zona reversa e arquivo):

      • sudo named-checkzone 128.10.in-addr.arpa /etc/bind/zones/db.10.128

      Quando todos os arquivos de configuração e zona estiverem livres de erros, você está pronto para reiniciar o serviço BIND.

      Reiniciando o BIND

      Reinicie o BIND:

      • sudo systemctl restart bind9

      Se você tiver o firewall UFW configurado, libere o acesso para o BIND digitando:

      Seu servidor de DNS primário agora está configurado e pronto para responder às consultas do DNS. Vamos seguir em frente para a criação do servidor DNS secundário.

      Configurando o servidor DNS secundário

      Na maioria dos ambientes, é uma boa ideia configurar um servidor DNS secundário que responda aos pedidos caso o primário fique indisponível. Felizmente, o servidor DNS secundário é muito mais fácil de configurar.

      No ns2, edite o arquivo named.conf.options:

      • sudo nano /etc/bind/named.conf.options

      Ao topo do arquivo, adicione o ACL com os endereços IP privados de todos os seus servidores confiáveis:

      /etc/bind/named.conf.options — updated 1 of 2 (secondary)

      acl "trusted" {
              10.128.10.11;   # ns1
              10.128.20.12;   # ns2 - can be set to localhost
              10.128.100.101;  # host1
              10.128.200.102;  # host2
      };
      
      options {
      
              . . .
      

      Abaixo da diretriz directory, adicione as seguintes linhas:

      /etc/bind/named.conf.options — updated 2 of 2 (secondary)

              recursion yes;
              allow-recursion { trusted; };
              listen-on { 10.128.20.12; };      # ns2 private IP address
              allow-transfer { none; };          # disable zone transfers by default
      
              forwarders {
                      8.8.8.8;
                      8.8.4.4;
              };
      

      Salve e feche o arquivo named.conf.options. Este arquivo deve se parecer exatamente com o arquivo named.conf.options do ns1, exceto por precisar ser configurado para escutar o endereço IP privado do ns2.

      Agora, edite o arquivo named.conf.local:

      • sudo nano /etc/bind/named.conf.local

      Definas as zonas subordinadas que correspondam às zonas mestras no servidor DNS primário. Note que como o tipo é “subordinado”, o arquivo não contém um caminho e há uma diretriz masters que deve ser configurada para o endereço IP privado do servidor DNS primário. Se você definiu várias zonas inversas no servidor DNS primário, certifique-se de adicionar todas elas aqui:

      /etc/bind/named.conf.local — updated (secondary)

      zone "nyc3.example.com" {
          type slave;
          file "db.nyc3.example.com";
          masters { 10.128.10.11; };  # ns1 private IP
      };
      
      zone "128.10.in-addr.arpa" {
          type slave;
          file "db.10.128";
          masters { 10.128.10.11; };  # ns1 private IP
      };
      

      Agora salve e feche o arquivo named.conf.local.

      Execute o comando a seguir para verificar a validade dos seus arquivos de configuração:

      Assim que for aprovado, reinicie o BIND:

      • sudo systemctl restart bind9

      Permita conexões DNS ao servidor pela alteração das regras do firewall UFW:

      Agora você tem servidores DNS primários e secundários para resoluções de nome e endereço IP da rede privada. Agora, você precisa configurar os seus servidores de cliente para usar os seus servidores DNS privados.

      Configurando os clientes DNS

      Antes que todos os seus servidores ACL “confiáveis” possam consultar seus servidores DNS, você precisa configurar cada um deles para usar o ns1 e o ns2 como servidores de nomes. Este processo varia dependendo do SO, mas para a maioria das distribuições do Linux, envolve a adição dos seus servidores de nomes ao arquivo /etc/resolv.conf.

      Clientes Ubuntu 18.04

      No Ubuntu 18.04, a rede é configurada com o Netplan, uma abstração que permite que você escreva configurações padronizadas de rede e aplique-as para softwares backend de rede incompatíveis. Para configurar o DNS, precisamos escrever um arquivo de configuração do Netplan.

      Primeiramente, encontre o dispositivo associado à sua rede privada consultando a sub-rede privada com o comando ip address:

      • ip address show to 10.128.0.0/16

      Output

      3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 inet 10.128.100.101/16 brd 10.128.255.255 scope global eth1 valid_lft forever preferred_lft forever

      Neste exemplo, a interface privada é a eth1.

      Em seguida, crie um novo arquivo em /etc/netplan chamado 00-private-nameservers.yaml:

      • sudo nano /etc/netplan/00-private-nameservers.yaml

      Cole lá dentro o seguinte conteúdo. Será necessário modificar a interface da rede privada, os endereços dos seus servidores DNS ns1 e ns2 e da zona do DNS:

      Nota: o Netplan usa o formato de serialização de dados YAML para seus arquivos de configuração. Como o YAML usa recuos e espaços em branco para definir sua estrutura de dados, certifique-se de que sua definição utilize recuos consistentes para evitar erros.

      /etc/netplan 00-private-nameservers.yaml

      network:
          version: 2
          ethernets:
              eth1:                                 # Private network interface
                  nameservers:
                      addresses:
                      - 10.128.10.11                # Private IP for ns1
                      - 10.132.20.12                # Private IP for ns2
                      search: [ nyc3.example.com ]  # DNS zone
      
      

      Salve e feche o arquivo quando você terminar.

      Em seguida, faça o Netplan tentar usar o novo arquivo de configuração utilizando o netplan try. Se houver problemas que causem uma perda de rede, o Netplan irá retroceder automaticamente as mudanças após um tempo limite:

      Output

      Warning: Stopping systemd-networkd.service, but it can still be activated by: systemd-networkd.socket Do you want to keep these settings? Press ENTER before the timeout to accept the new configuration Changes will revert in 120 seconds

      Se a contagem regressiva estiver atualizando corretamente ao fim, a nova configuração é, ao menos, funcional o suficiente para não interromper sua conexão via protocolo SSH. Pressione ENTER para aceitar a nova configuração.

      Agora, verifique o resolvedor DNS do sistema para determinar se sua configuração de DNS foi aplicada:

      • sudo systemd-resolve --status

      Role para baixo até ver a seção da sua interface de rede privada. Você deve ver os endereços IP privados dos seus servidores DNS listados primeiro, seguidos de alguns valores de retorno. Seu domínio deve estar no “DNS Domain”:

      Output

      . . . Link 3 (eth1) Current Scopes: DNS LLMNR setting: yes MulticastDNS setting: no DNSSEC setting: no DNSSEC supported: no DNS Servers: 10.128.10.11 10.128.20.12 67.207.67.2 67.207.67.3 DNS Domain: nyc3.example.com . . .

      Seu cliente agora deve estar configurado para usar seus servidores DNS internos.

      Clientes Ubuntu 16.04 e Debian

      Nos servidores Linux Ubuntu 16.04 e Debian, você pode editar o arquivo /etc/network/interfaces:

      • sudo nano /etc/network/interfaces

      Encontre lá dentro a linha dns-nameservers e anexe no início os seus próprios servidores de nomes na frente da lista que atualmente está lá. Abaixo dessa linha, adicione uma opção dns-search apontada para o domínio base da sua infraestrutura. No nosso caso, seria “nyc3.example.com”:

      /etc/network/interfaces

          . . .
      
          dns-nameservers 10.128.10.11 10.128.20.12 8.8.8.8
          dns-search nyc3.example.com
      
          . . .
      

      Salve e feche o arquivo quando você terminar.

      Agora, reinicie seus serviços de rede, aplicando as novas mudanças com os comandos a seguir. Certifique-se de substituir o eth0 pelo nome da sua interface de rede:

      • sudo ifdown --force eth0 && sudo ip addr flush dev eth0 && sudo ifup --force eth0

      Isso deve reiniciar sua rede sem interromper sua conexão atual. Se funcionou corretamente, você verá algo similar a isto:

      Output

      RTNETLINK answers: No such process Waiting for DAD... Done

      Verifique novamente se suas configurações foram aplicadas digitando:

      Você deve ver seus servidores de nomes no arquivo /etc/resolv.conf, além do seu domínio de busca:

      Output

      # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN nameserver 10.128.10.11 nameserver 10.128.20.12 nameserver 8.8.8.8 search nyc3.example.com

      Seu cliente agora está configurado para usar seus servidores DNS.

      Clientes CentOS

      No CentOS, RedHat, e Fedora Linux, edite o arquivo /etc/sysconfig/network-scripts/ifcfg-eth0. Pode ser que você precise substituir o eth0 pelo nome da sua interface de rede primária:

      • sudo nano /etc/sysconfig/network-scripts/ifcfg-eth0

      Procure as opções DNS1 e DNS2 e defina-as para os endereços IP privados dos seus servidores de nomes primários e secundários. Adicione um parâmetro DOMAIN junto com o domínio base da sua infraestrutura. Neste guia, seria “nyc3.example.com”:

      /etc/sysconfig/network-scripts/ifcfg-eth0

      . . .
      DNS1=10.128.10.11
      DNS2=10.128.20.12
      DOMAIN='nyc3.example.com'
      . . .
      

      Salve e feche o arquivo quando você terminar.

      Agora, reinicie o serviço de rede digitando:

      • sudo systemctl restart network

      O comando pode ficar suspenso por alguns segundos, mas deve retornar você para o prompt em breve.

      Verifique se suas alterações foram aplicadas digitando:

      Você deve ver seus servidores de nomes e domínio de busca na lista:

      /etc/resolv.conf

      nameserver 10.128.10.11
      nameserver 10.128.20.12
      search nyc3.example.com
      

      Seu cliente agora deve conseguir se conectar aos seus servidores DNS e utilizá-los.

      Testando os clientes

      Use o nslookup para testar se seus clientes podem consultar seus servidores de nomes. Você deve conseguir fazer isso em todos os clientes que configurou e que estão no ACL “confiáveis”.

      Para clientes CentOS, pode ser necessário instalar o utilitário com:

      • sudo yum install bind-utils

      Podemos começar executando uma pesquisa direta.

      Pesquisa direta

      Por exemplo, é possível executar uma pesquisa direta para recuperar o endereço IP do host1.nyc3.example.com executando o seguinte comando:

      A consulta do “host1” expande-se para o “host1.nyc3.example.com” pelo fato da opção search estar configurada para o seu sub-domínio privado e as consultas de DNS tentarão procurar naquele sub-domínio antes de procurar o host em outro lugar. O resultado do comando acima se pareceria com o seguinte:

      Output

      Server: 127.0.0.53 Address: 127.0.0.53#53 Non-authoritative answer: Name: host1.nyc3.example.com Address: 10.128.100.101

      Em seguida, podemos verificar as pesquisas inversas.

      Pesquisa inversa

      Para testar a pesquisa inversa, consulte o servidor DNS com o endereço IP privado do host1:

      Deverá ver um resultado que se parece com o seguinte:

      Output

      11.10.128.10.in-addr.arpa name = host1.nyc3.example.com. Authoritative answers can be found from:

      Se todos os nomes e endereços IP resolverem os valores corretos, seus arquivos de zona estão configurados corretamente. Se receber valores inesperados, certifique-se de rever os arquivos de zona no seu servidor DNS primário (por exemplo, db.nyc3.example.com e db.10.128).

      Parabéns! Seus servidores DNS internos agora estão configurados corretamente! Agora, vamos falar sobre a manutenção dos seus registros de zona.

      Conservando os registros DNS

      Agora que você tem um DNS interno funcionando, é preciso conservar seus registros DNS para que eles reflitam com precisão o ambiente do seu servidor.

      Como adicionar um Host ao DNS

      Sempre que adicionar um host ao seu ambiente (no mesmo datacenter), adicione-o ao DNS. Aqui está uma lista de passos que você precisa seguir:

      Servidor de nomes primário

      • Arquivo de zona de encaminhamento: adicione um registro “A” para o novo host, incrementando o valor de “Serial”
      • Arquivo de zona inversa: adicione um registro “PTR” para o novo host, incrementando o valor de “Serial”
      • Adicione o endereço IP privado do seu novo host ao ACL “confiáveis” (named.conf.options)

      Teste os seus arquivos de configuração:

      • sudo named-checkconf
      • sudo named-checkzone nyc3.example.com db.nyc3.example.com
      • sudo named-checkzone 128.10.in-addr.arpa /etc/bind/zones/db.10.128

      Então, recarregue o BIND:

      • sudo systemctl reload bind9

      Seu servidor primário deve estar agora configurado para o novo host.

      Servidor de nomes secundário

      • Adicione o endereço IP privado do seu novo host ao ACL “confiáveis” (named.conf.options)

      Verifique a sintaxe de configuração:

      Então, recarregue o BIND:

      • sudo systemctl reload bind9

      Seu servidor secundário agora aceitará conexões do novo host.

      Configure o novo host para usar o seu DNS

      • Configure o /etc/resolv.conf para que use seus servidores DNS
      • Teste utilizando o nslookup

      Removendo o host do DNS

      Se você remover um host do seu ambiente ou quiser simplesmente removê-lo do DNS, remova todas as coisas que foram adicionadas quando adicionou o servidor ao DNS (ou seja, o inverso dos passos acima).

      Conclusão

      Agora, é possível consultar as interfaces de rede privadas dos seus servidores por nome ao invés de endereço IP. Isso torna mais fácil a configuração dos serviços e aplicativos porque você já não precisa se lembrar dos endereços IP privados e os arquivos serão mais fáceis de ler e entender. Além disso, é possível agora alterar suas configurações para que apontem para um novo servidor em um único lugar, o seu servidor DNS, ao invés de precisar editar uma variedade de arquivos de configuração distribuídos, facilitando a manutenção.

      Assim que tiver seu DNS interno configurado, e os seus arquivos de configuração estiverem usando FQDNs privados para especificar conexões de rede, é fundamental que seus servidores DNS estejam devidamente conservados. Se ambos ficarem indisponíveis, seus serviços e aplicativos que dependem deles deixam de funcionar corretamente. É por isso que é recomendável configurar o seu DNS com pelo menos um servidor secundário, além de manter backups funcionais de todos eles.



      Source link