دو لپ‌تاپ به یک دروازهٔ Azure point-to-site احراز هویت می‌کنند و فقط یکی به VNet تازه متصل‌شده می‌رسد. هر دو Connected نشان می‌دهند، پس احراز هویت تفاوت نیست؛ مسیرهای مقصدی که نگه می‌دارند تفاوت است. از کلاینتی که شکست می‌خورد شروع کنید، یک مقصد را مقایسه کنید و تنها پس از آن تصمیم بگیرید که شکاف به بستهٔ دروازه تعلق دارد یا به جدول مسیر محلی.

از کلاینتی که شکست می‌خورد شروع کنید، نه از دروازه

پیش از سرزنش لپ‌تاپ، توپولوژی را تأیید کنید. بررسی کنید کدام VNet‌ها به VNet دروازه متصل‌اند و شبکهٔ جدید مستقیماً peered است یا از طریق تونل جداگانهٔ site-to-site به آن می‌رسند. اگر VNet جدید اصلاً به VNet دروازه متصل نباشد، هیچ بستهٔ کلاینتی نمی‌تواند به آن مسیر یابد و لپ‌تاپ سالم همان ناهنجاری است که باید توضیح داده شود. پاسخ را بنویسید، چون تعیین می‌کند کلاینت را عیب‌یابی می‌کنید یا دروازه را.

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

یک مقصد را با route print مقایسه کنید

یک IP مجاز منبع انتخاب کنید و هر دو لپ‌تاپ را دو بار مقایسه کنید: قطع‌شده و سپس متصل. در ویندوز، route print -4 مسیرهای IPv4 را با پیشوند مقصد، رابط، گام بعدی و متریک فهرست می‌کند. سطری را ثبت کنید که واقعاً برای آن مقصد برنده می‌شود، نه اینکه ورودی‌های حاوی واژهٔ VPN را بشمارید.

انتخاب نخست بر پایهٔ بلندترین پیشوند و سپس متریک است، پس یک مسیر محلی خاص‌تر می‌تواند بدون اینکه اشتباه به نظر برسد بر مسیر تونل پیروز شود. اگر مقصد موردنظر درون 10.24.0.0/16 باشد، کلاینت سالم مسیر منطبقی روی رابط VPN نشان می‌دهد، در حالی که کلاینت شکست‌خورده همان نشانی را به دروازهٔ پیش‌فرض خود می‌فرستد.

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

TTL expired یک باگ توزیع مسیر نیست

پینگی که TTL expired in transit برمی‌گرداند می‌گوید بسته سهمیهٔ گام‌هایش را تمام کرده، که معمولاً یعنی حلقهٔ ارسال، نه درایور VPN خراب. پینگ ویندوز TTL تا 255 را می‌پذیرد و بالا بردن مقدار حلقه را تعمیر نمی‌کند؛ فقط همان خطا را به تعویق می‌اندازد. پیام را نشانهٔ مسیر بدانید، نه مدرکی دربارهٔ توزیع مسیر.

از tracert -4 10.24.1.10 استفاده کنید تا ببینید مسیر کجا تکرار می‌شود. اگر همان دو گام بارها و بارها ظاهر شوند، مسیری را بجویید که ترافیک متوجه به تونل را به تونل یا به مسیریاب محلی‌ای که آن را بازمی‌فرستد برمی‌گرداند.

بسته را روی همان دروازه‌ای که مالک آن است دوباره بسازید

مایکروسافت مستند می‌کند که بسته‌های کلاینت ویندوز باید پس از تغییرات توپولوژیکی مرتبط دوباره بارگیری و نصب شوند. بستهٔ کنونی را از دروازهٔ Azure که این پروفایل را سرویس می‌دهد بگیرید و سپس آن را با فرایند پشتیبانی‌شده برای آن کلاینت اعمال کنید. جایگزین‌کردن فایل اجرایی یک برنامهٔ VPN نامرتبط همان عملیات بازسازی تنظیمات مخصوص دروازه نیست. بارگیری دوبارهٔ بسته ارزان است؛ حدس‌زدن دربارهٔ مسیرهای محلی نیست.

دوباره متصل شوید و مسیر مقصد اصلی را بازخوانی کنید. سطرهای پیش و پس را همراه با سابقهٔ تغییر نگه دارید تا نتیجه دقیق‌تر از «کلاینت را دوباره نصب کردم» باشد.

سناریوهای مسیریابی Azure P2S VNet‌های مستقیماً peered را از شبکه‌هایی که از تونل‌های دیگر می‌آیند جدا می‌کنند و بستهٔ جدید نمی‌تواند peering را گذرا کند. برخی سناریوهای Windows site-to-site یا BGP هم به مسیرهای راه دور دستی نیاز دارند، پس تازه‌سازی بسته یک سازوکار جهانی توزیع مسیر نیست.

مسیر موقت را موقت نگه دارید

یک مسیر دستی می‌تواند مسیر گمشدهٔ کلاینت را جدا کند، اما آن را از طراحی واقعی بسازید: route add 10.24.0.0 mask 255.255.0.0 172.16.0.1 if 42، بدون پرچم ماندگار، تا هنگام راه‌اندازی مجدد ناپدید شود. شاخص رابط و گام بعدی را از آداپتور VPN متصل انتخاب کنید، نه از حدس.

مسیر آزمایشی را به‌عنوان مالک رقیب دائمی رها نکنید. به‌روزرسانی‌های آیندهٔ پروفایل ممکن است همان پیشوند را با متریک متفاوت بیفزایند و آنگاه ورودی دستی بی‌صدا تعیین می‌کند کدام مسیر برنده می‌شود. مرحلهٔ حذف را در تغییر ثبت کنید.

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

مقالات مرتبط