Преимущества использования доменной сети — Первый Сервисный Провайдер
Преимущества использования доменной сети
Доменная сеть – способ взаимодействия компьютеров между собой. Такая сеть позволяет управлять компьютерами централизованно.
В доменной сети всегда есть главный компьютер – Контроллер Домена. В специальной программе на контроллере домена создаются учетные записи пользователей– имя пользователя и пароль. Например, для сотрудника Ивана Петрова создана учетная запись i.petrov. С её помощью Иван может выполнить вход в свой рабочий компьютер, работать с общими файлами и печатать на сетевом принтере.
Контроллер домена отвечает ещё и за права доступа к файлам и ресурсам. Например, Иван Петров может иметь доступ только к определенным принтерам и общим папкам, а директор – к любым.
Нужна ли Вам доменная сеть
Вам стоит задуматься о доменной сети, если хотя бы одно утверждение для Вас верно:
- В Вашем офисе больше 15 компьютеров и их количество будет расти
- В Вашей сети есть файловый сервер или сервер 1С
- Необходимо единообразие в настройках компьютеров – одинаковые программы, используемые принтеры и параметры безопасности
- Вы нанимаете или увольняете сотрудников раз в два-три месяца или чаще
- Ваши сотрудники работают за одним компьютером посменно
- Один и тот же сотрудник работает за несколькими компьютерами
- Вы хотите знать, кто и когда работал с общими файлами.
Кто мог удалить важный документ или занести вирус
- Нужно управлять доступом в Интернет – запретить социальные сети или разрешить доступ только к Вашему сайту и CRM
Как изменится работа в офисе с введением доменной сети?
Доменная сеть требует выполнения правил безопасности и единообразия.
Учетные записи сотрудников уникальны. Учетная запись сотрудника в доменной сети – универсальный пропуск к рабочему пространству компании. При входе в систему пользователь получает доступ к сетевым принтерам, общим файлам, серверу 1С, почте или общему чату.
Пароли сотрудников уникальны и периодически меняются. Никто кроме самого сотрудника не должен знать его пароль. Ответственность за секретность пароля лежит на самом сотруднике, он отвечает за все действия, совершенные с помощью его учетной записи. Это правило упрощает разбирательства внутри компании, например когда были удалены важные данные.
Учетные записи сотрудников не имеют прав администратора на компьютере. Пользователи не могут самостоятельно устанавливать программы и вносить изменения в системные настройки. Благодаря этому пользователь не сможет случайно запустить вирус или удалить настройки принтера. Для установки программ лучше обратиться к системному администратору.
Управление пользователями в доменной сети
Учетные записи в доменной сети создаются только на Контроллере Домена. Контроллер домена сообщает всем компьютерам сети об имеющихся учетных записях сотрудников. Сотрудник Иван может использовать свою учетную запись i.petrov для работы за любым компьютером доменной сети. Файлы других сотрудников на этом компьютере Иван не увидит.
Единая точка создания учетных записей помогает избежать беспорядка. На компьютерах нет лишних учетных записей, а права администратора есть только у администраторов доменной сети.
Доменная сеть объединяет все ресурсы компании в единое рабочее пространство. В домен можно ввести хранилище файлов, сервер 1С или сервер для удаленной работы.
Если сотрудник уволится, его учетную запись придется заблокировать только на контроллере домена, все компьютеры узнают об этом запрете моментально.
Безопасность доменной сети
К уязвимым частям информационной структуры доступ имеют только квалифицированные сотрудники. Доступ к важным документам разграничен, обычно ни один сотрудник не может повредить все данные. Разграничение доступа усложняет работу вирусов и снижает вероятность диверсии со стороны сотрудников.
Даже если документы были удалены или повреждены, все действия пользователей записываются в специальный журнал. Найти источник проблемы и избежать её в будущем не составляет труда.
Контроллер домена знает какие компьютеры должны быть в сети. В доменной сети можно установить правило запрещать всю активность «незнакомых» компьютеров или даже оповещать службу безопасности об их появлении.
Автоматизация в доменной сети
Групповые политики — набор настроек операционной системы. Эти настройки определяют отображение элементов Windows – окно входа, панели инструментов. Групповые политики позволяют запретить запуск определенных программ или автоматическую установку программ для новых пользователей. Можно даже запретить работать с внешними накопителями флешками или съемными дисками.
В доменной сети групповыми политиками компьютеров централизованно управляет контроллер домена. Благодаря доменной сети и групповым политикам новый компьютер настроится автоматически: будут установлены все необходимые программы, параметры безопасности, подключены принтеры и папки с общими документами. Сотруднику нужно будет только зайти в систему с помощью своих учетных данных – и можно работать.
А можно без доменной сети?
Использование доменной сети не обязательно, но значительно упрощает администрирование больших или сложных ИТ-инфраструктур.
Статью подготовил менеджер отдела проектов Заболотский Андрей.
Хотите получить более подробную консультацию по доменной сети?
Теги:
- абонентское обслуживание компьютеров
- аренда виртуального сервера
- аренда выделенного сервера
- ит аутсорсинг
- обслуживание компьютеров спб
- услуги системного администратора
Поделиться с друзяьми:
Домен в локальной сети: что это такое, создание
Главная » Windows
Windows
На чтение 4 мин. Просмотров 25.1k. Опубликовано
В некоторых случаях возникает необходимость вывести компьютеры локальной сети из рабочих групп и подключить их к локальному домену. Это дает возможность устанавливать групповые политики, управлять доступом пользователей, распределять между ними ресурсы, пользоваться своей учетной записью с любого компьютера в сети и другие полезные для системного администратора преимущества.
Что такое домен в локальной сети
Под доменом локальной сети принято понимать такую сеть, которая объединяет компьютеры под одной общей политикой безопасности и управляется централизовано. Таким образом при объединении компьютеров сети в рабочие группы взаимодействие машин основывается на принципе «клиент-клиент», а в домене это уже «клиент-сервер». В качестве сервера выступает отдельная машина, на которой хранятся все учетные записи пользователей сети.
Целесообразность организации такого доступа обусловлена несколькими факторами:
- локальная сеть постоянно развивается и количество пользователей растет;
- видоизменяется топология и география сети;
- необходимо разграничить доступ к ресурсам для каждого пользователя или группы;
- контроль за использованием ресурсов глобальной сети интернет.
При организации доступа на основе рабочих групп, такой контроль организовать просто невозможно. Однако, когда сеть состоит из всего нескольких компьютеров, то совершенно не имеет никакого смысла ставить отдельный сервер домена, это просто экономически нецелесообразно.
Если ЛВС организована на основе Microsoft Windows Server, то служба, которая отвечает за контролер домена называется AD (Active Directory), если под управлением *nix (Unix, Linux, FreeBSD) служба управляющая пользователями имеет название LDAP (Lightweght Directory Access Protocol).
Создание контроллера домена под Windows Server 2003/2008
Теперь разберемся, как создать домен в локальной сети. После того, как на сервер установлена операционная система и проведены предварительные настройки, можно приступить к конфигурации службы Active Directory:
- Серверу задается статический IP, желательно в начальном диапазоне адресов подсети.
- Устанавливаются компоненты, которые отвечают за работу сервера, если они не были установлены раньше — Active Directory, DNS, DHCP, WINS.
- Следующий шаг — это установка непосредственно контролера домена. Для этого нужно:
- открыть «Диспетчер сервера» и нажать ссылку «Добавить роли»;
- в открывшемся диалоговом окне нужно проставить галочки напротив установленных служб, чтобы мастер конфигурации смог провести настройки, добавил службы в автозапуск и другие служебные действия.
- После того как службы были установлены в «Диспетчере сервера» под ролями сервера их можно будет увидеть.
При этом будет висеть ошибка запуска напротив «Доменные службы Active Directory».
- Избавиться от ошибки поможет «Мастер установки доменных служб», который запускается из командной строки «Пуск — Выполнить — cmd — dcpromo».
- Пропустив несколько информационных окон, поставить переключатель на «Создать новый домен в новом лесу».
- Следующий шаг — это придумать имя домена. О правилах выбора доменных имен написано множество статей в интернете, но все они сводятся к одному: при выборе имени необходимо придерживаться соглашения и стандартов ICANN.
- После проверки имени на совпадения в сети, требуется выбрать режим совместимости работы сервера.
- В следующем шаге мастер предупредит о том, что дополнительно будет настроен DNS сервер и на вопрос о делегировании соглашаемся.
- Дальше нужно будет выбрать каталоги, в которых будут располагаться базы данных. Можно оставить по умолчанию или выбрать другое размещение.
- И напоследок придумать и ввести пароль для учетной записи «Администратор».
Это все действия, которые надлежит проделать для настройки домена в локальной сети. После того как мастер завершит работу, желательно будет перегрузить машину и войти в домен под учетной записью администратора для дальнейшей конфигурации пользователей и политик безопасности.
Иногда происходит такая ситуация, что компьютер не определяет сеть, вернее ставит статус «Неопознанная сеть». Ситуация возникает из-за того, что сервер замыкает DNS сам на себя, т.е. на петлю с адресом 127.0.0.1. Чтобы избавиться от этого, необходимо в настройках соединения указать в качестве DNS адрес сервера в локальной сети.
Организация работы ЛВС в доменной зоне процесс не сложный, но хлопотный. После настройки сервера не забываем ввести все рабочие станции в доменную зону. Дальнейшие действия по организации сети зависят от текущих нужд, но значительно упростят работу администратору и снимут ряд вопросов от пользователей.
Какое доменное имя использовать для вашей домашней сети
На этот вопрос есть окончательный ответ, и вы можете найти его в RFC 8375: используйте home.
Никогда не слышал об этом раньше? До 2018 года оно не назначалось в качестве имени домена верхнего уровня специального назначения ( spTLD ) для частных и малых сетей. не решить его через Интернет. Он предназначен только для использования внутри небольшой сети, такой как ваша домашняя сеть. Маршрутизаторы и система доменных имен ( DNS ) серверы [теоретически] знают, что не пересылают ARPA запросы, которые они не понимают, в общедоступный Интернет. arpa.
Возможно, вы видели, что некоторые предлагают вместо этого использовать .local
spTLD . Это старое имя spTLD , используемое самонастраивающимся протоколом Multicast DNS ( mDNS ) (RFC 6762). Вам не следует настраивать маршрутизатор или устройства для использования этого доменного имени.
Клиенты DNS могут отложить разрешение .local
spTLD s к распознавателям mDNS системы вместо распознавателя DNS . Вы можете столкнуться с конфликтами разрешения доменов или ситуацией, когда только некоторые устройства могут разрешать ваши домены.
Какое доменное имя использовать в жилом доме или в локальной сети чаще всего возникает в контексте настройки сервера DHCP на вашем маршрутизаторе. Большинство маршрутизаторов-шлюзов по умолчанию оставляют его пустым или могут заполнить его доменом, назначенным вашим интернет-провайдером ( Интернет-провайдер ). Вы можете безопасно установить его на home.arpa
на сервере DHCP вашей локальной сети.
Устройства в вашей сети должны затем назначить себе доменное имя example-device-hostname.home.arpa
. Обратите внимание, что не все домашние маршрутизаторы привязывают имена хостов и доменов DHCP к разрешаемым записям DNS на сервере DNS маршрутизатора. Возможно, вам не удастся разрешить домены home.arpa
без дополнительной настройки (или другого маршрутизатора или выделенного DNS сервер).
Лучше потратить время на то, чтобы убедиться, что все ваши устройства поддерживают разрешение mDNS , чем пытаться исправить привязки аренды DHCP и разрешение DNS на маршрутизаторе. DHCP- Разрешение DNS сложно заставить работать правильно, если ваше сетевое оборудование даже поддерживает его. Linux и MacOS должны быть настроены для работы с mDNS . Хотя вам может потребоваться настроить конфигурацию брандмауэра в Linux, в зависимости от ваших настроек. Устройства Windows могут потребовать от вас установки mDNS и настроить брандмауэр Windows.
Устройства и программы, которые настроены так, чтобы избегать вашего маршрутизатора для разрешения DNS , могут не разрешить доменное имя home.arpa
. Попробуйте отменить любые изменения, внесенные вами в настройки DNS на ваших устройствах, или убедитесь, что они настроены на использование вашего маршрутизатора для DNS . Некоторые программы, такие как веб-браузеры, могут иметь свои собственные специальные настройки для DNS или зашифрованного DNS 9. 0006 как DNS поверх HTTPS .
Не используйте неделегированные доменные имена , такие как .lan
, .home
, .homenet
, .homegroup
, .network
, а также не придумывайте собственное доменное имя. Если вы используете вымышленное доменное имя, то запросы DNS могут остаться невыполненными вашим маршрутизатором, и он перенаправит их на глобальные корневые серверы DNS . Это создает ненужные накладные расходы для базовой интернет-инфраструктуры и приводит к утечке информации о вашей сети (например, именах устройств). Веб-браузеры и другое программное обеспечение, включая ваш маршрутизатор, уже должны знать, что нельзя делать это с .
и local
.home.arpa
домены.
В качестве альтернативы вы можете использовать доменное имя или субдомен, который вы купили у регистратора доменных имен или поставщика услуг DynDNS . Эта настройка требует дополнительной настройки вашего маршрутизатора для локальной работы и расширенной настройки с использованием динамических доменных имен, например DynDNS , для работы через Интернет.
Сокращения
- САРП
- Агентство перспективных исследовательских проектов
- DHCP-сервер
- Протокол динамической конфигурации хоста
- DNS
- Система доменных имен
- ДинДНС
- Динамическая система доменных имен
- HTTPS
- Безопасный протокол передачи гипертекста
- mDNS
- Многоадресный DNS
- сДВУ
- домен верхнего уровня специального назначения
networking — Как настроить локальный домен в локальной сети, чтобы все могли видеть?
Я настроил DNS-сервер на ПК с bind9
в качестве DNS-сервера под Ubuntu 20. 04 в моей домашней сети, чтобы иметь свои собственные специальные доменные имена.
Несколько подробностей о DNS и прокси-сервере с HTTP
Чтобы сопоставить несколько разных имен поддоменов в домене с определенными портами на одном ПК, вам потребуется прокси-сервер, установленный на ПК, а также DNS-сервер. для локальной сети. Доменные имена сопоставляются с определенным IP-адресом с помощью протокола DNS и не сопоставляются с определенным портом в IP-адресе.
В моем случае у меня такое же аппаратное обеспечение ПК с Ubuntu 20.04, у которого есть (1) Bind9 для моего DNS-сервера и (2) Apache для моего прокси-сервера. Я мог бы использовать два разных ПК, один в качестве DNS-сервера для преобразования доменных имен в IP-адреса, а другой — для предоставления различных услуг, доступ к которым осуществляется либо через один IP-порт с использованием прокси-сервера, прослушивающего порт для отправки подключений к службам, либо непосредственно к службу, указав правильный номер порта нужной службы.
Например, http://kitchen.home/
в браузере даст указание браузеру открыть TCP-соединение с IP-адресом, представленным доменным именем kitchen.home
, используя порт 80, порт протокола HTTP по умолчанию. DNS-сервер используется для преобразования доменного имени kitchen.home
в IP-адрес. С URL-адресом http://kitchen.home:8081/
браузер попросит DNS-сервер преобразовать доменное имя kitchen.home
в IP-адрес, а затем откроет TCP-соединение с этим IP-адресом, но с использованием порт 8081 вместо стандартного HTTP-порта 80.
Таким образом, для http://kitchen.home/
для сопоставления с портом 8080 на этом IP-адресе и для http://hall.home/
для сопоставления с портом 8081 на этом IP-адресе вам необходимо объединить DNS сервер, который разрешает доменное имя, с прокси-сервером, находящимся на порту 80, стандартном порту HTTP. Затем прокси-сервер перенаправит запрос на другой порт на ПК, выбранный на основе имени субдомена, зал
или кухня
, всего спецификатора домена, кухня.
или дом
холл.дом
.
См. https://stackoverflow.com/a/58122704/1466970, в котором описывается настройка Nginx в качестве прокси-сервера.
Веб-сервер Apache также может служить прокси-сервером, что я и рассматриваю. См. этот учебник от DigitalOcean, Как использовать HTTP-сервер Apache в качестве обратного прокси-сервера с использованием расширения mod_proxy, а также Настройка базового веб-прокси в apache.
Моя среда
У меня есть ПК с Windows 10 внизу и ПК с Ubuntu 20.04 наверху, который подключается через маршрутизатор Arris к моему кабельному интернет-провайдеру. Оба ПК подключены к моей локальной домашней сети через WiFi.
ПК с Ubuntu 20.04 — это мой сервер Subversion, использующий веб-сервер Apache. Я провожу большую часть своего времени с ПК с Windows 10 внизу, используя PuTTY для подключения к ПК с Ubuntu с одним или несколькими окнами терминала, когда это необходимо. Я планирую работать с Visual Studio на ПК с Windows 10, получая доступ к Subversion через веб-сервер Apache, а также использовать ПК с Ubuntu в качестве сервера базы данных (MySQL) и веб-сервера (Apache с Php) и микросервисов (golang и node. js) .
Я хотел настроить DNS-сервер на ПК с Ubuntu, а затем указать своему ПК с Windows 10 использовать локальный DNS-сервер для специального доменного имени, используя стандартные DNS-серверы, такие как Google в 8.8.8.8 и 8.8.4.4.
Что я сделал
Процедура, которой я следовал (см. Как настроить DNS-сервер BIND9 в Ubuntu 20.04, а также см. Службу доменных имен (DNS) и Все, что вам нужно знать о DNS-серверах Ubuntu):
- установить
bind9
, используяsudo apt install bind9
- создать правило брандмауэра
sudo ufw разрешить Bind9
- изменить файл
/etc/bind/named.conf.options
- изменить файл
/etc/bind/named.conf.local
- создайте копию
/etc/bind/db.local
для моего нового доменного имени,home.x
- изменить новый файл
/etc/bind/db.home.x
с правильными правилами
Доменное имя, которое я хотел использовать локально, было home.
с идеей, что если я введу URL-адрес веб-сайта x
http://www.home.x/
, результирующей страницей будет веб-сервер Apache на мой компьютер с Ubuntu. Или если я ввел http://home.x/svn
результатом будет репозиторий Subversion на моем сервере Ubuntu.
Примечание: для доступа к Subversion через Apache мне пришлось настроить это. См. включение доступа к Subversion через веб-сервер Apache и DAV в Ubuntu, если вам это интересно.
Подробная информация об изменениях и измененных файлах
Компьютер с Ubuntu имеет IP-адрес 192.168.0.4 в моей локальной сети. В приведенных ниже описаниях этот IP-адрес используется везде, где упоминается ПК с Ubuntu.
Я добавил раздел forwarders
в файл /etc/bind/named.conf.options
, чтобы пересылать любые DNS-запросы, неизвестные моему серверу Ubuntu, на какой-то другой DNS-сервер. IP-адреса, которые я скопировал из списка DNS-серверов, возвращенных командой Windows 10 ipconfig /all
, которую я запустил на своем ПК с Windows 10. Измененный файл выглядит следующим образом:
rick@rick-MS-7B98:~/Documents$ cat /etc/bind/named.conf.options опции { директория "/var/cache/bind"; // Если между вами и нужными серверами имен есть брандмауэр // чтобы поговорить, вам может понадобиться исправить брандмауэр, чтобы разрешить несколько // порты для разговора. См. http://www.kb.cert.org/vuls/id/800113. // Если ваш интернет-провайдер предоставил один или несколько IP-адресов для стабильной // серверы имен, вы, вероятно, захотите использовать их в качестве серверов пересылки. // Раскомментируйте следующий блок и вставьте адреса вместо // заполнитель всех 0. // экспедиторы { // 0.0.0.0; // }; // следующие перенаправления на DNS-серверы Google по адресам 8.8.8.8 и 8.8.4.4 экспедиторы { 8.8.8.8; 8.8.4.4; 209.55.27.13; }; //=============================================== ======================== // Если BIND регистрирует сообщения об ошибках об истечении срока действия корневого ключа, // вам нужно будет обновить ваши ключи.См. https://www.isc.org/bind-keys //=============================================== ======================== автоматическая проверка dnssec; слушать на v6 { любой; }; };
После изменения файла /etc/bind/named.conf.options
я запустил утилиту проверки, которая не обнаружила ошибок, а затем перезапустил привязать службу
.
sudo named-checkconf sudo systemctl перезапустить bind9
Затем я добавил новую директиву zone
в файл /etc/bind/named.conf.local
, чтобы создать запись DNS для моего нового локального доменного имени home.x
. Измененный файл выглядит так:
rick@rick-MS-7B98:~/Documents$ cat /etc/bind/named.conf.local // // Делаем здесь любую локальную настройку // // Рассмотрите возможность добавления сюда зон 1918, если они не используются в вашем // организация //включить "/etc/bind/zones.rfc1918 дюймов; зона "home.x" { тип мастер; файл "/etc/bind/db.home.x"; };
Наконец, мне нужно было создать файл /etc/bind/db.home.x
, указанный в директиве файла
директивы зоны
. Я сделал это, начав с копии существующего файла /etc/bind/db.local
, используя команду
sudo cp /etc/bind/db.local /etc/bind/db.home.x.
Затем я изменил файл /etc/bind/db.home.x
, чтобы указать правила, необходимые для разрешения доменного имени home.x
, а также субдомен www.home.x
на IP-адрес моего ПК с Ubuntu. Измененный файл выглядит так:
rick@rick-MS-7B98:~/Documents$ cat /etc/bind/db.home.x ; ; Файл данных BIND для локального петлевого интерфейса ; $TTL 604800 @ В SOA home.x. root.home.x. ( 2; Серийный 604800 ; Обновить 86400 ; Повторить попытку 2419200 ; Срок действия 604800 ) ; Отрицательный TTL кэша ; @ IN NS ns.home.x. @ В А 192.168.0.4 @ В АААА ::1 нс В А 192.168.0.4 www в А 192.168.0.4
На этом этапе я мог проверить, что все работает на моем ПК с Windows 10, используя команду nslookup
из командного окна. Я попробовал сначала без указания IP-адреса ПК с Ubuntu, а затем с IP-адресом ПК с Ubuntu
C:\Users\rickc>nslookup home.x Сервер: dns.google Адрес: 8.8.8.8 *** dns.google не может найти home.x: несуществующий домен C:\Users\rickc>nslookup home.x 192.168.0.4 Сервер: Неизвестный Адрес: 192.168.0.4 Имя: home.x Адреса: ::1 192.168.0.4
Затем я использовал панель управления Windows 10 ( Панель управления > Сеть и Интернет > Сетевые подключения
), чтобы просмотреть список моих сетевых адаптеров, чтобы изменить адреса DNS-серверов, которые использовал мой WiFi-адаптер. Этот параметр можно найти, щелкнув адаптер правой кнопкой мыши, чтобы открыть всплывающее меню, выберите «Свойства», чтобы открыть диалоговое окно «Свойства», затем выберите «Протокол Интернета версии 4», затем нажмите кнопку «Свойства» в диалоговом окне и измените адрес DNS-сервера. Ниже скриншот диалогов.
После изменения адреса DNS-сервера я повторил попытку nslookup
без указания адреса DNS-сервера, и команда находит home.x
:
C:\Users\rickc>nslookup home.x Сервер: Неизвестный Адрес: 192.168.0.4 Имя: home.x Адреса: ::1 192.168.0.4
Когда я протестировал URL-адрес http://www.home.x/
, отображается тестовая страница моего веб-сервера Apache. Когда я проверил URL-адрес http://home.x/svn
, веб-браузер показал дерево каталогов моего репозитория Subversion. Когда я получаю доступ к моему репозиторию Subversion с помощью http://home.x/svn/trunk/
в плагине Ankh Subversion с Visual Studio 2017 работает.
Другие мысли
Одна из проблем с этой настройкой заключается в том, что если мой ПК с Ubuntu не запущен и не работает, то ПК с Windows 10 не будет иметь работающего DNS-сервера до тех пор, пока либо ПК с Ubuntu не будет запущен, либо адрес DNS-сервера не будет вернитесь к исходным настройкам адаптера Wi-Fi.