Mae DNS cyhoeddus yn gweithio, ond nid yw hynny’n golygu bod Active Directory i’w chanfod

Mae’r VPN yn cysylltu, mae’r porwr yn agor safle cyhoeddus, ac eto nid yw’r gliniadur yn gallu mewngofnodi i’r parth. Y casgliad arferol yw bod DNS yn iawn oherwydd bod enwau’n datrys. Nid yw’n iawn, a’r rheswm yw bod prawf porwr yn arfer un ymholiad o gadwyn y mae angen i gleient sydd wedi’i ymuno â pharth ei chael. Mae darganfod parth yn gofyn am gofnodion gwasanaeth yn gyntaf, yna am gyfeiriadau’r rheolyddion a enwir gan y cofnodion hynny, ac yna am lwybr at y pyrth y mae’r rheolyddion hynny’n gwrando arnynt. Nid yw ateb cyhoeddus yn bodloni unrhyw un o’r camau hynny.

Y myth: mae enwau’n datrys, felly mae DNS wedi’i orffen

Mae safle cyhoeddus yn datrys yn dweud wrthych fod rhyw ddatryswr wedi ateb un ymholiad A neu AAAA am enw mewn parth cyhoeddus. Mae Active Directory yn defnyddio’r un protocol ar gyfer cwestiwn gwahanol: ble mae gwasanaethau’r parth, a pha reolydd y dylai’r cleient hwn ei ddefnyddio. Mynegir y cwestiwn fel cofnodion SRV o dan barth a enwir ar ôl y parth, ac nid oes gan ddatryswr cyhoeddus atchweliadol unrhyw reswm i’w cadw.

Pan fo’r cofnod ar goll, mae’r datryswr yn dychwelyd ateb negyddol, sy’n ateb DNS dilys yn hytrach na thoriad. Yna mae’r cleient yn disgyn yn ôl i wybodaeth reolyddion a storiwyd os oes ganddo, a dyna’n union pam y gall desg edrych yn iawn am oriau a methu ar ôl ailgychwyn neu newid cyfrinair.

Beth mae cleient parth yn ei ofyn mewn gwirionedd, yn ôl trefn

Ar gyfer parth fel corp.example, yr ymholiad lleoli cyffredinol yw _ldap._tcp.dc._msdcs.corp.example. Mae atebion SRV yn enwi rheolyddion posibl a’u pyrth, ac yna mae angen cofnodion cyfeiriad ar y cleient ar gyfer yr enwau gwesteiwyr hynny cyn y gall agor cysylltiad. Mae darganfod sy’n ymwybodol o safle yn ychwanegu ymholiadau o dan isbarth y safle, ac mae’r atebion yn pennu pa reolyddion sy’n well, nid pa un sy’n orfodol.

nltest /dsgetdc:corp.example
Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.corp.example

Dilynwch y gadwyn yn y drefn honno, o’r rhwydwaith lle mae’r problem yn digwydd. Mae enw gwesteiwr sy’n datrys i gyfeiriad unanhygyrch yn fethiant llwybro, nid yn fethiant DNS. Mae rheolydd hygyrch y mae ei gofnodion lleoli ar goll yn fethiant DNS, nid yn fethiant llwybro. Mae’r ddau yn cynhyrchu cwynion defnyddwyr tebyg ac atyriadau hollol wahanol.

Pam mae datryswr cyhoeddus yn ateb ac yn dal i dorri mewngofnodi

Os yw’r addasydd yn rhoi datryswr cyhoeddus i’r cleient, mae enwau cyhoeddus yn gweithio ac nid yw’r gofod enwau mewnol yn gweithio. Nid yw ychwanegu ail ddatryswr cyhoeddus yn helpu, oherwydd nid oes gan y naill na’r llall y parth. Ac nid yw’r rhestr arferol “mewnol yn gyntaf, cyhoeddus yn ail” yn ymddwyn fel rheol fesul parth: mae ateb negyddol gan y gweinydd cyntaf yn ateb dilys, ac nid yw’r cleient yn ailgeisio’r ail weinydd dim ond oherwydd bod yr ateb yn wag.

Mae’n rhaid i’r ddau ddatryswr mewnol, os ydych chi’n rhedeg dau, ddal gofod enwau AD a bod yn hygyrch o rwydwaith presennol y cleient. Dyma’r rhan y mae dyluniadau tiwnel hollt yn ei thorri: gall y VPN gario is-rwydwaith y tiwnel tra bo’r datryswr mewnol ar ragddodiad nad yw’r tiwnel yn ei lwybro, felly mae’r ymholiad yn mynd allan i ddatryswr na all ei ateb.

Mae Windows hefyd yn cymhwyso polisi datrys enwau a all gyfeirio gofodau enwau penodol at weinyddion penodol, ac nid yw’r cyfeiriadau DNS a ddangosir gan yr addasydd yn y stori gyfan. Gall newid rhestr yr addasydd heb newid y polisi hwnnw adael y ffurfweddiad effeithiol heb ei gyffwrdd, a dyna pam nad oes gan atyriad sy’n edrych fel pe bai wedi’i gymhwyso unrhyw effaith.

Cadwch DNS y tiwnel a’i lwybrau’n gyson

Mae proffil VPN sy’n gwthio datryswr ond nid y rhagddodiad sy’n ei gynnwys yn creu datryswr na all y cleient ei gyrraedd; mae un sy’n gwthio’r rhagddodiad heb ddatryswr yn gadael y cleient yn gofyn i’r un lleol. Triniwch y pâr fel un eitem ffurfweddu a gwiriwch y ddau ar ôl pob newid proffil, oherwydd gall gwthiad a aildrefnwyd neu bolisi tiwnel hollt newydd eu gwahanu.

Gwiriwch hefyd beth mae’r cleient yn ei wneud â’r gosodiad a wthiwyd. Mae rhai cleientiaid yn cymhwyso’r gweinydd DNS i ryngwyneb y tiwnel yn unig ac yn gadael datryswr yr addasydd corfforol yn ei le, felly mae pa un sy’n ennill yn dibynnu ar fetrig y rhyngwyneb a’r enw sy’n cael ei holi. Os mai dim ond pan fo’r addasydd corfforol wedi’i analluogi y daw’r ateb mewnol, dyna’r mecanwaith i’w drwsio, nid cofnodion y parth.

Derbyniwch gyda galwad ddarganfod ac un gweithrediad byw

Mae prawf derbyn defnyddiol yn rhedeg yr ymholiad lleoli ac yna’n cyflawni un gweithrediad dilysedig go iawn, fel agor rhannu a gefnogir gan gyfeiriadur neu ofyn am docyn. Gwnewch hyn cyn y trosglwyddiad VPN ac eto ar ei ôl, ar yr un peiriant, heb ailgychwyn rhyngddynt. Bydd manylion mewngofnodi a storiwyd a sesiynau sydd eisoes ar agor yn gwneud llwybr wedi torri i edrych yn iach yn fodlon, felly nid yw mewngofnodi llwyddiannus i’r bwrdd gwaith yn brawf.

Mae argymhellion Microsoft ar gyfer y cleient DNS yn tynnu’r un llinell rhwng datrys y gofod enwau mewnol ac anfon ymholiadau cyhoeddus ymlaen i fyny, a dyna’r drefn i’w chadw pan gyflwynir VPN.

Os mai dim ond araf yw’r methiant yn hytrach na wedi methu, cadwch yr oedi ar wahân i’r diagnosis. Gall terfyn amser yn ystod darganfod ddod o reolydd unanhygyrch, porth sydd wedi’i rwystro, neu ddatryswr sy’n ateb yn hwyr, ac ni phrofir yr un ohonynt gan yr arosiad yn unig. Cofnodwch yr ymholiad gwirioneddol, ei ateb, a’r ymgais i gysylltu cyn i chi newid gosodiad datryswr.