Trije publisearjers kinne it VPN-adres fan in domeinkontrôleur yn DNS sette

Trije ferskillende komponinten op in multihomed domeinkontrôleur kinne itselde VPN-adres yn DNS sette, en se mislearje ûnôfhinklik. Ferlykje wat elk publisearret ynstee fan it kontrôlefakje fan de adapter te fertrouwen, dat mar ien fan harren regelet. It symptoom is yn elk gefal itselde: in klant oplost de namme, krijt it tunneladres en kin de domeinkontrôleur net berikke. Wa’t it publisearre hat, bepaalt hoe’t it stopset wurde moat.

Ien ynstelling, ien tsjinst en ien rol; trije publisearjers, trije skeakels.

Begjin by it record, net by it kontrôlefakje

Freegje de folsleine namme fan de oanbelangjende server op fia de DNS-tsjinner dy’t de klanten echt brûke, en skriuw elk adres op dat weromkomt. Set elk weromjûn adres tsjin de echte LAN- en tunnelinterfaces fan de server, en tsjin de netwurken dêr’t de klanten yn sitte. In adres kin lokaal folslein jildich wêze en dochs ûnberikber foar de klanten dy’t fan belang binne. No en dan mislearjende autentikaasjes binne in gewoan symptoom, omdat klanten by ferskillende pogingen ferskillende adressen krije of kieze.

Dat de masine syn eigen namme korrekt oplost, bewiist hiel lyts bytsje. De test dy’t fan belang is, rint fan de klantnetwurken ôf.

De adapter is mar ien publisearjer

De TCP/IP-eigenskippen fan de adapter hawwe in kontrôlefakje om it adres fan dy ferbining te registrearjen, en it fuortheljen fan it hykje makket krekt ien publisearjer stil. It stoppet de oaren net, en dêrom kin it record nei in werstart wer ferskine. As de domeinkontrôleur ek de DNS-tsjinst draait, hat dy tsjinst syn eigen harkkonfiguraasje en syn eigen nammetsjinner-records. De rjochtline fan Microsoft foar omjouwings mei meardere interfaces behannelet it gedrach fan de interface, de DNS-tsjinst en Netlogon as aparte relevante publisearjers.

Trije skeakels, trije eigners, en mar ien fan harren wennet op de eigenskippeside fan de adapter.

De DNS-tsjinst hat syn eigen adressen

In DNS-tsjinner dy’t sein is om op in VPN-adres te harkjen, bliuwt it yn syn eigen records publisearjen, wat it kontrôlefakje fan de adapter ek beweart. Lijn de harkadressen fan de tsjinst ôf op de bedoelde interfaces, en besjoch tagelyk de nammetsjinner-ynfieringen fan de sône. It feroarjen fan harkers kin klanten ûnderbrekke dy’t op dit stuit in adres brûke dat jo fuortsmite, stel dêrom earst fêst wa’t fan elk ôfhinklik is. In harker fuortsmite allinnich om’t it in VPN-adres is, kin de klanten ôfsnije dy’t jo helpe woene.

Netlogon, en it ûntdekken fan domeinkontrôleurs yn it algemien, registrearje ek adressen as ûnderdiel fan har eigen taken. Underdruk registraasjes net oer it hiele domein, en kopiearje gjin âlde registraasje-oplossing foar remote tagong sûnder te befêstigjen dat dy jildt foar jo ferzje en rol.

Eignerskip foar opromjen

Reparearje de publisearjer foardat jo it record fuortsmite, oars set de folgjende registraasjegebeurtenis it werom en wurdt de oefening werhelle. Ferwiderje ferâldere ynfieringen fia it proses fan de DNS-eigner en hâld rekken mei cache en ferâldering. Kontrolearje fan de klantnetwurken ôf, ynklusyf domeinûntdekking en de applikaasje dy’t oarspronklik mislearre, en lokje dan deselde VPN-gebeurtenis út dy’t it adres de earste kear makke hat.

Wat jo oan ’e ein wolle, is in bekende set publisearre adressen en harkers, wylst de deistige domeinregistraasje noch altyd syn wurk docht. In masine waans namme tafallich fuortendaliks nei hânmjittich opromjen korrekt oplost, is dat net.

Skriuw op hokker publisearjer ferantwurdlik wie, hokker records feroare binne en hokker klanten testen binne. De folgjende multihomed server sil deselde trije fertochten hawwe.