Drie publiseerders kan ’n domeinbeheerder se VPN-adres in DNS plaas

Drie verskillende komponente op ’n multihomed domeinbeheerder kan dieselfde VPN-adres in DNS plaas, en hulle faal onafhanklik. Vergelyk wat elkeen publiseer eerder as om die adapter se kiesblokkie te vertrou, wat net een van hulle beheer. Die simptoom is in elke geval dieselfde: ’n kliënt los die naam op, kry die tonneladres en kan nie die domeinbeheerder bereik nie. Wie dit gepubliseer het, bepaal hoe om dit te stop.

Een instelling, een diens en een rol; drie publiseerders, drie skakelaars.

Begin by die rekord, nie by die kiesblokkie nie

Vra die geaffekteerde bediener se volle naam op deur die DNS-bediener wat die kliënte werklik gebruik, en teken elke adres aan wat terugkom. Plaas elke teruggekeerde adres teen die bediener se werklike LAN- en tonnelkoppelvlakke, en teen die netwerke waarop die kliënte sit. ’n Adres kan plaaslik heeltemal geldig wees en tog onbereikbaar wees vir die kliënte wat saak maak. Af en toe mislukte verifikasies is ’n algemene simptoom, want kliënte ontvang of kies verskillende adresse by verskillende pogings.

Die masjien wat sy eie naam korrek oplos, bewys baie min. Die toets wat saak maak, loop vanaf die kliëntnetwerke.

Die adapter is net een publiseerder

Die adapter se TCP/IP-eienskappe het ’n kiesblokkie om daardie verbinding se adres te registreer, en om dit af te merk stilmaak presies een publiseerder. Dit stop nie die ander nie, en daarom kan die rekord ná ’n herstart weer verskyn. As die domeinbeheerder ook die DNS-diens bedryf, het daardie diens sy eie luisterkonfigurasie en sy eie naamserver-rekords. Microsoft se multihomed-riglyne behandel die koppelvlakgedrag, die DNS-diens en Netlogon as afsonderlike relevante publiseerders.

Drie skakelaars, drie eienaars, en net een van hulle woon op die adapter se eiendomsblad.

Die DNS-diens het sy eie adresse

’n DNS-bediener wat opdrag het om op ’n VPN-adres te luister, publiseer dit steeds in sy eie rekords, wat die adapter se kiesblokkie ook al beweer. Belyn die diens se luisteradresse met die bedoelde koppelvlakke, en hersien terselfdertyd die sone se naamserver-inskrywings. Om luisteraars te verander kan kliënte onderbreek wat tans ’n adres gebruik wat jy verwyder, so stel eers vas wie op elkeen staatmaak. Om ’n luisteraar te skrap bloot omdat dit ’n VPN-adres is, kan die kliënte afsny wat jy wou help.

Netlogon, en domeinbeheerder-ontdekking in die algemeen, registreer ook adresse as deel van hul eie pligte. Moenie registrasies oor die hele domein onderdruk nie, of ’n ou remote-access-registeroplossing kopieer sonder om te bevestig dat dit op jou weergawe en rol van toepassing is nie.

Eienaarskap voor opruiming

Maak die publiseerder reg voordat jy die rekord verwyder, anders sit die volgende registrasiegebeurtenis dit terug en herhaal die oefening. Verwyder verouderde inskrywings deur die DNS-eienaar se proses en hou rekening met kas en veroudering. Toets vanaf die kliëntnetwerke, dek domeinontdekking en die toepassing wat oorspronklik gefaal het, en veroorsaak dan dieselfde VPN-gebeurtenis wat die adres die eerste keer geskep het.

Wat jy aan die einde wil hê, is ’n bekende stel gepubliseerde adresse en luisteraars, terwyl gewone domeinregistrasie steeds sy werk doen. ’n Masjien wie se naam toevallig dadelik ná handmatige opruiming korrek oplos, is nie dit nie.

Teken aan watter publiseerder verantwoordelik was, watter rekords verander het en watter kliënte getoets is. Die volgende multihomed-bediener gaan dieselfde drie verdagtes hê.