dadv: (chuck)

Стандартная ситуация: локальная сеть с маршрутизатором, один публичный IP, для выхода в мир используется NAT. Плюс на маршрутизаторе работает кеширующий DNS-сервер для локальной сети. Всё работает.

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

А ведь DNS-сервер, выполняя запросы к внешним серверам, для исходящих запросов сам использует динамические UDP-порты и ожидает ответ на них. Например, ISC BIND под FreeBSD использует sysctl net.inet.ip.portrange.hifirst и net.inet.ip.portrange.hilast для определения диапазона таких эфемерных портов, по умолчанию это 49152-65535. Пока этот диапазон не пересекается с диапазоном проброшенных внутрь локалки портов, всё будет в порядке. Но стоит лишь пробросить, скажем, порты 40000-65535, и наступает катастрофа. В случае FreeBSD проброс портов "имеет приоритет выше" (выполняется раньше, чем доставка локальным приложениям) и проброс-то работать будет, но DNS-сервер остается без DNS-ответов на свои запросы, которые теперь уходят по пробросу локальному хосту, которому они и не нужны вовсе. И вся локальная сеть остаётся без локального DNS-сервиса.

Решением будет либо изменить диапазон проброшенных портов, если это допустимо для сервера в локальной сети, а если нет - изменить диапазон эфемерных портов для DNS-сервера. Кроме изменения системного дефолта, ISC BIND позволяет задать этот диапазон в собственной конфигурации:

use-v4-udp-ports { range 10000 30000; };

Аналогично для IPv6. Для защиты от некоторых типов атак, BIND каждый раз выбирает случайный порт из диапазона и рекомендуется, чтобы диапазон был достаточно большим, минимум 16384 портов (14 бит энтропии).

dadv: (chuck)

Открыл для себя, что named читает ключ rndc.key (нужен, в частности, чтобы работала команда rndc) только из каталога, заданного при компиляции пакета и не имеет опции командной строки для переопределения пути к ключу.

Например, пакет bind910 для FreeBSD 10 нынче собирается с путем конфигурационных файлов /usr/local/etc/namedb и это неудобно, если хочется запускать named в chroot, где иерархия /usr/local вообще не нужна. Средствами /etc/rc.conf можно переопределить путь к named.conf внутри chroot, но нельзя к rndc.conf. Можно это сделать настройками самого named.conf, хотя и неочевидным образом. Перед стандартной секцией options добавляем команды:


include "/etc/namedb/rndc.key";
controls { inet 127.0.0.1 port 953 allow { any; } keys { rndc-key; }; };


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

В итоге для того, чтобы установленный из портов/пакетов named в FreeBSD 10 работал в chroot так же, как до этого он работал в составе базовой системы FreeBSD 9 и ранее, в /etc/rc.conf остаётся прописать:

named_enable="YES"
named_conf="/etc/namedb/named.conf"
named_chrootdir="/var/named"
named_symlink_enable="YES"

dadv: (chuck)

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

Детально проблема расписана в базе знаний ISC (наш случай - пункт 4. DNS queries/responses using EDNS are allowed, but UDP fragmentation and reassembly is broken), но решение достаточно простое - настроить свой DNS-сервер сообщать другим серверам не посылать требующие фрагментации ответы. Этакий аналог TCP adjust mss, но для DNS через UDP. Более крупные ответы будут доставляться сразу по TCP вместо UDP.

Для сервера BIND достаточно прописать в секции options:

options {
  edns-udp-size 1432;
}

dadv: (Default)

openssl-1.0.0_5 из свежих портов на FreeBSD 4.11 собирается без проблем, но при установке вылетает в самом конце:

===>   Compressing manual pages for openssl-1.0.0_5
/bin/sh:Argument list too long
*** Error code 1

На 4.11 максимальная длина командной строки 64K, на свежих версиях 256K и список манов openssl не влазит в 64K. Пришлось патчить sys/sys/syslimits.h на удаленном сервере и пересобирать ядро - всё взлетело и make install для openssl прошел нормально. А затем и bind-9.8.0.4 с openssl 1.0.0d собрался и запустился без проблем, если знать, что он вообще вместе с этой версией openssl в chroot работает, только если смонтировать /usr/local/lib внутрь chroot (read-only nullfs mount).

dadv: (Default)
Подняли шухер по поводу отроду дырявого DNS.
Решил, что повод неплохой и поставил bind 9.5.0-P1 почти на десяток боевых FreeBSD 4.11-STABLE, некоторые из них заодно и обновил до последней RELENG_4 (получив, например, sendmail 8.14 вместо 8.13). Обновление прошло на удивление гладко везде - делается совершенно механически:

cd /usr/ports/dns/bind95
make all install clean
rndc-confgen -a
chgrp bind /usr/local/etc/rndc.key
chmod g+r /usr/local/etc/rndc.key
chgrp bind /etc/namedb
chmod +t,g+w /etc/namedb
echo 'named_program="/usr/local/sbin/named"' >> /etc/rc.conf
echo 'named_flags="-u bind -c /etc/namedb/named.conf"' >> /etc/rc.conf
killall named; sleep 1; /usr/local/sbin/named -u bind -c /etc/namedb/named.conf


Лишь в одном месте в named.conf была секция logging{}, её пришлось переписать - во всех других местах конфиги не менял вообще. Всё работает. Да, а named.root уже был везде обновлен по ftp.

Profile

dadv: (Default)
Choose your future

June 2017

M T W T F S S
   1234
56 7891011
12131415161718
19202122232425
2627282930  

Syndicate

RSS Atom

Tags

Style Credit

Powered by Dreamwidth Studios