ویندوز تونل را متصل نشان می‌دهد و آن را بدون دسترسی به اینترنت برچسب می‌زند، که مردم آن را یک عجیب‌بودن ویندوز می‌خوانند. این یک گزاره درباره آن چیزی است که کلاینت دریافت کرده: هیچ دروازه پیش‌فرض قابل‌استفاده‌ای، هیچ حل‌کننده کارآمدی، و هیچ مسیر بازگشتی برای آدرس‌های داخل تونل. وقتی سرور یک Incoming Connection ویندوز است، یک تنظیم بیشتر این گزارش‌ها را توضیح می‌دهد. برچسب تشخیص نیست، اما جست‌وجو را به سه جا محدود می‌کند.

پیش از تغییر، اجاره را بخوانید

روی کلاینت ipconfig /all را اجرا کنید و آداپتور VPN را میان ورودی‌ها بیابید. آدرس، دروازه پیش‌فرض و سرور DNS که فهرست می‌کند همان واقعیت‌هایی هستند که لازم دارید، و اغلب با آنچه مدیر فرض می‌کند تحویل داده شده تفاوت دارند.

سه الگو به سه خطا نگاشت می‌شوند. آدرسی در 169.254.0.0/16 یعنی کلاینت هیچ چیزی دریافت نکرده و خودش به خودش یک آدرس محلی پیوند داده است. آدرس باورپذیر بدون دروازه یعنی مجموعه بدون گزینه‌ای که مسیر پیش‌فرض را به کلاینت بدهد ارائه شده است. اجاره کامل که هنوز به هیچ‌جا نمی‌رسد به ارسال یا ترجمه در سمت سرور اشاره دارد.

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

چرا تخصیص خودکار می‌تواند بدون دروازه رها کند

ورودی Incoming Connections ویژگی‌های IPv4 خودش را دارد، جدا از آداپتور فیزیکی. پیش‌فرض آنجا پیشنهاد تخصیص خودکار آدرس‌ها را می‌دهد که بر توزیع‌کننده درونی اتصال برای تأمین آدرس، ماسک، دروازه و DNS تکیه می‌کند.

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

به همین دلیل جابه‌جایی به یک محدوده مشخص بسیاری از این گزارش‌ها را درست می‌کند. از خواستن از سرویسی که ممکن است اجرا نشود برای اختراع یک اجاره دست می‌کشید و خودتان اجاره را اعلام می‌کنید.

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

محدوده صریحی تعیین کنید که سرور بتواند مسیریابی کند

بلوک کوچکی داخل زیرشبکه‌ای که سرور می‌تواند به آن برسد، بیرون از محدوده‌ای که روتر LAN توزیع می‌کند و بیرون از هر مجموعه دیگری در شبکه انتخاب کنید. اگر سرور روی 172.20.10.0/24 باشد و روتر 172.20.10.1 را نگه دارد، بلوک کوتاهی نزدیک بالای آن زیرشبکه، مثلاً از 172.20.10.201 تا 172.20.10.209، اجاره‌های تونل را از توزیعی که روتر از قبل مدیریت می‌کند دور نگه می‌دارد.

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

این دستورها پیکربندی حاصل و مسیرهایی را که کلاینت اکنون دارد چاپ می‌کنند:

ipconfig /all
route print -4
Get-NetIPConfiguration -InterfaceAlias \"Incoming Connection\"

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

آدرس مسیری به اینترنت نیست

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

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

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

ابتدا مسیر بیرونی را کنار بگذارید

هیچ مجموعه‌ای کمکی نمی‌کند اگر تونل هرگز شکل نگیرد. پروتکل تعیین می‌کند مسیر چه چیزی باید حمل کند: PPTP به TCP 1723 و GRE نیاز دارد، که پروتکل IP 47 است نه یک پورت؛ L2TP/IPsec به UDP 1701 به‌علاوه 500 و 4500 نیاز دارد؛ SSTP به TCP 443 نیاز دارد.

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

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

مقالات مرتبط