Split DNS, также известный в терминологии Microsoft как Split-Brain DNS, используется для реализации выдачи разных DNS-ответов в зависимости от расположения клиента. В классическом виде это делает один и тот же сервер DNS, анализируя с какой подсети пришел запрос и на основе существующих политик возвращает определенный ответ. На общеизвестном сервере Bind это делается путем создания разных представлений (Views) и сопоставления их со списками доступа (ACL). В Windows Server этот функционал ранее отсутствовал и появился только с выходом версии 2016.
Тем не менее, в контексте Exchange Server нас будет интересовать немного другой сценарий, о котором читайте ниже.
Найти больше информации по настройке и администрированию Exchange 2013 на моем блоге вы сможете в основной статье тематики — .Exchange Server и Split DNS
В статье планирую рассказать не только про реализацию Split DNS, но и про изменения на Exchange Server, которые вам предстоит сделать после.
ТеорияВ Exchange Server почти для каждого виртуального каталога вы можете задать два имени — отдельно для внутренних и внешних клиентов. Например:
| 1 2 3 4 | [PS] C:\Windows\system32>Get-OwaVirtualDirectory | fl *ternalUrl InternalUrl : ExternalUrl : |
Зону bq.local обслуживает ваш внутренний сервер DNS, чаще всего контроллер домена. Зону bq-srv.ru — DNS-сервер третьей стороны, вероятно ваш регистратор.
Если клиент обращается из локальной сети, то он это должен делать по адресу в InternalUrl. Если из интернета, то через ExternalUrl. Это «расщепление» путей накладывает ряд неудобств, связанных не только с использованием разных имен для одного объекта.
Примечание: например если раньше в сертификаты публичных ЦС можно было засунуть имена локальных доменов, то с осени 2015 года это сделать нельзя — лавочку прикрыли (и правильно).Чтобы обойти проблему, можно использовать одну хитрость — создать на вашем внутреннем сервере DNS записи зоны bq-srv.ru и сделать так, чтобы они разрешались во внутренние имена серверов Exchange. В таком случае клиенты что внутри сети, что снаружи смогут обращаться по одинаковому URL. Публичные имена зоны bq-srv.ru будут обслуживать все те же внешние серверы DNS, а ваши записи будут актуальны только для клиентов внутри периметра локальной сети.
Настройка DNSК этому моменту вы уже должны были определиться с доменными именами, которые у вас будут использоваться. В моем случае это:
- autodiscover.bq-srv.ru
- mail.bq-srv.ru
Далее на любом КД открывайте оснастку DNS и приступайте к созданию зон прямого просмотра. Все настройки оставляйте по умолчанию, а в имени зоны вписывайте fqdn. Например:
Примечание: да, я не ошибся, надо вписывать именно домен третьего уровня, но не bq-srv.ru. Почему, я рассажу в последней главе.Далее в каждой зоне создайте А-запись с пустым именем и адресом вашего сервера Exchange (если серверов несколько, создавайте записи для каждого, у вас получится DNS RR):
Далее запустите nslookup и попробуйте разрешить записи со стороны клиентов, чтобы убедиться в корректности работы.
Настройка ExchangeНа этом этапе крайне желательно, чтобы у вас на серверах Exchange уже был установлен сертификат со всеми нужными именами.
Примечание: если ваш сертификат получен с локального ЦС, то возможно вам понадобится предварительно распространить его по всем клиентам. Сделать это можно через GPO, а как именно, читайте в статье .Приступаем.
Виртуальные каталогиИтак, начнем настраивать Exchange с изменения виртуальных каталогов. Для каждого каталога существует собственный набор командлетов, поэтому получается немного громоздко:
| 1 2 3 4 5 6 7 | Get-EcpVirtualDirectory | Set-EcpVirtualDirectory -ExternalUrl '; -InternalUrl '; Get-OwaVirtualDirectory | Set-OwaVirtualDirectory -ExternalUrl '; -InternalUrl '; Get-WebServicesVirtualDirectory | Set-WebServicesVirtualDirectory -ExternalUrl '; -InternalUrl '; Get-ActiveSyncVirtualDirectory | Set-ActiveSyncVirtualDirectory -ExternalUrl '; -InternalUrl '; Get-OabVirtualDirectory | Set-OabVirtualDirectory -ExternalUrl '; -InternalUrl '; Get-PowerShellVirtualDirectory | Set-PowerShellVirtualDirectory -ExternalUrl '; -InternalUrl '; Get-MapiVirtualDirectory | Set-MapiVirtualDirectory -ExternalUrl '; -InternalUrl '; |
Если есть желание изменить каталоги вручную, можно это сделать в EAC — Серверы — Виртуальные каталоги. Изменить домен внешнего доступа можно, нажав на соответствующую кнопку:
Примечание: несмотря на доступность веб-интерфейса для администрирования, я рекомендую выполнять все команды в EMS. Это быстрее, легче документируется, проще дебажится.Для Autodiscover имена должны быть пустыми .
Если вдруг появились вопросы, настоятельно рекомендую обратиться к официальной документации .
Обратите особое внимание на Mapi , ведь протокол может не использоваться в вашей инфраструктуре, поскольку он появился только в Exchange Server 2013 SP1 и если вы мигрировали с 2010 версии, то по умолчанию он не будет активирован. Настройка Mapi — это отдельная тема, которую я не планирую рассматривать в рамках этой статьи.
Изменения виртуальных каталогов вступят в силу не сразу. Можете форсировать процесс перезапуском IIS.
SCPСледующий этап — настройка SCP. Многие забывают про этот момент, хотя он очень важен для доменных клиентов внутри локальной сети, ведь они первым делом ломятся именно к SCP. Изменим SCP командой:
| 1 | Get-ClientAccessService | Set-ClientAccessService -AutoDiscoverServiceInternalUri '; |
Все просто, идем дальше.
Outlook AnywhereОстался последний штрих — настройка Outlook Anywhere. Протокол (RPC over HTTP) позволяет клиентам Outlook подключаться к Exchange, находясь за пределами периметра локальной сети. Задать домены для подключения можно командой, но только с дополнительными настройками безопасности и аутентификации:
| 1 | Get-OutlookAnywhere | Set-OutlookAnywhere -ExternalHostname 'mail.bq-srv.ru' -ExternalClientsRequireSsl $true -ExternalClientAuthenticationMethod Negotiate -InternalHostname 'mail.bq-srv.ru' -InternalClientsRequireSsl $false |
На этом настройки завершены, на клиентской стороне как минимум потребуется перезапустить Outlook.
Частые ошибкиПервая и главная ошибка — чаще всего админы создают DNS-зоны с доменом второго уровня, а уже внутри их плодят записи autodiscover.bq-srv.ru, mail.bq-srv.ru и т.п.. Это будет работать, но не забывайте, что при обращении к любым доменам третьего уровня ваши серверы DNS (они же КД) будут считать себя авторитативными, то есть, ответственными за эту зону. Чем это чревато? Если вы обратитесь к записи внешнего корпоративного ресурса, например, careers.bq-srv.ru и её не окажется на ваших КД, то на сайт вы не попадете. Другими словами — если эта зона в оригинале хостите на внешних серверах DNS, то вам придется дублировать все её записи на КД и поддерживать их в актуальном состоянии. Оно вам надо?
Вторая ошибка — недостаточная проработка вопроса и подготовка к изменениями. Как следствие — юзеры, бегающие в панике с криками о неработающей почте. Изменения виртуальных каталогов, SCP и Outlook Anywhere являются достаточно серьезными, чтобы вот так сразу все менять посередине рабочего дня. Продумайте все изменения заранее и протестируйте на лабе. Технические работы проводите в выходные дни. Если не уверены, то почитайте первые шаги сразу после установки Exchange , они помогут последовательно продиагностировать работоспособность сервиса и освежить в голове логику работы и взаимосвязи всех компонентов.
