چرا پس از اتصال شماره‌گیری، نام یک سرور به نشانی VPN آن تبدیل می‌شود

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

دو نشانی، یک نام، سه شرط

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

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

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

پیش از تغییر ثبت‌کننده، رکورد را بخوانید

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

dig +short files.corp.example A
dig @10.20.0.10 +short files.corp.example A
Resolve-DnsName files.corp.example -Server 10.20.0.10 -Type A

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

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

منتشرکننده را اصلاح کنید یا رکورد را، اما بدانید کدام

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

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

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

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

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

ipconfig /flushdns
ipconfig /displaydns | findstr /i files.corp.example

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

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