VPN از سایت به سایت Azure متصل است اما ترافیکی نیست: گزارش IKE را بخوانید

پورتال می‌گوید Connected، تونل یک شمارنده زمان کار دارد، و یک trace از ماشین مجازی شما در دومین hop می‌میرد. وضعیت اتصال، مذاکره IKE و IPsec را توصیف می‌کند، نه اینکه آیا یک بسته از لایه خط‌مشی در هر طرف جان سالم به در می‌برد. دو خطا بیشتر این تیکت‌ها را توضیح می‌دهد و هیچ‌کدام با تغییر یک مسیر در Azure اصلاح نمی‌شود. هر دو از قبل در گزارشی نوشته شده‌اند که دروازه تولید کرده است، به همین دلیل از آنجا شروع می‌کنم نه از جدول مسیرها.

Connected در واقع چه چیزی را تأیید می‌کند

یک اتصال سایت به سایت متصل یعنی فاز 1 و فاز 2 کامل شده‌اند و انجمن‌های امنیتی برپا هستند. این سخنی درباره مذاکره است: هر دو طرف بر یک پیشنهاد توافق کردند، کلیدها را مبادله کردند و جفت SA را نصب کردند. این چیزی درباره اینکه آیا انتخابگرهای ترافیک با زیرشبکه‌هایی که فکر می‌کنید محافظت‌شده‌اند مطابقت دارند نمی‌گوید، و نه درباره اینکه آیا طرف دور پس از رمزگشایی بسته را جایی مسیریابی می‌کند. یک تونل می‌تواند هفته‌ها برپا بماند در حالی که هر جریان مهمی را دور می‌ریزد، و این دقیقاً همان الگویی است که مردم را وادار می‌کند یک دروازه سالم را از نو بسازند.

دو خطایی که ارزش دارد اول بررسی شوند عبارت‌اند از همتایی که به جای ESP پیشنهاد AH می‌دهد، و یک شبکه مجازی که در فضایی شماره‌گذاری شده که دروازه آن را داخلی نمی‌داند.

پیش از دست زدن به مسیرها، گزارش صادرشده را باز کنید

در پورتال، دروازه شبکه مجازی را باز کنید و عملیات VPN troubleshoot را روی اتصال اجرا کنید، سپس بسته‌ای را که تولید می‌کند دانلود و از حالت فشرده خارج کنید. درون آن گزارشی از IKE با تبادل‌های فاز 1 و فاز 2 است، با مهر زمانی و خوانا به‌صورت متن ساده. در آن به دنبال خط transform بگردید نه اینکه از بالا به پایین بخوانید، چون مدخل مهم معمولاً چند صد خط پایین‌تر است. اگر به پورتال دسترسی ندارید، همان تشخیص‌ها وقتی تنظیمات تشخیصی فعال باشد در مقصد گزارش دروازه ظاهر می‌شوند.

دو مدخل بیشترین ارزش را دارند. اولی چیزی شبیه به این است: expected ESP with combined authentication and cipher, received AH. دومی خطای payload نامعتبر در جریان تبادل IKE است، که معمولاً یعنی یک فیلد پیشنهاد بدشکل یا پشتیبانی‌نشده.

هر دو توصیف می‌کنند که دستگاه داخلی چه چیزی پیشنهاد داده، پس هر دو تنظیماتی در سمت همتا هستند. بازتولید سمت Azure اتصال، پیشنهادی را که فایروال شما می‌فرستد تغییر نمی‌دهد، و انجام دادنش با این حال رایج‌ترین ساعت تلف‌شده در این فرایند است. روی همتا، فاز 2 را روی ESP با احراز هویت و رمزنگاری ترکیبی بگذارید و بگذارید الگوریتم را مذاکره کند، بعد بررسی کنید آیا یک چک‌باکس فروشنده با نامی مثل combined mode بی‌صدا یک پیشنهاد AH زیرش انتخاب می‌کند یا نه.

فضای آدرس شبکه مجازی را تأیید کنید

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

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

پیشوندها را در هر دو جهت بررسی کنید

منبع دروازه شبکه داخلی پیشوندهای داخلی را نگه می‌دارد و آن‌ها باید با زیرشبکه‌هایی که دستگاه دور واقعاً محافظت می‌کند مطابقت داشته باشند. خلاصه‌ای که نشانی‌هایی را دربر بگیرد که دستگاه دور می‌ریزد، برخی جریان‌ها را عبور می‌دهد و در برخی دیگر شکست می‌خورد، و این مانند یک خطای مسیریابی متناوب خوانده می‌شود نه یک ناسازگاری پیکربندی. طرف دور را هم بررسی کنید: یک سر /16 فهرست کند در حالی که سر دیگر سه /24 درون آن فهرست کند — این همان شکست جزئی کلاسیک است. هیچ‌کدام از فهرست‌ها به‌تنهایی معتبر نیست، پس آن‌ها را کنار هم مقایسه کنید نه اینکه به آن یکی که می‌بینید اعتماد کنید.

تغییر پیشوند همیشه خودبه‌خود برداشته نمی‌شود، پس برای ذخیره دوباره یا بازسازی شیء اتصال برنامه بریزید و سپس تأیید کنید پیشوندهای جدید در هر دو طرف ظاهر می‌شوند.

یک مسیر را آزمایش کنید، نه یک ping

trace‌ای که تونل کارکننده را از مسیر کارکننده جدا می‌کند چنین است: اولین hop دروازه داخلی است، سپس چند hop بی‌پاسخ، سپس میزبان دور پاسخ می‌دهد. اگر trace هرگز به میزبان نرسد، پورت TCP را که برنامه واقعاً استفاده می‌کند آزمایش کنید، چون ICMP به‌قدر کافی فیلتر می‌شود که یک ping ناموفق چیز بسیار کمی را ثابت می‌کند. همان trace را از یک میزبان دور به سوی یک ماشین مجازی در Azure اجرا کنید. ناقرینگی میان دو نتیجه سریع‌ترین راه برای یافتن یک مسیر بازگشت گم‌شده یا قاعده‌ای است که فقط یک جهت را مجاز می‌کند.

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

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