GVC در Acquiring IP گیر می‌کند: این مشکل رمز عبور نیست

Global VPN Client روی Acquiring IP می‌ماند و واکنش اول این است که رمز عبور را دوباره بنویسید یا سرویس‌گیر را از نو نصب کنید. هیچ‌کدام به مرحله‌ای که شکست خورده دست نمی‌زنند. احراز هویت پیش از آنکه سرویس‌گیر اصلاً نشانی بخواهد تمام شده بود، پس این اطلاعات ورود نیست که شما را روی آن خط نگه می‌دارد. آنچه شما را آنجا نگه می‌دارد تبادل DHCP ناتمامی است و می‌تواند در سه جای مختلف گیر کند.

احراز هویت و تخصیص نشانی دو مرحله جدا هستند

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

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

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

اجاره در واقع از کجا می‌آید

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

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

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

تونل می‌تواند برپا باشد و باز هم اجاره را از دست بدهد

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

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

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

مسیر اجاره را به ترتیب بپیمایید

از آداپتور شروع کنید و به بیرون بروید، تا هر گام فقط به یک دلیل شکست بخورد:

> Get-NetAdapter | Where-Object Name -like "*GVC*"
> ipconfig /all | findstr /i /c:"GVC" /c:"IPv4" /c:"DHCP"
> Test-NetConnection 10.60.0.1 -Port 443

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

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

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