دو VPN، یک resolver: هر که دیرتر نوشت برنده است

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

افسانه: جدیدترین VPN مالک DNS است

هیچ قاعده کلی‌ای وجود ندارد که جدیدترین اتصال برنده شود. آنچه رخ می‌دهد به سازوکار پلتفرم و به نحوه نوشتن هر کلاینت بستگی دارد. کلاینتی که یک فایل resolver را جایگزین می‌کند یک نتیجه می‌دهد؛ کلاینتی که برای هر پیوند یک دامنه اضافه می‌کند نتیجه دیگری؛ کلاینتی که هیچ کاری نمی‌کند وضعیت قبلی را دست‌نخورده می‌گذارد.

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

فضاهای نام را به resolverها نگاشت کنید

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

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

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

یک مسیر راه‌اندازی نگه دارید

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

به مسیر رسیدن به هر resolver نگاه کنید، نه فقط نامی که برایش تنظیم شده است. resolverی که فقط از تونل دیگر قابل دسترسی است مانند resolver غایب رفتار می‌کند و نشانه، پایان مهلت است نه خطای مسیریابی.

نشانی‌های هم‌پوشان مسئله DNS نیستند

دو شبکه خصوصی که از همان بازه نشانی استفاده می‌کنند با ترتیب DNS اصلاح نمی‌شوند. اگر هر دو تونل 10.0.0.0/8 را ادعا کنند، نامی که درست حل می‌شود باز هم به نشانی‌ای اشاره می‌کند که میزبان نمی‌تواند آن را به تونل درست مسیریابی کند. این به راه‌حلی در سطح نشانی نیاز دارد، مانند بازه‌های متفاوت، یک فضای نام یا ترجمه، نه یک تنظیم resolver دیگر. تصمیم زودهنگام از یک انحراف طولانی در پیکربندی DNS که هرگز کار نمی‌کرد جلوگیری می‌کند.

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

با برنامه‌های واقعی اثباتش کنید

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

کلاینتی با گزینه DNS رمزنگاری‌شده خودش می‌تواند از سیاستی که همین حالا بررسی کردید عبور کند، پس آن تنظیم را به‌عنوان بخشی از بازبینی بررسی کنید. سپس هر دو کلاینت را به ترتیبی که فروشنده پشتیبانی می‌کند دوباره وصل کنید و جستجوها را تکرار کنید؛ اگر با تغییر ترتیب پاسخ‌ها جابه‌جا شوند، یک نویسنده رقیب هنوز مالک بخشی از پیکربندی است. پیش از ویرایش هر چیزی پیدا کنید کدام مؤلفه قاعده را نصب می‌کند - کلاینت، نمایه سیستم‌عامل یا یک عامل مدیریت. ترتیب و مالکان را ثبت کنید تا نفر بعد مجبور نباشد دوباره کشفشان کند.