Тры публікатары могуць змясціць VPN-адрас кантролера дамена ў DNS

Тры розныя кампаненты на кантролеры дамена з некалькімі інтэрфейсамі могуць змясціць адзін і той жа VPN-адрас у DNS, і яны церпяць няўдачу незалежна адзін ад аднаго. Параўнайце, што публікуе кожны з іх, замест таго каб давяраць сцяжку адаптара, які кіруе толькі адным з іх. Сімптом аднолькавы ў кожным выпадку: кліент вырашае імя, атрымлівае адрас тунеля і не можа дасягнуць кантролера дамена. Тое, хто апублікаваў адрас, вызначае, як гэта спыніць.

Адна налада, адна служба і адна роля; тры публікатары, тры перамыкачы.

Пачніце з запісу, а не са сцяжка

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

Тое, што машына правільна вырашае ўласнае імя, даказвае вельмі мала. Вырашальны тэст праводзіцца з сетак кліентаў.

Адаптар — гэта толькі адзін публікатар

Уласцівасці TCP/IP адаптара ўтрымліваюць сцяжок для рэгістрацыі адраса гэтага злучэння, і яго зняцце заглушае роўна аднаго публікатара. Гэта не спыняе іншых, таму запіс можа з’явіцца зноў пасля перазапуску. Калі кантролер дамена таксама запускае службу DNS, гэтая служба мае ўласную канфігурацыю праслухоўвання і ўласныя запісы сервера імёнаў. Рэкамендацыі Microsoft для асяроддзяў з некалькімі інтэрфейсамі разглядаюць паводзіны інтэрфейса, службу DNS і Netlogon як асобныя значныя публікатары.

Тры перамыкачы, тры ўласнікі, і толькі адзін з іх жыве на старонцы ўласцівасцей адаптара.

Служба DNS мае ўласныя адрасы

DNS-сервер, якому загадана слухаць на VPN-адрасе, працягвае публікаваць яго ў сваіх уласных запісах, што б ні сцвярджаў сцяжок адаптара. Узгадніце адрасы праслухоўвання службы з прызначанымі інтэрфейсамі і адначасова перагледзьце запісы сервера імёнаў зоны. Змена слухачоў можа перарваць кліентаў, якія якраз выкарыстоўваюць адрас, які вы выдаляеце, таму спачатку вызначце, хто ад якога залежыць. Выдаленне слухача толькі таму, што гэта VPN-адрас, можа адразаць кліентаў, якім вы хацелі дапамагчы.

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

Уласнасць перад чысткай

Выпраўце публікатара, перш чым выдаляць запіс, інакш наступная падзея рэгістрацыі верне яго, і практыкаванне паўторыцца. Выдаліце састарэлыя запісы праз працэс уласніка DNS і ўлічыце кэш і старэнне. Праверце з сетак кліентаў, уключна з выяўленнем дамена і праграмай, якая першапачаткова не спрацавала, затым выклічце тую ж падзею VPN, якая першай стварыла адрас.

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

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