ترافیک برگشتی Azure P2S VPN فقط در یک جهت کار میکند
تونل برقرار است، اما VM نمیتواند نشستی به سمت کلاینت آغاز کند. ابتدا جهت را آزمایش کنید، سپس نوع تونل IKEv2 و در پایان مرز broadcast.
آیکون تونل سبز است، NSG مجاز به نظر میرسد، مسیرهای مؤثر درست به نظر میرسند، و با این حال VM هنوز نمیتواند اتصالی به سمت کلاینت متصل باز کند. فرض معمول این است که یک تونل point-to-site سالم متقارن است: اگر کلاینت به VM برسد، VM هم به کلاینت میرسد. همین فرض، خطای استدلال است، نه خطای پیکربندی. یک تونل میتواند یک جهت از یک جریان ناخواسته را حمل کند و جهت دیگر را بیندازد، و اصلاح به این بستگی دارد که کدام لایه آن را میاندازد.
افسانه: تونل متصل، تونلی دوطرفه است
تونل VPN یک مسیر سیاستی است، نه یک سیم. هر جهت با انتخابگرها، مسیرها و فیلترها تطبیق داده میشود و هر یک از آنها میتواند یک جهت را مجاز کند و جهت دیگر را مسدود کند.
در عمل عدم تقارن آنقدر رایج است که جهت باید در نخستین آزمون باشد، نه آخرین. کلاینت آغاز میکند، دروازه جریان را ردیابی میکند و پاسخ از وضعیتی که ایجاد شده پیروی میکند. VMی که جریان تازهای آغاز میکند چنین وضعیتی ندارد، پس به این وابسته است که مسیر برگشت صراحتاً قابل مسیریابی و مجاز باشد. وقتی آن مسیر نباشد، تلاش برای اتصال پیش از آنکه هیچ برنامهای آن را ببیند از بین میرود.
پیش از آزمودن دسترسپذیری، جهت را آزمایش کنید
یک نشانی کلاینت، یک نشانی VM و یک پروتکل انتخاب کنید. از کلاینت متصل شوید و نتیجه را ثبت کنید؛ سپس همان آزمون را از VM آغاز کنید و آن را هم ثبت کنید. اگر اولی موفق و دومی ناموفق باشد، استخر کلاینت، پیوند دروازه و مسیر کلاینت به VNet همگی کار میکنند.
گام بعدی شواهد است، نه قوانین بیشتر. NSG روی زیرشبکه VM را در هر دو جهت بررسی کنید، مسیرهای مؤثر روی NIC دستگاه را بخوانید و هنگام ارسال ترافیک از کلاینت، بستهها را روی VM ضبط کنید. درخواستی که بدون پاسخ میرسد مشکل فیلتر یا مسیر برگشت است؛ درخواستی که هرگز نمیرسد مشکل مسیر است. ping ناموفق را دلیل دسترسناپذیری VM ندانید، زیرا سیاست ICMP میتواند پاسخ را بیندازد در حالی که TCP کار میکند.
مسیر برگشت IKEv2 point-to-site مظنون همیشگی است
در گزارش Azure که پشت این مقاله است، کلاینت میتوانست از طریق IKEv2 به VMها برسد، اما ICMP ورودی از VM به کلاینت تا زمانی که نوع تونل دروازه به OpenVPN تغییر نکرد ناموفق بود. نویسنده گزارش میگوید مایکروسافت محدودیتی در مسیر IKEv2 point-to-site تأیید کرده است که در آن ترافیک برگشتی از VM به کلاینت، مگر اینکه کلاینت نشست را آغاز کرده باشد، بهصورت متقارن مسیریابی نمیشود. IKEv2 به انتخابگرهای ترافیک تکیه دارد و دروازه در آن مورد جهت برگشت را رعایت نکرد.
این OpenVPN را بهطور کلی نوع تونل بهتر نمیکند. این نوع تونل را در ماتریس آزمون این بار کاری به یک متغیر تبدیل میکند.
تغییر نوع تونل یک تغییر سرویس است، نه یک کلید. هر کلاینت به نمایه سازگار نیاز دارد و دروازه ممکن است به گواهی یا پیکربندی احراز هویت متفاوتی نیاز داشته باشد. رفتار یکطرفه را با یک کلاینت آزمون و یک VM آزمون بازتولید کنید، نوع را طبق زمانبندی تأییدشده تغییر دهید و سپس همان آزمونهای جهت را تکرار کنید. اگر رفتار پس از تغییر باقی بماند، نوع تونل علت نبوده و مسئله را بدون دستزدن به محیط عملیاتی محدود کردهاید.
افسانه: کشف از طریق broadcast از مرز VNet عبور میکند
فرض دوم به دلیلی نامرتبط شکست میخورد. شبکه مجازی Azure ترافیک broadcast را حمل نمیکند، بنابراین VM نمیتواند قابهای broadcast را از یک شبکه محلی از طریق اتصال site-to-site یا point-to-site دریافت کند. برنامههایی که همتاها را از طریق broadcast پیدا میکنند، مانند مرور فایل قدیمی یا برخی پروتکلهای کشف دستگاه، هرگز طرف دور را نخواهند دید، هر طور که مسیرها نوشته شده باشند.
کشف از طریق broadcast را با نامهای DNS، یک سرویس دایرکتوری یا فهرست صریح همتاها جایگزین کنید. اگر برنامه جایگزین unicast ندارد، طراحی به سازوکار کشف دیگری نیاز دارد، نه تونل گستردهتر.
چه چیزی را تغییر دهیم و چگونه آن را اثبات کنیم
اگر آزمون جهت فقط روی IKEv2 شکست میخورد، نوع تونل دروازه، استخر نشانی کلاینتها و آزمون دقیق ICMP یا TCP را ثبت کنید، سپس یک نمایه OpenVPN تأییدشده را برای کلاینتهای آسیبدیده ارزیابی کنید. اگر روی هر نوع تونلی شکست میخورد، روی مسیر برگشت کار کنید: نشانی کلاینت باید از زیرشبکه VM قابل مسیریابی باشد، هر مسیر تعریفشده توسط کاربر باید به گام بعدی معتبر اشاره کند و فایروال کلاینت باید جریان ورودی را بپذیرد. شواهد NSG و مسیرها را به تیکت پیوست کنید.
با برنامه بررسی کنید، نه با ping. تبادل موفق ICMP پس از یک تغییر هیچ چیزی درباره پورت سرویس، احراز هویت یا نامگشایی آن نمیگوید. آزمون را پس از اتصال مجدد تکرار کنید، زیرا کلاینتی که نشانی متفاوتی از استخر میگیرد میتواند نتیجه را تغییر دهد. سپس یک بار دیگر پس از خوابیدن و بیدار شدن کلاینت تکرار کنید، چون در نشست ازسرگرفتهشده است که رفتار یکطرفه اغلب دوباره ظاهر میشود.