نام میزبان LAN از طریق VPN کار نمیکند: پسوند، mDNS یا ناحیه؟
یک نام کوتاه ممکن است به پسوند جستجو تکیه کند، نام .local به چندپخشی و نام شرکت به یک ناحیه خصوصی. مسیر بهتنهایی هیچ سرویس نامگذاری ارائه نمیدهد.
کنار دستگاه، چاپگر به یک نام کوتاه پاسخ میدهد و سرور فایل به یک لقب. از طریق تونل، هر دو نام منقضی میشوند در حالی که نشانیهایشان همچنان کار میکند. مسیر کار خود را انجام میدهد؛ مسیر نامگذاری که آن نامهای کوتاه را کار میانداخت هرگز از تونل عبور نکرد. سه سازوکار این رفتار را ایجاد میکنند و هر یک به اصلاح متفاوتی نیاز دارد.
با تعیین اینکه نام به کدام سازوکار وابسته است شروع کنید.
سه نوع نام که رفتار متفاوتی دارند
یک نام تکبرچسبی مانند fileserver معمولاً به پسوند جستجوی DNS که حلکننده اضافه میکند تکیه دارد. این پسوند اغلب همراه اجاره DHCP محلی میآید، بنابراین کارگیر دوری که نشانیدهی را از VPN میگیرد دلیلی برای دانستن آن ندارد. افزودن مسیر پسوند را تحویل نمیدهد. نام کوتاه بهسادگی بهعنوان نام از بین میرود، حتی اگر نشانی پشت آن قابل دسترسی باشد.
نامی که به .local ختم میشود معمولاً با DNS چندپخشی روی پیوند محلی حل میشود، همانطور که RFC 6762 توصیف میکند. چندپخشی از تونل مسیریابیشده عبور نمیکند مگر اینکه چیزی آگاهانه آن را پل یا نمایندگی کند، بنابراین نام در لحظهای که بخش را ترک میکنید دیگر حل نمیشود.
نام کاملاً واجد شرایط شرکت به ناحیه داخلی که حلکنندههای سازمان آن را سرویس میدهند تعلق دارد. آن یکی از راه دور کار میکند وقتی VPN آن حلکنندهها را هل میدهد و کارگیر برای استفاده از آنها پیکربندی شده است. و localhost طبق RFC 6761 کاربرد ویژه دارد: به دستگاهی که پیش روی شماست اشاره میکند، هرگز به سرویس دور.
حلکننده را پیش از تغییر مسیر بخوانید
بپرسید کدام کارساز نام پاسخ داد و کدام پسوند افزوده شد. همان پرسش از طریق حلکنندههای مختلف پاسخهای متفاوتی میدهد و همین تفاوت شاهدی است که نیاز دارید.
getent hosts fileserver getent hosts fileserver.corp.example.com nslookup fileserver.corp.example.com dig +search fileserver A resolvectl query fileserver.corp.example.com scutil --dns | head -30
اگر پرسش کاملاً واجد شرایط حل شود اما کوتاه نه، خطا در پسوند است نه در کارساز. اگر هیچکدام حل نشود و نشانی کار کند، کارگیر اصلاً از حلکننده داخلی استفاده نمیکند. فهرست حلکنندهها را با آنچه VPN باید هل دهد مقایسه کنید، زیرا کارگیری که حلکننده محلی خود را برای هر پرسش نگه میدارد هرگز ناحیه داخلی را نخواهد دید.
نام درست را به کارگیر برسانید
نام مستند دسترسی از راه دور را بهطور کامل از مدیر بخواهید و بهجای حدس زدن پسوندها از آن در نمایه استفاده کنید. اگر استقرار از split DNS پشتیبانی میکند، دامنه داخلی را طوری پیکربندی کنید که توسط کارسازهای داخلی حل شود و بقیه چیزها حلکننده محلی را نگه دارند. دامنه جستجو را از طریق پیکربندی VPN در جایی که کارگیر پشتیبانی میکند هل دهید.
نتیجه را روی کارگیر بررسی کنید نه روی دروازه. تنظیمی که روی کارساز اعمال شود و هرگز به کارگیر نرسد چیزی را تغییر نمیدهد.
هویت گواهی را دستنخورده نگه دارید
آزمون مبتنی بر نشانی که خطای گواهی را نادیده میگیرد فقط اثبات میکند که سوکت باز شد. گواهی سرویس برای یک نام صادر شده است و کارگیر بهدرستی به رد ناسازگاری ادامه خواهد داد. اگر گواهی فقط نام داخلی را فهرست کند، از همان نام استفاده کنید و حل را درست کنید، یا گواهیای بگیرید که نشانی مورد نظر شما را پوشش دهد.
نام، حلکننده و پسوندی را که اتصال موفق ایجاد کردند ثبت کنید. آن ثبت شخص بعدی را از تکرار راهحل موقت مبتنی بر نشانی که مشکل واقعی را پنهان میکند نجات میدهد.