گیر کردن کلاینت جدید هات‌اسپات روی دریافت IP خطای VPN نیست
اتصال، اجارهٔ DHCP محلی و ارسال به جلو سه مرحله‌اند. دستگاهی که روی دریافت نشانی گیر کرده هرگز به VPN نرسیده است، پس ویرایش DNS را متوقف کنید.
تلفن به هات‌اسپات می‌پیوندد، روی «در حال دریافت نشانی IP» می‌ماند و سرانجام رها می‌کند. نتیجهٔ طبیعی این است که VPN تلفن با DNS تداخل دارد، پس افراد شروع می‌کنند به ویرایش ریزولورها و قواعد افزوده. این مرحلهٔ اشتباه است. کلاینت هرگز نشانی محلی دریافت نکرد، و بدون آن نه دروازه‌ای دارد، نه ریزولوری و نه چیزی برای ارسال، بنابراین هیچ تنظیم VPN روی تلفن میزبان نمی‌تواند این شکست را توضیح دهد. اتصال، تخصیص نشانی محلی و ارسال به جلو سه مرحلهٔ جدا هستند و تنها مرحلهٔ آخر تونل را درگیر می‌کند.
سه مرحله، و اینکه در کدام‌اید
نخست اتصال می‌آید: کلاینت به شبکهٔ بی‌سیم هات‌اسپات می‌پیوندد. گذرواژهٔ نادرست، ناسازگاری WPA3 یا مشکل سازگاری رادیویی اینجا شکست می‌خورند و کلاینت معمولاً همین را می‌گوید. دوم تخصیص نشانی می‌آید: برای IPv4 کلاینت درخواست اجاره می‌کند و نشانی به‌همراه تنظیمات دروازهٔ محلی می‌گیرد، در حالی که IPv6 معمولاً به‌جای DHCP از اعلان‌های مسیریاب استفاده می‌کند، همان‌گونه که مستندات tethering در AOSP توصیف می‌کند. سوم دسترسی به بیرون می‌آید: تلفن میزبان ترافیک مجاز را به هر مسیر بالادستی که برگزیده ارسال می‌کند، که ممکن است تونل آن باشد یا نباشد.
عبارت‌بندی روی کلاینت مرحله را به شما می‌گوید. گیر کردن روی دریافت نشانی مرحلهٔ دوم است، پیش از آنکه بسته‌ای به اینترنت برود. متصل، با نشانی، اما هیچ چیز بارگذاری نمی‌شود مرحلهٔ سوم است، جایی که مسیریابی، نام‌ها و پوشش تونل همه مهم‌اند. تشخیص مرحلهٔ سوم در حالی که کلاینت در مرحلهٔ دوم گیر کرده همان چیزی است که یک مشکل اجارهٔ پنج‌دقیقه‌ای را به یک بعدازظهر ویرایش DNS تبدیل می‌کند.
افسانه: VPN مسیریابی‌شده DHCP محلی را به درخواست دوردست تبدیل می‌کند
تونل مسیریابی‌شده بسته‌های IP را برای مقصدهایی که برمی‌گزیند جابه‌جا می‌کند. کشف DHCP پخشی در بخش خودِ هات‌اسپات است و سرویس tethering روی تلفن به‌صورت محلی پاسخ می‌دهد، به همین دلیل کلاینت می‌تواند هنگامی که تونل بالاست نشانی بگیرد. تنها طراحی عمداً پل‌شده یا بازپخش‌شده آن تبادل را جای دیگری می‌فرستد، و آن چیدمان دیگری با امضای شکست دیگری است.
پس «سرور VPN به DHCP پاسخ نمی‌دهد» تشخیص نیست، خطای مدل است. واسط محلی روی تلفن است. اگر پاسخ‌دادن را متوقف کند، دلایل محلی‌اند: سرویس tethering، سقف کلاینت‌ها، استخر اجاره یا کلاینتی که هرگز اتصال را درست کامل نکرد. هیچ‌کدام از این‌ها در سمت دور تونل زندگی نمی‌کنند.
کار کردن یک کلاینت موجود در واقع چه چیزی را اثبات می‌کند
اگر لپ‌تاپی که پیش‌تر متصل بوده هنوز کار کند و تلفن جدید نه، هات‌اسپات و مسیر بالادستی به‌طور کلی زنده‌اند. این مقایسه سودمند است و اثبات این نیست که کدام مؤلفه مقصر است، چون کلاینت کارکننده ممکن است صرفاً اجاره‌ای از پیش از تغییر را نگه دارد و بی‌صدا تمدیدش کند.
دو محدودیت محلی ارزش بررسی دارند تا آنجا هستید. هات‌اسپات استخر اجارهٔ محدود و سقف کلاینت قابل‌تنظیم ارائه می‌دهد، بنابراین دستگاهی که پیوسته و خوابیده می‌تواند نشانی را نگه دارد در حالی که دستگاه تازه منتظر است. و کلاینتی که پیکربندی ایستا از شبکهٔ دیگری را به یاد دارد اصلاً درخواست اجاره نمی‌کند، که از بیرون یکسان به نظر می‌رسد و در کلاینت اصلاح می‌شود، نه روی تلفن.
مقایسه را محلی و بازگشت‌پذیر نگه دارید
روی دستگاهی که سیاست اجازه می‌دهد، یک پیوستن کلاینت جدید را با تونل غیرفعال و سپس فعال مقایسه کنید و هات‌اسپات و کلاینت را در بقیهٔ موارد بی‌تغییر نگه دارید. نسخه‌های تلفن و کلاینت، پروفایل برگزیده و مرحلهٔ دقیقی که شکست خورد را ثبت کنید. روی تلفن مدیریت‌شده، به‌جای غیرفعال‌کردن اجرا برای آزمون پاک‌تر، مقایسهٔ تأییدشده را درخواست کنید.
شکست پیوستهٔ اجاره که به تونل وابسته است شواهد سودمندی دربارهٔ سیاست محلی یا تعامل پیاده‌سازی است. مجوز پاک‌کردن هر قاعدهٔ ارسال و NAT روی دستگاه نیست. آن قواعد ترافیک نامرتبط را محافظت می‌کنند و پذیرش گستردهٔ ارسال توضیح نمی‌دهد چرا یک سرویس DHCP محلی پاسخ‌دادن را متوقف کرد.
اجارهٔ گمشده را هم با نشانی ایستای حدسی نپوشانید. پیکربندی ایستای عمدی به زیرشبکهٔ واقعی، دروازه، طرح تخصیص و بررسی تعارض نیاز دارد. تغییر DNS کلاینت هیچ‌یک از این‌ها را فراهم نمی‌کند و دستگاه بعدی را با همان شکست رها می‌کند.
اجاره چه چیزی را اثبات نمی‌کند
گرفتن نشانی پذیرش در شبکهٔ محلی را اثبات می‌کند، نه محافظت با تونل تلفن. وقتی کلاینت اجاره دارد، مسیر پایین‌دست را جداگانه ارزیابی کنید: آیا ترافیک کلاینت واقعاً از تلفن عبور می‌کند، آیا جست‌وجوها همان‌جا که انتظار دارید حل می‌شوند، و آیا نشانی بیرونی با خروجی موردنظر شما می‌خواند؟ این‌ها پرسش‌های مرحلهٔ سوم‌اند و آزمون خودشان را می‌طلبند نه اینکه در پیوستن تا شوند.
مراحل را به ترتیب کار کنید تا شکست از جابه‌جاشدن بایستد. کلاینت گیرکرده روی دریافت نشانی یک پرسش محلی tethering است؛ کلاینت با نشانی و بدون صفحه یک پرسش ارسال یا نام‌گذاری است؛ کلاینت با صفحه و خروجی نادرست یک پرسش پوشش تونل است. جدا نگه‌داشتن این‌ها بیشتر اشکال‌زدایی است.