Openbsd настройка dns сервера

Обновлено: 04.07.2024

Популяризация OpenBSD, часть2 (dns, TimeMachine, Samba, ftpd, smtp+imap, pptp+l2tp)

Полезные советы и программы от пользователей нашего форума.

Популяризация OpenBSD, часть2

Привет! Очередной раз постараюсь простым языком рассказать как настроить простые сервисы в опенке.
Перед этим обращу внимание на различия FreeBSD и OpenBSD которые лично мне показались достаточными чтобы использовать именно опенку.
FreeBSD конечно хороша, особенно в плане поддержки оборудования и работы с дисками. Однако весь сетевой софт, который вызывает интерес (это тот же pf, openssh, opensmtpd, npppd) пишется прежде всего под опенку, а потом уже портируются во FreeBSD.
Кроме того это ещё вопрос кому что удобнее. Я долгое время пользуюсь OpenBSD и она мне по нраву гораздо больше любых других систем. Потому что с ней никогда не бывает проблем.

DNS:
В дефолтной установке OpenBSD в составе системы для организации dns идут unbound и nsd. Поскольку я всё таки ориентируюсь на новичков, объясняю чем они отличаются.
Говоря простым языком,
Nsd - это авторитативный dns сервер. Авторитативный dns север - это dns сервер, который отвечает только за свою зону (или несколько зон). И бесполезно спрашивать у него про другие зоны.
Unbound - это кэширующий сервер. Кэширующий сервер, это сервер который обслуживает клиентов. И у него можно спросить про любую зону, однако управлять своей зоной как nsd он не может.

Логично и правильно определение, что если мы настраиваем NSD, то у нас есть реальный ip адрес, чтобы регистратор мог работать с нашим dns сервером.
Существуют ситуации когда невозможно держать dns сервер на реальном ip адресе. В таком случае сервер размещается внутри сети, и на него осуществляется редирект tcp и udp порта 53 со внешнего шлюза.
Это уже не такой каноничный способ, но я рассмотрю и его.

У нас есть дефолтная установка OpenBSD с настроенными ip адресами, пусть это будет 1.2.3.4 внешний, и 192.168.0.1 внутренний адрес.
Всё что нужно для работы nsd в опенке лежит в директории


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

А потом в конце файла добавить описание зон. Пусть это будет зона foo.bar:

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

В нескольких следующих строках опущен знак @ в начале строки. Поскольку иных знаков там нет, подразумевается что мы всё ещё описываем зону @ (то есть foo.bar.)
IN NS это описание dns сервера который будет описывать нашу зону. Сюда должны входить все сервера, как первичные, так и вторичные.
IN A это ip адрес самой зоны.
IN MX 10 это описание почтового сервера для зоны.
После чего мы уже описываем не зону foo.bar., а узел ns. мы указываем что узел ns.foo.bar. это мнемоническое имя foo.bar.
Обратите внимание на точки. Точка ставится если описывается полное имя (например ns.foo.bar.), если описывается короткое имя (например ns, тогда точка не ставится)

Теперь у нас есть всё для запуска nsd, и его можно запустить, не забыв добавить в /etc/rc.conf.local строку nsd_flags=""
запускаем командой

В первой части статьи была информация как включить unbound. Тогда я привязал его к локальному ip адресу. Теперь получается что у нас запущены сразу два dns. Один для клиентов локальной сети, другой авторитетный для управления своей зоной.
Но нужно подсказать unbound чтобы спрашивал про нашу зону, на нашем же сервере. Для этого добавим в конец конфига unbound следующую запись:

Кроме того, иногда бывает что у провайдеров есть такие штуки как retracker.local, если это имеет место, следует добавить так же форвард зоны .local на сервер провайдера.
Если например у провайдера dns имеет адрес 10.10.10.10 то запись будет такой:

Всё, теперь всё работает как нужно!
Но вначале я упоминал что бывает такое, что невозможно расположить dns на сервере с реальным ip. В этом случае необходимо либо располагать unbound и nsd на разных машинах в сети, либо присвоить одной машине сразу два ip адреса, и привязать nsd к одному адресу, а unbound к другому.
Предположим что это OpenBSD машина с адресом 192.168.0.10 и сетевой картой intel.
Тогда в /etc/hostname.em0 добавляем ещё один ип чтобы оно выглядело примерно так:

И теперь привязать nsd например к алиасу а unbound к основному ip. Тогда нужно будет на шлюзе пробросить tcp и udp порт 53 на ип адрес 192.168.0.11.

Я время от времени вижу рецепты, как например повесить nsd на порт 5353 а unbound будет слушать на всех интерфейсах и соотвественно отвечать на все запросы. Это крайне не тепло, и уж тем более не лампово! Так делать не следует.

Вроде бы про настройку dns я вкратце рассказал.
Следующий пункт TimeMachine. Сейчас маки стали довольно популярны. И с помощью OpenBSD можно реализовать хранилку для TimeMachine. Для этого нужно установить пакет netalalk


В OpenBSD 5.7 так же будет добавлен пакет netatalk3 с версией 3.1.7 и конфигурация будет немного отличатся.
Сначала создаём где-нибудь на диске папку где всё наше богатство будет хранится.
Допустим это будет /somewhere

Теперь редактируем /etc/netatalk/AppleVolumes.default добавляя в конец:

Тут видно что мы разрешаем доступ только юзеру myuser
Обратите так же внимание на вот этот кусочек:

Он находится почти сразу над концом файла.
Такая настройка выключает домашние директории (

) и устанавливает опции для каждой шары.
Дополнительно, если речь идёт о домашнем сервере следует обеспокоится об ограничении доступа. Хоть мы и заблокировали доступ ко всему в первой части статьи, можно дополнительно указать серверу слушать только на локальном интерфейсе, отредактировав /etc/netatalk/afpd.conf вот так:

uams_dhx предполагает что мы авторизовываем клиентов через /etc/passwd.
Поэтому следует добавить нового пользователя (исходя из AppleVolumes.default это будет myuser), но учитывать что для того чтобы netatalk правильно работал, нужно чтобы этот юзер был в группе wheel и у него был настроен нормальный shell, не nologin!
С чем связаны такие ограничения сказать не могу т.к. не смог найти какой либо описания проблемы.
Добавляем пользователя:

Всё, теперь можно запускать
/etc/rc.d/netatalk start
и пробовать логинится. Если увидим шару TimeMachine значит всё работает.
Возможно netatalk3 перестанет требовать пользователя из группы wheel, однако пока что ситуация такова.

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


Весь конфиг и всё что нужно он будет хранить в:
/var/transmission.
Добавим в /etc/rc.conf.local

Теперь можно редактировать settings.json по своему усмотрению. Не буду рассказывать как, тут у каждого свои предпочтения. Важно что нельзя его редактировать пока трансмишен включен. При перезапуске он его перепишет. Редактировать можно только после выключения.

Родной ftpd. Не мудрёная штучка. Он работает с пользователями в passwd, никаких виртуальных, никаких сложных настроек. Для работы родного ftpd в режиме анонимуса, достаточно просто добавить пользователя ftp c шеллом /usr/bin/false а потом добавить /usr/bin/false в список шеллов, /etc/shells.
Для запуска используем /etc/rc.conf.local добавляя туда:
ftpd_flags="-4A"
Это позволит заходить и под анонимусом, и под системными пользователями.

Предположим что для пользователя ftp домашняя директория установлена в /somewhere/ftp, а для transmission вы установили директорию для скачивания в /somewhere/torrent

Тогда мы можем установить самбу

Этого необходимо и достаточно чтобы иметь доступ из локальной сети к нужным файлам. Не забываем конечно назначить пользователей

И перед тем как приступить к описанию простого почтового сервера, кратко опишу pptp и l2tp.

После чего в pf.conf нужно (или не нужно?) добавить строку для раздачи интернета vpn клиентам.
pass out on $wan inet from 192.168.200.0/24 received-on pppx nat-to $wan:0

И наконец про почтовый сервер.

Вообще настройка почты это сложная задача для любого системного администратора. К счастью с приходом OpenSMTPD жить стало проще, хотя в нём и недостаёт некоторых функций, он всё равно очень хорош!
Сначала небольшой экскурс для новичков простым языком, как же вообще работает электронная почта.
Прежде всего необходимо понимать, что smtp сервер и imap это разные сервисы. Электронной почтой можно пользоваться и вовсе без imap или pop. Говоря простым языком, почта хранится на серверах И метод передать почту с одного сервера на другой, это smtp.
Давайте подробнее изучим что происходит при передаче письма и в чём основная сложность.

Допустим письма доставлены и лежать на сервере, но как их теперь прочитать? А тут уже работает pop3/imap сервер, который позволяет вам читать корреспонденцию лежащую на сервере.

Для создания простого почтового сервера нам понадобится установить dovecot, он будет служить pop3/imap сервером.

Dovecot является одним из тех крупных рогатых серверов, которые любят съесть системных ресурсов побольше. В OpenBSD для каждого процесса и пользователя установлены ограничения на количество открытых файлов и объём потребляемой памяти.
Нужно расширить для довекота эти объёмы. Для этого в конец /etc/login.conf дописываем:

Первая колонка описывает рамки для демона который запустится через /etc/rc.d/dovecot. Имя файлика для запуска определяет имя колонки которую нужно вписать. Вторая колонка определяет ресурсы для пользователя _dovecot.
Настроенный по умолчанию dovecot будет искать письма в

/Maildir чего нам на данном этапе достаточно. Авторизацию будем проводить как и в примерах ранее через системных пользователей.

Для правильной работы smtp следует размещать его там, где есть реальный ip адрес. Возможно так же расположение и внутри сети, но лучше и проще чтобы он был запущем на внешнем ip адресе.
Конфигурация opensmtpd очень проста, но сначала нужно сгенерировать сертификат и ключ для сервера, я буду надеятся что читатель сделает это самостоятельно т.к. я по памяти не вспомню.
Редактируем /etc/mail/smtpd.conf:

Последним делом нужно настроить проверку спама. Для этого устанавливаем procmail и spamassassin

Такая настройка сначала передаёт письма спам фильтру, если они размером больше чем 512000 байт.
Далее возвращенные письма идут по цепочке и проверяется заголовок X-Spam-Level. В этом заголовке куча звёздочек. Если из больше чем 11 письмо абсолютно точно спам и отправляется в мусор.
Далее проверяется заголовок X-Spam-Status. Если звёздочек меньше 11 но статус письма спам, то его нужно положить в папку Junk
Последняя строка отдаёт довекотовскому деливеру все остальные письма.

Нужно включить спамассассин и настроить его на обновления.
/etc/rc.d/spamassassin start
а в
/etc/daily.local добавляем:

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

ДОПОЛНЕНО 16.10.2016

Немного хочу добавить про netatalk. Как я уже говорил в OpenBSD 5.7 добавлен netatalk версии 3.1.7. Его конфиг отличается, кроме того удалось решить проблему с друппой wheel и shell что создавало небольшие но потенциальные проблемы безопасности.
Во первых конфиг был многократно упрощён. Теперь Он выглядит так:

Обратите особое внимание на самый конец. appledouble = v2. эта опция нужна т.к. это опция чтобы нетаталк не ругался на невозможность записи extended attributes.
Теперь можно вынуть пользователя из группы wheel и просто сделать папку /etc/netatalk читаемой для всех.

Что же с шеллом, можно установить шелл /usr/bin/false. Как показала практика с ним всё работает.

This is my network.

It is mine
or technically my employer's,
it is my responsibility
and I care for it with all my heart

there are many other networks a lot like mine,
but none are just like it.

I solemnly swear
that I will not mindlessly paste from HOWTOs.

Клятва системного администратора.
(c) Peter N. M. Hansteen[6]

Как уже было сказано в первой части, правильно настроенный DNS поможет избежать многих трудностей. Настройка DNS-сервера named(8) по-умолчанию - работает, но простой кэширующий сервер - это только вершина айсберга. Настройка проведена по мотивам статей [1] и [3], сверяясь с [4].

1. Простая настройка dhcpd(8)

* Данный параметр не является обязательным, но так удобнее.
** О настройке NTP сервера читать часть 4. WinXP так и не удалось заставить использовать эту опцию.

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

Листинг 1.1. Конфигурационный файл dhcpd.conf(5)


Запускаем dhcpd(8) на внутреннем интерфейсе и проверяем его работоспособность.


Если все проверки прошли успешно, добавляем автоматический запуск.


Осталось настроить узлы внутри сети на автоматическое получение настроек через DHCP.

2. Более тонкая настройка DNS-сервера

Основные задачи, которые решались при доведении стандартного конфига:
1. использование только IPv4 (отключить IPv6);
2. управление сервером только локально;
3. выполнение запросов только из локальной (внутренней) сети;
4. разрешение всех имен через корневые сервера (рекурсивные запросы);
5. разрешение имен из зоны провайдера через DNS-сервера провайдера;
6. поддержка зоны internal.lan и обратной зоны 0.168.192.in-addr.arpa - локальная сеть.

Некоторые комментарии относительно каждого пункта:
1. IPv6 не используется в моей сети, а лишние сервисы - это дыра в системе безопасности;
2. управлять DNS-сервером буду только со шлюза - еще один элемент безопасности;
3. без комментариев;
4. защита от проблем с сервером провайдера (если его скомпрометируют);
5. сохранение возможности работать с внутренними ресурсами провайдера, если с внешними будут проблемы.
6. поддерживать внутреннюю зону - полезно;

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

Здесь и далее предполагается, что локальный DNS-сервер запущен (см. Часть 1). Пойдем по порядку и выполним первые четыре пункта. В результате получили следующий конфигурационный файл.

Листинг 2.1. Первая версия named.conf(5)


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


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


Далее, во исполнении пункта первого, отредактируем rc.conf.local, что бы named(8) запускался с поддержкой только IPv4.


Теперь, вручную, перезапустим named(8) с новыми параметрами.


Теперь настроим разрешение имен сети провайдера, в первую очередь, через DNS-сервера провайдера, для этого добавим дополнительную зону в named.conf(5). Тип зоны установим "forward" и разрешим выполнять рекурсивный запрос, если DNS сервер провайдера упадет.

Листинг 2.6. Разрешение имен через DNS-сервер провайдера

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

Листинг 2.7. Полный конфигурационный файл named.conf(5) c поддержкой DNS провайдера


Далее проверяем синтаксис и применяем новые настройки (листинг 2.2, листинг 2.3). Теперь самая интересная часть, добавим поддержку DNS для локальной сети. Перед добавлением зон в named.conf(5), напишем сами зоны и сохраним в /var/named/master.
Написание зоны задача непростая, но данный процесс хорошо описан в [5], а подглядывание в [4] сделает задачу элементарной.

Листинг 2.8. Описание зоны "internal.lan"

Листинг 2.9. Описание зоны "0.168.192.in-addr.arpa"


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


Если проверка прошла успешно, переходим к добавлению зон в named.conf(5). Потребуется добавить две зоны, для которых данный сервер будет мастером. Итоговая конфигурация представлена в листинге 2.11.

Листинг 2.11. Конфигурация с поддержкой внутренних зон (прямой и обратной)


Проверяем синтаксис и применяем новую конфигурацию (листинг 2.2, листинг 2.3). Теперь можно проверить работоспособность данной конфигурации.

Name: gate.internal.lan
Address: 192.168.0.254

254.0.168.192.in-addr.arpa name = gate.internal.lan.


Теперь необходимо проверить работу с одного из узлов локальной сети. После завершения проверок файлы зон можно дополнить описанием новых узлов в сети, по примеру "gate.internal.lan" (одна A запись в прямой зоне и одна PTR запись в обратной зоне).
Для проверки зон, которые поддерживает named(8), подойдет следующая последовательность действий.


3. Динамическое обновление DNS-записей для локальной сети

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


Сервер будет установлен в /usr/local. Теперь необходимо решить вопрос с его автоматическим запуском и при этом избежать конфликта с уже установленным DHCP-сервером. Автор [1] предлагает заменить бинарные файлы старого сервера на новые. Но можно пойти другим путем: дописать команды запуска в rc.local и использовать конфигурационный файл с другим именем, например - dhcpd-isc.conf. Но все по порядку. Начнем с того, что создадим конфигурационный файл для нового сервера. Для этого скопируем старый файл (см. разд. 1.) и после глобальных параметров добавим строку "ddns-update-style none;". В результате должен получиться конфигурационный файл следующего содержания.

Листинг 3.2. Конфигурационный файл для нового DHCP-сервера


Проверим работоспособность сервера, перед этим остановив встроенный.

Листинг 3.4. Код автозапуска нового DHCP-сервера


Данный код позволяет запускать новый сервер не конфликтуя со старым, единственный минус в том, что параметр dhcpd_isc_flags должен быть равен "NO" или должен отсутствовать файл /etc/dhcpd-isc.conf для того, что бы сервер не запустился. Т.е. для прекращения его автоматического запуска придется приложить некоторые усилия (простым удалением строки не обойтись), но новый сервер ставят и прописывают на автозапуск не для того, что бы держать выключенным.

После этого удаляем строку "dhcpd_flags" из rc.conf.local (для избежания конфликтов) и добавляем параметр dhcpd_isc_flags с указанием интерфейса для автоматического запуска.


Единственным способом проверить работоспособность конфигурации - перезагрузить систему. Если все прошло нормально и сервер успешно раздает адреса, то переходим к связыванию DHCP- и DNS-серверов. В начале создадим новый ключ для взаимодействия dhcpd и named.


Создадим новый файл в /var/named/etc, который будет содержать сгенерированный ключ, следующего содержания.

Листинг 3.7. Новый ключ для named(8)


Не забываем о владельце и правах доступа.


Перед разрешением обновления зон необходимо установить корректные права доступа [1,3].


Далее необходимо подключить новый ключ к named.conf(5) и разрешить обновление зон "internal.lan" и "0.168.192.in-addr.arpa".

Листинг 3.10. Измененный named.conf(5)


Проверяем синтаксис и применяем новую конфигурацию.


Теперь скопируем ключ dhcp.key в директорию /etc (не забывая о правах).

В результате получим следующий конфигурационный файл.

Листинг 3.13. Конфигурационный файл DHCP-сервера с поддержкой обновления DNS-записей


Перезапускаем DHCP-сервер и проверяем, обновляются ли данные при выделении адреса узлу.

Внимание: записи для узлов со статически указанным IP-адресом обновляться не будут. Такие записи необходимо вручную внести в файлы зон.

4. Список литературы

размещено: 2010-03-01,
последнее обновление: 2010-10-15,
автор: BlackCat

konstantine, 2010-10-15 в 4:45:02

Зачем это вообще надо .

BlackCat, 2010-10-15 в 8:01:10

В статье это описано, но повторюсь: "сохранение возможности работать с внутренними ресурсами провайдера, если с внешними будут проблемы". Если требуется более подробный ответ - добро пожаловать на форум (ссылка на обсуждение в конце статьи).

Этот информационный блок появился по той простой причине, что многие считают нормальным, брать чужую информацию не уведомляя автора (что не так страшно), и не оставляя линк на оригинал и автора — что более существенно. Я не против распространения информации — только за. Только условие простое — извольте подписывать автора, и оставлять линк на оригинальную страницу в виде прямой, активной, нескриптовой, незакрытой от индексирования, и не запрещенной для следования роботов ссылки.
Если соизволите поставить автора в известность — то вообще почёт вам и уважение.

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

Содержание:

Введение

Итак. Почему я выбрал в качестве основы для сервера (шлюза) именно систему OpenBSD , а не какую-то другую? Этот выбор не случайный, а вполне обоснованный, и причин для выбора данной ОС более чем достаточно. Дело в том, что до OpenBSD мне приходилось работать со многими системами (DOS, Windows , Linux , Lindows, BeOS, FreeBSD и т.д.), однако ни одна из них меня настолько не впечатлила своей простотой, целостностью, гибкостью и надёжностью как OpenBSD .
Для начала давайте определимся чего мы хотим, что конкретно и как должен делать наш сервер. Если это обычный шлюз (типа "мост"), то достаточно просто включить перенаправление сетевого трафика с одной сетевой карты на другую и всё. Делается это правкой всего двух-трёх конфигурационных файлов. Если же наш сервер должен выполнять ещё какие-то функции, то это уже сложнее, но не намного.

Установка

Возьмём более или менее стандартную ситуацию. Допустим нам нужно просто-напросто соединить локальную сеть провайдера, типа 10.135.62.0 (класса A), провод от которой приходит к нам в дом или офис, и нашу внутреннюю (локальную) сеть Ethernet, типа 172.18.7.0 (класса B), которая проложена по офису или квартире. Адреса сетей могут быть и другими (и других классов), это несущественно. Практически то же самое представляет собой соединение через ADSL- или кабельный модем, который имеет обычный сетевой выход и выполняет функцию роутера. Плюс к этому, для уменьшения точек (узлов) настройки и облегчения администрирования, на шлюз мы поставим DHCP-сервер, который будет автоматически назначать адреса всем компьютерам локальной сети. Теперь, когда задача ясна, приступим к её решению.
Для этого понадобится сделать всего 4 шага:

  1. собрать компьютер для нашего шлюза (возьмём старый IBM PC Pentium II).
  2. установить и настроить саму ОС (мы будем ставить OpenBSD 4.8 для платформы i386).
  3. настроить пересылку пакетов (трансляцию трафика) между сетевыми интерфейсамию.
  4. настроить сервер DHCP (DHCPD).

На выполнение всех этих действий уйдёт всего несколько минут! Итак, приступим.

Оборудование

Для шлюза можно взять любой старый компьютер (например, приготовленный на выброс или списанный в утиль) или, при его отсутствии, покупаем такой компьютер через Интернет или у знакомых (или берём старьё в другой организации). Стоит он копейки, или даже совсем ничего не стоит, так как это хлам. Также, можно собрать такую машину из старых запчастей, которых в организациях и у компьютерщиков, обычно, навалом! Не забудьте поставить в него 2 сетевые карты (ведь сети у нас 2).

Операционная система

Сетевые настройка

Теперь у нас есть действующий сервер с уже работающими и подключёнными сетевыми интерфейсами, если конечно Вы их правильно настроили при установке. Если нет, тоже не так страшно, просто отредактируйте конфигурационные файлы сетевых карт типа /etc/hostname.fxp0 и /etc/hostname.rtl0 (здесь предполагается, что наши сетевые карты определены как fxp0 и rtl0). Посмотреть список всех подобных файлов можно командой ls, например:

Чтобы убедиться в правильности настроек, можно вывести параметры всех сетевых интерфейсов с помощью команды ifconfig, например так:

Или же просто пустить ping на те адреса, которые вы указали в настройках, например:


10.135.62.26 - IP-адрес от Вашего провайдера или модема.

Если проверка прошла успешно, переходим к настройкам трансляции сетевого трафика между нашими сетями (NAT).

Для трансляции сетевого трафика между нашими сетями (NAT) достаточно включить forwarding (пересылку) в файле /etc/sysctl.conf:

А также настроить встроенный пакетный фильтр (pf) на работу в качестве NAT (Network Address Translation). Делается это в файле конфигурации /etc/pf.conf с помощью параметра nat-to, например так:

В данном случае мы перенаправляем весь трафик из внутренней (локальной) сети 172.18.7.0 на адрес провайдера (или модема) 10.135.62.26.
Обратите внимание на переменную $ext_if. Вместо неё должно быть подставлено название внешнего интерфейса (который подключён к сети провайдера). Обычно она определяется в самом начале pf.conf примерно следующим образом:

Ну вот и все настройки NAT-а в OpenBSD . Как видите это делается правкой всего двух конфигов, в которые нужно дописать по одной строчке. Простота и доступность - главные преимущества систем BSD !

Автозагрузка

Осталось только добавить NAT (точнее pf) в автозагрузку. Самый простой способ это сделать - найти и изменить строчку типа "pf=" в файле /etc/rc.conf, должно быть так:

После перезагрузки Вы увидите, что pf был запущен и настроен, а следовательно, все пользователи локальной сети могут подключаться к сети провайдера и наслаждаться доступом в Интернет!

DHCPD

Ну и последний штрих в настройке нашего сервера - включение и настройка DHCPD. Эта штука позволит нам автоматически раздавать IP-адреса, ограничивать количество компов в сети, а также изолировать некоторые компьютеры в отдельные сетевые группы не вставая из-за консоли сервера. Причём все настройки делаются в одном единственном файле - /etc/dhcpd.conf, например так:

В этом примере мы указываем общий для всех DNS-сервер 10.135.62.2, затем создаём подсеть (блок адресов) из 60 адресов (с 172.18.7.130 по 172.18.7.190) и прописываем для неё шлюз (маршрутизатор) 172.18.7.1. Таким образом, компьютеры локальной сети, при обращении к нашему серверу будут получать свободный адрес из указанного диапазона, шлюз 172.18.7.1 и DNS-сервер 10.135.62.2. И таких подсетей можно сделать сколько угодно с разными настройками.
Если же в этот диапазон попал, например, принтер или просто требуется жёсткая привязка компьютера к какому-то IP-адресу, тоже не проблема. Нужно всего лишь указать MAC-адрес сетевой карты этого компа и выделить ему IP, например так:

Таким образом мы делаем постоянную привязку IP-адреса 172.18.7.150 к MAC-адресу 00:12:25:2a:3c:17. То есть только компьютер (или принтер) с MAC-ом 00:12:25:2a:3c:17 будет получать IP-шник 172.18.7.150, он будет для этой машины зарезервирован. И, опять же, таких привязок можно сделать сколько угодно, хоть на всю подсеть, например так:

В этом примере зарезервированы 3 адреса: 172.18.7.140, 172.18.7.150, 172.18.7.160.
В завершение включаем автоматический запуск данного демона (службы) всё в том же /etc/rc.conf следующей строчкой:

Её просто нужно найти и поменять значение параметра.

Ну вот и всё. После перезагрузки компьютера Вы увидите запуск всех настроенных демонов (сервисов), а проверить их работу и состояние можно с помощью команды pgrep, например:

При этом на экран будет выведен номер процесса (PID) и ссылка на сам DHCP-сервер. Аналогично проверяется работа и других сервисов (демонов), запущенных в OpenBSD .

Для более расширенной настройки DHCPD демона прочтите следующую статью ISC-DHCP

Заключение

Как видите в создании сервера (шлюза) на базе операционной системы OpenBSD нет ничего сложного и страшного. Попробуйте, у Вас обязательно получится!


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

Формат файла конфигурации для 4-ой версии программы отличается от того, который применяется в восьмой и девятой версиях BIND. Учитывая, что я рассчитываю на установку нового DNS сервера, а старую версию смысла ставить не вижу, посему буду рассматривать конфиг новой версии.

Исходные данные

Для корректной работы DNS нем необходимо иметь настроенную сеть. DNS в текущей статье будет настроен на дистрибутиве FreeBSD, Конфиг сети стенда следующий:

Установка BIND9

Параметры (синтаксис) named.conf

Синтаксис файла named.conf придерживается следующих правил:

Каждая завершенная строка параметров должна завершаться символом ; .

Раздел Acl

Раздел Options

Раздел Zone

Определяет описание зон(ы). Формат раздела: zone операторы_раздела_zone>;Операторы, которые наиболее часто используются:

Дополнительные параметры конфигурации

В конфигурационных файлах BIND могут применяться следующие директивы:

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

Настройка кэширующего DNS сервера

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

  • named.conf;
  • описание серверов корневой зоны (зона типа hint);
  • описание зоны 127.in-addr.arpa.

Чтобы не вносить неразбериху в куче конфигурационных файлов, в статье я привожу примеры на основе единого конфигурационного файла. На самом деле, в последних версиях Debian (и других дистрибутивах Linux), файл named.conf выглядит следующим образом:

В записи SOA указывается primary NS для домена и e-mail контактного лица. В скобках, по порядку:

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

  • Если вы указываете полное имя домена, пишите в его конце точку.
  • Записи NS, MX и A для основного домена (не субдомена) не должны начинаться с начала строки.
  • Если почтовый шлюз принадлежит этому же домену, не забывайте указывать его в секции A.

Проверить файл зоны на ошибки можно с помощью команды:

Далее, хочу обратить внимание на наличие файлов зон в каталоге, указанном в разделе options в параметре directory с именами, соответствующими параметрам file в разделах, описывающих зоны:

Главный (master) сервер зоны

Основной конфиг содержит следующие настройки:

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

а так же в домене in-addr.arpa.

Вторичный (secondary, slave) авторитетный сервер зоны

Так же, slave DNS-сервер делит нагрузку с master сервером или принимает на себя всю нагрузку в случае аварии па первом сервере.

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

Получение зоны прошло успешно. Далее, для настройки подчиненного сервера, алгоритм следующий:

  1. Скопироватьконфигурационный файл named.conf с master сервера;
  2. Заменитьпараметр type master на type slave в тех зонах, для которых он будет вторичным;
  3. Параметр allow-transfer < 10.0.0.191; >;заменить на masters < 10.0.0.152;>; в тех зонах, для которых он будет вторичным;
  4. Удалить зоны, которые не будет обслуживать текущий сервер, в том числе и корневую, если slave не будет отвечать на рекурсивные запросы;
  5. Создать каталоги для логов, как в предыдущем примере.

Итого, мы получаем конфиг slave сервера:

после перезапуска наш slave сервер благополучно скопирует необходимую ему информацию с главного сервера, о чем будет говорить наличие файлов в каталоге:

Резюме

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