# Плануйте адреси та DNS як частини вашого розгортання | SwissOctet Insights https://swissoctet.com/uk/insights/plan-addresses-and-dns-for-deployment/ SwissOctet / Аналітика / Мережева інженерія Мережева інженерія Основа · 4 хв читання Плануйте адреси та DNS як частини розгортання Відокремте публічні, приватні, статичні та виділені адреси, потім зіставте прямий DNS, зворотний DNS та TLS зі сторонами, які можуть їх налаштувати. Автор: SwissOctet Editorial Зберегти посібник Копіювати посилання НА ЦІЙ СТОРІНЦІ 01 Властивості адрес відповідають на різні питання 02 Приватна адресація все одно потребує маршрутизації та контролю доступу 03 Стабільні назви та стабільні адреси пов’язані 04 Прямий DNS і зворотний DNS мають різних власників 05 Виділена адреса не потрібна для кожного сайту HTTPS 06 Використовуйте карту розгортання перед зміною записів Ваш практичний контрольний список Джерела та додаткове читання Назад до бібліотеки ПРЯМА ВІДПОВІДЬ Публічна, приватна, статична та виділена — це незалежні властивості адрес. Побудуйте карту розгортання, яка також охоплює маршрутизацію, брандмауери, прямий DNS, зворотний DNS і TLS, та перевірте кожне налаштування зі стороною, що ним керує. 01 Властивості адрес відповідають на різні питання Публічна та приватна описують, куди адресу призначено маршрутизувати. Статична та динамічна описують, як призначення поводиться з часом. Виділена та спільна описують, як адреса використовується або розподіляється в межах служби. Це окремі властивості: стабільна публічна адреса може обслуговувати багато сайтів, а приватна адреса може призначатися динамічно в контрольованій мережі. Запишіть роль кожної адреси в розгортанні: публічна точка входу, внутрішня база даних, маршрут керування або вихідне з’єднання. Потім визначте, хто її призначає і що може змінитися. Це запобігає залежності конфігураційної роботи від припущення, як-от «виділена означає назавжди фіксована» або «публічна означає, що служба доступна». Доступність також залежить від маршрутизації, брандмауерів і слухача застосунку. 02 Приватна адресація все одно потребує маршрутизації та контролю доступу RFC 1918 резервує діапазони IPv4 10.0.0.0/8, 172.16.0.0/12 і 192.168.0.0/16 для приватних мереж. Їхні адреси не є глобально унікальними публічними призначеннями. Мережа може транслювати приватні адреси для вихідних з’єднань або з’єднувати приватні мережі через явні маршрути. Вхідна служба за трансляцією потребує навмисного методу публікації; зміна лише запису DNS не створює цього маршруту. IPv6 має власні типи та області адрес, зокрема локальні для каналу адреси та глобально маршрутизовані унікаст-адреси. Перегляньте це окремо, а не припускайте, що правило брандмауера чи трансляції IPv4 охоплює IPv6. Приватна адреса не є механізмом автентифікації, а публічна адреса IPv6 не є причиною відкривати кожну службу. Перевіряйте доступ із кожної відповідної мережі та обмежуйте адміністрування на належній межі. 03 Стабільні назви та стабільні адреси пов’язані DHCP розподіляє конфігурацію адрес через протокол і може використовувати оренди. Динамічно призначена адреса може залишатися незмінною деякий час; це не робить її постійність договірною гарантією. Коли застосунок залежить від стабільної адреси, перевірте політику призначення та змін у постачальника, а не виводьте її з учорашнього з’єднання. Динамічний DNS може оновити назву після зміни адреси, але клієнти все одно можуть кешувати попередню відповідь. Він також не може подолати недоступний слухач, відсутній вхідний маршрут або трансляцію адрес операторського рівня. Використовуйте його, коли мережа дозволяє з’єднання, а застосунок терпить затримки оновлення. Для розміщеного розгортання задокументуйте передбачуваний життєвий цикл адреси, перш ніж будувати навколо неї списки дозволів або зовнішні інтеграції. Властивість Що підтвердити Поширене помилкове припущення Публічна чи приватна Область маршрутизації та шлях доступу Сама лише адреса робить службу доступною Статична чи динамічна Політика призначення та змін Незмінна оренда є постійною Виділена чи спільна Розподіл і дозволене використання Виділена адреса забезпечує анонімну ідентичність IPv4 чи IPv6 Конфігурації як маршрутизації, так і брандмауера Налаштування одного протоколу охоплюють інший 04 Прямий DNS і зворотний DNS мають різних власників Прямий DNS зіставляє назви з даними, як-от записи адрес A та AAAA. Зворотний DNS використовує простір імен, пов’язаний з адресами, і записи PTR, щоб пов’язати адресу з назвою. Організація, що контролює пряму зону DNS, не обов’язково є організацією, яка контролює зворотний DNS для діапазону адрес. Отримайте правильний шлях конфігурації, перш ніж обіцяти зворотну назву. Перевірте запис через відповідний резолвер і запишіть результат. Для PTR, призначеного ідентифікувати хост, також перевірте, чи відповідний прямий запис указує на очікувану адресу. Зворотний DNS може підтримувати операційну ідентифікацію та деякі перевірки поштових систем, але він не автентифікує застосунок і не гарантує доставку повідомлень. Надсилання пошти також потребує окремого огляду домену, репутації та автентифікації. 05 Виділена адреса не потрібна для кожного сайту HTTPS Маршрутизація хостів HTTP і розширення TLS Server Name Indication дозволяють підтримуваним клієнтам і серверам вибирати сайт або сертифікат за назвою. Тому кілька сайтів HTTPS можуть використовувати одну адресу, не потребуючи окремої публічної адреси для кожного домену. Фактична конфігурація хостингу та потрібні клієнти визначають, чи придатне таке влаштування. Вибирайте додаткову адресу лише тоді, коли цього вимагає задокументована потреба, як-от підтримуване розділення мереж або зовнішня система, що очікує окрему кінцеву точку. Адреса не дає імунітету від проблем із репутацією і не ідентифікує особу, яка керує службою. Тримайте сертифікати, маршрутизацію за іменем хоста та розподіл адрес як окремі перевірки. Перевіряйте наданий сертифікат через ім’я хоста, яке користувачі справді відвідають. 06 Використовуйте карту розгортання перед зміною записів Створіть невелику карту, що містить кожне ім’я хоста, запис адреси, слухач, шлях брандмауера та відповідальну сторону. Включіть адміністрування, резервні копії та будь-які вихідні списки дозволів. Перевірте, чи конфігурація SwissOctet містить потрібну вам опцію адреси, і запитайте про контроль зворотного DNS, перш ніж покладатися на нього. Не подавайте опції каталогу як активне призначення, яке вже надано. Під час переміщення підготуйте налаштування застосунку та TLS призначення, перш ніж спрямовувати туди користувачів. Врахуйте кеші DNS і підтримуйте робочий шлях відновлення. Перевіряйте пряме розв’язання, фактичну доступність застосунку та очікувану зворотну назву окремо. Карта полегшує локалізацію збоїв, бо неправильний запис, закритий порт і невідповідний сертифікат — це різні проблеми з різними власниками. ПЕРЕТВОРІТЬ ЦЕ НА ДІЮ Ваш практичний контрольний список. ✓ Зіставте роль адреси, призначення та власність. ✓ Перевірте IPv4 і IPv6 окремо. ✓ Перевірте вхідну маршрутизацію, перш ніж покладатися на DNS. ✓ Визначте, хто контролює записи PTR. ✓ Перевірте ім’я хоста, сертифікат і застосунок разом. Завантажити контрольний список ПОШИРЕНІ ЗАПИТАННЯ Деталі, які мають значення. Чи робить виділена IP-адреса службу анонімною? + Ні. Вона описує розподіл або домовленість про використання, а не ідентичність чи гарантію приватності. Облікові записи, трафік і дані застосунку мають окремі наслідки. Чи можу я налаштувати записи PTR з панелі DNS мого домену? + Лише якщо вона також контролює відповідну зворотну зону. Постачальник адреси зазвичай контролює цю зону або надає окремий процес запиту. Чи потребує кожен домен HTTPS власної адреси? + Не обов’язково. Підтримувані клієнти та сервери можуть використовувати маршрутизацію за назвою та TLS SNI. Перевірте фактичні вимоги хостингу та клієнтів. ОСНОВНІ ДЖЕРЕЛА Перейдіть до джерела. Ці джерела підкріплюють технічні концепції в цьому посібнику. Дотримуйтеся поточної документації перед зміною робочої системи. RFC 1918: розподіл адрес для приватних інтернетів www.rfc-editor.org RFC 2131: протокол динамічної конфігурації хоста www.rfc-editor.org RFC 1035: реалізація та специфікація DNS www.rfc-editor.org RFC 4291: архітектура адресації IPv6 www.rfc-editor.org RFC 6066: розширення TLS, зокрема Server Name Indication www.rfc-editor.org Редакційне керівництво від SwissOctet. Приклади є ілюстративними. Специфікації послуг, доступні опції та договірні умови потрібно перевіряти окремо. ПОЄДНАЙТЕ ЗНАННЯ Пов'язана інфраструктура. Vector VPS Швейцарія Canvas Web Швейцарія Metal Origin Швейцарія Shield VPN Швейцарія ЗБЕРІГАЙТЕ НИТКУ Ваші наступні польові нотатки. Дослідити всі посібники ПОЛЬОВА НОТАТКА / 01 + Мережева інженерія Основа Пропускна здатність, швидкість порту та передача: прочитайте повну картину Оцініть обсяг даних, які переміщує ваш проєкт, і зрозумійте, чому більший порт — лише частина мережевої продуктивності. 4 хв читання Читати посібник ПОЛЬОВА НОТАТКА / 02 + Операції другого дня Прикладний Безпечне адміністрування Windows RDP без втрати доступу Розділіть мережеву доступність, автентифікацію та привілеї, а потім перевірте шлях відновлення, перш ніж посилювати віддалений доступ. 6 хв читання Читати посібник ПОЛЬОВА НОТАТКА / 03 + Мережева інженерія Просунутий Розмір передачі з вимірюваннями затримки, паралелізму та пропускної здатності Побудуйте повторювану модель передачі, використовуючи обсяг корисного навантаження, вікна доставки та час кругового обігу, а потім перевірте її, не плутаючи ярлик порту з корисною пропускною здатністю. 4 хв читання Читати посібник