VPN-taskoj, kiuj restarigas la dosieron hosts, forviŝas postajn redaktojn
Faru momentfoton de la dosiero hosts ĉe konekto kaj restarigu ĝin ĉe malkonekto, kaj ĉiu redakto farita intere perdiĝas. Donu al ĉiu mapado posedanton anstataŭ momentfoto.
Konekta tasko kopias la dosieron hosts de Vindozo, aldonas unu privatan adreson, kaj malkonekta tasko kopias la konservitan version reen. Ĝi funkcias dum semajnoj, kaj poste unu posttagmeze la maŝino ne povas atingi internan retejon, kiu tute ne rilatas al la VPN. La restarigo faris ĝuste tion, kion oni ordonis: ĝi remetis dosieron el antaŭ la redakto de iu alia. La paneo estas en la modelo, ne en la komanda kopio.
Ĉiu laborfluo, kiu momentfotas komunan dosieron kaj poste restarigas ĝin, heredas ĉiun intere faritan ŝanĝon kiel perdon.
Sekurkopio restarigita poste ne estas kopio de la nuno
Trapaŝu ordinaran sinsekvon. La tasko konservas la dosieron kaj aldonas eron por la tunelo. Poste administranto aldonas nerilatan korektadon, kaj dua profilo aldonas sian propran eron. Ĉe malkonekto la restarigo remetas la originan momentfoton, forigante kaj la eron de la dua profilo kaj la korektadon de la administranto. Neniu el ili apartenis al la VPN, kaj ambaŭ nun mankas.
Unu fiksa sekurkopia dosiernomo plimalbonigas tion. Posta konekta okazaĵo povas kopii la jam ŝanĝitan dosieron super la supozata originalo, do la restariga bazo drivas al tio, kiel la dosiero aspektis ĉe la lasta okazaĵo.
Ĉiu okazaĵo estas sciigo, ne transakcio
Okazaĵpelita tasko estas sciigo. Rekonekto, interrompita malŝalto aŭ dua profilo povas reformi la postulatan staton dum pli frua tasko ankoraŭ skribas. Nenio serialigas la du, kaj nenio malfaras duone pretan ŝanĝon. Ankaŭ sola okazaĵa identigilo ne diras, al kiu profilo ĝi apartenas sen la provizanto kaj ĝiaj datumoj. Trakti la taskon kiel transakcion estas la supozo, kiu malsukcesas.
Ripetaj konektaj okazaĵoj estas la alia duono: aldono sen kontrolo kreas duan identan eron, kaj iuj solvantoj tiam vidas du respondojn por unu nomo.
Donu al ĉiu mapado posedanton
Ĉiu linio en la dosiero hosts mapas gastigantan nomon al adreso kaj diras nenion pri tio, kiu tunelo estas aktiva. Se aŭtomatigo neeviteblas, asignu unu posedanton por la VPN-administrataj mapadoj. Tiu posedanto devus ĝisdatigi nur siajn proprajn erojn, konservi nerilatan nunan enhavon, eviti duoblaĵojn ĉe ripeta okazaĵo, kaj akordigi kun la konektoj, kiuj efektive estas aktivaj, anstataŭ kun memorita listo.
Kiam du aktivaj tuneloj bezonas la saman mapadon, unuopa malkonekto ne rajtas forigi ĝin dum la alia posedanto ankoraŭ bezonas ĝin. Tio postulas referencan kalkuladon aŭ eksplicitan posedecan rikordon, ne logikan valoron.
Sekurkopio ankoraŭ valoras por reviziita restarigo. Ĝi ne devus esti la normala malkonekta ago, kaj ĝi ne devus esti la sola rikordo de tio, kion la dosiero enhavis.
Kiam kondiĉa DNS estas la reala bezono
Se la reala postulo estas privata nomspaco, kiu solviĝas nur dum la tunelo estas aktiva, hosts estas la malĝusta mekanismo. Windows NRPT povas elekti solvanton por nomspaco, kaj ĝi ne kreas mem la adresan rikordon; solvanto ankoraŭ devas respondi. Tio estas alia dizajno kun alia posedanto, kaj ĝi tute forigas la dosieran redakton ĉe ĉiu transiro.
Se hosts estas konservata intence por unu fiksa servo, certigu, ke ĝia adreso restu atingebla laŭ la celita vojo kaj ke ĝia gastiganta nomo restu stabila, por ke la identecaj kontroloj de la aplikaĵo daŭre funkciu. Viŝado de DNS-kaŝmemoro ne povas ripari malnoviĝintan eron, kiun la sekva serĉo denove legos.
Testu ripetajn konektojn, du samtempajn profilojn kaj malkonekton post nerilata redakto. La rezulto devus esti, ke la mapado de la VPN sekvas sian posedanton sen malfrui la reston de la maŝino.