پایش VPN در Azure Site: وضعیت تونل را با یک کاوشگر واقعی جفت کنید

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

از نشانه خراب شروع کنید، نه از تونل

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

سه وضعیت باید از هم تشخیص داده شوند: تونل پایین است، تونل بالا است و سرویس شکست می خورد، و خود منبع پایش در دسترس نیست.

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

برای برنامه ای از شعبه به آژور، آزمون مصنوعی را از میزبان داخل شبکه بار کاری شعبه اجرا کنید و آن را به نقطه ورود خصوصی HTTPS که کاربران واقعا به آن می رسند نشانه بگیرید. کاوشگری که از دروازه راه می افتد نشانی مبدأ متفاوت و غالبا مسیر سیاستی متفاوتی دارد، پس می تواند موفق شود در حالی که همه کاربران شکست می خورند. Azure Connection Monitor بررسی های TCP و ICMP و HTTP را با گروه های آزمون و آستانه ها پشتیبانی می کند، و منابع محلی آن الزامات عاملی متفاوت از الزامات سمت آژور دارند. آرایش پشتیبانی شده کنونی را بررسی کنید نه اینکه دستور کار منسوخ پایش کلاسیک را از یک وبلاگ کپی کنید.

کاوشگر را باریک و خسته کننده نگه دارید: یک مقصد، یک پورت، بسامدی که با نیاز عملیاتی بخواند، و یک قاعده اجازه صریح برای همان مبدأ.

بررسی ای را انتخاب کنید که با سرویس بخواند

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

ICMP ضعیف ترین گزینه از سه است، چون بسیاری از پشته ها آن را بر اساس سیاست دور می ریزند و پینگ ناموفق چیز کمی را ثابت می کند.

هر دو نشانه را بدون ساختن از خود به Elastic برسانید

دروازه VPN سنجه های پلتفرم مانند بایت های خروج و ورود تونل و شمارنده های افت بسته منتشر می کند و می تواند گزارش های تشخیصی را در دسته هایی شامل رویدادهای تونل و IKE بفرستد. نتایج Connection Monitor از طریق Azure Monitor به صورت سنجه و از طریق فضای کاری Log Analytics به صورت رکورد گزارش می رسند. هیچ کدام از این ها به تنهایی در نمایه Elastic ظاهر نمی شود. یک خط لوله پشتیبانی شده برای سنجه ها و یکی برای گزارش ها انتخاب کنید، معمولا ورودی Azure Event Hub یا یکپارچه سازی Azure Monitor، و پیش از اعتماد به الگوی نمایه بررسی کنید که یکپارچه سازی نصب شده واقعا چه چیزی را می گیرد.

برچسب هایی را نگه دارید که به اپراتور امکان می دهد دو مجموعه داده را به هم بپیوندد: نقطه پایانی مبدأ، مقصد، پروتکل و پورت برای کاوشگر، و هویت تونل به همراه نشانی همتا برای دروازه.

خط لوله را با یک رویداد کنترل شده اعتبارسنجی کنید، سپس آن را در Elastic جست وجو کنید و مهر زمانی و برچسب های منبعش را بررسی کنید. سندی با مهر زمانی نادرست بدتر از سند ناپیداست، چون داده کهنه را تازه نشان می دهد.

بر تفاوت هشدار بدهید، نه بر رنگ

منطق نگه داشتن دو نشانه در ترکیب هاست. تونل پایین باید به مالک شبکه اطلاع دهد؛ تونل بالا با کاوشگر شکست خورده به مالک برنامه؛ نتیجه ناپیدای کاوشگر به کسی که عامل پایش را دارد. ترکیب هر سه در یک پنل سرخ تضمین می کند که هشدار تا یک ماه خاموش شود. بر شکست پایدار با پنجره ماندگاری هشدار بدهید نه بر یک نمونه، و بررسی جداگانه ای برای سلامت خود خط لوله دریافت اضافه کنید.

داشبوردی پر از نمونه های موفق دیروز نباید امروز مسیر سالم خوانده شود.

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