Відразу обмовлюся, що жодного таємного знання я не відкрию, так що для більшості досить досвідчених адміністраторів стаття буде не дуже корисна.
Отже, ми припускаємо, що локальний домен у нас називається alexxhost. local, а зовнішній відповідно alexxhost. ru. Для прикладу розглянемо веб-сервіси сервера Exchange. В цьому випадку, зовнішні користувачі відкривають Outlook Web App за посиланням https://mail.alexxhost.ru/owa , В той час як внутрішні використовують адресу https: //e2010sp1.alexxhost.local/owa . Завдання полягає в тому, щоб внутрішні і зовнішні клієнти набирали в браузері один і той же адресу і при цьому потрапляли б на сервер Exchange за найкоротшим маршрутом.
Рішення
Логічно, що загальною адресою для всіх слід зробити адресу https://mail.alexxhost.ru/owa , Тому що зовнішні користувачі не зможуть дозволити локальне ім'я, а ось внутрішніх ми можемо «послати» туди, куди нам потрібно. Також очевидно, що для вирішення подібного роду завдань нам необхідно внести деякі корективи в налаштування локального DNS сервера.
Отже, що ж потрібно зробити:
- Створюємо додаткову зону alexxhost. ru на локальному DNS-сервері.
Для цього вибираємо розділ Зони прямого перегляду (Forward Lookup Zone) - Створити нову зону (New Zone ...) і відповідаємо на пару нескладні питання майстра:
Рис.1: Створюємо нову DNS-зону.
- Після створення зони, її потрібно «заповнити».
Для початку потрібно зрозуміти до чого призвело виконане нами дію. Потрібно чітко усвідомити, що тепер всі запити локальних користувачів на дозвіл IP адрес домену alexxhost.ru і всіх його піддоменів будуть оброблятися нашим локальним DNS сервером. Отже, потрібно зробити так, щоб імена потрібних нам вузлів сервер би дозволяв сам, а для вирішення всіх інших імен вузлів, про які він ні чого не «знає» - перенаправляв б запити на DNS сервер, керуючий зовнішньою зоною домена alexxhost.ru. Для цього зробимо наступне:
1. перенаправити «зовнішні» запити користувачів на внутрішні сервера, для цього створимо відповідні CNAME, або А-записи: (рис.2)
- CNAME - mail вказує на вузол e2010 sp1. alexxhost. local
2. Настроїмо доступ до вузлів, які знаходяться поза локальної мережі наступним чином:
- Налаштуємо делегування на зовнішній NS-сервер для всіх записів, які розташовані зовні (у мене це www і portal). Для цього натиснемо правою кнопкою миші на імені зони - Створити делегування ... (New Delegation). Далі пройдемо по кроках майстра (див. Ріс.3-4)
- Зробимо так, щоб локальні користувачі могли ходити на зовнішній сайт без www, для цього створимо кореневу А-запис (як папка верхнього рівня), що вказує на IP зовнішнього сайту.
Рис.2: Створюємо потрібні записи в новій зоні.
Рис.3: Вказуємо ім'я субдомена.
Рис.4: Вказуємо NS сервер, на якому є запис для цього субдомена.
В результаті:
Налаштування локального DNS сервера будуть виглядати приблизно так (рис.5):
Рис.5: Результуюча картина.
І це призведе до того, що всі запити локальних користувачів до зовнішнього сайту http://www.alexxhost.ru або просто http://alexxhsot.ru підуть на зовнішній IP, а ось запити на mail.alexxhost.ru будуть співставлені через запис CNAME з дійсним ім'ям сервера Exchange - e2010sp1.alexxhost.local, важливо - при такій реалізації буде працювати навіть Kerberos. При цьому, для вирішення запитів виду www.alexxhost.ru і portal.alexxhost.ru, наш DNS сервер буде звертатися до вищестоящого сервера імен, який ми вказали в налаштуваннях делегування.
Примітка: Можна було б вказати зовнішні вузли і за допомогою А-записів (без делегування), але в цьому випадку довелося б руками синхронізувати зміни, які в майбутньому ви вносили б у зовнішнє зону.
висновок
На цьому мабуть все, що я хотів розповісти про DNS.
PS. Винуватцем написання статті є Станкевич Олександр (Stanky). Саме йому і хоче висловити особливу подяку за допомогу в технічних деталях.