Приватно 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

Затим једном тестирајте забрањени извор и забележите резултат.

Држите два записа одвојено у документацији: име и његову зону, прихваћене изворе и власника правила. Када се једно промени, друго не мора.

Где одлука обично пође наопако

Чест квар је услуга објављена под именом које се разрешава само на канцеларијској мрежи, уз правило прихватања које прихвата само канцеларијски опсег. Удаљени корисници тада пријављују покварену услугу која је заправо два одвојена пропуста. Други чест квар је обрнут: широко правило прихватања додато да уклони проблем са именом оставља услугу доступном са извора које нико није намеравао. Оба су пропусти у конфигурацији, и са корисничке столице изгледају исто.

Ниједна грешка није видљива из једног успешног теста. Зато две одлуке заслужују одвојене записе и одвојене тестове, чак и када их доноси иста особа.

Запишите обоје пре него што услуга заживи, јер ће следећа промена бити лакша за размишљање. Запис је кратак: један ред за име и његову зону, један ред за прихваћене изворе и власника правила.