DNS-запісы VPN-кліентаў: уласнік, TTL і ачыстка — розныя рэчы

Ноўтбукі падключаюцца, атрымліваюць адрас VPN, а імя, якое развязаюць іншыя сістэмы, усё яшчэ паказвае на ўчорашні адрас офіса. Нішто не зламалася: адрас быў выдзелены, запіс не быў абноўлены, а кэш па-ранейшаму трымае стары адказ. Гэта тры аб'екты з трыма ўласнікамі, і толькі адзін з іх належыць VPN. Планаванне публікацыі азначае рашэнне, хто піша імя, якія інтэрфейсы ўдзельнічаюць і калі састарэлыя даныя знікаюць.

Сімптом: імя, якое ідзе за няправільным адрасам

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

Адваротны выпадак цішэйшы: запіс знікае, і імя перастае развязвацца зусім. Абодва вынікі паходзяць з адной прагаліны ў праекце, і ні адзін не выпраўляецца зніжэннем TTL. Кароткі тэрмін жыцця кэша змяняе, як доўга жыве няправільны адказ, а не тое, ці ён запісаны.

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

Тры аб'екты, тры ўласнікі

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

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

Хто можа абнаўляць запіс

У зоне, інтэграванай з Active Directory і з бяспечнымі дынамічнымі абнаўленнямі, дазволы жывуць на самім запісе. Запіс, створаны ўліковым запісам службы DHCP, можа быць недаступны для запісу ўліковым запісам камп'ютара ноўтбука, а змена мадэлі ўласнасці пазней — гэта пераход, а не перамыкач. Менавіта таму канфлікт уласнасці перажывае любую наладу на баку кліента.

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

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

ipconfig /all
Resolve-DnsName laptop-042.corp.example -Type A
Get-DnsServerResourceRecord -ZoneName corp.example -Name laptop-042

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

Тры гадзіннікі, а не адзін

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

Гэтыя гадзіннікі незалежныя, і іх блытанне дае выпраўленні, якія не працуюць. Змена аднаго незаўважная для двух іншых. Кароткі TTL скарачае жыццё кэшаванага адказу і не дае права на абнаўленне. Ачыстка выдаляе запісы, якія не абнаўляліся, і не можа адрамантаваць запіс, які ніколі не быў запісаны правільным уласнікам.

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

Плануйце публікацыю для вандравальнай прылады

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

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

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