Обсяг
Цей документ призначений для надання клієнтам SAP Private Cloud рекомендацій щодо вибору та налаштування сценаріїв інтеграції DNS для доступу до послуг SAP Private Cloud через приватні з'єднання, такі як:
• Віртуальна приватна мережа (VPN)
• Множинне маркування протоколів (MPLS)
• Пірінг SAP Cloud
• AWS Direct Connect
• Azure ExpressRoute
• GCP Interconnect
• Пірінг VPC-/VNET
Зверніть увагу, що інтеграція DNS є важливою для різних функцій, таких як одноразовий вхід (Single Sign-On), відновлення після катастроф (Disaster Recovery), з’єднання RFC (Remote Function Call) тощо.
Зміст
Сценарії інтеграції DNS — огляд
Які DNS зони / DNS домени потрібно інтегрувати в DNS зону клієнта. Перенесення DNS зон — за замовчуванням і рекомендований варіант для SAP Private Cloud
• Переваги та чому ми віддаємо перевагу
• Налаштування брандмауера
• Як налаштувати за допомогою UNIX ® або LINUX DNS
• Як налаштувати за допомогою MS® Windows DNS
Умовне пересилання DNS
• Переваги та недоліки у порівнянні з перенесенням DNS зон
• Налаштування брандмауера
• Як налаштувати за допомогою UNIX ® або LINUX DNS
• Як налаштувати за допомогою MS® Windows DNS
Делегація DNS домену
• Як налаштувати за допомогою MS® Windows DNS
Особливі функції та вимоги
• DNSSEC
• DNS TSIG
• DNS6
• Перегляди DNS та трансляція мережевих адрес
Сценарії інтеграції DNS — огляд
Клієнтські комп'ютери в кінцевому підсумку налаштовані майже завжди на використання внутрішніх DNS серверів клієнта як резольверів DNS. Ці внутрішні DNS сервери повинні надавати DNS інформацію для внутрішніх ресурсів — інтрамережі, зазвичай для Інтернету, а також для зовнішніх ресурсів, таких як SAP Private Cloud. Це вимагає, щоб внутрішні DNS сервери мали динамічний доступ до DNS даних SAP Private Cloud. Загалом SAP Private Cloud підтримує три різні техніки для надання DNS даних SAP Private Cloud внутрішнім DNS серверам клієнта:
-
Перенесення DNS зон (використовуючи основні та вторинні зони)
-
Умовне пересилання DNS
-
Делегація DNS домену
Залежно від внутрішнього дизайну DNS клієнта, один із наведених сценаріїв має підходити.
SAP Private Cloud рекомендує та віддає перевагу налаштуванню перенесення DNS зон на цьому етапі. Це найбільш надійне та безпечне рішення. SAP Private Cloud може надати лише для перенесення DNS зон рівень обслуговування 99,5% (SLA).
Умовне пересилання DNS може бути гарним альтернативним вибором, якщо брандмауер клієнта не дозволяє вхідні з'єднання з SAP Private Cloud до внутрішніх DNS серверів клієнта, що необхідно для отримання DNS повідомлень від DNS серверів SAP Private Cloud для перенесення DNS зон. Але це має недолік: воно здійснює кешування, і тому має затримку, яка залежить від часу життя (TTL) даних DNS SAP Private Cloud, що за замовчуванням становить 1 годину. У сценарії відновлення після катастрофи, що використовує два незалежних дата-центри SAP Private Cloud, це може призвести до більшої або меншої затримки під час відновлення вторинних систем SAP Private Cloud у внутрішньому DNS клієнта.
Делегація DNS домену ймовірно буде найкращим вибором, якщо у клієнта є десятки чи сотні внутрішніх DNS серверів і немає внутрішніх "резольверів" DNS, де налаштовано перенесення DNS зон або умовне пересилання DNS для зовнішніх ресурсів, таких як SAP Private Cloud.
Не має сенсу налаштовувати та підтримувати перенесення DNS зон або умовне пересилання DNS для SAP Private Cloud на кожному з численних DNS серверів. Натомість можна налаштувати делегацію DNS домену в одній точці в Active Directory, щоб мати інформацію про делегацію DNS на всіх внутрішніх DNS серверах. У разі делегації DNS домену внутрішні DNS сервери лише зберігають інформацію про те, який DNS сервер SAP Private Cloud надаватиме резолюцію DNS для делегованих DNS зон / доменів SAP Private Cloud.
Недоліком є те, що кожен сервер або клієнтський комп'ютер на стороні клієнта повинен буде безпосередньо взаємодіяти з DNS серверами SAP Private Cloud — або з вашими внутрішніми DNS серверами, якщо ми налаштуємо їх у DNS зонах приватного хмари як вторинні сервери імен, але це додатково і не є стандартним для SAP Private Cloud.
Кожен з наступних доменів/зон SAP Private Cloud має бути налаштований з використанням однієї з наведених вище технік на стороні клієнта. Також можливі змішані конфігурації на тому ж сервері DNS у приміщенні і для різних філій клієнта. DNS сервери SAP Private Cloud підтримують усі 3 конфігурації паралельно, але кожна має обмеження в 1000 клієнтів DNS або вторинних DNS серверів одночасно за замовчуванням.
Які DNS зони / DNS домени потрібно інтегрувати в DNS клієнта
Для того щоб комп'ютери на стороні клієнта могли використовувати додатки SAP Private Cloud через приватне з'єднання (VPN або MPLS), необхідно, щоб клієнтський комп'ютер мав додаткове розв'язування DNS для
мінімум трьох доменів DNS SAP Private Cloud, де SAP Private Cloud має авторитет — основні зони, також звані «делегованими зонами»:
Топ- рівневий домен (TLD) клієнта SAP Private Cloud:
.customer.corp
Тут “customer.corp” передбачається як внутрішній DNS домен клієнта або TLD кінцевої точки клієнта. “hec.customer.corp” — це домен, де зазвичай розташовані точки входу до додатків SAP Private Cloud.
Імена DNS точок входу до додатків SAP Private Cloud, а отже, цей DNS домен повинен бути незалежним від дата-центру. Тут зазвичай немає IP-адрес або DNS імен хостів, тільки DNS псевдоніми (CNAME) можливі в цьому DNS домені.
У випадку аварійного відновлення (DR Failover) тільки ціль цих псевдонімів буде змінена з основного дата-центру SAP Private Cloud на
вторинний дата-центр SAP Private Cloud — або на систему з високою доступністю в тому ж дата-центрі SAP Private Cloud, наприклад.
DNS доменне ім’я “hec.customer.corp” може бути також “sap.ourcompany.local”, наприклад. Це ім’я слід сприймати як шаблон — але воно повинно починатися з “hec” або “sap”. Максимум два таких TLD клієнта можуть бути
допустимі на одного клієнта SAP Private Cloud. Цей домен буде використовуватися для SSL сертифікатів.
“Залежний від дата-центру” DNS домен SAP Private Cloud:
.customer.corp
У цьому домені є DNS імена хостів, IP-адреси (а, можливо, й DNS псевдоніми). Але клієнтські комп'ютери не повинні використовувати ці DNS
імена хостів або DNS псевдоніми в цьому DNS домені безпосередньо — як точку входу до додатка, URL або “ціль”.
Знову ж таки, .sap.anothercompany.local або будь-який інший домен будуть допустимі. Але SAP Private Cloud вимагає ієрархічного
порядку в делегованих доменах DNS.
Імена доменів в іншому порядку, як-от “sap..company.corp”, є недійсними. Загалом, тільки один DNS домен можна призначити одному сегменту мережі SAP Private Cloud.
Якщо бажана "многошарова" конфігурація, SAP Private Cloud потребує хоча б одного сегмента мережі на кожен шар — наприклад: З максимум двома TLD = sap.customer.corp і sap.customer.com
.dev.sap.customer.corp для SAP Private Cloud Dev мережі 192.168.110.0/24
.qas.sap.customer.corp для SAP Private Cloud QA мережі 10.10.200.0/24
.sap.customer.com для SAP Private Cloud Production мережі 10.10.100.0/23
DNS зворотний домен(-и), де розташовані DNS вказівники (PTR-записи). Наприклад:
110.168.192.in-addr.arpa
Якщо IP-діапазон мережі клієнта SAP Private Cloud складає 192.168.110.0/24. Якщо у нас є діапазон мережі 192.168.110.0/23, ми маємо два зворотних домени:
110.168.192.in-addr.arpa та 111.168.192.in-addr.arpa
Для діапазону мережі 192.168.110.0/22 в SAP Private Cloud ми матимемо чотири зворотних домени (110,111,112,113) і так далі.
DNS зворотні зони, такі як 168.192.in-addr.arpa для маски мережі /16 або 10.in-addr.arpa для маски мережі /8, неможливі.
Кожна з вищезгаданих прямих і зворотних DNS зон є «незалежною» — SAP Private Cloud не підтримує піддомени чи налаштування Stub.
DNS Zone Transfer — це стандарт і переважний метод SAP Private Cloud
Переваги і чому SAP Private Cloud віддає перевагу:
• Продовжує працювати, навіть якщо з'єднання з DNS SAP Private Cloud тимчасово порушено.
• Кожна вторинна зона може мати іншу вторинну зону як основну.
• Тому можливо побудувати внутрішнє дерево DNS клієнта.
• Якщо налаштовані сповіщувачі, затримка часу в такому дереві мінімальна або відсутня.
• Забезпечує резервування та дозволяє досягти 99,5% рівня обслуговування (SLA), особливо в сценаріях відновлення після аварій SAP Private Cloud.
- SAP Private Cloud та клієнт можуть встановити надійний моніторинг статусу
Недоліки :
- Необхідне вхідне з'єднання від DNS серверів SAP Private Cloud до DNS серверів на місці для сповіщувачів DNS (інакше ми матимемо повну затримку TTL DNS)
DNS Zone Transfer (один дата-центр)
Як налаштувати, використовуючи MS® Windows DNS
DNS умовний перенаправлення
Переваги:
• Не потрібні вхідні з'єднання від DNS SAP Private Cloud на брандмауері клієнта.
• Ця перевага існує лише якщо не потрібно перенаправляти від SAP Private Cloud до клієнта.
Недоліки:
• Затримка кешування перенаправлення на місці (час затримки можна налаштувати на стороні клієнта).
• Це може бути проблемою, якщо використовується сценарій відновлення після аварії SAP Private Cloud. Перехід на іншу точку займе більше часу, тому SAP Private Cloud не може гарантувати повний рівень обслуговування (SLA).
• Лише обмежений моніторинг статусу.
Як налаштувати, використовуючи UNIX ® або LINUX DNS
Приклад налаштування на BIND/named DNS — на серверах DNS на місці:
Делегація DNS домену
Переваги:
• Ви можете адмініструвати делегацію DNS вашої приватної хмари в єдиній точці для всіх ваших серверів DNS компанії.
Недоліки:
• Кожен з ваших серверів DNS та клієнтські комп'ютери повинні мати з'єднання з DNS клієнта SAP Private Cloud.
• Це може призвести до великого обсягу DNS трафіку до серверів DNS клієнта SAP Private Cloud і, отже, уповільнити відповідь для всього середовища SAP Private Cloud.
• Затримка TTL кешу DNS велика. Це може бути проблемою, якщо використовується сценарій відновлення після аварії SAP Private Cloud.
Перехід на резервну копію (Failover) займе більше часу, тому SAP Private Cloud не може гарантувати повний рівень обслуговування (SLA).
• Кількість DNS клієнтів обмежена до 1000 на кожному DNS сервері клієнта SAP Private Cloud за замовчуванням.
Для допомоги в налаштуванні вашого середовища Windows DNS, будь ласка, зверніться до: http://technet.microsoft.com/en-us/library/cc771640.aspx
Також ви можете знайти відео з інструкцією для делегації DNS в середовищі Windows тут: https://www.windows-server-2012-r2.com/dns-zone-delegation.html
Делегація домену також можлива в середовищі UNIX® або Linux DNS на стороні клієнта. Просто створіть зони, які ви хочете делегувати до SAP Private Cloud, як основні DNS зони і вкажіть DNS сервери клієнта SAP Private Cloud як записи NS. Також потрібно вказати ці DNS сервери клієнта SAP Private Cloud як записи A у вашому внутрішньому домені верхнього рівня DNS.
SAP Private Cloud не рекомендує делегацію DNS доменів на стороні клієнта для середовища SAP Private Cloud.
Спеціальні функції DNS та вимоги
DNSSEC:
SAP Private Cloud може надати DNSSEC для захисту DNS трафіку. Але це не є стандартною функцією в портфоліо продуктів SAP Private Cloud. Якщо у вас є VPN з'єднання з SAP Private Cloud, будь ласка, пам'ятайте, що цей трафік вже зашифрований і захищений.
DNS TSIG:
SAP Private Cloud може надати DNS TSIG для захисту DNS трафіку. Але це не є стандартною функцією в портфоліо продуктів SAP Private Cloud. Якщо у вас є VPN з'єднання з SAP Private Cloud, будь ласка, пам'ятайте, що цей трафік вже зашифрований і захищений. DNS TSIG не сумісний з MS® Windows DNS.
DNS6:
SAP Private Cloud не надає DNS6 для IPv6.
DNS перегляди та трансляція мережевих адрес (NAT):
SAP Private Cloud може налаштувати вручну підтримувані перегляди DNS для своїх клієнтів. Але це не є стандартною функцією в портфоліо продуктів SAP Private Cloud. Це може бути необхідно в деяких випадках, якщо між DNS клієнта та DNS клієнта SAP Private Cloud є NAT. Однак більшість пристроїв NAT надають цю функціональність внутрішньо — для трансляції DNS трафіку, що робить необхідність налаштовувати спеціальні перегляди DNS в SAP Private Cloud і на стороні клієнта неактуальною. Можливо, DNS Zone Transfer буде складно реалізувати через NAT у всіх випадках, але використання DNS умовного перенаправлення з кількома переглядами DNS є можливим за більшості обставин.
Перекладено з: DNS Integration guide for private Cloud