گزارشهای VPN نقطه به سایت Azure کجاست؟ در Monitor نگاه کنید
یک شکست نقطه به سایت چیزی در صفحهٔ دروازه باقی نمیگذارد. سوابق اتصال از یک تنظیم تشخیصی روی دروازه میآیند که در Monitor مدیریت میشود.
کاربری نمیتواند به دروازهٔ نقطه به سایت وصل شود، صفحهٔ دروازه را باز میکنید و هیچجای صفحه تاریخچهٔ اتصال نیست. پیکربندی، گواهیها، وضعیت: همه حاضرند، هیچ سابقهای نیست. گزارشها وجود دارند، اما صفحههای شبکه بهکلی آنها را تولید نمیکنند. آنها از یک تنظیم تشخیصی متصل به منبع دروازه میآیند و آن تنظیم زیر Monitor زندگی میکند؛ به همین دلیل نخستین جستوجو در جای بدیهی چیزی برنمیگرداند و مردم نتیجه میگیرند که سرویس هیچ رد حسابرسی نگه نمیدارد.
چرا جستوجوی بدیهی شکست میخورد
راهنماهای قدیمی میگویند VPN نقطه به سایت Azure هیچ حسابرسی ندارد و این درست بود زمانی که سرویس هیچ سابقهای برای هر اتصال ارائه نمیداد. دروازههای کنونی سوابق تشخیصی تونل را منتشر میکنند، پس پرسش سودمند تغییر کرده است: نه اینکه گزارشها وجود دارند یا نه، بلکه کدام منبع آنها را منتشر میکند و کدام دسته را روشن کردهاید. صفحهٔ دروازه یک سطح پیکربندی است و سطوح پیکربندی بهندرت همزمان نمایشگر گزارش هم هستند. تنظیم تشخیصی یک شیء برای هر منبع است، بنابراین منبعی که انتخاب میکنید همهٔ ادامه را تعیین میکند.
نیمهٔ دیگر سردرگمی احراز هویت است. اتصالهای نقطه به سایت مبتنی بر گواهی رویداد ورود برای هر کاربر مانند یک ارائهدهندهٔ هویت تولید نمیکنند، بنابراین سابقهای از شخصی نامدار که رمز عبور تایپ کند وجود ندارد.
تنظیم تشخیصی را به منبع دروازه متصل کنید
Monitor را باز کنید، سپس Diagnostic settings، و تنظیم تازهای بیفزایید که هدفش خود دروازهٔ شبکهٔ مجازی باشد نه شبکهٔ مجازی که آن را در بر دارد. دستهٔ تشخیصی نقطه به سایت را انتخاب کنید، همان که P2SDiagnosticLog نام دارد، زیرا سوابق اتصال هر مشتری را همان حمل میکند؛ دستههای تونل، مسیر یا IKE را فقط برای خطاهای سایت به سایت که پوشش میدهند بیفزایید. سپس دادهها را به یک فضای کاری Log Analytics که کنترل میکنید بفرستید، با دورهٔ نگهداری که آگاهانه انتخاب کردهاید. بیشتر جستوجوهای ناموفق یک تنظیم متصل به منبع اشتباه است، نه یک ویژگی گمشده.
فهرست دستهها بر اساس نوع و نسل دروازه متفاوت است. اگر دستهٔ نقطه به سایت غایب است، دروازه ممکن است قدیمیتر از این ویژگی باشد یا با SKUای کار کند که هرگز آن را منتشر نمیکند، پس پیش از جستوجوی مشکل مجوز، دستههای پشتیبانیشده را بررسی کنید. دروازهای بدون دستهٔ نقطه به سایت خراب نیست؛ بهسادگی نمیتواند منبع آن سابقه باشد و نزدیکترین جانشین دستهٔ تونل یا IKE است که نشانی مشتری را ثبت میکند حتی اگر جلسهٔ نقطه به سایت را توصیف نکند. پیش از باز کردن مورد پشتیبانی دربارهٔ گزارشهای گمشده، فهرست دستهها را تأیید کنید.
سوابق را در جدولی بخوانید که حالت شما استفاده میکند
در حالت جمعآوری قدیمی، ورودیها در جدول AzureDiagnostics فرود میآیند و دسته بهصورت مقدار ستون ظاهر میشود؛ با جدولهای مخصوص منبع، دروازه جدول خودش را دارد. در هر حال، بر اساس منبع دروازه و پنجرهای پیرامون تلاش ناموفق جستوجو کنید و سپس همبستگی را بخوانید نه سطرهای جداگانه:
AzureDiagnostics
| where ResourceType == "VIRTUALNETWORKGATEWAYS"
| where _ResourceId has "gateway-name"
| where TimeGenerated > ago(2h)
| project TimeGenerated, Category, OperationName, ResultType, ResultDescription
| order by TimeGenerated descمجموعهٔ ستونها از حالت جمعآوری شما پیروی میکند، پس با پرسوجو مانند یک شکل رفتار کنید نه یک اسکریپت. آنچه میجویید نشانی مشتری است که ظاهر میشود و سپس ناپدید میشود، با نوع نتیجهای که موفقیت نیست.
سابقهٔ دروازه را با دید خود مشتری جفت کنید
گزارشهای دروازه تونل را توصیف میکنند، نه اینکه چرا یک لپتاپ نتوانست یکی بسازد. سمت مشتری را در همان مهر زمانی جمع کنید: گزارش رویداد Windows برای مشتری RAS، گزارش اتصال macOS یا متن خطایی که برنامهٔ مشتری نشان داد. سابقهٔ دروازه بدون تلاش متناظر مشتری به مشتری اشاره میکند؛ مشتریای که موفقیت گزارش میکند در حالی که دروازه چیزی ثبت نمیکند معمولاً یعنی نمایه به دروازهٔ دیگری نشانه رفته است.
هر دو نیمه را در یک بلیت نگه دارید. گزارش دروازه بهتنهایی به نتیجهگیری نادرست دعوت میکند و گزارش مشتری بهتنهایی نمیتواند نشان دهد بسته هرگز رسیده است یا نه.
اگر هیچکجا چیزی ظاهر نشد، پیش از تردید در پلتفرم، ساعت مشتری را بررسی کنید. مهرهای زمانی کج باعث میشوند همبستگی به شکلی شکست بخورد که دقیقاً مانند دادههای گمشده به نظر میرسد.
نگهداری، دامنه و مدخل runbook
سوابق تونل نشانیهای مشتری و مهرهای زمانی اتصال را حمل میکنند، پس با آنها مانند دادههای شخصی با برنامهٔ حذف رفتار کنید نه اینکه پیشفرض پلتفرم را رها کنید. همچنین بررسی کنید که فضای کاری هر دسته از هر منبع در اشتراک را نمیبلعد، زیرا فضای کاری پرسروصدا همبستگی را از خواندن مستقیم گزارش مشتری کندتر میکند.
در پایان، نام تنظیم، فضای کاری و دستههای برگزیده را در runbook دروازه بنویسید. نفر بعدی که مشتریای را اشکالزدایی کند نخست به صفحهٔ دروازه نگاه میکند، چیزی نمییابد و نتیجه میگیرد که گزارشها وجود ندارند.