چرا یک مسیر گسترده VPN چند سایت عمومی را خراب می‌کند
چند سایت از کار می‌افتند در حالی که بقیه بارگذاری می‌شوند، چون یک پیشوند گسترده آدرس‌های آن‌ها را می‌گیرد. مسیر را با آدرس حل‌شده مطابقت دهید و سپس پیدا کنید چه کسی آن را نصب می‌کند.
بیشتر صفحه‌ها بارگذاری می‌شوند، دو یا سه تا از مهلت می‌گذرند و مرورگر اتصال را سرزنش می‌کند. سایت‌هایی که از کار می‌افتند چیزی مشترک دارند که سایت‌های سالم ندارند: آدرس‌های حل‌شده آن‌ها درون پیشوندی می‌افتد که VPN نصب کرده است. مسیری که به اندازه کافی گسترده باشد تا یک محدوده عمومی را بپوشاند، ترافیکی را می‌گیرد که تونل هرگز قرار نبود حمل کند، و نشانه مانند مشکل یک وب‌سایت به نظر می‌رسد نه تصمیم مسیریابی.
نامی را که از کار می‌افتد حل کنید، سپس به جدول مسیریابی نگاه کنید نه به مرورگر.
آدرس را مقایسه کنید، نه نام وب‌سایت را
آدرسی را که مشتری واقعاً امتحان کرده جستجو کنید، سپس بررسی کنید کدام مسیر با آن مطابقت دارد. مقصدی درون 45.61.20.10 زیر 45.0.0.0/8 قرار می‌گیرد اگر آن پیشوند حاضر باشد، حتی اگر خود وب‌سایت هیچ ارتباطی با تونل نداشته باشد. مقایسه آدرس از کار افتاده با پیشوندهای نصب‌شده یک مسئله تفریق است، نه حدس.
ویندوز می‌تواند به هر دو نیمه مستقیم پاسخ دهد، و یک جستجو نشان می‌دهد کدام رابط و کدام گام بعدی انتخاب را برده‌اند. اگر سایت چند آدرس برمی‌گرداند، نام را دو بار حل کنید. هر یک را همراه با مسیری که مطابقت داشت یادداشت کنید. آدرس‌های مختلف می‌توانند پاسخ‌های مختلف بدهند و فقط یکی از آن‌ها ممکن است همان مورد از کار افتاده باشد.
Resolve-DnsName www.example.org Get-NetRoute -AddressFamily IPv4 | Select-Object DestinationPrefix,InterfaceIndex,NextHop,RouteMetric Find-NetRoute -RemoteIPAddress 45.61.20.10 Get-VpnConnection | Format-List Name,SplitTunneling,Routes
دقیق‌ترین پیشوند منطبق را بخوانید، نه اولین خطی که آشنا به نظر می‌رسد. مسیری که در جدول هست ثابت نمی‌کند که جستجو را برده است؛ تطابق طولانی‌تر این کار را می‌کند. دو پیشوند می‌توانند با یک آدرس مطابقت کنند و فقط یکی از آن‌ها بسته را دریافت می‌کند. بازنده در جدول می‌ماند و در یک فهرست هم به همان اندازه واقعی به نظر می‌رسد.
پیشوند، رابط آن و آدرس حل‌شده را بنویسید. این سه مقدار تمام تشخیص هستند.
پیدا کنید چه کسی مسیر را نصب کرده است
مسیرها از چهار جا می‌آیند: پروفایل بومی VPN، یک سیاست مدیریت، یک اسکریپت اتصال یا مشتری کاملاً دیگری. حذف ورودی فعال می‌تواند اهمیت آن را تأیید کند، اما اتصال بعدی آن را از پیکربندی ذخیره‌شده دوباره می‌سازد، پس منبع چیزی است که باید تغییر کند.
اول فهرست مسیرهای پروفایل را بررسی کنید، سپس سیاست مدیریت، سپس هر اسکریپتی که هنگام اتصال اجرا می‌شود. این ترتیب با اینکه هر کدام چند وقت یک بار مسئول است مطابقت دارد. همچنین تغییر را در یک لایه نگه می‌دارد نه سه لایه.
رفتار بومی مبتنی بر کلاس را با دقت بخوانید
پروفایل‌های بومی ویندوز تنظیم مستندی دارند، NativeProfile/DisableClassBasedDefaultRoute، که یک مسیر خودکار استنباط‌شده از آدرس رابط را کنترل می‌کند. یک آدرس پروفایل که با 45 شروع شود می‌تواند تحت آن رفتار یک ورودی 45.0.0.0/8 تولید کند، و اینگونه است که یک آدرس عمومی تنها کل یک محدوده کلاس A را می‌گیرد.
نام این ویژگی خوانش نادرست را دعوت می‌کند: تنظیم آن روی true استنباط را غیرفعال می‌کند و false آن را فعال می‌کند. همچنین همان شیء مسیر پیش‌فرض نیست و مشتریان شخص ثالث را که پیشوندهای خودشان را نصب می‌کنند کنترل نمی‌کند.
اگر استنباط علت اثبات‌شده است، پروفایل را از طریق مالک مدیریت آن اصلاح کنید و پیشوندهای خصوصی مورد نظر را صریحاً فراهم کنید. اگر اسکریپتی ورودی را اضافه کرده، اسکریپت را تعمیر کنید. جایگزینی یک مسیر گسترده توضیح‌نشده با دیگری نشانه را عوض می‌کند بی‌آنکه به پرسش پاسخ دهد.
منبع را تعمیر کنید، سپس هر دو مسیر را دوباره بررسی کنید
پس از تغییر، دوباره وصل شوید و جستجو را برای یک سایت عمومی از کار افتاده و برای منبعی که باید از تونل استفاده کند تکرار کنید. اولی باید اکنون به رابط فیزیکی حل شود و دومی باید هنوز VPN را انتخاب کند. در اولین موفقیت متوقف نشوید؛ اصلاحی که دسترسی خصوصی را هم خراب می‌کند یک خطا را با دیگری عوض کرده است.
در همان زمان طرح آدرس سرور را مرور کنید. استخری که با فضای عمومی همپوشانی دارد این دسته مشکل را بارها و بارها ایجاد می‌کند. محدوده‌ای که اپراتور عمداً انتخاب کرده شایسته گفتگویی دیگر است، نه شماره‌گذاری مجدد خودکار.
افزایش MTU یا پاک کردن DNS پیشوندی را که هنوز آن آدرس را به تونل می‌فرستد اصلاح نمی‌کند. اول انتخاب را آزمایش کنید، سپس مسیر را.