چرا یک نقطهٔ پایانی خصوصی هنوز با یک نشانی عمومی پاسخ می‌دهد
پرس‌وجو را از لپ‌تاپ به سمت بیرون دنبال کنید: کدام حل‌کننده پاسخ می‌دهد، کدام نشانی برمی‌گردد و چه چیزی باید پیوند شود تا نقطهٔ پایانی خصوصی قابل دسترسی باشد.
لپ‌تاپ وصل می‌شود، تونل خود را فعال اعلام می‌کند و حساب ذخیره‌سازی همچنان هر درخواستی را رد می‌کند. نقطهٔ پایانی خصوصی وجود دارد، مسیر به زیرشبکهٔ آن وجود دارد و نام یا با یک نشانی عمومی پاسخ می‌دهد یا اصلاً تحلیل نمی‌شود. هیچ ایرادی در تونل نیست: هرگز به کارخواه گفته نشده که کدام کارساز باید برای آن نام پاسخ دهد. پرس‌وجو را به بیرون دنبال کنید و شکاف آشکار می‌شود.
از حل‌کنندهٔ کارخواه شروع کنید
از کارخواه بپرسید تا زمانی که تونل فعال است از کدام کارساز می‌پرسد. نمایهٔ نقطه به سایت آن نشانی را فراهم می‌کند و نمایه‌ای که چیزی فراهم نمی‌کند سیستم عامل را به پیش‌فرض‌های کارت شبکه برمی‌گرداند.
حل‌کننده‌های عمومی هیچ دیدی نسبت به یک ناحیهٔ خصوصی ندارند، بنابراین از اینترنت پاسخ می‌دهند که دقیقاً کارشان همین است. پس نخستین بررسی نشانی حل‌کنندهٔ در حال استفاده است، نه تونل و نه نقطهٔ پایانی.
بخوانید که پاسخ واقعاً چیست
نام سرویس را تحلیل کنید و نشانی برگشتی را بخوانید. پاسخ عمومی یعنی پرس‌وجو به کارسازی رسیده که ناحیه را نمی‌بیند. نبود پاسخ یعنی نام فقط به‌صورت خصوصی وجود دارد و چیزی که کارخواه بتواند به آن برسد آن را نگه نمی‌دارد.
این دو نتیجه خطاهای برنامه‌ای مشابهی تولید می‌کنند و به دو مالک متفاوت تعلق دارند. یکی مسئلهٔ انتخاب حل‌کننده است و دیگری یک پیوند ناحیهٔ گمشده.
ورودی hosts مسیر را اثبات می‌کند و سپس دروغ می‌گوید
گذاشتن نشانی نقطهٔ پایانی در پروندهٔ محلی hosts سریع‌ترین راه برای اثبات این است که تونل و دیوار آتش سرویس از قبل کار می‌کنند. اگر درخواست با آن ورودی موفق شود، فقط تحلیل نام خراب است. این همچنین تغییری در هر ماشین است که دقیقاً یک نام را پوشش می‌دهد.
به حساب دوم، نقطهٔ پایانی دوم یا یک همکار کمکی نمی‌کند و وقتی نقطهٔ پایانی با نشانی جدید بازسازی شود، بی‌هشدار می‌شکند.
بدتر از آن، باعث می‌شود ماشین شما متفاوت از ماشین همه رفتار کند، و همین‌گونه است که یک عیب حل‌کننده یک هفته بررسی را زنده می‌ماند. از آن برای تأیید مسیر استفاده کنید، سپس آن را بردارید و علت را درست کنید.
ناحیه را پیوند دهید و یک حل‌کننده توزیع کنید
دو شرط باید هم‌زمان برقرار باشند. ناحیهٔ خصوصی باید به شبکهٔ مجازی که نقطهٔ پایانی در آن زندگی می‌کند پیوند شود و کارخواه باید پرس‌وجوهایش را به کارسازی بفرستد که بتواند آن ناحیه را بخواند. یک نقطهٔ پایانی ورودی DNS Private Resolver چنین نشانی‌ای درون شبکه فراهم می‌کند و به پرس‌وجوهایی که از تونل می‌رسند پاسخ می‌دهد. آن نشانی را در نمایهٔ VPN بگذارید و پسوند خصوصی را که کارخواه باید اعمال کند اضافه کنید.
یک حل‌کنندهٔ محلی که از قبل وجود دارد می‌تواند از طریق یک فرستندهٔ شرطی که به ناحیه نشانه رفته است به همان نتیجه برسد.
قواعد شبکه روی حل‌کننده به اندازهٔ مسیریابی اهمیت دارند. اگر قاعدهٔ ورودی بازهٔ کارخواهان VPN را کنار بگذارد، پرس‌وجوها به‌جای برگرداندن پاسخ نادرست منقضی می‌شوند. همین انقضا است که مردم را به جدول مسیری برمی‌گرداند که هیچ ایرادی در آن نیست.
نام، درگاه و هویت را به ترتیب بررسی کنید
به ترتیب کار کنید: نام را تحلیل کنید، تأیید کنید که پاسخ خصوصی است، درگاه را باز کنید، سپس یک درخواست احراز هویت‌شده انجام دهید. هر مرحله صاحب خود و اثر انگشت شکست خود را دارد.
پاسخ خصوصی که پس از آن انقضا می‌آید به یک مسیر یا دیوار آتش اشاره دارد. پاسخ عمومی به حل‌کننده اشاره دارد. اتصال کاملی که خطای هویت برمی‌گرداند متعلق به سرویس است.
یک شکست دیگر هم به این فهرست تعلق دارد. دیوار آتش سرویسی که یک نشانی کارخواه را مجاز می‌کند وقتی استخر آن نشانی را پس از اتصال دوباره به نشست دیگری می‌دهد، دیگر منطبق نمی‌شود. نشانی فراخواننده‌ای را بخوانید که سرویس ثبت کرده است، نه آن را که کارخواه فکر می‌کند دارد. این دو بیشتر از آنچه مردم انتظار دارند با هم اختلاف دارند. راهنمای Azure DNS Private Resolver پیوند ناحیه و چیدمان فرستادن را پوشش می‌دهد.