Yhdistämistehtävä kopioi Windowsin hosts-tiedoston, lisää yhden yksityisen osoitteen, ja katkaisutehtävä kopioi tallennetun version takaisin. Se toimii viikkoja, ja sitten eräänä iltapäivänä kone ei tavoita sisäistä sivustoa, jolla ei ole mitään tekemistä VPN:n kanssa. Palautus teki täsmälleen sen, mitä käskettiin: se pani takaisin tiedoston ajalta ennen jonkun toisen muokkausta. Vika on mallissa, ei kopiointikomennossa.

Jokainen työnkulku, joka tallentaa jaetusta tiedostosta tilannekuvan ja palauttaa sen myöhemmin, perii jokaisen välissä tehdyn muutoksen menetyksenä.

Myöhemmin palautettu varmuuskopio ei ole nykyhetken kopio

Käy läpi tavanomainen jakso. Tehtävä tallentaa tiedoston ja lisää tunnelille merkinnän. Myöhemmin ylläpitäjä lisää siihen kuulumattoman korjauksen, ja toinen profiili lisää oman merkintänsä. Katkaistaessa palautus panee takaisin alkuperäisen tilannekuvan ja poistaa sekä toisen profiilin merkinnän että ylläpitäjän korjauksen. Kumpikaan ei kuulunut VPN:lle, ja molemmat ovat nyt poissa.

Yksi kiinteä varmuuskopiotiedoston nimi pahentaa asiaa. Myöhempi yhdistämistapahtuma voi kopioida jo muokatun tiedoston väitetyn alkuperäisen päälle, joten palautuksen perusta ajautuu kohti sitä, miltä tiedosto näytti viimeisimmän tapahtuman hetkellä.

Jokainen tapahtuma on ilmoitus, ei transaktio

Tapahtuman laukaisema tehtävä on ilmoitus. Uudelleenyhdistäminen, keskeytynyt sammutus tai toinen profiili voivat muovata vaaditun tilan uudelleen, kun aiempi tehtävä on vielä kirjoittamassa. Mikään ei sarjallista kahta, eikä mikään peru puolivalmista muutosta. Lisäksi pelkkä tapahtumatunniste ei kerro, mihin profiiliin se kuuluu ilman tarjoajaa ja sen tietoja. Tehtävän kohteleminen transaktiona on se oletus, joka pettää.

Toistuvat yhdistämistapahtumat ovat toinen puoli: lisäys ilman tarkistusta luo toisen samanlaisen merkinnän, ja jotkut ratkaisijat näkevät silloin kaksi vastausta yhdelle nimelle.

Anna jokaiselle kuvaukselle omistaja

Jokainen hosts-tiedoston rivi kuvaa isäntänimen osoitteeseen eikä kerro mitään siitä, mikä tunneli on päällä. Jos automaatiota ei voi välttää, nimeä yksi omistaja VPN:n hallitsemille kuvauksille. Sen omistajan tulisi päivittää vain omat merkintänsä, säilyttää siihen kuulumaton nykyinen sisältö, välttää kaksoiskappaleet toistuvassa tapahtumassa ja täsmäyttää ne yhteydet, jotka todella ovat aktiivisia, eikä muistissa olevaa luetteloa vasten.

Kun kaksi elävää tunnelia tarvitsevat saman kuvauksen, yksi katkaisu ei saa poistaa sitä, kun toinen omistaja tarvitsee sitä vielä. Se vaatii viitelaskennan tai nimenomaisen omistustietueen, ei totuusarvoa.

Varmuuskopiolla on yhä arvoa tarkastetulle palautukselle. Sen ei pitäisi olla tavallinen katkaisutoimi, eikä sen pitäisi olla ainoa tietue siitä, mitä tiedosto sisälsi.

Kun ehdollinen DNS on todellinen tarve

Jos todellinen vaatimus on yksityinen nimiavaruus, joka ratkeaa vain tunnelin ollessa päällä, hosts on väärä mekanismi. Windows NRPT voi valita nimiavaruudelle ratkaisijan, eikä se luo osoitetietuetta itse; ratkaisijan on silti vastattava. Se on erilainen suunnittelu eri omistajalla, ja se poistaa tiedoston muokkauksen jokaiselta siirtymältä kokonaan.

Jos hosts pidetään tarkoituksella yhdelle kiinteälle palvelulle, varmista, että sen osoite pysyy tavoitettavissa aiotulla reitillä ja että sen isäntänimi pysyy vakaana, jotta sovelluksen identiteettitarkistukset toimivat edelleen. DNS-välimuistin tyhjentäminen ei voi korjata vanhentunutta merkintää, jonka seuraava haku lukee uudelleen.

Testaa toistuvia yhteyksiä, kahta samanaikaista profiilia ja katkaisua siihen kuulumattoman muokkauksen jälkeen. Tuloksen pitäisi olla, että VPN:n kuvaus seuraa omistajaansa kelautumatta koneen muuta osaa taaksepäin.

Aiheeseen liittyvät artikkelit