Линукс для wifi роутера

Наш рецепт отказоустойчивого Linux-роутера

В высоконагруженных проектах всегда повышенные требования к избыточности и надежности. Одним из важнейших звеньев инфраструктуры является маршрутизатор, потому что от его устойчивости зависит доступность сети в целом. Именно на таких узлах мы используем одну из схем реализации отказоустойчивого виртуального роутера на базе GNU/Linux с использованием iproute2, NetGWM, keepalived, ISC DHCPD, PowerDNS. Как мы всё это настраиваем, читайте в этой статье.

Компоненты

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

• каналы связи,
• коммутаторы,
• маршрутизаторы.

В общем виде схема (на уровне L2) выглядит так:

Как видно из схемы, нам нужны 2 коммутатора с поддержкой 802.1Q VLAN. Оператор 1 коммутируется в Коммутатор 1 и ему выделяется отдельный VLAN (например, 110). Оператор 2 коммутируется в Коммутатор 2, в другой VLAN (например, 120). Отдельный VLAN (в нашем случае — 200), выделяется под локальную сеть. Между коммутаторами организуется транк, и транком же линкуем оба маршрутизатора, которые и будут «сердцем» нашего виртуального роутера (схема router-on-a-stick).

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

Стек базовых компонентов, которые мы используем в работе роутеров:

• Ubuntu Linux;
• NetGWM — утилита приоритезации основного шлюза в решении. Это наша Open Source-разработка, о которой мы готовим отдельную статью (пока предлагаю ознакомиться с базовой документацией) [Обновлено 08.08.2017: статья опубликована как «Настройка основного и двух резервных операторов на Linux-роутере с NetGWM»];
• iproute2 — для создания нескольких таблиц маршрутизации;
• keepalived — для реализации протокола VRRP в Linux;
• ISC DHCPD — как горизонтально масштабируемый DHCP-сервер;
• PowerDNS — как DNS-сервер для локальной сети.

Маршрутизаторы настраиваются примерно одинаково, за исключением конфигурации IP-адресов и keepalived.

Настройка интерфейсов

Настраиваем VLAN. Конфигурация /etc/network/interfaces будет выглядеть примерно так:

• настраиваем blackhole — хорошая практика для того, чтобы локальные пакеты не улетали по маршруту по умолчанию в сторону провайдера;
• net.ipv4.conf.$IFACE.rp_filter=0 — необходим для корректной работы multi-wan;
• для каждого провайдера настраиваем отдельную таблицу маршрутизации с единственным маршрутом по умолчанию.

Настроим маркинг пакетов для направления в определенные таблицы — добавим в iptables правила:

И настроим правила маршрутизации для промаркированных пакетов — мы это делаем вызовом скрипта iprules.sh при выполнении ifup lo (смотри выше в /etc/network/interfaces ). Внутри скрипта:

Эти таблицы маршрутизации необходимо объявить в /etc/iproute2/rt_tables :

Балансировщик основного шлюза

Настроим NetGWM — утилиту для приоритезации основного шлюза. Она будет устанавливать маршрут по умолчанию, выбирая операторов в соответствии с двумя правилами: а) установленным нами приоритетом, б) статусом оператора (жив или нет).

Чтобы установить NetGWM, можно воспользоваться исходниками на GitHub или нашим репозиторием для Ubuntu. Второй способ в случае Ubuntu 14.04 LTS выглядит так:

Укажем в конфиге /etc/netgwm/netgwm.yml , что у нас 2 оператора, маршруты по умолчанию для каждого из них, приоритезацию и настройки для контроля доступности:

Обратите внимание на имена oper1 и oper2 — это названия таблиц маршрутизации из /etc/iproute2/ip_tables . Рестартнем сервис netgwm , чтобы он начал управлять шлюзом по умолчанию для системы:

Настройка keepalived

Keepalived — реализация протокола VRRP для Linux. Этот протокол позволяет реализовать схему с отказоустойчивой маршрутизацией, создавая виртуальный IP, который будет использоваться в качестве маршрута по умолчанию для обслуживаемой сети. Виртуальный IP автоматически передается резервному серверу при выходе из строя основного сервера.

На этом этапе мы определяемся, что Маршрутизатор 2 будет играть роль Backup, а Маршрутизатор 1 — роль Master. Настраиваем keepalived, изменяя конфигурационный файл /etc/keepalived/keepalived.conf :

Так как наш отказоустойчивый роутер — многокомпонентный, мы решили использовать режим, в котором переключение keepalived режимов Backup → Master происходит только в случае отказа Master-сервера. За это как раз отвечает параметр nopreempt .

Настройка ISC DHCPD

ISC DHCPD был выбран нами, так как позволяет масштабировать DHCP на несколько серверов. Он прост в конфигурировании и хорошо зарекомендовал себя на практике. Кроме того, нам понравилось, что разработчики этого DHCP-сервера придумали изящное решение для организации реплики между серверами. Для основного и второстепенного серверов выделяются разные пулы адресов и на запросы отвечает сервер, который успел сделать это первым, выдавая адрес из своего пула. При этом база арендованных IP синхронизируется. В случае, если один из серверов отказывает, второй как ни в чем не бывало продолжает выдачу адресов из своего пула. При возврате отказавшего сервера он начинает выдачу из своего пула, при этом не возникает коллизий.

Правим конфиг /etc/dhcp/dhcpd.conf :

Нам понадобится сгенерировать ключ update_key , с помощью которого мы будем обновлять зону mynet . Сгенерируем его и выведем на экран:

Скопируйте сгенерированный ключ и вставьте в конфигурационный файл вместо слова КЛЮЧ.

Настройка PowerDNS

В качестве DNS-сервера мы предпочли PowerDNS, так как он имеет возможность хранить зоны в СУБД MySQL, которую удобно реплицировать между первым и вторым сервером. Кроме того, PoweDNS — это производительное решение, хорошо функционирующее в высоконагруженном роутере.

Настройку PowerDNS начнем с подготовки базы данных.

Теперь нужно настроить PowerDNS и научить его работать с БД. Для этого требуется установить пакет pdns-backend-mysql и изменить конфиг /etc/powerdns/pdns.conf :

На этом базовая конфигурация PowerDNS закончена. Нам же ещё потребуется настроить рекурсор — обработчик рекурсивных DNS-запросов, который позволяет значительно повысить производительность DNS-сервера. Правим файл /etc/powerdns/recursor.conf :

В файл forward_zones вносим зоны intranet, которые обслуживают соседние серверы:

По окончании настройки перезапускаем сервисы pdns и pdns-recursor .

После запуска настраиваем реплику MySQL между серверами.

Заключение

Мы используем данное решение не только в чистом виде. В большинстве случаев оно усложняется добавлением туннелей VTun, OpenVPN или IPSec через основного и резервного оператора связи и динамической маршрутизацией, которая реализуется с помощью Quagga. Поэтому схему, предложенную в статье, предлагаю воспринимать как фундамент для создания более сложных решений.

Будем рады, если вы зададите свои вопросы в комментариях или укажете на места в схеме, которые можно улучшить. И, конечно, подписывайтесь на наш хаб, чтобы не пропускать новые полезные материалы! )

Источник

Беспроводная точка доступа, используя Linux

Самый первый шаг, конечно же:

Мда, в исходниках уже есть 2.0. Такой он, Debian stable. Но на самом деле это нам не особо помешает — версия 1.0 у меня работает достаточно стабильно.

Настройка:

Отредактировать файл /etc/default/hostapd.conf. В нём раскомментировать строку вида Это путь к файлу конфигурации демона hostapd.
Затем идем дальше — редактировать /etc/hostapd/hostapd.conf. Предоставлю содержимое моего файла конфигурации. Предупреждаю, парсер конфигурационных опций у этого демона очень чувствителен и ругается даже на пустые строки с пробелом. На комментарии не ругается.

Сетевой интерфейс беспроводной карты
Драйвер сетевой карты — обычно для hostapd отлично работает nl80211, не вижу смысла менять, да и говорят, что он работает в большинстве случаев.
Название точки доступа, т.н. SSID
Режим работы сетевой карты — 801.11b/g/n. На самом деле — там всегда должно оставаться g, даже если карта способна на n, для настройки режима n придётся кое-что поменять, смотрите дальше:

Беспроводной канал — от 1 до 13. Для лучшей производительности рекомендуются 1, 6 или 11 канал.
Версия WPA
Пароль беспроводной точки
Дополнительные настройки WPA2:
Следующая опция устанавливает блокировку MAC-адресов. Пока не знаю, как это настроить, да и штука довольно бесполезная, но все говорят, что без блокировки эту опцию нужно выставить в ноль — что я и сделал:

Конфиг автоматически проверяется перед запуском, так что — смело пробуйте запустить hostapd. Команды управления:
Напомню — также в Debian можно использовать команды вида service hostapd start, что легче в написании.

Пару шагов для устойчивости:

• Нельзя забывать, что для шифрования WPA/WPA2 пароль должен быть не короче 8 символов. Если поменять пароль на лету, используя SSH сессию через беспроводной канал, можно внезапно отрезать себя от сервера — hostapd не захочет запускаться и единственное средство связи с сервером будет потеряно. Работает — не трогай, ну а если трогаешь — трогай осторожно.
• В случае многопользовательской системы советую поставить права чтения файлов вида 700, чтобы простые пользователи не могли узнать пароль для точки доступа — если вас это волнует, конечно.

Что ещё могу сказать? С мобильными устройствами проблем нет, с ноутбуком под Windows 7 — крайне редко (примерно раз-два в месяц) не получается подключиться к точке. Лечится командой service hostapd restart, велика вероятность, что в новых релизах эта проблема убрана — есть версия hostapd 2.0.0, но компилировать и ставить её я пока что не пытался.

Пока всё. К точке можно попробовать подключиться, но… Для успешного подключения к точке доступа нужен DHCP сервер, без него к точке полноценно не подключишься — те же операционные системы не дадут этого сделать, поскольку без получения адреса само подключение не имеет особого смысла. Вот его и настроим!

Когда я только начинал учиться настраивать сервера под свои нужды, первое, на что я тогда я наткнулся — это пакет isc-dhcp-server, его я и планировал предложить, и статья уже была готова, но… Я нашёл dnsmasq, и моя жизнь изменилась в лучшую сторону. Dnsmasq — это и кэширующий DNS, и DHCP сервер со своим набором различных фич. Как только я заглянул в его конфиг, мое зрение улучшилось, все мысли в мозгу внезапно стали упорядоченными и я достиг просветления. Реально, конфиг очень простой и понятный. Но пока подготавливаем площадку для работы dnsmasq. Что же делать?

1) Придумать, как будут выглядеть адреса в нашей локальной сети. Я выбрал адреса типа 192.168.51.x.

2) Настроить сетевой интерфейс, на котором будет работать dnsmasq. На самом деле — очень важный шаг, который пропускают многие в своих мануалах по настройке DHCP-серверов. Дело в том, что компьютеру, на котором работает DHCP-сервер, необходимо прописать статический адрес — кто выдаст адрес DHCP-серверу, если он сам не может запуститься без адреса, а адрес себе он выдать не может, потому что не запущен?
Итак, открываем для редактирования файл /etc/network/interfaces и добавляем туда абзац вида:
Сохраняем и перезапускаем наш сетевой интерфейс, на котором настроен DHCP:
Проверяем состояние, сверяем настройки с теми, что должны быть:

3) Нужно удалить любые DNS и DHCP серверы, чтобы dnsmasq мог спокойно запуститься — иначе выдаёт ошибку. У меня были установлены bind9 и isc-dhcp-server, пришлось избавиться от них. Если работаем по SSH из сети, в которой раньше адреса раздавал покойный DHCP-сервер, не перезагружаемся — выдавать адреса уже некому.

4) Нужно создать условия для работы сервера — создать пользователя для того, чтобы под ним запускать dnsmasq, прописать в системных настройках DNS-сервера, к которым dnsmasq будет обращаться и ещё пару мелочей.
Прописываем DNS сервера Гугла. Правда, первой строчкой у нас будет localhost. Это сделано для того, чтобы остальные системные приложения на нашем же сервере, когда им надо получить адрес от DNS-сервера, обращались сначала к dnsmasq, а не к Гуглу. Ну а dnsmasq достаточно умён, чтобы игнорировать эту строчку:

Нужно защитить это файл от перезаписи при каждом запуске системы. Перезаписывает его dhclient, если что. Честно говоря, блокировка от записи — лишь один из способов того, как не допустить перезапись =) Есть и другие, но этот самый простой:

Что же, если вы по каким-либо причинам считаете блокирование файла неверным путём или также хотите использовать DNS, которые столь настойчиво предлагает dhclient? Тогда, как советует merlin-vrn, нужно использовать программу resolvconf.

Если пакет resolvconf ещё не установлен, устанавливаем. Единственное, что нужно для того, чтобы прописать статический адрес DNS для системы — отредактировать /etc/resolvconf/resolv.conf.d/base, вписав туда всё, что мы бы вписали в /etc/resolv.conf:

service resolvconf reload — готово!

Добавляем группу и пользователя:

5) Ставим Dnsmasq, он запускается и готов к работе, но мы его отключаем — ещё не настроен, нечего ему тут делать:

6) Чистим оригинальный файл от стандартного конфига:
Ну а теперь мы готовы настраивать. Скажу сразу — у dnsmasq много разных опций, которые я при написании статьи подробно описывал в комментариях… Пока не понял, что топик раздулся до неприличных и нечитаемых размеров, как будто недостаточно того, что статья и так переполнена текстом и отформатирована, как кусок незнамо чего. Поэтому — я оставлю конфиг с самыми важными без длинных комментариев и всяких дополнительных опций, а конфиг с дополнительными опциями будет под спойлером.

Источник

Опыт создания домашнего Wi-Fi маршрутизатора. Часть 2. Установка и настройка ПО

И снова здравствуйте!

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

Когда я затевал всё это движение, я предполагал, что будет непросто. Но не предполагал, что настолько. В одном из комментариев к предыдущей части статьи я клятвенно пообещал рассказать о нижеследующем «к выходным». Благоразумно умолчал к каким именно. 🙂 Тут ещё умудрился прихворнуть не вовремя, но всё-таки сдерживаю своё обещание.

• материнская плата Intel D2500CC с комплектным двухядерным 64-bit процессором Intel Atom D2500, двумя гигабитными сетевыми интерфейсами
• оперативная память SO-DIMM DDR-3 1066 4Gb Corsair
• SSD-накопитель Crucial M500 120 GB
• сетевая карта 1000 Mbit D-Link DGE-528T
• mini-PCI-E Wi-Fi карта Intel 7260.HMWWB 802.11 a/b/g/n/ac + Bluetooth 4.0
• всё это хозяйство упаковано в корпус Morex T-3460 60W

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

Ещё раз уточню, что эти ваши интернеты приходят ко мне по 100 Мбитному каналу (тариф, естественно, даёт несколько меньшую скорость, но не суть). Получилось, собственно, вот что:

• Доступ в интернет со всех устройств, имеющихся дома в распоряжении +n устройств, появляющихся эпизодически или вообще однократно
• Домашняя локалка
• Соответственно, маршрутизация трафика из/в интернет/локальная сеть
• Файлохранилище (доступ по FTP или Samba)
• Торрентокачалка
• ed2k-сеть (ибо очень круто развита у провайдера)
• web-сервер

В перспективе:

• домен
• видеонаблюдение
• элементы «умного дома»
• чёрт в ступе много чего интересного

Естественным в этой ситуации было выбирать из *nix-based систем. Некоторое время пришлось потратить на изучение матчасти, рыская по сети. В итоге я проделал следующий путь…

1. FreeBSD 10.1-RELEASE

Всё было замечательно, система встала, но меня ждал неприятный сюрприз, о котором я, откровенно говоря, знал, но решил-таки проверить на практике: FreeBSD напроч отказывалась видеть Wi-Fi карточку. Вернее видеть-то она её видела, но только адрес и название вендора, а что это и с чем её едят, фряха понимать не желала (драйвер устройства значился как none1). Кроме того, дальнейшее чтение мануала выявило, что в режиме точки доступа во FreeBSD работают только Wi-Fi карты на основе набора микросхем Prism. Печальбеда. Да, нашёл я также и информацию, что моя карточка в настоящий момент вообще не имеет драйвера под фряху. Даже портированного.

10. Debian 7.7.0

Расстраивался я недолго: не состоялась фряха — возьму старый добрый Debian. Установил с netinstall-образа базовую систему без графического окружения. Долго пытался понять, что не так. Стабильный релиз Debian в данный момент 7.7.0, имеет ядро версии 3.2. В этом ядре опять же нет поддержки моей многострадальной Wi-Fi сетевушки. Полез на ЛОР искать ответ, в итоге получил неутешительные выводы: надо ставить ядро посвежее (в случае Debian — тот ещё геморрой), пляски с бубном ядрами, по мнению гуру, не труъ Debian-way (так прямо и сказали: хочешь перекомпилять ядра — выбери другой дистрибутив).

11. Ubuntu Server 14.04 LTS

Плюнув на попытки круто провести время покрасноглазить, я взял знакомый и уважаемый мной дистрибутив. Уже более года он (правда версии 12.04 LTS ) вертится у меня на сервере, раздающем плюшки в сети провайдера.

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

Установка

По сути не представляет ничего сложного и аналогична таковой в Debian. Производится в диалоговом режиме text-mode. Описывать детально не вижу смысла, т.к. всё это уже десятки раз пережёвано и валяется на множестве ресурсов (начиная с официальных сайтов на разных языках и заканчивая местечковыми форумами).

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

Первой необходимой манипуляцией при разметке накопителя является выравнивание разделов диска. Если кратко, то каждый раздел должен начинаться с сектора кратного 8. Первый раздел рекомендовано начинать с 2048 сектора (это связано с расположением в начале накопителя MBR или GPT , а «отступ» в 1 Мб берётся с запасом.

При разметке я создал 3 раздела:

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

Далее в опциях монтирования разделов в /etc/fstab следует добавить discard — для включения TRIM и noatime — для отключения записи в метаданные времени последнего доступа к файлу.

Все остальные советы, нагугленные на просторах сети, как то увеличение времени между сбросами буферов на диск (опция commit=[time, sec.]), отключение «шлагбаума» (опция barrier=0) и прочее не внушили мне доверия в плане приобретаемой полезности в ущерб сохранности данных и безопасности.
Кроме того, я не стал выделять отдельный раздел для swap, решив, что оперативной памяти мне должно хватить для поставленных задач. Если же всё-таки возникнет необходимость в подкачке, ничто не мешает сделать swap в виде файла и смонтировать его как раздел.

Также было принято волевое решение вынести временные файлы (/tmp) в tmpfs.

В процессе установки задаются общие параметры, как то: локаль, параметры времени/геопозиции, имя системы, а также создаётся новый юзер и пароль к нему. Далее следует выбор устанавливаемого программного обеспечения, в котором я пометил для установки следующее:

• OpenSSH server
• DNS server
• LAMP server
• Print server
• Samba file server

После загрузки в свежеустановленную систему проявилась одна крайне неприятная особенность (кстати, в Debian было то же самое): после инициализации драйверов вырубалось видео, монитор переходил в режим ожидания, и становилось непонятно система зависла или просто что-то не так с выводом. Обнаружилось, что доступ по ssh есть, и можно было бы на этом остановиться, но всегда может возникнуть ситуация, когда необходимо получить физический доступ к маршрутизатору (например, шаловливые ручонки админа поковырялись в настройках сети, и доступ через консоль категорически пропал %) ). Посёрфиф по форумам я наткнулся на решение (оказывается баг известен и проявляется именно на этой материнской плате):

add to /etc/modprobe.d/blacklist.conf:
blacklist gma500_gfx

run
sudo update-initramfs -u
sudo reboot

Пруф.
В случае с Debian — /etc/modprobe.d/fbdev-blacklist.conf.
После перезагрузки всё заработало.

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

no talloc stackframe at ../source3/param/loadparm.c:4864, leaking memory

Проблема связана с библиотекой авторизации libpam-smbpass, можно просто её снести, а можно поступить более изящно:

снять пометку с SMB password synchronization, что отключает синхронизацию паролей системных пользователей и пользователей Samba.
Устанавливаем все доступные обновления:

И приступаем к настройке сетевых интерфейсов. В маршрутизаторе 4 физических интерфейса и loopback:

• eth0 — «смотрит» в интернет, получает настройки по DHCP
• eth1 и em0 — интегрированные в материнку сетевые адаптеры
• wlan0 — как нетрудно догадаться, беспроводной интерфейс Wi-Fi

Устанавливаем hostapd и переводим беспроводной интерфейс в режим Master:

К моему величайшему сожалению такой способ не сработал, и команда вывалилась с ошибкой, поэтому я прибегнул к альтернативному способу:

Теперь необходимо сконфигурировать все сетевые интерфейсы, чтобы было удобнее с ними работать. Я решил объединить встроенные сетевушки и Wi-Fi в мост, чтобы управлять этим хозяйством как единым целым при раздаче IP-адресов по DHCP, маршрутизации и пр. Приводим к следующему виду /etc/network/interfaces:

Включаем автоматический запуск hostapd при загрузке системы, для этого в /etc/default/hostapd раскомментируем и редактируем строки:

Далее, не мудрствуя лукаво, я настроил общий доступ. Скрипт для настройки iptables и ip-форвардинга я взял отсюда, привёл его в соответствие своим реалиям и настроил автозапуск. В результате iptables наполняются необходимым содержимым при загрузке системы.
Логично, что нужно текже настроить DHCP-сервер. Решив упростить задачу до минимума, я установил dnsmasq и снёс имеющийся в наличии и конфликтующий с ним bind9. Конфиг прост:

На самом деле в конфиге ещё куча закомментированных опций, которые позволяют производить очень fine tuning, но такого набора вполне хватает для корректной работы. В принципе, с этого момента аппарат уже работает как домашний маршрутизатор.
После окончания основной настройки я установил и настроил transmission-daemon, aMuled и vsftpd. Собственно говоря, настройка данных сервисов достаточно тривиальна, останавливаться детально на ней не буду. Естественно, доступ к данным ресурсам имеется только из локальной сети, если хочется получить доступ извне, необходимо будет открыть соответствующие порты в iptables.
Вёб-сервер представляет из себя связку Apache 2.4.7 + MySQL Ver 14.14 Distrib 5.5.40. Пока не придумал, чем буду его заполнять: накатить готовый движок и баловаться с дизайном или же просто попрактиковаться в html и php. В любом случае сие имеет для меня прикладное значение. Возможно, в перспективе получится настроить вёб-интерфейс для мониторинга и управления маршрутизатором.
После всех манипуляций остаётся настроить ведение логов: по возможности привести настройки всех процессов, ведущих логи, выводить в них только критически важные уведомления и предупреждения. Идея заключается в снижении количества операций записи, а, соответственно, и негативного влияния на SSD.
Кроме того, следует настоятельно рекомендуется включить запуск по cron раз в сутки fstrim (для каждого раздела отдельно). Говорят, хуже не будет точно.

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

В комментарии к предыдущей части статьи многоуважаемый dmitrmax интересовался уровнем энергопотребления сборки. Ну что же, привожу примерные данные, которые мне удалось почерпнуть из открытых источников:

• процессор Intel Atom D2500 — до 10 Вт
• SSD-накопитель Crucial M500 — 3,6 Вт

По остальным крмплектующим данных сходу не нашлось, но практически везде в характеристиках сетевой карты и Wi-Fi модуля пишут «низкое энергопотребление». Если грубо накинуть на всё про всё 10 Вт (прочее железо, интегрированные сетевушки, etc), то итого получается около 25 Вт — не так уж и много, полагаю…

Вроде бы ничего не забыл, упомянул все ключевые моменты. За подробностями прошу в комментарии. Спасибо за внимание! (-;

UPD: Господин Revertis справедливо заметил, и я с ним соглашусь, что изначально при установке системы не следовало отмечать DNS-сервер, чтобы потом его сносить (речь о bind9), но в статье я описывал именно путь, который проделал — со всеми его ошибками и закоулками. И да, соглашусь, что nginx лучше, чем Apache, более того — я его даже заменю. Спасибо за совет.

Источник