Upstream dns что это

Обновлено: 04.07.2024

Подробное объяснение dnsmasq и его использования в openstack и контейнерах

Чтобы понять Dnsmasq, он все еще начинает с изучения нейтронной сети с открытым стеком. В сети с открытым стеком dnsmasq предоставляет функции dhcp и dns для указанной сети. Этот процесс в фоновом режиме выглядит следующим образом:

Этот процесс запускается, когда функция подсети dhcp или dns включена.Если функция dhcp или dns нескольких подсетей включена в одной сети, процесс запуска dnsmasq в первый раз в сети будет изменен. То есть, если процесс dnsmasq запущен в первой подсети, подсеть под сетью связи, созданной позже, не перезапустит новый процесс, но изменит процесс, запущенный в первый раз. Следующим образом:
Подсеть запускает процесс dnsmasq:

Две подсети запускают процесс dnsmasq:

Мы обнаружим, что функция dhcp или dns дополнительной подсети будет изменена только в процессе dnsmasq, созданном в первый раз, и будет добавлена соответствующая информация о второй подсети, например: --dhcp-range = set: tag1,10.11 .0.0, статический, 255.255.255.0,86400 с. Здесь кратко упоминается Dnsmasq об openstack, давайте поговорим об общей функции dnsmasq.

Dnsmasq （dnsmasq）
Предоставляет функции DNS-кэша и службы DHCP. Будучи сервером разрешения доменных имен (DNS), dnsmasq может кэшировать DNS-запросы, чтобы увеличить скорость нашего соединения с посещаемыми веб-сайтами. В качестве DHCP-сервера dnsmasq может предоставлять IP-адреса в интрасети и маршрутизацию для компьютеров (облачных хостов) в локальной сети (например, сети в openstack). Две функции DNS и DHCP могут быть реализованы одновременно или по отдельности. dnsmasq является легким и простым в настройке, подходит для отдельных пользователей или сетей с менее чем 50 хостами.

Давайте поговорим о конфигурации dnsmasq, файл конфигурации dnsmasq находится в /etc/dnsmasq.conf, или он может находиться в / etc / default / dnsmasq, /etc/dnsmasq.d/ или / etc / dnsmasq из-за вашей другой версии Linux В каталоге d-available / мы также можем указать адрес файла конфигурации при запуске процесса dnsmasq или вызвать другие файлы конфигурации с помощью опции conf-file = в файле конфигурации. Они могут быть гибко определены в соответствии с потребностями.
Ниже приведены выдержки из dnsmasq.conf, которые являются важными и часто используемыми элементами конфигурации и краткими описаниями:

Не читать ни одного сервера. Файл /etc/resolv.conf по умолчанию можно настроить с помощью resolv-файла
не загружать локальный файл / etc / hosts

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

Прочитать все файлы в каталоге, обновления файлов будут прочитаны автоматически

Укажите пользователей и группы

Укажите порт DNS, по умолчанию 53, установите порт = 0, чтобы полностью отключить функцию DNS, использовать только DHCP / TFTP

Установить размер кеша DNS (единица измерения: количество разрешений DNS)

Кэш неизвестного доменного имени не кэшируется. По умолчанию dnsmasq кэширует неизвестное доменное имя и возвращает его непосредственно клиенту.

Укажите номер пересылки DNS-запроса

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

Определите, где dnsmasq получает адрес вышестоящего DNS-сервера, по умолчанию его получают из /etc/resolv.conf

Указывает, что разрешение DNS выполняется строго сверху вниз в порядке в файле resolv-файла, пока первое разрешение не будет успешным

Привязать интерфейс, открыть этот пункт будет слушать только указанный интерфейс.

Недавно добавленный интерфейс также связан.

Ограничьте сетевые интерфейсы, которые слушает Dnsmasq

Укажите интерфейс, который нужно исключить из прослушивания, с высоким приоритетом, чтобы исключить, вы можете использовать подстановочный знак '*'

Указывает интерфейс, который не предоставляет службы DHCP или TFTP, а предоставляет только службы DNS.

dhcp динамически распределяемый диапазон адресов

Статическая привязка службы DHCP

Установить аренду по умолчанию

Аренда сохранена в следующем файле

Игнорирование запроса DHCP для MAC-адреса ниже

Домен, в котором находится dhcp

Установите выход по умолчанию для маршрута, опция 3 - маршрут по умолчанию, 10.10.10.1 - шлюз

После прочтения файла конфигурации давайте взглянем на параметры процесса dnsmasq, которые можно настроить:
Вы можете обратиться к документации на английском языке:анализ параметров командной строки dnsmasq

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

Далее мы проанализируем параметры процесса dnsmasq в openstack в приведенной выше конфигурации:

Dnsmasq также установлен в контейнере, следующая установка для версии centos7:

Прост в использовании:

Простая топология сети выглядит следующим образом: создайте следующую сеть в среде ovs + kvm, процесс dnsmasq прослушивает устройство DHCP tap1, широковещательные пакеты dhcp, отправленные хостом host1 и host2, принимаются tap1, процесс dnsmasq найдет соответствующий mac в соответствующем файле хоста. Ip доставляется на хост. Если он не найден, хост не может получить ip.

Для этой среды, пожалуйста, смотрите:Настройка тестовой среды

Запишите mac двух хостов в соответствующий файл хоста:

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

Чтобы запустить dnsmasq в контейнере, контейнер должен быть запущен в сетевом режиме net = host, чтобы можно было отслеживать интерфейс dhcp_tap на хосте и сохранять такие файлы, как host и pid, в контейнере.

Начать процесс в контейнере

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

После тестирования, когда виртуальная машина получает IP, процесс сообщает о следующей ошибке:

Операция не разрешена, вот из-за проблемы с разрешениями, при создании контейнера вы можете дать режим привилегий.

Wireless Comprehensive Advanced Technology. Build your network now.

Включение локальных DNS в ПО Wive-NG

Для того, чтобы обеспечить корректную работу локальной записи DNS, необходимо первым делом присвоить постоянный IP адрес (2) MAC адресу (1) устройства (3), для которого мы создаем запись. Сделать это можно в разделе Services → DHCP Server → Static IP address assignment table. При отсутствии статической пары MAC — IP, IP адрес целевого устройства, полученный от DHCP сервера роутера, может измениться, после чего локальная запись DNS станет недействительной.

Присвоение постоянного IP адреса MAC адресу целевого устройства

Следующим шагом в блоке Add Local DNS Entry следует создать запись, включающую IP адрес (1) (который ранее мы присвоили на постоянной основе ресурсу, к которому обеспечиваем доступ) и доменное имя (2), по которому ресурс будет доступен пользователям локальной сети. Достаточно добавить запись (3) и применить, нажав Apply внизу страницы. Перезагрузка устройства не требуется.

Добавление локальной DNS записи

После добавления записи, последняя появится в таблице Local DNS Entries. Одновременно с этим целевой ресурс станет доступен по доменному имени.

Проверка доступности локального ресурса по доменному имени

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

Включение редиректа всех запросов на локальный DNS

Для препятствования атакам, основанным на подмене DNS, в ПО Wive-NG-mt добавлена поддержка DNSSec. Чтобы ее включить, достаточно выставить параметр DNSSec в значение Enable.

Важно: в силу ресурсоёмкости функционал DNSSEC доступен только в сборках Wive-NG для старших моделей (на базе MT7621)

Включение DNSSec в Wive-NG

Как работает DNSSec:

Какая-либо ручная настройка для работы DNSSec не требуется — достаточно просто включить данную опцию в web интерфейсе.

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

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

Просмотр и добавление альтернативных DNS серверов для корректной работы DNSSec

В этом случае DNSMASQ использует для резолва альтернативные серверы из блока Upstream DNS, в то время как локальные сервисы ПО продолжают использовать провайдерские DNS серверы.

Список публичных DNS серверов, в том числе поддерживающих DNSSec, доступен, например, здесь

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Установка и настройка на Raspberry крайне понятная и простая. Посмотрим вкратце процесс установки и настройки при условии, что у вас на Raspberry уже установлена ОС Linux и вы имеете доступ по ssh.

Подключаетесь по ssh к Raspberry и выполняете следующую команду:

Определение из википедии:

tar -xvzf cloudflared-stable-linux-arm.tgz

cp ./cloudflared /usr/local/bin

sudo chmod +x /usr/local/bin/cloudflared

Создадим пользователя для работы сервиса

sudo useradd -s /usr/sbin/nologin -r -M cloudflared

Создадим файл конфигурации

sudo nano /etc/default/cloudflared

Дадим на него и на исполняемый файл права пользователю сервиса

sudo chown cloudflared:cloudflared /etc/default/cloudflared

sudo chown cloudflared:cloudflared /usr/local/bin/cloudflared

Создадим файл для возможности добавления сервиса в автозагрузку

sudo nano /lib/systemd/system/cloudflared.service

User=cloudflared

EnvironmentFile=/etc/default/cloudflared

ExecStart=/usr/local/bin/cloudflared proxy-dns $CLOUDFLARED_OPTS

Restart=on-failure

RestartSec=10

KillMode=process

Активация сервиса и его запуск

systemctl enable cloudflared

systemctl start cloudflared

systemctl status cloudflared

Если всё получилось, то увидите, что сервис в состоянии active (running).

В Advanced DNS Settings галки оставляете только на Never forward non-FQDNs и Never forward revers lookups for private IP ranges. Нажимаете Save.

Также в белый лист добавил несколько доменов, чтобы они не блокировались.

И если всё ок, то в настройках DHCP сервера (вероятно он у вас включен в роутере) указываете DNS - ip адрес вашего мини-компьютера Raspberry.

Добавляете скрипт и настраиваете планировщик ( я у себя настроил запускать скрипт каждые 2 часа) согласно инструкции, указанной на сайте. Рекомендую, в скрипт добавлять и тестить по одному списку, т.к. у меня на Mikrotik HAP AC LITE при добавлении всех списков поднялась загрузка процессора на 100% и после завис. После в Mikrotik переходите в настройки ДНС IP - DNS, указываете первый днс сервер ip адрес Pi-hole, второй днс сервер 1.1.1.1 или гугловский/провайдерский, вообщем любой.

После переходите в настройки DHCP сервера и указываете как второй днс сервер - ip адрес вашего роутера. В моем случае 192.168.77.23 - Pi-hole, 192.168.77.1 - роутер.

На этом всё! Настройка закончена! Приятно удивитесь даже заблокированной рекламой в приложениях на телефоне. Удачи!

Шифрование трафика между вашим устройством и DNS-сервисом помешает посторонним лицам отслеживать трафик или подменить адрес

Смерть сетевого нейтралитета и ослабление правил для интернет-провайдеров по обработке сетевого трафика вызвали немало опасений по поводу конфиденциальности. У провайдеров (и других посторонних лиц, которые наблюдают за проходящим трафиком) уже давно есть инструмент, позволяющий легко отслеживать поведение людей в интернете: это их серверы доменных имен (DNS). Даже если они до сих пор не монетизировали эти данные (или не подменяли трафик), то наверняка скоро начнут.

«Открытые» DNS-сервисы позволяют обходить сервисы провайдеров ради конфиденциальности и безопасности, а кое в каких странах — уклоняться от фильтрации контента, слежки и цензуры. 1 апреля (не шутка) компания Cloudflare запустила свой новый, бесплатный и высокопроизводительный DNS-сервис, предназначенный для повышения конфиденциальности пользователей в интернете. Он также обещает полностью скрыть DNS-трафик от посторонних глаз, используя шифрование.

Названный по своему IP-адресу, сервис 1.1.1.1 — это результат партнёрства с исследовательской группой APNIC, Азиатско-Тихоокеанским сетевым информационным центром, одним из пяти региональных интернет-регистраторов. Хотя он также доступен как «открытый» обычный DNS-резолвер (и очень быстрый), но Cloudflare ещё поддерживает два протокола шифрования DNS.

Хотя и разработанный с некоторыми уникальными «плюшками» от Cloudflare, но 1.1.1.1 — никак не первый DNS-сервис с шифрованием. Успешно работают Quad9, OpenDNS от Cisco, сервис 8.8.8.8 от Google и множество более мелких сервисов с поддержкой различных схем полного шифрования DNS-запросов. Но шифрование не обязательно означает, что ваш трафик невидим: некоторые службы DNS с шифрованием всё равно записывают ваши запросы в лог для различных целей.

Cloudflare пообещал не журналировать DNS-трафик и нанял стороннюю фирму для аудита. Джефф Хастон из APNIC сообщил, что APNIC собирается использовать данные в исследовательских целях: диапазоны 1.0.0.0/24 и 1.1.1.0/24 изначально были сконфигурированы как адреса для «чёрного» трафика. Но APNIC не получит доступ к зашифрованному трафику DNS.

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

Как работает DNS

Есть много причин для лучшей защиты DNS-трафика. Хотя веб-трафик и другие коммуникации могут быть защищены криптографическими протоколами, такими как Transport Layer Security (TLS), но почти весь трафик DNS передаётся незашифрованным. Это означает, что ваш провайдер (или кто-то другой между вами и интернетом) может регистрировать посещаемые сайты даже при работе через сторонний DNS — и использовать эти данных в своих интересах, включая фильтрацию контента и сбор данных в рекламных целях.

Как выглядит типичный обмен данными между устройством и DNS-резолвером

«У нас есть проблема “последней мили” в DNS, — говорил Крикет Лю, главный архитектор DNS в компании Infoblox, которая занимается информационной безопасностью. — Большинство наших механизмов безопасности решают вопросы коммуникаций между серверами. Но есть проблема с суррогатами резолверов на различных операционных системах. В реальности мы не можем их защитить». Проблема особенно заметна в странах, где власти более враждебно относятся к интернету.

Наиболее очевидный способ уклонения от слежки — использование VPN. Но хотя VPN скрывают содержимое вашего трафика, для подключения к VPN может потребоваться запрос DNS. И в ходе VPN-сеанса запросы DNS тоже могут иногда направляться веб-браузерами или другим софтом за пределы VPN-тоннеля, создавая «утечки DNS», которые раскрывают посещённые сайты.

Однако эта опция защиты недоступна массовому пользователю. Ни один из этих протоколов нативно не поддерживается ни одним DNS-резолвером, который идёт в комплекте с ОС. Все они требуют установки (и, вероятно, компиляции) клиентского приложения, которое действует как локальный «сервер» DNS, ретранслируя запросы, сделанные браузерами и другими приложениями вверх по течению к безопасному провайдеру DNS по вашему выбору. И хотя две из трёх данных технологий предлагаются на роль стандартов, ни один из проверенных нами вариантов пока не представлен в окончательном виде.

Поэтому если хотите погрузиться в шифрование DNS, то лучше взять для DNS-сервера в домашней сети Raspberry Pi или другое отдельное устройство. Потому что вы наверняка обнаружите, что настройка одного из перечисленных клиентов — это уже достаточно хакерства, чтобы не захотеть повторять процесс заново. Проще запросить настройки DHCP по локальной сети — и указать всем компьютерам на одну успешную установку DNS-сервера. Я много раз повторял себе это во время тестирования, наблюдая падение одного за другим клиентов под Windows и погружение в спячку клиентов под MacOS.

Сообщество DNSCrypt пыталось сделать доступный инструмент для тех, кто не обладает навыками работы в командной строке, выпустив программы DNSCloak (слева) под iOS и Simple DNSCrypt (справа) под Windows

Для полноты картины в исторической перспективе начнём обзор с самой первой технологии шифрования DNS — DNSCrypt. Впервые представленный в 2008 году на BSD Unix, инструмент DNSCrypt изначально предназначался для защиты не от прослушки, а от DNS-спуфинга. Тем не менее, его можно использовать как часть системы обеспечения конфиденциальности — особенно в сочетании с DNS-сервером без логов. Как отметил разработчик DNSCrypt Фрэнк Денис, гораздо больше серверов поддерживают DNSCrypt, чем любой другой вид шифрования DNS.

«DNSCrypt — это немного больше, чем просто протокол, — говорит Фрэнк Денис. — Сейчас сообщество и активные проекты характеризуют его гораздо лучше, чем мой изначальный протокол, разработанный в выходные». Сообщество DNSCrypt создало простые в использовании клиенты, такие как Simple DNSCrypt для Windows и клиент для Apple iOS под названием DNS Cloak, что делает шифрование DNS доступнее для нетехнических людей. Другие активисты подняли независимую сеть приватных DNS-серверов на основе протокола, помогающего пользователям уклониться от использования корпоративных DNS-систем.

«DNSCrypt — это не подключение к серверам конкретной компании, — сказал Денис. — Мы призываем всех поднимать собственные сервера. Сделать это очень дёшево и легко. Теперь, когда у нас есть безопасные резолверы, я пытаюсь решить задачу фильтрации контента с учётом конфиденциальности».

Для тех, кто хочет запустить DNS-сервер с поддержкой DNSCrypt для всей своей сети, лучшим клиентом будет DNSCrypt Proxy 2. Старая версия DNSCrypt Proxy по-прежнему доступна как пакет для большинства основных дистрибутивов Linux, но лучше загрузить бинарник новой версии непосредственно с официального репозитория на GitHub. Есть версии для Windows, MacOS, BSD и Android.

Опыт сообщества DNSCrypt по защите конфиденциальности воплощён в DNSCrypt Proxy. Программа легко настраивается, поддерживает ограничения по времени доступа, шаблоны для доменов и чёрный список IP-адресов, журнал запросов и другие функции довольно мощного локального DNS-сервера. Но для начала работы достаточно самой базовой конфигурации. Есть пример файла конфигурации в формате TOML (Tom's Obvious Minimal Language, созданный соучредителем GitHub Томом Престоном-Вернером). Можете просто переименовать его перед запуском DNSCrypt Proxy — и он станет рабочим файлом конфигурации.

По умолчанию прокси-сервер использует открытый DNS-резолвер Quad9 для поиска и получения с GitHub курируемого списка открытых DNS-сервисов. Затем подключается к серверу с самым быстрым откликом. При необходимости можно изменить конфигурацию и выбрать конкретный сервис. Информация о серверах в списке кодируется как «штамп сервера». Он содержит IP-адрес поставщика, открытый ключ, информацию, поддерживает ли сервер DNSSEC, хранит ли провайдер логи и блокирует ли какие-нибудь домены. (Если не хотите зависеть от удалённого файла при установке, то можно запустить «калькулятор штампов» на JavaScript — и сгенерировать собственный локальный статичный список серверов в этом формате).

Для своего тестирования DNSCrypt я использовал OpenDNS от Cisco в качестве удалённого DNS-сервиса. При первых запросах производительность DNSCrypt оказалась немного хуже, чем у обычного DNS, но затем DNSCrypt Proxy кэширует результаты. Самые медленные запросы обрабатывались в районе 200 мс, в то время как средние — примерно за 30 мс. (У вас результаты могут отличаться в зависимости от провайдера, рекурсии при поиске домена и других факторов). В целом, я не заметил замедления скорости при просмотре веб-страниц.

С другой стороны, DNSCrypt для шифрования не полагается на доверенные центры сертификации — клиент должен доверять открытому ключу подписи, выданному провайдером. Этот ключ подписи используется для проверки сертификатов, которые извлекаются с помощью обычных (нешифрованных) DNS-запросов и используются для обмена ключами с использованием алгоритма обмена ключами X25519. В некоторых (более старых) реализациях DNSCrypt есть условие для сертификата на стороне клиента, который может использоваться в качестве схемы управления доступом. Это позволяет им журналировать ваш трафик независимо от того, с какой IP-адреса вы пришли, и связывать его с вашим аккаунтом. Такая схема не используется в DNSCrypt 2.

С точки зрения разработчика немного сложно работать с DNSCrypt. «DNSCrypt не особенно хорошо документирован, и не так много его реализаций», — говорит Крикет Лю из Infoblox. На самом деле мы смогли найти только единственный клиент в активной разработке — это DNSCrypt Proxy, а OpenDNS прекратил поддерживать его разработку.

Интересный выбор криптографии в DNSCrypt может напугать некоторых разработчиков. Протокол использует Curve25519 (RFC 8032), X25519 (RFC 8031) и Chacha20Poly1305 (RFC 7539). Одна реализация алгоритма X24419 в криптографических библиотеках Pyca Python помечена как «криптографически опасная», потому что с ней очень легко ошибиться в настройках. Но основной используемый криптографический алгоритм Curve25519, является «одной из самых простых эллиптических кривых для безопасного использования», — сказал Денис.

Разработчик говорит, что DNSCrypt никогда не считался стандартом IETF, потому что был создан добровольцами без корпоративной «крыши». Представление его в качестве стандарта «потребовало бы времени, а также защиты на заседаниях IETF», — сказал он. «Я не могу себе этого позволить, как и другие разработчики, которые работают над ним в свободное время. Практически все ратифицированные спецификации, связанные с DNS, фактически написаны людьми из одних и тех же нескольких компаний, из года в год. Если ваш бизнес не связан с DNS, то действительно тяжело получить право голоса».

TLS стал приоритетом для CloudFlare, когда понадобилось усилить шифрование веб-трафика для защиты от слежки

У DNS по TLS (Transport Layer Security) несколько преимуществ перед DNSCrypt. Во-первых, это предлагаемый стандарт IETF. Также он довольно просто работает по своей сути — принимает запросы стандартного формата DNS и инкапсулирует их в зашифрованный TCP-трафик. Кроме шифрования на основе TLS, это по существу то же самое, что и отправка DNS по TCP/IP вместо UDP.

Существует несколько рабочих клиентов для DNS по TLS. Самый лучший вариант, который я нашел, называется Stubby, он разработан в рамках проекта DNS Privacy Project. Stubby распространяется в составе пакета Linux, но есть также версия для MacOS (устанавливается с помощью Homebrew) и версия для Windows, хотя работа над последней ещё не завершена.

Хотя мне удалось стабильно запускать Stubby на Debian после сражения с некоторыми зависимостями, этот клиент регулярно падал в Windows 10 и имеет тенденцию зависать на MacOS. Если вы ищете хорошее руководство по установке Stubby на Linux, то лучшая найденная мной документация — это пост Фрэнка Сантосо на Reddit. Он также написал shell скрипт для установки на Raspberry Pi.

Положительный момент в том, что Stubby допускает конфигурации с использованием нескольких служб на основе DNS по TLS. Файл конфигурации на YAML позволяет настроить несколько служб IPv4 и IPv6 и включает в себя настройки для SURFNet, Quad9 и других сервисов. Однако реализация YAML, используемая Stubby, чувствительна к пробелам, поэтому будьте осторожны при добавлении новой службы (например, Cloudflare). Сначала я использовал табы — и всё поломал.

Клиенты DNS по TLS при подключении к серверу DNS осуществляют аутентификацию с помощью простой инфраструктуры открытых ключей (Simple Public Key Infrastructure, SPKI). SPKI использует локальный криптографический хэш сертификата провайдера, обычно на алгоритме SHA256. В Stubby этот хэш хранится как часть описания сервера в файле конфигурации YAML, как показано ниже:

После установления TCP-соединения клиента с сервером через порт 853 сервер представляет свой сертификат, а клиент сверяет его с хэшем. Если всё в порядке, то клиент и сервер производят рукопожатие TLS, обмениваются ключами и запускают зашифрованный сеанс связи. С этого момента данные в зашифрованной сессии следуют тем же правилам, что и в DNS по TCP.

После успешного запуска Stubby я изменил сетевые настройки сети DNS, чтобы направлять запросы на 127.0.0.1 (localhost). Сниффер Wireshark хорошо показывает этот момент переключения, когда трафик DNS становится невидимым.

Переключаемся с обычного трафика DNS на шифрование TLS

Хотя DNS по TLS может работать как DNS по TCP, но шифрование TLS немного сказывается на производительности. Запросы dig к Cloudflare через Stubby у меня выполнялись в среднем около 50 миллисекунд (у вас результат может отличаться), в то время как простые DNS-запросы к Cloudflare получают ответ менее чем за 20 мс.

Здесь тоже имеется проблема с управлением сертификатами. Если провайдер удалит сертификат и начнёт использовать новый, то в настоящее время нет чистого способа обновления данных SPKI на клиентах, кроме вырезания старого и вставки нового сертификата в файл конфигурации. Прежде чем с этим разберутся, было бы полезно использовать какую-то схему управления ключами. И поскольку сервис работает на редком порту 853, то с высокой вероятностью DNS по TLS могут заблокировать на файрволе.

Google и Cloudflare, похоже, одинаково видят будущее зашифрованного DNS

Как Cloudflare, мы считаем, что туннели иллюстрируют операцию «Арго» лучше, чем Бен Аффлек

Дабы убедиться, что проблема именно в протоколе DoH, а не в программистах Cloudflare, я испытал два других инструмента. Во-первых, прокси-сервер от Google под названием Dingo. Его написал Павел Форемски, интернет-исследователь из Института теоретической и прикладной информатики Академии наук Польши. Dingo работает только с реализацией DoH от Google, но его можно настроить на ближайшую службу Google DNS. Это хорошо, потому что без такой оптимизации Dingo сожрал всю производительность DNS. Запросы dig в среднем выполнялись более 100 миллисекунд.

Это сократило время отклика примерно на 20%, то есть примерно до того показателя, как у Argo.

А оптимальную производительность DoH неожиданно показал DNSCrypt Proxy 2. После недавнего добавления DoH Cloudflare в курируемый список публичных DNS-сервисов DNSCrypt Proxy почти всегда по умолчанию подключается к Cloudflare из-за низкой задержки этого сервера. Чтобы убедиться, я даже вручную сконфигурировал его под резолвер Cloudflare для DoH, прежде чем запустить батарею dig-запросов.

Все запросы обрабатывались менее чем за 45 миллисекунд — это быстрее, чем собственный клиент Cloudflare, причём с большим отрывом. С сервисом DoH от Google производительность оказалась похуже: запросы обрабатывались в среднем около 80 миллисекунд. Это показатель без оптимизации на ближайший DNS-сервер от Google.

Я не Бэтмен, но моя модель угроз всё равно немного сложнее, чем у большинства людей

Я профессиональный параноик. Моя модель угроз отличается от вашей, и я предпочел бы сохранить в безопасности как можно больше своих действий в онлайне. Но учитывая количество нынешних угроз приватности и безопасности из-за манипуляций с трафиком DNS, у многих людей есть веские основания использовать какую-либо форму шифрования DNS. Я с удовольствием обнаружил, что некоторые реализации всех трёх протоколов не оказывают сильно негативного влияния на скорость передачи трафика.

Другая проблема в том, что, хотя прекрасные ребята из сообщества DNSCrypt проделали большую работу, но такая приватность по-прежнему слишком сложна для обычных людей. Хотя некоторые из этих DNS-клиентов для шифрования оказалось относительно легко настроить, но ни один из них нельзя назвать гарантированно простым для нормальных пользователей. Чтобы эти услуги стали действительно полезными, их следует плотнее интегрировать в железо и софт, который покупают люди — домашние маршрутизаторы, операционные системы для персональных компьютеров и мобильных устройств.

Интернет-провайдеры наверняка постараются активнее монетизировать обычный DNS-трафик, и никуда не исчезнут государственные агентства и преступники, которые стремятся использовать его во вред пользователю. Но маловероятно, что крупные разработчики ОС стремятся надёжно защитить DNS доступным для большинства людей способом, потому что они часто заинтересованы в монетизации, как и интернет-провайдеры. Кроме того, эти разработчики могут столкнуться с сопротивлением изменениям со стороны некоторых правительств, которые хотят сохранить возможности мониторинга DNS.

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

Постепенно рассмотрим разные варианты настройки распределения нагрузки в NGINX. Начнем с простого понимания, как работает данная функция и закончим некоторыми примерами настройки балансировки.

Основы

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

* в данном примере мы создаем файл upstreams.conf, в котором можем хранить все наши апстримы. NGINX автоматически читает все конфигурационные файлы в каталоге conf.d.

upstream dmosk_backend server 192.168.10.10;
server 192.168.10.11;
server 192.168.10.12;
>

* предполагается, что в нашей внутренней сети есть кластер из трех веб-серверов — 192.168.10.10, 192.168.10.11 и 192.168.10.12. Мы создали апстрим с названием dmosk_backend. Позже, мы настроим веб-сервер, чтобы он умел обращаться к данному бэкенду.

В настройках сайта (виртуального домена) нам необходимо теперь проксировать запросы на созданный upstream. Данная настройка будет такой:

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

Проверяем корректность нашего конфигурационного файла:

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

systemctl restart nginx

Приоритеты

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

Синтаксис при указании веса:

server <имя сервера> weight=<числовой эквивалент веса>;

По умолчанию приоритет равен 1.

Также мы можем указать опции:

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

Давайте немного преобразуем нашу настройку upstreams:

upstream dmosk_backend server 192.168.10.10 weight=100 ;
server 192.168.10.11 weight=10 ;
server 192.168.10.12;
server 192.168.10.13 backup ;
>

* итак, мы указали нашему серверу:

переводить на сервер 192.168.10.10 в 10 раз больше запросов, чем на 192.168.10.11 и в 100 раз больше — чем на 192.168.10.12.
переводить на сервер 192.168.10.11 в 10 раз больше запросов, чем на 192.168.10.12.
на сервер 192.168.10.13 запросы переводятся, только если не доступны все три сервера.

Задержки, лимиты и таймауты

Изменить поведение лимитов и ограничений при балансировке можно с помощью опций:

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

server <имя сервера> max_fails=<число попыток> fail_timeout=<числовой показатель времени><еденица времени>;

В нашем примере мы преобразуем настройку так:

upstream dmosk_backend server 192.168.10.10 weight=100 max_conns=1000 ;
server 192.168.10.11 weight=10 max_fails=2 fail_timeout=90s ;
server 192.168.10.12 max_fails=3 fail_timeout=2m ;
server 192.168.10.13 backup;
>

сервер 192.168.10.10 будет принимать на себя, максимум, 1000 запросов.
сервер 192.168.10.10 будет иметь настройки по умолчанию.
если на сервер 192.168.10.11 будет отправлено 2-е неудачные попытки отправки запроса, то в течение 90 секунд на него не будут отправлять новые запросы.
сервер 192.168.10.12 будет недоступен в течение 2-х минут, если на него будут отправлены 3 неудачных запроса.

Метод балансировки

Рассмотрим способы балансировки, которые можно использовать в NGINX:

Round Robin.
Hash.
IP Hash.
Least Connections.
Random.
Least Time (только в платной версии NGINX).

Настройка метода балансировки выполняется в директиве upstream. Синтаксис:

upstream <название апстрима> <метод балансировки>
.
>

Round Robin

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

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

upstream dmosk_backend hash $scheme$request_uri;
server 192.168.10.10;
server 192.168.10.11;
server 192.168.10.12;
>

IP Hash

Для адресов IPv4 учитываются только первые 3 октета — это позволяет поддерживать одинаковые соединения с клиентами, чьи адреса меняются (получение динамических адресов от DHCP провайдера). Для адресов IPv6 учитывается адрес целиком.

upstream dmosk_backend ip_hash;
server 192.168.10.10;
server 192.168.10.11;
server 192.168.10.12;
>

Least Connections

NGINX определяет, с каким бэкендом меньше всего соединений в данный момент и перенаправляет запрос на него (с учетом весов).

Настройка выполняется с помощью опции least_conn:

upstream dmosk_backend least_conn;
server 192.168.10.10;
server 192.168.10.11;
server 192.168.10.12;
>

Random

Запросы передаются случайным образом (но с учетом весов). Дополнительно можно указать опцию two — если она задана, то NGINX сначала выберет 2 сервера случайным образом, затем на основе дополнительных параметров отдаст предпочтение одному из них. Это следующие параметры:

least_conn — исходя из числа активных подключений.
least_time=header (только в платной версии) — на основе времени ответа (расчет по заголовку).
least_time=last_byte (только в платной версии) — на основе времени ответа (расчет по полной отдаче страницы).

upstream dmosk_backend random two least_conn;
server 192.168.10.10;
server 192.168.10.11;
server 192.168.10.12;
>

Least Time

Данная опция будет работать только в NGINX Plus. Балансировка выполняется исходя из времени ответа сервера. Предпочтение отдается тому, кто отвечает быстрее.

Опция для указания данного метода — least_time. Также необходимо указать, что мы считаем ответом — получение заголовка (header) или когда страница возвращается целиком (last_byte).

upstream dmosk_backend least_time header;
server 192.168.10.10;
server 192.168.10.11;
server 192.168.10.12;
>

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

upstream dmosk_backend least_time last_byte;
server 192.168.10.10;
server 192.168.10.11;
server 192.168.10.12;
>

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

Сценарии настройки

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

Настройка сайта:

* обратите внимание на 2 момента:

Настройка upstream:

upstream dmosk_backend server 192.168.10.10:443;
server 192.168.10.11:443;
server 192.168.10.12:443;
>

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

2. Разные бэкенды для разных страниц

Нам может понадобиться разные страницы сайта переводить на разные группы внутренних серверов.

Настройка сайта:

* при такой настройке мы будем передавать запросы к странице page1 на группу backend1, а к page2 — backend2.

Настройка upstream:

upstream backend1 server 192.168.10.10;
server 192.168.10.11;
>

upstream backend2 server 192.168.10.12;
server 192.168.10.13;
>

* в данном примере у нас есть 2 апстрима, каждый со своим набором серверов.

3. На другой хост

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

Настройка сайта:

4. TCP-запрос

Рассмотрим, в качестве исключения, TCP-запрос на порт 5432 — подключение к базе PostgreSQL.

Настройка сайта:

server listen 5432;
proxy_pass tcp_postgresql;
>

* в данном примере мы слушаем TCP-порт 5432 и проксируем все запросы на апстрим tcp_postgresql.

Настройка upstream:

upstream tcp_postgresql server 192.168.10.14:5432;
server 192.168.10.15:5432;
>

* запросы будут случайным образом передаваться на серверы 192.168.10.14 и 192.168.10.15.

5. UDP-запрос

Рассмотрим также и возможность балансировки UDP-запросов — подключение к DNS по порту 53.

Настройка сайта:

server listen 53 udp;
proxy_pass udp_dns;
proxy_responses 1;
>

* в данном примере мы слушаем UDP-порт 53 и проксируем все запросы на апстрим udp_dns. Опция proxy_responses говорит о том, что на один запрос нужно давать один ответ.

Настройка upstream:

upstream udp_dns server 192.168.10.16:53;
server 192.168.10.17:53;
>

* запросы будут случайным образом передаваться на серверы 192.168.10.16 и 192.168.10.17.

Читайте также: