Всё, что читает или меняет каталог — оснастка Active Directory Users and Computers, модуль PowerShell, Exchange, sssd на Linux, система заявок, которая «интегрирована с AD», — говорит с контроллером по LDAP. Active Directory и есть LDAP-сервер: версии 3, по RFC 4510–4519, с расширениями Microsoft, описанными в открытой спецификации MS-ADTS. Оснастки показывают каталог отредактированным и переведённым; LDAP показывает его как есть. В этой части мы будем смотреть именно так, и это единственная часть серии, где графические инструменты — ldp.exe и ADSI Edit — не упоминание, а предмет: они показывают сырой каталог, и рядом с каждым их действием мы будем ставить ту же операцию в PowerShell.
Вторая половина части — о том, что в каталоге ломается при неосторожной правке и не восстанавливается откатом. Каталог хранит и данные, и собственную конфигурацию, и конфигурация защищена от администратора не сильнее, чем данные.
В прошлой части мы разобрали, что такое лес, домен, разделы каталога и глобальный каталог. Сегодня всё это появится на диске сервера dc1, который мы подготовили в части 1. Повышение сервера до контроллера — операция на десять минут и одну команду, но за эти десять минут меняется почти всё: исчезает локальная база учётных записей, появляются база каталога, DNS-зоны, общие папки и шесть новых служб. Пройдём по шагам и посмотрим на каждый.
Четыре года назад я писал, как поднять свой IKEv2 VPN на strongSwan, и эта статья до сих пор одна из самых читаемых в блоге. С тех пор у IKEv2 появился конкурент, который делает то же самое заметно проще: WireGuard. Там, где strongSwan требует удостоверяющий центр, сертификаты, выбор алгоритмов и три конфигурационных файла, WireGuard обходится парой ключей и десятью строками. Сегодня — как поднять такой сервер на Ubuntu с нуля и подключить к нему Windows и Android.
Что такое VPN в терминах интерфейсов и маршрутов, чем полный туннель отличается от раздельного и откуда берутся утечки DNS и IPv6, разобрано в двадцатой части «Сетей для самых маленьких». Здесь это не повторяется, зато всё, что встречается по ходу, объясняется на месте. Как устроен протокол WireGuard внутри — рукопожатие, криптография, формат пакетов — для настройки знать не нужно, и в этой статье этого нет.
Адреса в статье документационные: сервер 203.0.113.10 и 2001:db8::10, сеть туннеля 10.66.66.0/24. Ключи — заглушки в угловых скобках.
До Active Directory у каждого сервера Windows была своя база учётных записей — SAM, Security Account Manager — и пользователь с десятью серверами имел десять паролей. Домены Windows NT решили это наполовину: один сервер, PDC, держал базу, остальные контроллеры, BDC, получали копию только для чтения, а база оставалась плоским списком имён на 40 тысяч записей без какой-либо структуры и с собственным протоколом на всё. В Windows 2000 Microsoft заменила это каталогом, собранным из открытых стандартов: данные лежат в LDAP-каталоге, аутентификацию делает Kerberos, серверы находят через DNS, а репликация идёт между равными контроллерами без единственного хозяина. Так появился Active Directory, и за 26 лет его устройство почти не изменилось.
В этой части нет команд, которые что-то меняют: прежде чем в следующей выполнить Install-ADDSForest, нужно понимать, что эта команда создаст. Разберём каталог сверху вниз: логическую структуру, объекты, разделы, файлы на диске, и в конце — протоколы, по которым всё это общается.
В прошлой части мы настроили адрес четырьмя командлетами из модуля NetTCPIP. Любое руководство старше 2012 года сделает то же самое одной строкой netsh interface ip set address, а разметку диска доверит diskpart. Обе утилиты никуда не делись: они есть на каждом Windows от XP до Server 2025, работают в среде восстановления, где модулей PowerShell может не быть, и умеют несколько вещей, для которых командлетов так и не написали. Поэтому администратору нужно знать обе: и чтобы читать чужие скрипты, и чтобы не остаться без инструмента, когда PowerShell недоступен.
Эта часть устроена как словарь в обе стороны: что делает старая утилита, каким командлетом это делается сейчас, и где командлета нет.
Это первая статья серии «Windows Server для самых маленьких». Серия для тех, кто хочет понять, как устроен Windows Server и Active Directory изнутри: что происходит между нажатием Ctrl+Alt+Del и появлением рабочего стола, как контроллеры договариваются между собой, что лежит в каталоге и как это читать. К концу серии мы будем ходить по каталогу через LDAP, разбирать билеты Kerberos по полям и переносить роли между контроллерами.
У серии два принципа.
Первый: о каждом компоненте — не только зачем он нужен, но и как он работает. Какие объекты появляются в каталоге, какие пакеты идут по сети, что ломается и почему. Поэтому почти в каждой части будет вывод команд, журналы событий и разбор того, что в них написано.
В современных реалиях иногда бывает так, что кто-то очень хочет, чтобы вы не попали на какой-то ресурс. Кто именно и что это за ресурс — для этой статьи неважно: механика везде одна.
Сначала блокируют по-простому: адрес сайта вносят в чёрный список, ответ DNS подменяют. От этого спасает любой VPN или прокси — трафик уходит на чужой сервер за пределами блокировки, и тот сам ходит на нужный сайт. На следующем шаге этот кто-то ставит DPI, и обычные средства перестают помогать: VPN не подключается, прокси рвётся через секунду после начала. DPI не нужно знать, что внутри туннеля, — он узнаёт сам туннель по виду трафика и обрывает его, как бы надёжно туннель ни был зашифрован.
Что такое DPI и на что он смотрит, разберём ниже по порядку. А сама статья — о связке, сделанной против этого: Xray с протоколом VLESS, потоком XTLS Vision и маскировкой REALITY. Со стороны такое соединение выглядит как обычный HTTPS к большому зарубежному сайту, и даже если проверяющий подключится к серверу сам, он увидит этот сайт с его настоящим сертификатом.
Двадцать две части подряд мы говорили «TLS» одной фразой: «шифрование поверх TCP, на котором работает HTTPS». Пора разобрать его как протокол. IPsec защищал пакеты на сетевом уровне, и приложения о нём не знали; TLS, Transport Layer Security, делает обратное: он живёт внутри одного TCP-соединения (десятая часть), и приложение само решает им пользоваться. Зато ему не нужны ни шлюзы, ни туннели, ни права администратора: библиотека в браузере и библиотека на сервере — и всё. Поэтому именно TLS защищает подавляющую часть трафика в интернете: HTTPS, почту между серверами, DNS в DoT и DoH из двенадцатой части, OpenVPN из двадцатой.
Половина этой части — не о шифровании, а о доверии: откуда браузер знает, что разговаривает именно с www.example.com, а не с тем, кто встал посередине. Шифрование без этого бесполезно, и ответ на этот вопрос — сертификаты.
OSPF из прошлой части строит карту одной сети и считает по ней кратчайшие пути. Интернет — это семьдесят с лишним тысяч независимых сетей, у каждой свой владелец, свои деньги и свои интересы, и никто не согласится отдать соседу карту своей сети, а «кратчайший путь» там не критерий: провайдер повезёт трафик туда, где ему дешевле, а не ближе. Для этого нужен протокол другого рода — не про расстояния, а про политику. Это BGP, Border Gateway Protocol, версия 4, RFC 4271, 1994 год: единственный протокол маршрутизации между сетями, и единственный, на котором держится интернет целиком.
У меня в блоге уже есть серия о BGP на практике — там кластер Kubernetes анонсирует адреса роутеру. Здесь — сам протокол с нуля.
В шестой части таблица маршрутов роутера заполнялась тремя способами: подключённые сети появлялись сами, статические писал администратор, а динамические «приходили от протоколов маршрутизации, по которым роутеры рассказывают друг другу о своих сетях». Пора разобрать, как именно рассказывают. Внутри одной организации — офиса, кампуса, дата-центра, сети провайдера — это почти всегда OSPF, Open Shortest Path First, RFC 2328. Между организациями — BGP, и он в следующей части.