Tri publikigiloj povas meti la VPN-adreson de domajna regilo en DNS

Tri malsamaj komponentoj sur domajna regilo kun pluraj interfacoj povas meti la saman VPN-adreson en DNS, kaj ili malsukcesas sendepende. Komparu, kion ĉiu el ili publikigas, anstataŭ fidi la markobutonon de la adaptilo, kiu regas nur unu el ili. La simptomo identas en ĉiu kazo: kliento solvas la nomon, ricevas la tunelan adreson kaj ne povas atingi la domajnan regilon. Kiu publikigis ĝin decidas, kiel haltigi ĝin.

Unu agordo, unu servo kaj unu rolo; tri publikigiloj, tri ŝaltiloj.

Komencu per la rikordo, ne per la markobutono

Pripetu la plenan nomon de la koncerna servilo per la DNS-servilo, kiun la klientoj efektive uzas, kaj notu ĉiun redonitan adreson. Komparu ĉiun redonitan adreson kun la realaj LAN- kaj tunel-interfacoj de la servilo kaj kun la retoj, en kiuj troviĝas la klientoj. Adreso povas esti tute valida loke kaj tamen neatingebla por la klientoj, kiuj gravas. Intermitaj aŭtentigaj fiaskoj estas ofta simptomo, ĉar klientoj ricevas aŭ elektas malsamajn adresojn en malsamaj provoj.

Tio, ke la maŝino ĝuste solvas sian propran nomon, pruvas tre malmulte. La grava testo ruliĝas el la klientaj retoj.

La adaptilo estas nur unu publikigilo

La TCP/IP-ecoj de la adaptilo enhavas markobutonon por registri la adreson de tiu konekto, kaj malmarki ĝin silentigas ekzakte unu publikigilon. Ĝi ne haltigas la aliajn, tial la rikordo povas reaperi post restartigo. Se la domajna regilo ankaŭ funkciigas la DNS-servon, tiu servo havas sian propran aŭskultan agordon kaj siajn proprajn nomservilajn rikordojn. La gvidilo de Microsoft por medioj kun pluraj interfacoj traktas la interfacan konduton, la DNS-servon kaj Netlogon kiel apartajn gravajn publikigilojn.

Tri ŝaltiloj, tri posedantoj, kaj nur unu el ili loĝas sur la eco-paĝo de la adaptilo.

La DNS-servo havas proprajn adresojn

DNS-servilo, kiu ricevas la ordonon aŭskulti sur VPN-adreso, daŭre publikigas ĝin en siaj propraj rikordoj, kion ajn asertas la markobutono de la adaptilo. Agordu la aŭskultajn adresojn de la servo al la celataj interfacoj, kaj samtempe reviziu la nomservilajn enskribojn de la zono. Ŝanĝi aŭskultantojn povas interrompi klientojn, kiuj ĝuste nun uzas adreson, kiun vi forigas, do unue determini, kiu dependas de kiu. Forigi aŭskultanton nur ĉar ĝi estas VPN-adreso povas fortranĉi la klientojn, kiujn vi volis helpi.

Netlogon, kaj ĝenerale la malkovro de domajnaj regiloj, ankaŭ registras adresojn kiel parton de siaj propraj taskoj. Ne subpremu registradojn tutdomajne, kaj ne kopiu malnovan registran solvon por fora aliro sen konfirmi, ke ĝi validas por via versio kaj rolo.

Posedo antaŭ purigado

Riparu la publikigilon antaŭ ol forigi la rikordon, alie la sekva registra evento remetos ĝin kaj la ekzerco ripetiĝos. Forigu eksdatajn enskribojn per la procezo de la DNS-posedanto kaj konsideru kaŝmemoron kaj maljuniĝon. Kontrolu el la klientaj retoj, inkluzive la malkovron de la domajno kaj la aplikaĵon, kiu komence fiaskis, poste ekigu la saman VPN-eventon, kiu unue kreis la adreson.

Tion, kion vi volas fine, estas konata aro da publikigitaj adresoj kaj aŭskultantoj, dum la ĉiutaga domajna registrado plu faras sian taskon. Maŝino, kies nomo hazarde solviĝas ĝuste tuj post permana purigado, ne estas tio.

Notu, kiu publikigilo respondecis, kiuj rikordoj ŝanĝiĝis kaj kiuj klientoj estis testitaj. La sekva servilo kun pluraj interfacoj havos la samajn tri suspektatojn.