Частно 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

След това тествайте забранен източник веднъж и запишете резултата.

Дръжте двата записа отделно в документацията си: името и неговата зона, допуснатите източници и собственика на правилото. Когато едното се промени, другото не е длъжно.

Къде решението обикновено се обърква

Честата повреда е услуга, публикувана под име, което се разрешава само в офис мрежата, с правило за допускане, което допуска само офис диапазона. Тогава отдалечените потребители съобщават за счупена услуга, която всъщност е две отделни пропуска. Втората честа повреда е обратната: широко правило за допускане, добавено, за да махне проблем с име, оставя услугата достъпна от източници, които никой не е имал предвид. И двете са пропуски в конфигурацията и от стола на потребителя изглеждат еднакво.

Нито една от грешките не се вижда от един успешен тест. Затова двете решения заслужават отделни записи и отделни тестове, дори когато един и същ човек взема и двете.

Запишете и двете преди услугата да влезе в експлоатация, защото следващата промяна ще е по-лесна за обмисляне. Записът е кратък: един ред за името и зоната му, един ред за допуснатите източници и собственика на правилото.