A csatlakozási feladat lemásolja a Windows hosts fájlját, hozzáad egy privát címet, a leválási feladat pedig visszamásolja a mentett változatot. Hetekig működik, majd egy délután a gép nem ér el egy belső oldalt, amelynek semmi köze a VPN-hez. A visszaállítás pontosan azt tette, amit mondtak neki: visszatett egy fájlt valaki más módosítása előtti állapotból. A hiba a modellben van, nem a másolási parancsban.

Minden olyan munkafolyamat, amely pillanatképet készít egy megosztott fájlról, és később visszaállítja, minden közben történt változást veszteségként örököl.

A később visszaállított biztonsági mentés nem a mostani állapot mentése

Menjen végig egy szokásos sorrenden. A feladat elmenti a fájlt, és hozzáad egy bejegyzést az alagúthoz. Később egy rendszergazda hozzáad egy nem kapcsolódó javítást, és egy második profil hozzáadja a saját bejegyzését. Leváláskor a visszaállítás visszateszi az eredeti pillanatképet, eltávolítva a második profil bejegyzését és a rendszergazda javítását is. Egyik sem a VPN-hez tartozott, és mindkettő eltűnt.

Egyetlen rögzített biztonsági mentési fájlnév rontja a helyzetet. Egy későbbi csatlakozási esemény átmásolhatja a már módosított fájlt a feltételezett eredetire, így a visszaállítási alap elcsúszik a fájl utolsó eseménykori állapota felé.

Minden esemény értesítés, nem tranzakció

Az esemény által indított feladat értesítés. Egy újracsatlakozás, egy félbeszakadt leállítás vagy egy második profil átformálhatja a szükséges állapotot, miközben egy korábbi feladat még ír. Semmi nem szerializálja a kettőt, és semmi nem gördíti vissza a félkész változtatást. Ráadásul egy eseményazonosító önmagában, a szolgáltató és adatai nélkül nem mondja meg, melyik profilhoz tartozik. A feladat tranzakcióként kezelése az a feltevés, amely megbukik.

Az ismétlődő csatlakozási események a másik fele: az ellenőrzés nélküli hozzáadás egy második azonos bejegyzést hoz létre, és egyes feloldók ekkor két választ látnak egy névre.

Adjon minden leképezésnek gazdát

A hosts fájl minden sora egy hosztnevet rendel egy címhez, és semmit nem mond arról, melyik alagút van fent. Ha az automatizálás elkerülhetetlen, jelöljön ki egy gazdát a VPN által kezelt leképezésekhez. Ennek a gazdának csak a saját bejegyzéseit szabad frissítenie, meg kell őriznie a nem kapcsolódó jelenlegi tartalmat, el kell kerülnie az ismétlődő esemény okozta duplikátumokat, és a valóban aktív kapcsolatokhoz kell igazodnia, nem egy megjegyzett listához.

Ha két élő alagútnak ugyanarra a leképezésre van szüksége, egyetlen leválás nem távolíthatja el, amíg a másik gazdának még szüksége van rá. Ez referenciaszámlálást vagy kifejezett tulajdonosi rekordot igényel, nem logikai értéket.

A biztonsági mentésnek továbbra is van értéke az átvizsgált helyreállításhoz. Nem ez lehet a szokásos leválási művelet, és nem ez lehet az egyetlen feljegyzés arról, mi volt a fájlban.

Amikor a feltételes DNS az igazi igény

Ha a tényleges követelmény egy privát névtér, amely csak addig oldódik fel, amíg az alagút fent van, a hosts a rossz mechanizmus. A Windows NRPT képes feloldót választani egy névtérhez, és maga nem hozza létre a címrekordot; a feloldónak továbbra is válaszolnia kell. Ez más gazdával járó másik tervezés, és teljesen megszünteti a fájl szerkesztését minden átmenetnél.

Ha a hosts fájlt szándékosan egyetlen rögzített szolgáltatásra tartják meg, győződjön meg arról, hogy a címe elérhető marad a szándékolt útvonalon, és a hosztneve stabil marad, hogy az alkalmazás identitásellenőrzései tovább működjenek. A DNS-gyorsítótár törlése nem tud kijavítani egy elavult bejegyzést, amelyet a következő keresés újra beolvas.

Tesztelje az ismétlődő csatlakozásokat, két egyidejű profilt és egy nem kapcsolódó módosítás utáni leválást. Az eredmény az legyen, hogy a VPN leképezése a gazdáját követi anélkül, hogy visszatekerőztetné a gép többi részét.

Kapcsolódó cikkek