وظایف VPN که فایل hosts را برمی‌گردانند ویرایش‌های بعدی را پاک می‌کنند

وظیفه اتصال فایل hosts ویندوز را کپی می‌کند، یک نشانی خصوصی به آن می‌افزاید، و وظیفه قطع اتصال نسخه ذخیره‌شده را برمی‌گرداند. هفته‌ها کار می‌کند و بعد یک بعدازظهر دستگاه به سایت داخلی‌ای نمی‌رسد که هیچ ربطی به VPN ندارد. بازگردانی دقیقاً همان کاری را کرد که به آن گفته شده بود: فایلی از پیش از ویرایش شخص دیگری را بازگرداند. خطا در مدل است، نه در فرمان کپی.

هر گردش کاری که از یک فایل مشترک نسخه بردارد و بعد آن را بازگرداند، هر تغییری که در این میانه انجام شده باشد را به‌عنوان ضرر به ارث می‌برد.

نسخه پشتیبانی که بعداً بازگردانده می‌شود نسخه پشتیبان اکنون نیست

یک توالی معمولی را مرور کنید. وظیفه فایل را ذخیره می‌کند و یک ورودی برای تونل می‌افزاید. بعداً یک مدیر یک اصلاح نامرتبط اضافه می‌کند، و یک پروفایل دوم ورودی خودش را اضافه می‌کند. هنگام قطع اتصال، بازگردانی نسخه اصلی را برمی‌گرداند و هم ورودی پروفایل دوم و هم اصلاح مدیر را حذف می‌کند. هیچ‌کدام به VPN تعلق نداشتند، و هر دو اکنون رفته‌اند.

یک نام فایل پشتیبان ثابت و یکتا وضع را بدتر می‌کند. یک رویداد اتصال بعدی می‌تواند فایل از پیش تغییرکرده را روی اصل فرضی کپی کند، پس مبنای بازیابی به سمت آنچه فایل در آخرین رویداد داشت می‌لغزد.

هر رویداد یک اطلاع است، نه یک تراکنش

وظیفه‌ای که با رویداد اجرا می‌شود یک اطلاع است. یک اتصال دوباره، یک خاموشی نیمه‌کاره یا یک پروفایل دوم می‌توانند حالت لازم را بازشکل دهند در حالی که وظیفه پیشین هنوز در میانه نوشتن است. هیچ چیز این دو را سریالی نمی‌کند، و هیچ چیز یک تغییر نیمه‌تمام را برنمی‌گرداند. همچنین یک شناسه رویداد به‌تنهایی، بدون ارائه‌دهنده و داده‌هایش نمی‌گوید به کدام پروفایل تعلق دارد. برخورد با وظیفه به‌عنوان یک تراکنش همان فرضی است که شکست می‌خورد.

رویدادهای اتصال تکراری نیمه دیگر ماجراست: افزودن بدون بررسی یک ورودی همانند دوم می‌سازد، و آن‌گاه برخی حل‌کننده‌ها دو پاسخ برای یک نام می‌بینند.

به هر نگاشت یک مالک بدهید

هر سطر در فایل hosts یک نام میزبان را به نشانی نگاشت می‌کند و هیچ نمی‌گوید که کدام تونل برپاست. اگر خودکارسازی ناگزیر است، برای نگاشت‌های تحت مدیریت VPN یک مالک تعیین کنید. آن مالک باید فقط ورودی‌های خودش را به‌روز کند، محتوای جاری نامرتبط را حفظ کند، در رویداد تکراری از تکرار بپرهیزد، و با اتصال‌هایی که واقعاً فعال‌اند هم‌تراز شود نه با فهرستی که در حافظه مانده است.

وقتی دو تونل زنده به یک نگاشت نیاز دارند، یک قطع اتصال نباید آن را بردارد در حالی که مالک دیگر هنوز به آن نیاز دارد. این کار شمارش ارجاع یا یک سابقه مالکیت صریح می‌خواهد، نه یک مقدار بولی.

نسخه پشتیبان هنوز برای بازیابی بازبینی‌شده ارزش دارد. نباید کنش معمول قطع اتصال باشد، و نباید تنها سابقه آنچه فایل در خود داشت باشد.

وقتی DNS شرطی نیاز واقعی است

اگر نیاز واقعی یک فضای نام خصوصی است که فقط تا وقتی تونل برپاست حل می‌شود، hosts سازوکار نادرست است. Windows NRPT می‌تواند برای یک فضای نام یک حل‌کننده انتخاب کند، و خودش سابقه نشانی را نمی‌سازد؛ حل‌کننده هنوز باید پاسخ دهد. این طراحی دیگری با مالک دیگری است، و ویرایش فایل به‌ازای هر گذار را کاملاً برمی‌دارد.

اگر hosts عمداً برای یک سرویس ثابت نگه داشته می‌شود، مطمئن شوید نشانی آن از مسیر موردنظر دسترس‌پذیر می‌ماند و نام میزبانش پایدار می‌ماند تا بررسی‌های هویت برنامه همچنان کار کند. پاک کردن حافظه نهان DNS نمی‌تواند سابقه‌ای کهنه را که جستجوی بعدی دوباره می‌خواند ترمیم کند.

اتصال‌های تکراری، دو پروفایل هم‌زمان و یک قطع اتصال پس از ویرایشی نامرتبط را بیازمایید. نتیجه باید این باشد که نگاشت VPN مالکش را دنبال کند بدون آنکه بقیه دستگاه را به عقب برگرداند.