VPN піднімається. Пінги проходять. Хтось оголошує перемогу. Потім користувачі не можуть увійти, групові політики виконуються як геологічний процес, а повідомлення «trust relationship failed»
починають з’являтися, наче тости у спільній кухні офісу.
Active Directory не “відключається чемно” через VPN. Воно ламається по-особливому і повторювано: DNS поводиться дивно, час йде вбіг, порти «затискають», а
затримки роблять протоколи, розраховані на швидку локальну мережу, схожими на пересування крізь вологий цемент. Це польовий посібник про те, що
ламається першим — і які фікси справді витримують експлуатацію.
Що ламається першим: звичайний порядок болю
Якщо ви переносите або розширюєте Active Directory через VPN — site-to-site IPsec, WireGuard, OpenVPN, що завгодно — режими відмови дивовижно
послідовні. Порядок нижче не теоретичний. Це те, що дзвонить вам о 2:00 ранку.
1) DNS ламається першим (або завжди був проблемним, і ви просто це помітили)
AD — це каталог, але він поводиться як додаток DNS з функціями ідентифікації. Контролери домену знаходяться через SRV-записи.
Клієнти знаходять служби LDAP, Kerberos і GC через DNS. Якщо ваш VPN змінює DNS-сервер, який використовує клієнт, якщо split DNS налаштовано неправильно,
або якщо conditional forwarders вказують на мертву адресу, домен фактично зникає.
2) Час ламається другим (Kerberos відмовляється вести переговори з брехунами)
Kerberos використовує час, щоб запобігти повторному відтворенню атак. Якщо годинник клієнта відхиляється за допустимий поріг (звично 5 хвилин), автентифікація не відбудеться.
У LAN невідповідності NTP часто маскуються «досить близько». Через VPN ви додаєте нові джерела часу, поведінку сну/пробудження на ноутбуках
і іноді NAT-пристрої, що перешкоджають поведінці NTP/UDP.
3) Порти ламаються третіми (фаєрволи змушують дорослих плакати)
Хтось запропонує «дозволити лише 88 і 389». Хтось інший наполягатиме «зараз все через 443». Жодне з цього не відповідає істині для класичних операцій AD.
Вам потрібен набір відомих портів і стратегія для динамічних RPC-портів. Через VPN постава «за замовчуванням заборонено» — це хороша безпека,
але також спосіб створити містичні, напівпрацюючі домени.
4) Затримки й втрата пакетів руйнують користувацький досвід (навіть якщо нічого не «впало»)
AD може технічно функціонувати, поки входи тривають 90 секунд, групова політика таймаутиться або накопичується черга DFSR. Через VPN RTT і джиттер важливі.
Розмовні (chatty) протоколи AD — особливо під час входу й обробки політик — карають за довгі кругові запити.
Жарт №1: Active Directory через VPN — як стосунки на відстані: працює, поки хтось не перестає надійно комунікувати, і DNS зазвичай — «хтось».
Цікаві факти та історичний контекст (щоб дивне стало зрозумілим)
- Факт 1: Службове відкриття AD сильно покладається на SRV-записи DNS (RFC 2782). Ось чому «DNS працює» рідко означає, що все гаразд.
- Факт 2: Стандартний максимальний допуск відхилення годинника Kerberos у Windows-доменах зазвичай 5 хвилин — досить мало, щоб режим сну ноутбука зіпсував вам робочий день.
- Факт 3: Реплікація AD використовує RPC, що історично означало динамічні діапазони портів. Сучасний Windows може обмежити цей діапазон, але це потрібно робити свідомо.
- Факт 4: Реплікація SYSVOL перейшла з FRS на DFSR, бо FRS був крихким у масштабі та відомо погано обробляв конфлікти.
- Факт 5: «Sites and Services» існує тому, що AD передбачав швидкі, надійні лінки всередині сайту та повільніші між сайтами — по суті, WAN-aware дизайн до того, як «хмара» стала модною.
- Факт 6: Global Catalog (GC) працює на портах 3268/3269, бо Microsoft потрібен був спосіб виконувати запити по всьому лісу без нескінченних перенаправлень.
- Факт 7: LDAP signing і channel binding за роки посилилися, бо LDAP був надто поблажливим для сучасних загроз; VPN не робить слабкий LDAP безпечним автоматично.
- Факт 8: Приєднання до домену Windows все ще покладається на набір старих протоколів (SMB, RPC, Netlogon), бо сумісність в корпоративному середовищі — це не тимчасове явище, а стиль життя.
Швидкий план діагностики (перевірте в цьому порядку)
Вам потрібна швидкість. Не чекліст на 40 кроків, що виглядає як аудит відповідності. Це послідовність «знайти вузьке місце за 10 хвилин».
Крок 1: Підтвердьте, що клієнт використовує правильні DNS-сервери (а не «той, що запропонувала гостьова Wi‑Fi мережа»)
- Якщо клієнт не може розв’язати
_ldap._tcp.dc._msdcsдля домену — зупиніться. Спочатку виправляйте DNS. - Якщо DNS розв’язує, але повертає недоступні IP контролерів домену — виправте маршрутизацію/VPN split tunneling/підмережі.
Крок 2: Перевірте зсув часу на клієнті та DC, до якого він намагається звертатися
- Якщо зсув часу > 300 секунд, виправте ієрархію NTP і джерело часу клієнта. Не «просто збільшуйте допуск Kerberos».
Крок 3: Перевірте базові порти AD з проблемної мережі до конкретного DC
- Тестуйте TCP 88, 389/636, 445, 135, 53, 464 і представницький RPC high port (або ваш обмежений діапазон).
- Якщо 445 не працює: очікуйте проблем із SYSVOL/GPO, приєднанням до домену та «trust relationship».
Крок 4: Визначте, який DC обрав клієнт, і чи це правильний сайт
- Якщо віддалений сайт використовує DC через тунель, хоча існує ближчий DC — виправте Sites/Subnets і поведінку DC locator.
Крок 5: Якщо все «працює», але повільно — виміряйте RTT і втрати і пошукайте проблеми з MTU/MSS
- Високий RTT + втрата пакетів + SMB + RPC = повільні входи та таймаути політик.
- MTU black holes спричиняють божевільні переривчасті відмови, що виглядають як «випадкові проблеми автентифікації». Це не випадковість.
DNS: мовчазний саботажник
DNS не є другорядним актором в AD. DNS — співголовний. Механізм виявлення AD — «запитай DNS, хто контролери домену»
і «запитай DNS, який DC найближчий». Коли клієнти VPN або віддалені сайти не можуть надійно використовувати інтегрований у AD DNS, ви отримуєте часткові відмови:
підказки для входу, повільні приєднання до домену, помилки GPO та програми, які не знаходять LDAP.
Split DNS та клієнти VPN: оберіть дизайн і дотримуйтеся його
У вас по суті є два розумні варіанти:
- Примусово використовувати внутрішній DNS при підключенні до VPN (full tunnel або split tunnel з примусовим DNS). Це найпростіше для коректності AD.
- Використовувати conditional forwarding / split-horizon DNS, де внутрішні AD-зони розв’язуються внутрішніми DNS навіть якщо інші запити йдуть назовні.
Нерозумна опція — «дозволити клієнту використовувати будь-який DNS, який він отримав від DHCP або Wi‑Fi, і сподіватися». Надія — не стратегія; це відмова з мотиваційним постером.
SRV-записи: що клієнти реально запитують
Коли Windows-клієнту потрібен DC, він запитує записи типу:
_ldap._tcp.dc._msdcs.<domain> і _kerberos._tcp.<domain>.
Якщо вони не розв’язуються, клієнт не «трохи спантеличений». Він сліпий.
Чому DNS AD ламається саме через VPN
- Неправильний DNS-сервер, який штовхає VPN: ви налаштували публічний DNS «для швидкості», і тепер AD-записів немає.
- Split tunneling без маршруту до DNS-сервера: клієнту кажуть використовувати внутрішній DNS, але він не може дістатися до нього через політику маршрутизації.
- Conditional forwarders спрямовані через тунель: коли тунель дергається, розв’язування DNS зупиняється (і логон теж).
- EDNS/фрагментація: відповіді DNS зі SRV-записами можуть ставати більшими; проблеми MTU можуть зробити DNS нестабільним.
Час: Kerberos педантичний і зберігає квитанції
Kerberos ґрунтується на «квитках», що мають терміни дії і прив’язку до часу. Якщо ваші годинники не погоджені, протокол вважає, що хтось бреше або виконує повторне відтворення.
Через VPN проблеми з часом посилюються, бо ноутбуки мандрують, засинають, відновлюються і підхоплюють різні джерела NTP залежно від мережі.
Як виглядає «зсув часу» в продакшні
- Користувача повторно просять ввести облікові дані.
- Приєднання до домену не вдається з загальними помилками, що не згадують час.
- LDAP bind іноді працює, але Kerberos SSO — ні.
- У журналах подій з’являються помилки Kerberos (наприклад, pre-auth failures), які неправильно діагностують як «неправильний пароль».
Робіть нудну річ: одну авторитетну ієрархію часу
У Windows-домені варто:
- PDC Emulator в кореневому домені лісу синхронізувати з надійними зовнішніми джерелами часу.
- Усі інші DC синхронізуються з ієрархії домену.
- Усі члени домену синхронізуються з ієрархії домену.
Не дозволяйте клієнтам VPN використовувати випадкові публічні NTP-сервери одночасно з тим, як вони спробують Kerberos-автентифікацію до ваших DC. Так ви отримаєте «працює вдома, відмовляє в готелі».
Порти: коли «ми відкрили лише 443» зустрічає реальність
AD — це не один протокол. Це набір. Через VPN у вас може не бути «фаєрволу» в традиційному розумінні, але у вас є security groups,
ACL, політично-обумовлена маршрутизація, NAT-правила і люди з сильними почуттями. Порти все одно мають значення.
Основні порти, які зазвичай потрібні (не вичерпний список, але реальний)
- DNS: TCP/UDP 53
- Kerberos: TCP/UDP 88
- Зміна пароля Kerberos: TCP/UDP 464
- LDAP: TCP/UDP 389 (UDP використовується в деяких старих сценаріях; більшість bind-ів — TCP)
- LDAPS: TCP 636 (якщо використовується)
- Global Catalog: TCP 3268 / 3269
- SMB (SYSVOL, NETLOGON): TCP 445
- RPC endpoint mapper: TCP 135
- RPC динамічні порти: TCP high ports (діапазон залежить від ОС/налаштувань)
Проблема з динамічними RPC-портами (і дорослий фікс)
Реплікація AD та багато операцій управління Windows використовують RPC. RPC використовує TCP 135, щоб знайти службу, а потім передає управління динамічному високому порту.
Якщо політика «VPN-фаєрволу» дозволяє лише кілька портів, реплікація ламається дивними способами.
Правильний підхід: обмежити динамічний діапазон RPC на контролерах домену (і на відповідних серверах) до визначеного малого блока, а потім дозволити цей діапазон через VPN.
Це не гламурно. Але стабільно.
Жарт №2: Блокувати динамічні RPC-порти через «безпеку» — як прибрати всі ручки дверей, щоб запобігти зломам — вітаємо, ви тепер живете зовні.
Затримки й втрата пакетів: смерть від тисячі кругових запитів
Ви можете мати ідеальний DNS, ідеальний час і відкриті порти, і все одно мати поганий день. Той день називається «VPN має 120ms RTT і 1% втрат».
Логон та обробка GPO включають кілька мережевих операцій: LDAP-запити, обміни Kerberos, SMB-зчитування політик, іноді перевірки сертифікатів.
Кожна додає круговий запит. Множимо. Додаємо втрати пакетів, що викликають повторні передачі та таймаути.
MTU/MSS: грім за спиною «працює для дрібниць»
VPN часто зменшують ефективний MTU. Якщо ви не обмежуєте MSS або не налаштовуєте MTU відповідно, можна отримати black-hole фрагментації:
малі пакети проходять, більші зникають. DNS з великими відповідями, Kerberos-квитки та SMB-трафік можуть поводитися некоректно.
Симптом — переривчасті відмови, що не корелюють із завантаженням. Люди звинувачуватимуть «AD як AD». Це не AD. Це ваш шлях пакетів.
Коли «оптимізація» означає «гірше зробити»
Стиснення, агресивний DPI та «WAN-оптимізатори» можуть псувати трафік AD, особливо SMB і RPC.
Деякі пристрої працюють нормально. Деякі — ні. Якщо ви додасте коробку, яка переставляє пакети або має дивні таймаути, AD покарає вас непередбачуваними стражданнями.
Сайти, підмережі та реплікація: зробіть топологію AD відповідною до мережі
Якщо ви експлуатуєте AD через VPN і не налаштували Sites and Services правильно, ви залишаєте свою долю на розсуд heuristics DC locator.
Іноді пощастить. Іноді філія в Сінгапурі аутентифікує через DC у Вірджинії, бо клієнт подумав, що той «ближчий».
Це і смішно, і дорого.
Зробіть ці три речі або навіть не починайте
- Створіть AD Site для кожного VPN-підключеного розташування, де є значущі відмінності латентності/пропускної здатності.
- Призначте IP-підмережі до правильного сайту, щоб клієнти обирали місцеві DC, а топологія реплікації мала сенс.
- Налаштуйте site links і розклади реплікації, якщо VPN-лінк обмежений або тарифікується.
Реплікація через VPN: стабільність важливіша за швидкість
Реплікація — це не лише «відкрийте порти». Це також уникнення флапінгу. Якщо ваш VPN нестабільний, реплікація буде ставити чергу.
Ви отримаєте ризик залишкових об’єктів, накопичення DFSR backlog і дивності, що не проявляться одразу.
Операційний пріоритет: тримати тунель стабільним, час — стабільним, DNS — послідовним, і при потребі навмисно регулювати реплікацію.
«Дайте їй волю» — це як наситити лінк і потім звинуватити AD у наслідках.
SYSVOL, DFSR та GPO через VPN
Групова політика — там, де «AD працює» зустрічається «користувачі зляться». Обробка GPO залежить від:
LDAP для метаданих політики та фільтрації безпеки, і доступу SMB до SYSVOL для самих файлів політики.
Через VPN SMB (445) і здоров’я DFSR реплікації стають критичними.
Поширені шаблони болю GPO через VPN
- Повільний вхід: клієнт чекає на читання SYSVOL через лінк з великою латентністю.
- GPO зривається час від часу: SMB-таймаути через втрати пакетів або проблеми MTU.
- Нові політики не застосовуються: DFSR backlog або збої реплікації означають, що SYSVOL не однаковий на всіх DC.
Суб’єктивні поради
- Для віддалених користувачів на нестабільному VPN віддавайте перевагу політикам, що не вимагають великих читань SYSVOL під час входу.
- Тримайте SYSVOL чистим. Не використовуйте його як файлшар для «зручних скриптів».
- Якщо потрібні великі пакети, використовуйте нормальні механізми розповсюдження ПЗ, а не SYSVOL як неофіційну CDN.
Практичні завдання: команди, виводи та рішення (12+)
Ось команди, які ви запускаєте, коли все горить. Кожне завдання включає: команду, репрезентативний вивід, що це означає і яке рішення ухвалювати.
Мікс Windows і Linux — умисний: багато VPN-шлюзів і хостів для моніторингу працюють на Linux, і вам потрібно тестувати шлях, що ламається.
Завдання 1: Перевірити, які DNS-сервери використовує Windows-клієнт
cr0x@server:~$ powershell -NoProfile -Command "Get-DnsClientServerAddress -AddressFamily IPv4 | Format-Table -AutoSize"
InterfaceAlias ServerAddresses
-------------- --------------
Ethernet {10.20.0.10, 10.20.0.11}
Wi-Fi {8.8.8.8}
Значення: Wi‑Fi використовує публічний DNS. Якщо VPN-клієнт не переважає DNS на активному інтерфейсі, AD-пошуки можуть іти в публічний простір і провалюватися.
Рішення: Примусово використовувати внутрішній DNS при підключенні VPN або реалізувати NRPT/conditional forwarding, щоб AD-зони розв’язувалися внутрішньо.
Завдання 2: Перевірити розв’язування SRV-записів для контролерів домену
cr0x@server:~$ nslookup -type=SRV _ldap._tcp.dc._msdcs.corp.example.com 10.20.0.10
Server: dns01.corp.example.com
Address: 10.20.0.10
_ldap._tcp.dc._msdcs.corp.example.com SRV service location:
priority = 0
weight = 100
port = 389
svr hostname = dc01.corp.example.com
_ldap._tcp.dc._msdcs.corp.example.com SRV service location:
priority = 0
weight = 100
port = 389
svr hostname = dc02.corp.example.com
Значення: DNS може знайти DC через SRV-записи. Якщо це не працює, відкриття AD discovery — немає.
Рішення: Якщо NXDOMAIN/таймаут — виправляйте доступність DNS або реплікацію зон; поки не чіпайте Kerberos.
Завдання 3: Підтвердити, що розв’язаний DC доступний через VPN
cr0x@server:~$ ping -c 3 dc01.corp.example.com
PING dc01.corp.example.com (10.20.0.21) 56(84) bytes of data.
64 bytes from 10.20.0.21: icmp_seq=1 ttl=127 time=42.1 ms
64 bytes from 10.20.0.21: icmp_seq=2 ttl=127 time=41.8 ms
64 bytes from 10.20.0.21: icmp_seq=3 ttl=127 time=42.4 ms
--- dc01.corp.example.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 41.8/42.1/42.4/0.2 ms
Значення: Базова досяжність існує й RTT ≈ 42ms. Це придатно для роботи.
Рішення: Якщо ping не проходить — перевірте маршрутизацію VPN, ACL та чи не блокується ICMP (і все одно протестуйте TCP-порти).
Завдання 4: Протестувати критичні порти до DC з Linux jump-хоста
cr0x@server:~$ nc -vz dc01.corp.example.com 53 88 135 389 445 464 3268
Connection to dc01.corp.example.com (10.20.0.21) 53 port [tcp/domain] succeeded!
Connection to dc01.corp.example.com (10.20.0.21) 88 port [tcp/kerberos] succeeded!
Connection to dc01.corp.example.com (10.20.0.21) 135 port [tcp/msrpc] succeeded!
Connection to dc01.corp.example.com (10.20.0.21) 389 port [tcp/ldap] succeeded!
nc: connect to dc01.corp.example.com (10.20.0.21) port 445 (tcp) failed: Operation timed out
Connection to dc01.corp.example.com (10.20.0.21) 464 port [tcp/kpasswd] succeeded!
Connection to dc01.corp.example.com (10.20.0.21) 3268 port [tcp/globalcatLDAP] succeeded!
Значення: SMB (445) заблоковано або несправне. Очікуйте проблем зі GPO/SYSVOL і приєднанням до домену.
Рішення: Відновіть шлях до 445 через VPN або спроектуйте навколо цього (рідко реалістично, якщо хочете «звичайну» поведінку домену).
Завдання 5: Перевірити стан безпечного каналу Windows
cr0x@server:~$ powershell -NoProfile -Command "Test-ComputerSecureChannel -Verbose"
VERBOSE: Performing the operation "Test-ComputerSecureChannel" on target "WIN11-042".
True
Значення: Довірчий зв’язок машини з доменом цілий.
Рішення: Якщо False — можливо потрібно відновити secure channel (після виправлення DNS/часу/портів).
Завдання 6: Відновити зламаний secure channel (після перевірки підключення)
cr0x@server:~$ powershell -NoProfile -Command "Test-ComputerSecureChannel -Repair -Credential (Get-Credential)"
PowerShell credential request
Enter your credentials.
User: CORP\adminuser
Password for user CORP\adminuser: ********
True
Значення: Пароль облікового запису комп’ютера скинуто і довіра відновлено.
Рішення: Якщо ремонт не вдається — повторно перевірте зсув часу і доступність RPC/SMB; не намагайтеся нескінченно, щоб не заблокувати адмінські облікові дані.
Завдання 7: Перевірити стан синхронізації часу в Windows
cr0x@server:~$ w32tm /query /status
Leap Indicator: 0(no warning)
Stratum: 4 (secondary reference - syncd by (S)NTP)
Precision: -23 (119.209ns per tick)
Last Successful Sync Time: 12/28/2025 11:22:10 AM
Source: dc01.corp.example.com
Poll Interval: 6 (64s)
Значення: Клієнт синхронізується з доменом (добре).
Рішення: Якщо джерело — «Local CMOS Clock» або публічний NTP під час VPN — виправте конфігурацію часової служби і VPN DNS/маршрутизацію.
Завдання 8: Виміряти відхилення часу з Linux-хоста (швидка перевірка)
cr0x@server:~$ chronyc tracking
Reference ID : 0A140015 (dc01.corp.example.com)
Stratum : 4
Ref time (UTC) : Sun Dec 28 11:22:15 2025
System time : 0.000412345 seconds fast of NTP time
Last offset : -0.000120113 seconds
RMS offset : 0.000231009 seconds
Frequency : 12.345 ppm fast
Residual freq : -0.120 ppm
Skew : 0.210 ppm
Root delay : 0.042123456 seconds
Root dispersion : 0.001234567 seconds
Значення: Зсув субмілісекундний. Час — не ваша проблема.
Рішення: Якщо відхилення — секунди/хвилини, виправляйте шлях NTP перед тим, як чіпати Kerberos/GPO.
Завдання 9: Подивитися, який DC клієнт фактично вибрав
cr0x@server:~$ nltest /dsgetdc:corp.example.com
DC: \\dc02.corp.example.com
Address: \\10.20.0.22
Dom Guid: 3d1d5d8a-1111-2222-3333-aaaaaaaaaaaa
Dom Name: corp.example.com
Forest Name: corp.example.com
Dc Site Name: HQ
Our Site Name: BRANCH01
Flags: GC DS LDAP KDC TIMESERV WRITABLE DNS_DC DNS_DOMAIN DNS_FOREST CLOSE_SITE
Значення: Сайт клієнта — BRANCH01, але він вибрав DC в HQ; «CLOSE_SITE» вказує, що місцевого DC не знайдено або мапінг підмережі неправильний.
Рішення: Виправте мапінг Sites/Subnets або забезпечте DC/RODC в BRANCH01, якщо це передбачено.
Завдання 10: Перевірити підсумковий стан контролера домену
cr0x@server:~$ dcdiag /s:dc01 /q
cr0x@server:~$ echo $?
0
Значення: Код виходу 0 означає відсутність серйозних помилок у тихому режимі.
Рішення: Якщо з’являються помилки (збої DNS, advertising failures) — виправляйте стан DC перед тим, як звинувачувати VPN.
Завдання 11: Перевірити статус реплікації AD між DC
cr0x@server:~$ repadmin /replsummary
Replication Summary Start Time: 2025-12-28 11:24:31
Beginning data collection for replication summary, this may take awhile:
......
Source DSA largest delta fails/total %% error
dc01 00:05:12 0 / 20 0
dc02 00:06:01 2 / 20 10 (1722) The RPC server is unavailable.
Destination DSA largest delta fails/total %% error
dc01 00:06:01 0 / 20 0
dc02 03:42:19 2 / 20 10 (1722) The RPC server is unavailable.
Значення: Реплікація до/з dc02 падає з помилкою RPC unavailable. Це майже завжди проблеми з портами, правилами фаєрволу або маршрутизацією.
Рішення: Перевірте TCP 135 і динамічний діапазон RPC між DC через VPN; обмежте RPC-діапазон і дозволіть його, якщо потрібно.
Завдання 12: Перевірити динамічний діапазон RPC-портів у Windows
cr0x@server:~$ netsh int ipv4 show dynamicport tcp
Protocol tcp Dynamic Port Range
---------------------------------
Start Port : 49152
Number of Ports : 16384
Значення: Сучасний стандартний діапазон 49152–65535. Якщо ваша VPN-політика цього не дозволяє, RPC-операції можуть падати.
Рішення: Розгляньте можливість обмежити діапазон на DC до меншого блока і дозволити його через VPN.
Завдання 13: Протестувати доступ SMB до SYSVOL з Windows-клієнта
cr0x@server:~$ powershell -NoProfile -Command "dir \\corp.example.com\SYSVOL | Select-Object -First 3"
Directory: \\corp.example.com\SYSVOL
Mode LastWriteTime Length Name
---- ------------- ------ ----
d---- 12/12/2025 10:10 AM corp.example.com
d---- 12/12/2025 10:10 AM staging
d---- 12/12/2025 10:10 AM sysvol
Значення: SYSVOL доступний і доступний для перегляду. Доступ до файлів GPO повинен працювати.
Рішення: Якщо це зависає або помиляється — виправте TCP 445, проблеми MTU або розв’язування імен до DC, що тримає SYSVOL referrals.
Завдання 14: Примусово оновити групову політику і прочитати результат
cr0x@server:~$ gpupdate /force
Updating policy...
Computer Policy update has completed successfully.
User Policy update has completed successfully.
Значення: Принаймні один прохід успішний. Якщо це повільно — все одно можуть бути проблеми з латентністю/SMB.
Рішення: Якщо gpupdate падає з «cannot read gpt.ini», зосередьтеся на SYSVOL/SMB і здоров’ї DFSR.
Завдання 15: Перевірити ефективний MTU на шляху (Linux)
cr0x@server:~$ ping -M do -s 1372 -c 3 10.20.0.21
PING 10.20.0.21 (10.20.0.21) 1372(1400) bytes of data.
1380 bytes from 10.20.0.21: icmp_seq=1 ttl=127 time=42.5 ms
1380 bytes from 10.20.0.21: icmp_seq=2 ttl=127 time=42.0 ms
1380 bytes from 10.20.0.21: icmp_seq=3 ttl=127 time=42.2 ms
--- 10.20.0.21 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
Значення: Шлях підтримує пакети 1400 байт без фрагментації. Це хороший знак для багатьох VPN-настроєнь.
Рішення: Якщо з’являється «Frag needed» — обмежте MSS на краях VPN або налаштуйте MTU; переривчасті проблеми AD часто зникають після цього.
Завдання 16: Перевірити LDAPS handshake (якщо ви використовуєте LDAPS)
cr0x@server:~$ openssl s_client -connect dc01.corp.example.com:636 -servername dc01.corp.example.com -brief
CONNECTION ESTABLISHED
Protocol version: TLSv1.2
Ciphersuite: ECDHE-RSA-AES256-GCM-SHA384
Peer certificate: CN=dc01.corp.example.com
Verification: OK
Значення: LDAPS доступний і сертифікат валідується (з поточного trust store цього хоста).
Рішення: Якщо це падає — або відкрийте 636, або виправте сертифікат DC, або не наполягайте на LDAPS для застосунків, що не можуть дістатися його через VPN.
Три міні-історії з корпоративного життя (що насправді відбувається)
Міні-історія 1: Інцидент через неправильне припущення
Середня компанія придбала меншу фірму і вирішила «тимчасово» з’єднати мережі через site-to-site VPN. Припущення було простим:
«Якщо можемо пропінгувати контролер домену — приєднання до домену працюватиме».
Перший тиждень здавався нормальним, бо тестували лише кілька IT-ноутбуків — і ті мали кешовані облікові дані та вручну налаштований внутрішній DNS.
Потім розгорнули партію нових машин. Приєднання до домену почало випадково падати. Деякі машини приєднувались, деякі — ні, а ті, що приєдналися, довго застосовували політики.
Постмортем був жорсткий у простоті. VPN не передавав налаштування DNS. Клієнти використовували будь-який DNS, який мали — зазвичай маршрутизатор філії, що форвардив до резолвера провайдера.
Провайдер, на щастя, не містив _ldap._tcp.dc._msdcs записів для їх приватної зони AD. Тому процес приєднання падав на повільному, іноді неправильному виявленні.
Фікс не був героїчним. Вони примусово налаштували внутрішній DNS через VPN і додали conditional forwarders для AD-зони на філіальному DNS-форвардері.
Все стабілізувалося миттєво. Урок: «ping працює» — це тест для ICMP, а не тест для інфраструктури ідентифікації.
Міні-історія 2: Оптимізація, що зіграла злий жарт
Інша організація мала солідний дизайн AD: DC у кожному великому сайті, налаштовані Sites and Services, розклад реплікації. Було нудно.
Потім мережевий відділ додав «оптимізацію продуктивності» на VPN-концентраторі: агресивну обробку UDP з новою політикою, що пріоритизувала «важливий трафік»
і занижувала «bulk traffic». Здогадайтеся, куди потрапили SMB і деякі потоки RPC.
Симптоми були дивні. Автентифікація зазвичай працювала, але логон-скрипти іноді падали. Обробка групових політик випадково займала хвилини.
Накопичення DFSR почало рости, але не рівномірно — лише один сайт показував постійне відставання.
Вони довго ганялися за «проблемою реплікації AD». Коли хтось нарешті промоніторив втрати пакетів на тунелі і зв’язав це з повторними передачами SMB,
картина стала очевидною: оптимізатор скид а або затримував сегменти під навантаженням. Windows-клієнти тоді починали бомбардувати лінк повторними передачами,
що робило «оптимізатор» ще більш упевненим, що бачить «bulk traffic» і ще сильніше карало його. Петля зворотного зв’язку.
Фікс — прибрати політику і впровадити простий QoS, що захищає тунель від насичення, замість спроб обдурити TCP.
Продуктивність повернулася, і реплікація AD перестала виглядати так, ніби має сезонну депресію.
Міні-історія 3: Нудна, але правильна практика, що врятувала день
Глобальна компанія мала віддалені виробничі сайти, з’єднані VPN через ненадійні last-mile канали. Вони знали, що лінки флапатимуть.
Тому вони зробили три нудні речі вранці: встановили RODC в кожному віддаленому сайті, правильно змепили підмережі на сайти і встановили сувору ієрархію часу
з PDC emulator як зовнішнім джерелом часу.
Через місяць регіональний провайдер відрубав набір тунелів на півдня. Люди очікували хаосу з автентифікацією.
Натомість користувачі на заводах продовжували входити. Кешовані облікові дані допомогли, але справжнім героєм був локальний RODC для багатьох операцій,
плюс послідовне відліковування часу, яке запобігло збоїв Kerberos, коли з’єднання повернулося.
Коли тунелі повернулися, реплікація догналася контрольованим чином, бо site links і розклади були налаштовані для обмежених лінків.
Жодних панічних ручних втручань. Жодного «ми перезавантажили DC бо так». Інцидент залишився проблемою мережі, і залишився там.
Ось що робить хороша інфраструктура: вона ламається всередині свого власного радіусу ураження. Нудно — це ознака якості.
Поширені помилки: симптом → корінна причина → виправлення
1) Симптом: Приєднання до домену падає з загальними повідомленнями про помилку
Корінна причина: Клієнт не може розв’язати SRV-записи AD або використовує публічний DNS; або SMB/RPC порти заблоковані.
Виправлення: Примусово використовувати внутрішній DNS через VPN; перевірити SRV-запити; забезпечити доступ 445/135 і RPC-діапазону; підтвердити маршрути клієнта до підмереж DC.
2) Симптом: «The trust relationship between this workstation and the primary domain failed»
Корінна причина: Зламався secure channel через невідповідність пароля машини, часто викликану довгим офлайн-періодом і нестабільним повторним підключенням; іноді — зсув часу.
Виправлення: Виправте DNS/час спочатку; потім Test-ComputerSecureChannel -Repair або повторно приєднайте до домену; перевірте досяжність DC і SMB/RPC.
3) Симптом: Користувачі можуть увійти, але Group Policy повільна або падає
Корінна причина: SMB (445) порушений; SYSVOL недоступний; DFSR backlog; висока латентність і втрата пакетів.
Виправлення: Перевірте доступ до \\domain\SYSVOL; відновіть 445 і MTU/MSS; перевірте здоров’я DFSR; зменшіть надмірні GPO.
4) Симптом: Повторні запити на автентифікацію, або SSO не працює при роботі пароля
Корінна причина: Зсув часу Kerberos; клієнт використовує неправильний KDC через DNS або неправильні налаштування сайтів.
Виправлення: Застосуйте доменну ієрархію часу; перевірте статус w32tm; виправте Sites/Subnets, щоб клієнти вибирали місцеві DC.
5) Симптом: Помилки реплікації, як «RPC server unavailable»
Корінна причина: TCP 135 або динамічні RPC-порти заблоковані; асиметрична маршрутизація через split tunneling; NAT-перешкоди.
Виправлення: Дозвольте 135 і динамічний діапазон; або обмежте RPC-діапазон на DC і дозвольте цей діапазон. Перевіряйте repadmin і тести портів.
6) Симптом: Усе працює до пікових годин, після чого AD «поводиться неадекватно»
Корінна причина: Насичення VPN, чергування, втрата пакетів; іноді «оптимізатори», що шкодять SMB/RPC.
Виправлення: Плануйте пропускну здатність тунелю; додайте адекватний QoS; уникайте агресивних WAN-оптимізаторів; вимірюйте RTT/втрати і корелюйте з часами входу/GPO.
7) Симптом: Тільки деякі підмережі/користувачі падають
Корінна причина: Неповні Sites/Subnets; відсутні маршрути split tunneling; conditional forwarding DNS застосований лише до частини клієнтів.
Виправлення: Аудит мапінгу підмереж; стандартизація профілів VPN; забезпечення, що DNS-політики застосовуються послідовно для всіх типів клієнтів.
Контрольні списки / покроковий план (зробіть так, щоб це залишалося виправленим)
Покроково: зробити AD через VPN надійним
- Інвентаризуйте ваші DC і ролі. Знайте, де PDC emulator і які DC є GC.
- Оберіть DNS-стратегію для VPN-клієнтів. Примусово внутрішній DNS під час підключення, або правильно реалізуйте split DNS.
- Перевірте розв’язування SRV-записів з кожної віддаленої мережі. Зробіть це моніторинговою перевіркою, а не одноразовим тестом.
- Зміцніть ієрархію часу. PDC синхронізується із зовнішніми джерелами; усі інші — з доменної ієрархії. Перевіряйте через
w32tmі моніторинг. - Визначте потрібні порти і стратегію RPC. Розв’яжіть, чи дозволяти стандартний динамічний діапазон чи обмежити його. Документуйте та впровадьте.
- Виправте MTU/MSS заздалегідь. Налаштуйте MSS clamping на краях VPN. Тестуйте за допомогою пінгів з «do not fragment» і великих DNS-відповідей.
- Реалізуйте мапінг AD Sites/Subnets. Кожна віддалена підмережа має відповідний сайт. Без винятків. Винятки стають відмовами.
- Визначте локальний DC або RODC для віддалених сайтів. Якщо сайт має працювати під час відключення тунелю — встановіть RODC або місцевий DC.
- Плануйте розклади реплікації для обмежених лінків. Не насичуйте тунель реплікацією в робочі години.
- Тестуйте GPO і доступ до SYSVOL. Регулярно перевіряйте SMB-досяжність і здоров’я DFSR.
- Створіть синтетичний тест «віддалений вхід». З хоста у віддаленій мережі періодично тестуйте SRV, Kerberos, LDAP, SMB.
- Напишіть план відкату. Якщо зміна VPN ламає AD, потрібен швидкий шлях повернення. «Будемо усувати на живому» — не план.
Операційний чекліст: перш ніж звинувачувати AD
- Тунель VPN стабільний? Жодного флапу, частих rekey або падінь?
- Маршрутизація симетрична? Жодних дивностей split tunneling, коли запити йдуть в один бік, а відповіді повертаються іншим?
- DNS послідовний? Клієнти використовують внутрішні резолвери і можуть розв’язувати SRV-записи?
- Час стабільний? Клієнти і DC в межах 5 хвилин, бажано в межах секунд?
- Порти перевірені? 53/88/389/445/135 + RPC-діапазон доступні?
- Латентність прийнятна? Якщо RTT > ~150ms і втрата > ~0.5%, очікуйте болю без редизайну.
FAQ (питання, які люди задають одразу після зламу)
1) Чи може Active Directory взагалі працювати через VPN?
Так. Воно працює щоденно в реальних компаніях. Але це потребує дисциплінованого DNS, ієрархії часу, правильної портової політики (включно зі стратегією RPC)
та AD Sites/Subnets, що відповідають VPN-топології.
2) Що ламається першим на практиці: DNS, час чи порти?
DNS. Майже завжди DNS. Другим — час. Третім — порти. Затримки — це повільний підрив, що змушує вас думати, ніби AD нестабільне, коли це лінк.
3) Чи справді нам потрібен SMB (445) через VPN?
Якщо ви хочете звичайну поведінку домену: так. SYSVOL і багато логон/GPO-потоків покладаються на SMB.
Ви можете зменшити залежність (наприклад, мінімізувати скрипти і великі файли політик), але блокування 445 зазвичай призводить до самонанесеної ідентифікаційної дисфункції.
4) Чи можемо ми «просто використовувати LDAPS» і закрити LDAP 389?
Деякі середовища можуть, але це не універсальна заміна. Операції домену, застарілі додатки та певні механізми виявлення можуть іще використовувати 389.
Якщо ви впроваджуєте LDAPS, робіть це як спланований проєкт з інвентаризацією додатків і життєвим циклом сертифікатів, а не як п’ятничну зміну фаєрволу.
5) Чи варто збільшувати допустимий зсув Kerberos, щоб уникнути збоїв?
Ні. Виправляйте синхронізацію часу. Збільшення допуску — як послаблювати гайки коліс, бо вони вібрують.
Торгова безпека реальна, і ви все одно матимете дивності, бо інші частини системи припускають тимчасову узгодженість.
6) Чи сумісний split tunneling з AD?
Може бути, але це підвищує вимоги. Потрібно забезпечити, щоб DNS-запити для AD-зон йшли до внутрішніх резолверів і щоб існували маршрути до DC, SYSVOL і потрібних служб.
Split tunneling без дисципліни DNS/маршрутизації — надійний спосіб отримувати «працює іноді» тікети.
7) Чи потрібен нам RODC у кожному віддаленому сайті?
Якщо сайт має зберігати аутентифікацію під час відключення тунелю — так, розгляньте це серйозно.
Якщо сайт може терпіти залежність від VPN і використовує кешовані облікові дані — можливо, ні. Але будьте чесні щодо бізнес-вимог, а не сподівань.
8) Чому реплікація AD скаржиться на RPC, коли DNS здається в порядку?
DNS доставляє вас до DC. RPC потребує TCP 135, а потім динамічні порти. Якщо ці динамічні порти не дозволені, реплікація падає з «RPC server unavailable».
Ось чому політика портів має включати стратегію для динамічних портів.
9) Який найшвидший спосіб довести, що це пов’язано з MTU?
Використайте пінги з опцією «do not fragment», підібравши розмір близько підозрюваного MTU шляху і спостерігайте за відмовами, потім порівняйте поведінку з і без MSS clamping.
MTU-проблеми часто виявляються як переривчасті DNS та SMB-аномалії, а не як чисті «вимкнення».
10) Як моніторити це, щоб не дізнатися від CEO?
Запускайте синтетичні перевірки з кожної віддаленої мережі: SRV lookup, доступність Kerberos, LDAP bind (якщо придатно), SMB-перелік SYSVOL і підсумок реплікації на DC.
Попереджайте про відмови і про пороги латентності/втрат. Найкращий інцидент — той, що ви тихо виправили до того, як хтось про нього дізнався.
Наступні кроки (практичні)
Якщо зробите лише три речі цього тижня: примусово налаштуйте коректний DNS через VPN, забезпечте адекватну доменну ієрархію часу і зробіть портову/RPC-політику явною та тестованою.
Потім виконайте дорослу роботу: змепте Sites/Subnets правильно і вирішіть, де вам потрібні локальні DC/RODC.
Одна перефразована ідея, часто приписувана голосам з надійності на кшталт John Allspaw: Системи відмовляють передбачуваними способами; ваше завдання — зробити ці відмови видимими й відновлюваними.
Ось у чому річ. AD через VPN — це не магія. Це сантехніка. Зробіть сантехніку правильно, і все буде нудно.