Чаму імя сервера пасля званковага падключэння вырашаецца ў адрас VPN

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

Два адрасы, адно імя, тры ўмовы

Шматінтэрфейсны сервер Windows можа мець адрас LAN, адзін або некалькі адрасоў званковага падключэння і часам другую сеткавую карту. Кожны інтэрфейс можа рэгістраваць свае адрасы ў DNS, калі для яго дазволена дынамічная рэгістрацыя. Калі адаптар PPP рэгіструецца, тое ж імя хоста атрымлівае адрас, да якога можа дабрацца толькі партнёр тунеля, і кліенты LAN атрымліваюць яго як сапраўдны адказ.

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

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

Прачытайце запіс, перш чым змяняць рэгістратар

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

dig +short files.corp.example A
dig @10.20.0.10 +short files.corp.example A
Resolve-DnsName files.corp.example -Server 10.20.0.10 -Type A

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

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

Выпраўце публікатара або запіс, але ведайце, што менавіта

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

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

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

Праверце з кліенцкай сеткі, якая пацярпела

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

ipconfig /flushdns
ipconfig /displaydns | findstr /i files.corp.example

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

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