Prijenosnici se povezuju, dobiju VPN adresu, a ime koje drugi sistemi razrješavaju još pokazuje na jučerašnju adresu ureda. Ništa nije otkazalo: adresa je dodijeljena, zapis nije ažuriran, a keš još drži stari odgovor. To su tri objekta s tri vlasnika, a samo jedan od njih pripada VPN-u. Planiranje objavljivanja znači odlučiti ko piše ime, koji interfejsi učestvuju i kada zastarjeli podaci nestaju.

Simptom: ime koje slijedi pogrešnu adresu

S uređaja je tunel podignut i VPN adresa odgovara. S radne stanice kolege isti naziv hosta razrješava se na privatnu adresu koju uređaj više ne drži, pa veza istječe prema mašini koja se preselila. Zapis je autoritativan i pogrešan, što je gore od nedostajućeg. Svi mu vjeruju i niko se ne može povezati.

Obrnuti slučaj je tiši: zapis nestane i ime se uopće više ne razrješava. Oba ishoda dolaze iz iste praznine u dizajnu i nijedan se ne ispravlja snižavanjem TTL-a. Kraći životni vijek keša mijenja koliko dugo pogrešan odgovor preživi, a ne da li je zapisan.

Počnite pitanjem koji je objekat zastario. Adresa koju je VPN dodijelio, zapis u zoni i odgovor u kešu razrješivača imaju različite životne vijekove i različite vlasnike.

Tri objekta, tri vlasnika

VPN posjeduje dodjelu adresa i može izdati adresu iz internog bazena, a da nikakva DHCP razmjena ne stigne do prijenosnika. DNS zona posjeduje zapis i njen sigurnosni model odlučuje ko ga smije stvoriti ili izmijeniti. Keš razrješivača posjeduje kopiju koju čitatelj trenutno koristi i ništa što uređaj uradi ne može do nje doprijeti.

Pretpostavka da jedna komponenta radi sve tri je mjesto gdje se dizajn lomi. Adresa koja izgleda kao da dolazi iz upravljanog raspona ne dokazuje da je DHCP server obavio registraciju, a uspješna registracija ne dokazuje da su čitatelji osvježili keš.

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

Ko smije ažurirati zapis

U zoni integriranoj s Active Directory i sa sigurnim dinamičkim ažuriranjima dozvole žive na samom zapisu. Zapis koji je stvorio servisni račun DHCP-a možda nije upisiv s računarskog računa prijenosnika, a promjena modela vlasništva kasnije je prijelaz, a ne prekidač. Zato sukob vlasništva nadživi svaku postavku na strani klijenta.

Microsoftove smjernice za dinamička ažuriranja preferiraju registraciju na strani klijenta za hibridne krajnje točke u domeni. Prihvatiti to znači namjerno prenijeti postojeće zapise, a ne samo označiti polje na VPN adapteru i nadati se da će stari vlasnik popustiti.

Kada DHCP servis mora registrirati druge klase uređaja, dajte mu podržani model vjerovanja i dozvola za tu ulogu. Držite zapise naprijed i natrag u istom planu, jer ih često održavaju različite komponente i jedna od njih se obično zaboravi.

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

Prva komanda pokazuje koje adrese uređaj misli da drži i je li veza postavljena da ih registruje. Druga i treća upoređuju što klijent razrješava s onim što zona stvarno čuva, što odvaja problem keša od autoritativnog problema.

Tri sata, ne jedan

Objavljivanje i osvježavanje prvi je sat: kada ovlašteni ažurator objavi da se adresa promijenila. TTL keša je drugi: koliko dugo razrješivač smije držati primljeni odgovor. Autoritativno čišćenje je treći: kako se zastarjeli zapisi uklanjaju postupkom registracije ili starenjem i čišćenjem.

Ovi satovi su neovisni i njihovo miješanje daje ispravke koje ne rade. Promjena na jednom nevidljiva je za druga dva. Kratak TTL skraćuje život keširanog odgovora i ne daje nikakvu dozvolu za ažuriranje. Čišćenje uklanja zapise koji nisu osvježeni i ne može popraviti zapis koji nikada nije zapisao pravi vlasnik.

Postavite TTL prema tome koliko brzo čitatelji moraju vidjeti promjenu, a čišćenje prema tome koliko dugo napušteni uređaj treba držati ime. Nijedan od tih brojeva ne odlučuje ko smije pisati zapis i nijedna vrijednost TTL-a ne pretvara dodjelu adresa u DNS administratorska prava.

Planirajte objavljivanje za uređaj u pokretu

Odredite koji interfejsi učestvuju u registraciji. Kućna Wi-Fi adresa, VPN adresa i stara adresa ureda služe različitim publikama, a objavljivanje svih daje ime s nekoliko odgovora nejednake korisnosti. Registrujte interfejse do kojih namjeravani čitatelji stvarno mogu doprijeti.

Držite stabilno ime računara kao identitet i tretirajte adrese kao njegove atribute. Sačuvajte zapise otkrivanja domene koje uređaj treba i ne isključujte registraciju u cjelini da biste riješili problem dvostrukih zapisa koji bi promjena dozvola ispravila.

Upišite dodjeljivača, ažuratora i vlasnika čišćenja u jedan zapis, s imenovanim namjeravanim čitateljima. Kada ime ponovno pokaže pogrešnu adresu, taj zapis vam kaže koga od troje prvo provjeriti, umjesto da istragu počinjete iznova.

Povezani članci