Прыватнае 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

Затым адзін раз праверце забароненую крыніцу і запішыце вынік.

Трымайце два запісы асобна ў дакументацыі: імя і яго зону, дапушчаныя крыніцы і ўладальніка правіла. Калі адзін змяняецца, іншы не абавязаны.

Дзе рашэнне звычайна ідзе не так

Тыповая памылка — служба, апублікаваная пад імем, якое развязваецца толькі ў офіснай сетцы, з правілам допуску, якое дапускае толькі офісны дыяпазон. Тады аддаленыя карыстальнікі паведамляюць пра зламаную службу, якая насамрэч складаецца з двух асобных упусканняў. Другая тыповая памылка — зваротная: шырокае правіла допуску, дададзенае, каб пазбавіцца праблемы з імем, пакідае службу даступнай з крыніц, якіх ніхто не меў на ўвазе. Абодва — упусканні ў канфігурацыі, і з крэсла карыстальніка яны выглядаюць аднолькава.

Ні адну з памылак не відаць з аднаго паспяховага тэсту. Менавіта таму два рашэнні заслугоўваюць асобных запісаў і асобных тэстаў, нават калі іх робіць адзін чалавек.

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