درس ۱۲ از ۱۸

سناریو: VPN وصل نمی‌شود

این درس درباره سناریو: VPN وصل نمی‌شود است؛ مسیر را مرحله‌به‌مرحله جلو می‌بریم: اول مفهوم، بعد مشاهده در سیستم واقعی و در آخر عیب‌یابی؛ وقتی درس تمام شد باید بتوانی با ابزارهای مرتبط با همان سناریو و مستندات شرکت وضعیت این بخش را بررسی کنی و نتیجه را با حالت سالم مقایسه کنی در این درس تمرکز روی روش فکر کردن در رخداد واقعی است؛ به جای آزمون‌های تصادفی باید Scope، Timeline، Recent Change و Evidence را مشخص کنی و هر تست را برای تأیید یا رد یک فرضیه انجام بدهی؛ هدف فقط رسیدن به Fix نیست، بلکه باید بتوانی علت، نتیجه تست‌ها، Validation و اقدام پیشگیرانه را توضیح و مستند کنی

این درس برای مطالعه کامل نوشته شده است

با حوصله بخوان، مثال‌ها را تحلیل کن و تمرین‌ها را انجام بده؛ هدف حفظ کردن تعریف‌ها نیست

Internet Client و Endpoint را تست کن

برای VPN ابتدا ثابت کن Client اینترنت دارد و Endpoint VPN Reachable است؛ بعد Authentication، Policy و Route را بررسی کن VPN یک مسیر منطقی روی شبکه موجود ایجاد می‌کند و بسته به فناوری می‌تواند احراز هویت، رمزنگاری یا هر دو را فراهم کند؛ در عیب‌یابی Tunnel باید ابتدا دسترسی پایه دو Endpoint، زمان سیستم، Credential یا Key، پارامترهای مذاکره و Routeهای مربوط به شبکه‌های دو طرف بررسی شوند؛ بالا بودن وضعیت Tunnel به‌تنهایی تضمین نمی‌کند ترافیک کاربردی عبور می‌کند و Firewall و Route بعد از برقراری نیز باید کنترل شوند برای عیب‌یابی درست، این بخش را فقط به‌عنوان یک اصطلاح حفظ نکن و توجه داشته باش که در سناریوهای چندلایه، ترتیب آزمون اهمیت دارد؛ ابتدا تستی را انتخاب کن که با کمترین ریسک بیشترین اطلاعات را بدهد و اگر فرضیه رد شد مسیر بعدی را انتخاب کن؛ ارتباط با کاربران و ثبت Timeline هم بخشی از مدیریت رخداد است چون بعداً برای تحلیل علت، گزارش مدیریتی و جلوگیری از تکرار استفاده می‌شود برای اینکه این مفهوم در محیط واقعی قابل استفاده شود، سناریوی واقعی را مثل یک رخداد زنده مدیریت کن: ابتدا دامنه اثر و سرویس حیاتی را مشخص کن، سپس شواهد جمع کن و از تغییرهای پرخطر دوری کن؛ اگر چند نشانه هم‌زمان وجود دارند، ممکن است یک علت مشترک مانند DNS، Uplink، Storage یا Identity پشت آن‌ها باشد؛ وابستگی سرویس‌ها را روی کاغذ یا Diagram دنبال کن

Authentication Error را از Timeout جدا کن

Authentication Error یعنی ارتباط تا مرحله ورود پیش رفته اما Credential یا Policy رد شده؛ Timeout بیشتر به Reachability، Firewall یا مسیر اشاره می‌کند VPN یک مسیر منطقی روی شبکه موجود ایجاد می‌کند و بسته به فناوری می‌تواند احراز هویت، رمزنگاری یا هر دو را فراهم کند؛ در عیب‌یابی Tunnel باید ابتدا دسترسی پایه دو Endpoint، زمان سیستم، Credential یا Key، پارامترهای مذاکره و Routeهای مربوط به شبکه‌های دو طرف بررسی شوند؛ بالا بودن وضعیت Tunnel به‌تنهایی تضمین نمی‌کند ترافیک کاربردی عبور می‌کند و Firewall و Route بعد از برقراری نیز باید کنترل شوند OU در Active Directory برای سازمان‌دهی Objectها و اعمال مدیریت و Group Policy استفاده می‌شود و با Security Group نقش یکسانی ندارد؛ طراحی OU باید بر نیاز مدیریتی و محدوده اعمال Policy تکیه کند، نه صرفاً تقلید از چارت سازمانی؛ جابه‌جایی Object بین OUها می‌تواند مجموعه Policyهای اعمال‌شده را تغییر دهد، بنابراین قبل از تغییر باید Scope و Linkهای GPO بررسی شوند اگر بخواهی این بخش را از حالت تعریف به مهارت عملی تبدیل کنی، در سناریوهای چندلایه، ترتیب آزمون اهمیت دارد؛ ابتدا تستی را انتخاب کن که با کمترین ریسک بیشترین اطلاعات را بدهد و اگر فرضیه رد شد مسیر بعدی را انتخاب کن؛ ارتباط با کاربران و ثبت Timeline هم بخشی از مدیریت رخداد است چون بعداً برای تحلیل علت، گزارش مدیریتی و جلوگیری از تکرار استفاده می‌شود

Permission و Credential را بررسی کن

در VPN حساب فعال، Group/Policy مجاز و Credential درست را جدا بررسی کن؛ تغییر Password بدون بررسی Permission ممکن است مشکل را حل نکند VPN یک مسیر منطقی روی شبکه موجود ایجاد می‌کند و بسته به فناوری می‌تواند احراز هویت، رمزنگاری یا هر دو را فراهم کند؛ در عیب‌یابی Tunnel باید ابتدا دسترسی پایه دو Endpoint، زمان سیستم، Credential یا Key، پارامترهای مذاکره و Routeهای مربوط به شبکه‌های دو طرف بررسی شوند؛ بالا بودن وضعیت Tunnel به‌تنهایی تضمین نمی‌کند ترافیک کاربردی عبور می‌کند و Firewall و Route بعد از برقراری نیز باید کنترل شوند در File Server ویندوز، دسترسی کاربر می‌تواند هم‌زمان تحت تأثیر Share Permission و NTFS Permission باشد و برای تشخیص نتیجه باید هر دو لایه بررسی شوند؛ مدیریت دسترسی از طریق Security Group معمولاً قابل نگهداری‌تر از دادن Permission مستقیم به تعداد زیادی User است؛ Inheritance نیز تعیین می‌کند مجوزها چگونه به زیرپوشه‌ها برسند و تغییر بدون بررسی می‌تواند دسترسی‌های ناخواسته ایجاد کند؛ دسترسی مؤثر باید با یک حساب آزمایشی از دید کاربر هم تأیید شود برای اینکه این مفهوم در محیط واقعی قابل استفاده شود، در سناریوهای چندلایه، ترتیب آزمون اهمیت دارد؛ ابتدا تستی را انتخاب کن که با کمترین ریسک بیشترین اطلاعات را بدهد و اگر فرضیه رد شد مسیر بعدی را انتخاب کن؛ ارتباط با کاربران و ثبت Timeline هم بخشی از مدیریت رخداد است چون بعداً برای تحلیل علت، گزارش مدیریتی و جلوگیری از تکرار استفاده می‌شود

Firewall و NAT لازم را کنترل کن

Firewall ترافیک را بر اساس Rule، جهت، پروتکل، Port و آدرس اجازه یا مسدود می‌کند؛ برای عیب‌یابی به‌جای خاموش کردن کامل، Rule و Log مرتبط را بررسی کن باز کردن Any/Any برای رفع سریع، سطح حمله را زیاد می‌کند NAT نشانی‌ها را هنگام عبور از روتر ترجمه می‌کند و در مرز اینترنت معمولاً Private IP را به Public IP تبدیل می‌کند؛ در عیب‌یابی Source/Destination و تطبیق Rule را بررسی کن NAT جای Firewall یا Routing نیست و هر سه نقش جدا دارند NAT نشانی یا Port را هنگام عبور Packet تغییر می‌دهد و با Routing یا Firewall یک مفهوم نیست؛ Source NAT معمولاً برای تغییر هویت مبدأ هنگام خروج و Destination NAT برای هدایت ترافیک ورودی به مقصد دیگری استفاده می‌شود؛ در عیب‌یابی باید ترتیب عبور Packet، Route قبل و بعد از ترجمه، Rule مطابق با جهت ترافیک و وجود مسیر برگشت بررسی شود، چون Rule درست روی مسیر اشتباه نتیجه مورد انتظار را نمی‌دهد Firewall ترافیک را بر اساس سیاست و شرایطی مانند مبدأ، مقصد، پروتکل، Port و وضعیت Connection کنترل می‌کند؛ Ruleها معمولاً به ترتیب ارزیابی می‌شوند و جای Rule می‌تواند نتیجه را عوض کند؛ برای تحلیل مشکل باید مشخص شود Packet در کدام Chain یا جهت حرکت می‌کند، چه Ruleای با آن Match می‌شود و آیا Rule دیگری پیش از آن تصمیم را گرفته است؛ اصل حداقل دسترسی نیز می‌گوید فقط ترافیکی مجاز شود که برای سرویس لازم است

بعد Tunnel Route و DNS داخلی تست شود

DNS نام را به اطلاعاتی مانند IP تبدیل می‌کند تا کاربر مجبور نباشد نشانی عددی سرویس‌ها را حفظ کند؛ اگر IP مقصد کار می‌کند ولی نام نه، Query DNS را جداگانه آزمایش کن پاک کردن Cache ممکن است کمک کند اما جای بررسی Record، Resolver و مسیر DNS را نمی‌گیرد DNS سامانه نام‌گذاری توزیع‌شده‌ای است که نام را به داده‌هایی مانند IP مرتبط می‌کند و بسیاری از سرویس‌های سازمانی به Name Resolution درست وابسته‌اند؛ خطای DNS ممکن است در ظاهر شبیه قطعی شبکه یا خرابی برنامه دیده شود، بنابراین باید جداگانه بررسی شود که Client به DNS Server درست اشاره می‌کند، Query پاسخ می‌گیرد، Zone و Record مورد نیاز وجود دارند و زمان و دامنه جست‌وجو با طراحی شبکه سازگارند Router زمانی وارد مسیر می‌شود که مقصد خارج از شبکه محلی باشد و جدول Routing تعیین می‌کند Packet از کدام Next Hop یا Interface عبور کند؛ Default Route فقط مسیر پیش‌فرض برای مقصدهایی است که Route مشخص‌تری ندارند؛ در بررسی مشکل باید Routeهای موجود، Prefix هر Route، Gateway یا Next Hop، وضعیت Interface و مسیر برگشت را هم دید، چون رسیدن Packet به مقصد بدون مسیر برگشت معتبر ارتباط پایدار ایجاد نمی‌کند؛ در همین درس، موضوع «بعد Tunnel Route و DNS داخلی تست شود» را باید در ارتباط با «سناریو: VPN وصل نمی‌شود» بررسی کنی و نتیجه را با شواهد همان سیستم توضیح بدهی

مثال محیط واقعی

فرض کن در سناریوی واقعی شرکت مشکلی گزارش شده و احتمال می‌دهی به سناریو: VPN وصل نمی‌شود مربوط باشد. قبل از تغییر، وضعیت فعلی را با ابزارهای مرتبط با همان سناریو و مستندات شرکت بررسی می‌کنی و نتیجه را با یک حالت سالم یا مستند معتبر مقایسه می‌کنی. اگر شواهد فرضیه را تأیید کردند، فقط همان بخش مرتبط را تغییر می‌دهی و بعد همان تست را دوباره اجرا می‌کنی تا مطمئن شوی مشکل واقعاً برطرف شده است

اشتباهات رایج

این اشتباه‌ها را تکرار نکن

  • در VPN حساب فعال، Group/Policy مجاز و Credential درست را جدا بررسی کن؛ تغییر Password بدون بررسی Permission ممکن است مشکل را حل نکند
  • Firewall ترافیک را بر اساس Rule، جهت، پروتکل، Port و آدرس اجازه یا مسدود می‌کند؛ برای عیب‌یابی به‌جای خاموش کردن کامل، Rule و Log مرتبط را بررسی کن
  • تغییر دادن تنظیمات مرتبط با سناریو: VPN وصل نمی‌شود قبل از اینکه مطمئن شوی مشکل واقعاً به همین بخش مربوط است
تمرین عملی

حالا خودت انجام بده

  1. در یک نمونه آزمایشی مرتبط با سناریو: VPN وصل نمی‌شود، فقط وضعیت فعلی را مشاهده کن و سه نکته‌ای را که برای تشخیص حالت سالم مهم‌اند یادداشت کن
  2. با ابزارهای مرتبط با همان سناریو و مستندات شرکت وضعیت مرتبط با سناریو: VPN وصل نمی‌شود را بدون تغییر بررسی کن، سه داده واقعی جمع کن و توضیح بده هرکدام چه چیزی به تو می‌گویند
  3. یک خطای فرضی مرتبط با سناریو: VPN وصل نمی‌شود بنویس و مشخص کن اولین تست کم‌خطر تو چیست و چه نتیجه‌ای فرضیه‌ات را رد می‌کند

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

  • Internet Client و Endpoint را تست کن
  • Authentication Error را از Timeout جدا کن
  • Permission و Credential را بررسی کن
  • Firewall و NAT لازم را کنترل کن
  • بعد Tunnel Route و DNS داخلی تست شود
  • در هر مرحله فقط یک تغییر کنترل‌شده انجام بده تا اثر آن قابل تشخیص باشد
خودسنجی

قبل از رفتن به درس بعد، جواب را برای خودت توضیح بده

چرا باید Internet Client و Endpoint را تست کنی و از کجا می‌فهمی نتیجه درست است؟

برای VPN ابتدا ثابت کن Client اینترنت دارد و Endpoint VPN Reachable است؛ بعد Authentication، Policy و Route را بررسی کن

چرا باید Authentication Error را از Timeout جدا کنی و از کجا می‌فهمی نتیجه درست است؟

Authentication Error یعنی ارتباط تا مرحله ورود پیش رفته اما Credential یا Policy رد شده؛ Timeout بیشتر به Reachability، Firewall یا مسیر اشاره می‌کند

چرا باید Permission و Credential را بررسی کنی و از کجا می‌فهمی نتیجه درست است؟

در VPN حساب فعال، Group/Policy مجاز و Credential درست را جدا بررسی کن؛ تغییر Password بدون بررسی Permission ممکن است مشکل را حل نکند

مطالعه درس همیشه عمومی است

برای ذخیره پیشرفت، دوره را رسمی شروع کن

با ثبت‌نام، تکمیل درس‌ها و نمره آزمون روی حساب ذخیره می‌شود

ثبت‌نام و شروع رسمی