Линукс сервер локальной сети

Как настроить простой DNS-сервер для локальной сети

Если вы впервые столкнулись с необходимостью поднять DNS-сервер для локальной сети под Linux, то эта статья – для вас. Преимущество предлагаемого способа – простота: сервер можно настроить буквально за несколько минут. Но этот способ, скорее всего, не подойдёт для продакшн серверов.

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

Далее будем считать, что имеется локальная сеть, состоящая из нескольких хостов. Локальная сеть настроена, сетевой доступ между хостами имеется. На хостах установлен Ubuntu 18.04.4 LTS (для других версий не проверялось).

Шаг 1. Установка необходимых пакетов

Следующие шаги выполняются на хосте, на котором будет устанавливаться DNS-сервер.

Установите Dnsmasq: sudo apt-get install dnsmasq При установке выведутся следующие ошибки:

failed to create listening socket for port 53: Address already in use
FAILED to start up
Failed to start dnsmasq — A lightweight DHCP and caching DNS server.

При рестарте системы файл /etc/resolv.conf автоматически пересоздаётся. Поэтому если прописать в него нужный адрес вручную, то изменения окажутся стёртыми после перезапуска. По умолчанию после перезапуска в этот файл прописывается адрес 127.0.0.53 , который используется сервисом systemd-resolve . Этот сервис осуществляет определение IP-адресов доменов для приложений, работающих на том же хосте, на котором запущен сервис. Но мы планируем перестать использовать этот сервис и начать использовать dnsmasq .

Шаг 2. Настройка пакетов

1. Отредактируйте файл /etc/dnsmasq.conf :

1. no-resolv Эта настройка выключает загрузку настроек из /etc/resolv.conf . Все настройки будут браться из редактируемого файла /etc/dnsmasq.conf . Это сильно упрощает конфигурацию Dnsmasq’а, поскольку файл /etc/resolv.conf автоматически пересоздаётся при рестарте системы.
2. server=8.8.8.8 8.8.8.8 — это адрес DNS-сервера Гугл. Этот адрес можно заменить на любой другой адрес публичного DNS-сервера. Например, на адрес DNS-сервера вашего провайдера или ранее используемого DNS-сервера. Запросы, которые не сможет обработать Dnsmasq будут направлены на этот сервер.
3. listen-address=0.0.0.0 Эта настройка позволит осуществлять запросы к Dnsmasq’у с других хостов.
4. bind-interfaces Задаёт режим, при котором Dnsmasq не осуществляет привязку к интерфейсам, по которым не должна осуществляться обработка запросов. Без этой настройки в предлагаемом варианте конфигурации сервер не работает.

Шаг 3. Настройка используемых DNS-серверов

Данная настройка выполняется на всех хостах-клиентах, с которых будут отправляться запросы на хост с сервисом Dnsmasq.

Проще всего настроить используемые DNS-сервера в графическом интерфейсе. Укажите адрес хоста, на котором установлен Dnsmasq, первым в списке:

Шаг 4. Локальное тестирование DNS-сервера

Проверку настроек можно и не делать. Но если вам интересно узнать, всё ли работает правильно, то выполните следующие команды на хосте с сервисом Dnsmasq.

1. Проверьте, что в файле /etc/resolve.conf прописан адрес 127.0.0.1 : cat /etc/resolve.conf
2. Выполните команду: sudo netstat -tulpen Вы должны увидеть, что адрес 0.0.0.0:53 занят Dnsmasq’ом, а адрес 127.0.0.53:53 не фигурирует в списке.
3. Выполните команду: dig ya.ru Вы должны получить вывод, в котором присутствует примерно такая строчка. В начале строки не должно быть символов ; . ya.ru. 220 IN A 87.250.250.242
4. Выполните команду: dig myserver.tst Вы должны получить вывод, в котором присутствует примерно такая строчка: myserver.tst. 0 IN A 1.2.3.4

Шаг 5. Тестирование DNS-сервера с других хостов

Теперь можно проверить работу DNS-сервера с других хостов.

Выполните пункты 3 и 4 из предыдущего раздела. Вывод в консоль должен быть аналогичен результатам, указанным в предыдущем разделе.

Дополнительная информация

1. Следующая команда в режиме реального времени выводит в консоль все запросы, выполняемые на порт 53. Это помогает определить факт выполнения запросов. sudo tcpdump -l port 53 Данную команду логично выполнять в другом терминале – не в том, в который вводятся команды, подлежащие проверке.
2. Обратите внимание, что DNS-запросы кэшируются и сервисом systemd-resolved, и сервисом dnsmasq. Для сброса кэша проще всего перезапустить используемый сервис: sudo systemctl restart dnsmasq (на серверном хосте) sudo systemctl restart systemd-resolved (на клиентских хостах)

Заключение

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

Источник

VirtualBox: виртуальная локальная сеть, маршрутизация в Linux

На 4 курсе Бауманки я получил задание: сделать виртуальную локальную сеть на базе Linux. Информации на эту тему оказалось довольно много, но ее поиск может занять много времени, а порой даже запутать. Поэтому я решил расписать самые основные шаги для построения локальной сети с использованием VirtualBox, а также пролить свет на некоторые неочевидные настройки Linux.

Описание задачи

Создать виртуальную сеть в VirtualBox, включающую в себя первую сеть на 2048 хостов, вторую сеть на 256 хостов и сервер, выступающий в роли маршрутизатора. В последствии на сервере можно будет настроить файервол для вывода в интернет обоих сетей.

Любой компьютер первой сети должен успешно выполнять пинг любого другого компьютера второй сети и наоборот. ICMP-пакеты должны проходить через сервер. Сети и сервер должны быть представлены в виде компьютеров с соответствующими ipv4-адресами.

Настройка виртуальных машин

Если говорить максимально коротко, то сервер одновременно находится и в первой локальной сети, и во второй. Это значит, что по одному сетевому интерфейсу он видит все компьютеры из сети на 2048 хостов, а по другому — все компьютеры из сети на 256 хостов. Для объединения виртуальных машин, допустим сервера и машины первой сети, будем использовать тип подключения «Внутренняя сеть». Внутренняя сеть позволит объединить сервер (SERVER) и первую сеть (LAN 1) на физическом уровне (аналог — соединение кабелем).

Следует обратить внимание на то, что имя внутренней сети LAN1 на первом адаптере должно совпадать с именем внутренней сети SERVER’а на первом адаптере. Таким образом, можно реализовать физическое соединение любого адаптера виртуальной машины LAN 1 с любым адаптером виртуальной машины SERVER. Аналогичным образом соединим вторую сеть (LAN 2) с другим сетевым адаптером сервера, за одним исключением, название внутренней сети должно отличаться.

На данном этапе машины соединены физически, но отправлять ICMP пакеты еще нельзя, для этого необходимо настроить ip-адреса.

Настройка адресов сетей и сервера

Для первой сети на 2048 хостов зададим адрес 192.168.1.0/21, для второй — 192.168.2.0/24. Про ip-адресацию написано уже достаточно большое количество статей, поэтому на ней останавливаться не будем. Соответственно, необходимо задать адреса каждой виртуальной машине.

Для начала стоит посмотреть на сетевые интерфейсы сервера с помощью команды ifconfig:

• eth0 — из предыдущего пункта адаптер 1 с типом подключения «Сетевой мост», сейчас его рано разбирать
• eth1 — адаптер 2 с типом подключения внутренняя сеть, соединяется с адаптером 1 (там это будет eth0) первой виртуальной машины LAN 1, имя подключения LAN 1
• eth2 — адаптер 2 с типом подключения внутренняя сеть, соединяется с адаптером 1 второй виртуальной машины LAN 2, имя подключения LAN 2

Следующими двумя командами зададим ip-адреса сервера в первой и второй сетях соответственно:

• ifconfig eth1 192.168.1.10 netmask 255.255.248.0
• ifconfig eth2 192.168.2.10 netmask 255.255.255.0

Затем необходимо настроить ip-адреса на eth0 виртуальных машин LAN1 и LAN2. Выполнив команду ifconfig на каждой из машин можно увидеть следующее:

На данном этапе LAN 1 видит SERVER по адресу 192.168.1.10, а SERVER видит LAN 1 по 192.168.1.1. Похожая ситуация и со второй сетью, LAN 1 видит SERVER по адресу 192.168.2.10, а SERVER видит LAN 1 по 192.168.2.1.

Убедиться в этом можно с помощью команды ping, которая отсылает icmp пакеты по определенному ip-адресу и принимает ответ. При пинге с SERVER’а адреса 192.168.2.1 (команда ping 192.168.2.10) должен получиться следующий результат:

Пакеты идут, значит все правильно.

Маршрутизация через сервер

Данная часть статьи легче для понимая, поэтому коротко и по делу. LAN 1 и LAN 2 находят в разных сетях, но у них есть общая точка соприкосновения — SERVER. Это значит, что две сети могут общаться между собой именно через него. Но для этого надо настроить маршрутизацию.

Для начала стоит разрешить на сервере пересылку пакетов между различными сетевыми интерфейсами командой: echo 1 > /proc/sys/net/ipv4/ip_forward. С помощью утилиты маршрутизации route добавим статические маршруты из сети LAN 1 в LAN 2 через SERVER, и из сети LAN 2 в LAN 1 через SERVER.

LAN 1: route add -net 192,168.2.0 netmask 255.255.255.0 gw 192.168.1.10 dev eth0
LAN 2: route add -net 192.168.0.0 netmask 255.255.248.0 gw 192.168.2.10 dev eth0

Следует отметить, что атрибут -net указывается для того, чтобы провести маршрут именно до сети, а не до отдельного хоста, а после атрибута gw указывается адрес сервера для той сети, в которой начинается маршрут.

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

Заключение

Данная статья должна ответить на базовые вопросы читателей по поводу практической реализации и расставить по местам некоторые вопросы о создании виртуальных локальных сетей в VirtualBox с использованием Linux.

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

Источник