Приватне DNS-ім'я чи просто IP? Вирішіть, перш ніж ділитися

Два питання змішуються, коли приватна служба відкривається віддаленим користувачам. Перше — яке ім'я мають використовувати клієнти; друге — які джерела служба має допускати. Відповідайте на них у цьому порядку, бо правильне ім'я за неправильним правилом доступу все одно не працює, а правильне правило за іменем, яке не розв'язується, ніколи не перевіряється.

Умова перша: який шлях резолвера мають клієнти?

Приватне ім'я працює лише тоді, коли резолвер клієнта може відповісти на нього. Це означає, що авторизований віддалений клієнт має досягти DNS-сервера, який тримає зону, — або через тунель, або через резолвер, який організація вже запускає для віддалених користувачів. Тунель — це транспорт, а не каталог. Він дає клієнтові шлях до резолвера і не повідомляє, яку зону питати.

resolvectl query files.corp.example
dig @10.20.30.10 +short files.corp.example

Публічний резолвер не дізнається про приватну зону лише тому, що ноутбук підключився до VPN.

Суфікс заслуговує на таку саму увагу. Використовуйте піддомен домену, який контролює організація, щоб власність і планування сертифікатів залишалися явними. Уникайте .local: специфікація multicast DNS прив'язує цей суфікс до link-local розв'язання, а маршрутизований тунель не відтворює такої поведінки за вас.

Умова друга: яке джерело отримує служба?

Правила допуску пишуться щодо адрес, тому корисне питання — яку адресу служба бачить після маршрутизації та трансляції. Для прикладу служби на 10.20.30.40 офісні клієнти приходять з 10.20.30.0/24, а віддалені клієнти — з окремого пулу, наприклад 10.99.0.0/24.

Якщо шлюз транслює віддалений пул, служба бачить транслятор, і правило, написане для 10.99.0.0/24, не збіжиться.

Читайте це з боку служби, а не з боку клієнта. Журнал слухача або захоплення пакетів на хості служби показує джерело, яке справді прийшло; власна адреса клієнта — лише здогад про те, що пережило шлях.

Умова третя: ім'я прив'язане до служби чи до хоста?

Ім'я, що вказує на адресу однієї машини, прив'язує кожного клієнта до цієї машини. Ім'я, що вказує на балансувальник навантаження або стабільну адресу служби, переживає заміну хоста за ним. Вибирайте свідомо, бо змінити це пізніше означає змінити закладки кожного клієнта і суб'єкт кожного сертифіката.

Для однієї внутрішньої служби прямий запис зазвичай доречний і простіший для осмислення.

Для всього, що буде замінено, перебудовано або масштабовано, стабільний фронтенд вартий додаткової конфігурації. Тест простий: якщо ви можете замінити бекенд, не повідомляючи користувачів, ім'я прив'язане до служби; якщо ні — до хоста.

Перевірте два рішення окремо

Спочатку розв'яжіть, потім підключайтеся. Тест розв'язання, що повертає очікувану адресу, доводить шлях імені і нічого не каже про допуск. Тест підключення доводить шлях і правило разом, тому запускайте його лише після успішного розв'язання.

curl -sv --max-time 5 https://files.corp.example/health

Потім один раз перевірте заборонене джерело і запишіть результат.

Тримайте два записи окремо в документації: ім'я та його зона, допущені джерела та власник правила. Коли одне змінюється, інше не зобов'язане.

Де рішення зазвичай іде не так

Часта помилка — служба, опублікована під іменем, яке розв'язується лише в офісній мережі, з правилом допуску, яке допускає лише офісний діапазон. Тоді віддалені користувачі повідомляють про зламану службу, яка насправді є двома окремими упущеннями. Друга часта помилка — зворотна: широке правило допуску, додане, щоб прибрати проблему з іменем, залишає службу доступною з джерел, яких ніхто не мав на увазі. Обидві — упущення в конфігурації, і з крісла користувача вони виглядають однаково.

Жодної з помилок не видно з одного успішного тесту. Тому два рішення заслуговують на окремі записи й окремі тести, навіть коли їх ухвалює одна людина.

Запишіть обидва до запуску служби, бо наступну зміну буде легше обміркувати. Запис короткий: один рядок для імені та його зони, один рядок для допущених джерел і власника правила.