نام‌های میزبان VPN شکست می‌خورند، نشانی‌های IP کار می‌کنند: کجا را ببینیم

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

نام پرسشی می‌پرسد که نشانی نمی‌پرسد

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

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

تحلیل‌گری را بخوانید که تونل واقعاً نصب کرده است

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

resolvectl status
nslookup fileserver.corp.example
nslookup fileserver

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

Get-DnsClientNrptPolicy
ipconfig /all

اگر منطقه داخلی از طریق سرور درست تحلیل می‌شود، توقف کنید. تحلیل‌گر مشکل شما نیست.

پسوندها نام‌های کوتاه شکست‌خورده را توضیح می‌دهند

نام تک‌برچسبی پیش از فرستادن پرس‌وجو با فهرست پسوندهای اتصال گسترش می‌یابد. اگر VPN پسوند داخلی را تحویل ندهد، fileserver هرگز به fileserver.corp.example تبدیل نمی‌شود و پرس‌وجو به‌صورت نامی بیرون می‌رود که هیچ تحلیل‌گر عمومی آن را نمی‌شناسد. تحمیل پسوند، یا تایپ نام کامل، فرضیه را بدون تغییر چیزی روی سرور می‌آزماید.

nslookup fileserver.corp.example
ping -a 192.168.50.20

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

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

NetBIOS و WINS سازوکاری دیگرند

SMB قدیمی هنوز می‌تواند نام خالی را با سرویس نام NetBIOS جست‌وجو کند که از طریق پخش همگانی یا از طریق سرور WINS پاسخ می‌دهد. پخش همگانی درون یک دامنه پخش می‌ماند و در نخستین مسیریاب متوقف می‌شود، پس نمی‌تواند از یک تونل عبور کند؛ WINS کار می‌کند چون کارخواه نشانی یک‌پخشی برای ثبت و پرسیدن دارد. به همین دلیل VPNی که تنها IP را حمل می‌کند هنوز می‌تواند نام‌های قدیمی را پشتیبانی کند وقتی WINS پیکربندی شده و در دسترس است.

nbtstat -n
nbtstat -R

برای SMB مدرن، به DNS و نام کامل تکیه کنید و مسیر قدیمی را بازنشسته کنید. اگر واقعاً قدیمی است، WINS فراهم کنید یا برنامه را جایگزین کنید؛ راه میانه صف پشتیبانی‌ای است که هرگز خالی نمی‌شود.

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