DNS-rikordoj de VPN-klientoj: posedanto, TTL kaj purigado estas apartaj aferoj
VPN-adreso, DNS-rikordo kaj kaŝmemora enskribo havas apartajn posedantojn: decidu, kiu rajtas publikigi la nomon, kiuj interfacoj registras kaj kiam rikordoj malnoviĝas.
Tekkomputiloj konektiĝas, ricevas VPN-adreson, kaj la nomo, kiun aliaj sistemoj solvas, ankoraŭ montras al la oficeja adreso de hieraŭ. Nenio fiaskis: adreso estis asignita, rikordo ne estis ĝisdatigita, kaj kaŝmemoro ankoraŭ tenas la malnovan respondon. Temas pri tri objektoj kun tri posedantoj, kaj nur unu el ili apartenas al la VPN. Planado de publikigado signifas decidi, kiu skribas la nomon, kiuj interfacoj partoprenas kaj kiam malnovaj datumoj malaperas.
La simptomo: nomo, kiu sekvas la malĝustan adreson
De la aparato la tunelo estas aktiva kaj la VPN-adreso respondas. De la laborejo de kolego la sama gastigantnomo solviĝas al privata adreso, kiun la aparato jam ne havas, do la konekto eksvalidiĝas kontraŭ maŝino, kiu moviĝis. La rikordo estas aŭtoritata kaj malĝusta, kio estas pli malbona ol mankanta. Ĉiuj fidas ĝin kaj neniu povas konektiĝi.
La mala kazo estas pli silenta: la rikordo malaperas kaj la nomo tute ĉesas solviĝi. Ambaŭ rezultoj venas de la sama manko en la dezajno, kaj neniu el ili ripariĝas per malpliigo de TTL. Pli mallonga kaŝmemora vivoŝanĝas, kiom longe la malĝusta respondo pluvivas, ne ĉu ĝi estas skribita.
Komencu demandante, kiu objekto malnoviĝis. La adreso asignita de la VPN, la rikordo en la zono kaj la respondo en kaŝmemoro de solvilo havas malsamajn vivojn kaj malsamajn posedantojn.
Tri objektoj, tri posedantoj
La VPN posedas la asignadon de adresoj kaj povas doni la adreson el interna provizo sen ke iu DHCP-interŝanĝo atingu la tekkomputilon. La DNS-zono posedas la rikordon, kaj ĝia sekureca modelo decidas, kiu rajtas krei aŭ ŝanĝi ĝin. La kaŝmemoro de la solvilo posedas la kopion, kiun leganto nun uzas, kaj nenio, kion la aparato faras, povas atingi ĝin.
Supozi, ke unu komponanto faras ĉiujn tri, estas la loko, kie la dezajno rompiĝas. Adreso, kiu aspektas kvazaŭ ĝi venis el administrata gamo, ne pruvas, ke DHCP-servilo faris la registradon, kaj sukcesa registrado ne pruvas, ke legantoj refreŝigis sian kaŝmemoron.
| Object | Owner | What it decides |
|---|---|---|
| VPN address | Tunnel gateway pool | Which address the device holds now |
| DNS record | Zone security model | Which name resolves to which address |
| Cached answer | Each resolver | How long a reader keeps the old answer |
Kiu rajtas ĝisdatigi la rikordon
En zono integrita kun Active Directory kaj kun sekuraj dinamikaj ĝisdatigoj, la permesoj loĝas sur la rikordo mem. Rikordo kreita de DHCP-servokonto eble ne estas skribebla de la komputila konto de la tekkomputilo, kaj ŝanĝi la posedmodelon poste estas transiro, ne ŝaltilo. Tial posedkonflikto postvivas ĉiun agordon ĉe la klienta flanko.
La gvidlinioj de Microsoft pri dinamikaj ĝisdatigoj preferas registradon ĉe la klienta flanko por domajnligitaj hibridaj finpunktoj. Adapti ĝin signifas intence transigi ekzistantajn rikordojn, ne nur marki skatolon sur la VPN-adaptilo kaj esperi, ke la malnova posedanto cedos.
Kie DHCP-servo devas registri por aliaj aparatoklasoj, donu al ĝi la subtenatan kredencialan kaj permesan modelon por tiu rolo. Tenu antaŭajn kaj inversajn rikordojn en la sama plano, ĉar ofte prizorgas ilin malsamaj komponantoj kaj unu el ili kutime forgesiĝas.
ipconfig /all
Resolve-DnsName laptop-042.corp.example -Type A
Get-DnsServerResourceRecord -ZoneName corp.example -Name laptop-042La unua komando montras, kiujn adresojn la aparato kredas havi kaj ĉu la konekto estas agordita por registri ilin. La dua kaj tria komparas, kion kliento solvas, kun tio, kion la zono efektive konservas, kaj tio apartigas kaŝmemoran problemon de aŭtoritata.
Tri horloĝoj, ne unu
Publikigado kaj refreŝigado estas la unua horloĝo: kiam la rajtigita ĝisdatiganto anoncas, ke adreso ŝanĝiĝis. La TTL de la kaŝmemoro estas la dua: kiom longe solvilo rajtas teni la ricevitan respondon. Aŭtoritata purigado estas la tria: kiel malnovaj rikordoj foriĝas per la registra procezo aŭ per malnoviĝo kaj balaado.
Ĉi tiuj horloĝoj estas sendependaj, kaj konfuzi ilin produktas riparojn, kiuj ne funkcias. Ŝanĝo en unu estas nevidebla por la aliaj du. Mallonga TTL mallongigas la vivon de kaŝmemorita respondo kaj donas neniun ĝisdatigan permeson. Balaado forigas rikordojn, kiuj ne estis refreŝigitaj, kaj ĝi ne povas ripari rikordon, kiun neniam skribis la ĝusta posedanto.
Agordu la TTL laŭ tio, kiom rapide legantoj devas vidi ŝanĝon, kaj agordu la balaadon laŭ tio, kiom longe forlasita aparato devas teni nomon. Neniu el la du nombroj decidas, kiu rajtas skribi la rikordon, kaj neniu TTL-valoro transformas adresan asignadon en DNS-administrajn rajtojn.
Planu publikigadon por migranta aparato
Decidu, kiuj interfacoj partoprenas en la registrado. Hejma Wi-Fi-adreso, VPN-adreso kaj malnova oficeja adreso servas malsamajn publikon, kaj publikigi ĉiujn produktas nomon kun pluraj respondoj de neegala utileco. Registru la interfacojn, kiujn la celataj legantoj efektive povas atingi.
Tenu la stabilan komputilan nomon kiel identecon kaj traktu la adresojn kiel ĝiajn atributojn. Konservu la domajnajn malkovrajn rikordojn, kiujn la aparato bezonas, kaj ne malŝaltu la registradon tute por solvi problemon de duoblaj rikordoj, kiun permesa ŝanĝo riparus.
Skribu la asignanton, la ĝisdatiganton kaj la posedanton de purigado en unu rikordon, kun la celataj legantoj nomitaj. Kiam la nomo denove montros la malĝustan adreson, tiu rikordo diros al vi, kiun el la tri unue kontroli, anstataŭ rekomenci la esploradon.