Nešiojamieji kompiuteriai jungiasi, gauna VPN adresą, o vardas, kurį sprendžia kitos sistemos, vis dar rodo į vakarykštį biuro adresą. Niekas nesugedo: adresas buvo paskirtas, įrašas nebuvo atnaujintas, o podėlis vis dar laiko seną atsakymą. Tai trys objektai su trimis savininkais, ir tik vienas jų priklauso VPN. Skelbimo planavimas reiškia nuspręsti, kas rašo vardą, kurios sąsajos dalyvauja ir kada išnyksta pasenę duomenys.

Simptomas: vardas, kuris seka neteisingu adresu

Iš įrenginio tunelis pakeltas ir VPN adresas atsako. Iš kolegos darbo vietos tas pats mazgo vardas išsprendžiamas į privatų adresą, kurio įrenginys jau neturi, todėl ryšys pasibaigia laiku su mašina, kuri persikėlė. Įrašas yra autoritetingas ir klaidingas, o tai blogiau nei jo nebuvimas. Visi juo tiki ir niekas negali prisijungti.

Priešingas atvejis tylesnis: įrašas išnyksta ir vardas visai nustoja sprendžiamas. Abi pasekmės kyla iš tos pačios dizaino spragos, ir nė vienos neištaiso TTL sumažinimas. Trumpesnis podėlio gyvavimas keičia, kiek laiko išgyvena klaidingas atsakymas, o ne ar jis įrašomas.

Pradėkite klausdami, kuris objektas pasenęs. VPN paskirtam adresui, zonos įrašui ir sprendėjo podėlyje esančiam atsakymui galioja skirtingi gyvavimo laikai ir skirtingi savininkai.

Trys objektai, trys savininkai

VPN valdo adresų paskyrimą ir gali išduoti adresą iš vidinio telkinio, net jei jokie DHCP mainai nepasiekia nešiojamojo kompiuterio. DNS zona valdo įrašą, ir jos saugumo modelis nusprendžia, kas gali jį sukurti ar pakeisti. Sprendėjo podėlis valdo kopiją, kurią skaitytojas dabar naudoja, ir niekas, ką daro įrenginys, negali jos pasiekti.

Prielaida, kad viena komponentė atlieka visus tris, yra vieta, kur dizainas lūžta. Adresas, kuris atrodo atėjęs iš valdomo diapazono, neįrodo, kad DHCP serveris atliko registraciją, o sėkminga registracija neįrodo, kad skaitytojai atnaujino savo podėlį.

ObjectOwnerWhat it decides
VPN addressTunnel gateway poolWhich address the device holds now
DNS recordZone security modelWhich name resolves to which address
Cached answerEach resolverHow long a reader keeps the old answer

Kas gali atnaujinti įrašą

Zonoje, integruotoje su Active Directory ir su saugiais dinaminiais atnaujinimais, teisės gyvena pačiame įraše. DHCP tarnybos paskyros sukurtas įrašas gali būti neįrašomas nešiojamojo kompiuterio kompiuterio paskyra, o vėlesnis nuosavybės modelio pakeitimas yra perėjimas, ne jungiklis. Todėl nuosavybės konfliktas išgyvena bet kokį kliento pusės nustatymą.

Microsoft dinaminių atnaujinimų gairės pirmenybę teikia kliento pusės registracijai domenui prijungtiems hibridiniams galiniams taškams. Tai priimti reiškia sąmoningai perkelti esamus įrašus, o ne tik pažymėti langelį VPN adapteryje ir tikėtis, kad senasis savininkas nusileis.

Kai DHCP tarnyba turi registruoti kitų klasių įrenginius, duokite jai toms pareigoms palaikomą kredencialų ir teisių modelį. Laikykite tiesioginius ir atvirkštinius įrašus tame pačiame plane, nes juos dažnai prižiūri skirtingos komponentės ir vienas jų paprastai pamirštamas.

ipconfig /all
Resolve-DnsName laptop-042.corp.example -Type A
Get-DnsServerResourceRecord -ZoneName corp.example -Name laptop-042

Pirmoji komanda parodo, kuriuos adresus įrenginys mano turintis ir ar ryšys nustatytas juos registruoti. Antroji ir trečioji palygina, ką klientas išsprendžia, su tuo, ką zona iš tikrųjų saugo, ir tai atskiria podėlio problemą nuo autoritetingos.

Trys laikrodžiai, ne vienas

Skelbimas ir atnaujinimas yra pirmasis laikrodis: kada įgaliotasis atnaujintojas paskelbia, kad adresas pasikeitė. Podėlio TTL yra antrasis: kiek laiko sprendėjas gali laikyti gautą atsakymą. Autoritetingas valymas yra trečiasis: kaip pasenę įrašai pašalinami registracijos procesu arba senėjimu ir šlavimu.

Šie laikrodžiai nepriklausomi, ir jų painiojimas duoda pataisymus, kurie neveikia. Vieno pakeitimas nematomas kitiems dviem. Trumpas TTL sutrumpina podėlyje esančio atsakymo gyvenimą ir nesuteikia jokios atnaujinimo teisės. Šlavimas pašalina įrašus, kurie nebuvo atnaujinti, ir negali sutaisyti įrašo, kurio niekada neįrašė teisingas savininkas.

Nustatykite TTL pagal tai, kaip greitai skaitytojai turi pamatyti pakeitimą, o šlavimą – pagal tai, kiek laiko apleistas įrenginys turi išlaikyti vardą. Nė vienas iš šių skaičių nenusprendžia, kas gali rašyti įrašą, ir jokia TTL reikšmė nepaverčia adresų paskyrimo DNS administravimo teisėmis.

Suplanuokite skelbimą keliaujančiam įrenginiui

Nuspręskite, kurios sąsajos dalyvauja registracijoje. Namų Wi-Fi adresas, VPN adresas ir senas biuro adresas tarnauja skirtingoms auditorijoms, o paskelbus visus gaunamas vardas su keliais nevienodai naudingais atsakymais. Registruokite sąsajas, kurias numatyti skaitytojai tikrai gali pasiekti.

Laikykite stabilų kompiuterio vardą tapatybe, o adresus traktuokite kaip jo atributus. Išsaugokite domeno aptikimo įrašus, kurių reikia įrenginiui, ir neišjunkite registracijos visiškai, kad išspręstumėte dvigubų įrašų problemą, kurią išspręstų teisių pakeitimas.

Įrašykite skirstytuvą, atnaujintoją ir valymo savininką į vieną įrašą, nurodydami numatytus skaitytojus. Kai vardas vėl nurodys neteisingą adresą, tas įrašas pasakys, kurį iš trijų tikrinti pirmiausia, o ne pradėti tyrimą iš naujo.

Susiję straipsniai