RRAS پیش از آماده شدن تونل OpenVPN هنگام بوت شروع می شود

سرور دوباره راه اندازی می شود، OpenVPN شروع می شود و RRAS بالا می آید در حالی که آداپتور یا مسیری که به آن وابسته است هنوز وجود ندارد. راه اندازی مجدد دستی RRAS یک دقیقه بعد آن را درست می کند، که باعث می شود مشکل حل شده به نظر برسد و مشکل واقعی پنهان بماند. دو شرط متفاوت اینجا با هم اشتباه گرفته می شوند: سرویس پیش نیاز در حال اجراست، و منبع شبکه ای که RRAS واقعاً لازم دارد قابل استفاده شده است. وابستگی سرویس ویندوز می تواند شرط اول را بیان کند و هرگز شرط دوم را، پس افزودن یکی بدون تعریف منبع، بوت منظم تری به شما می دهد و همان خرابی.

این نشانه در بوت سرد چگونه دیده می شود

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

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

وابستگی که بر پایه «بعد از راه اندازی مجدد کار می کند» اضافه شده باشد، همان خرابی را فقط به اندازه زمانی که سرویس پیش نیاز برای گزارش RUNNING لازم دارد به تعویق می اندازد. همچنین بوت را سخت تر برای استدلال می کند، چون محدودیت ترتیب اکنون شبیه یک توضیح به نظر می رسد. بپرسید وابستگی چه شیئی را تضمین می کند و آیا آن شیء همان چیزی است که RRAS نمی توانست ببیند.

منبع را نام ببرید، نه فقط سرویس را

چیز مشخصی را که کم است بنویسید. می تواند یک آداپتور تونل با آدرس باشد، مسیری به زیرشبکه همتا، پاسخی از DNS، یا گواهی ای که هنوز ارائه می شود. «سرویس VPN در حال اجراست» توصیف منبع نیست، و آیکون سبز در یک کلاینت هم نیست. تا وقتی نمی توانید شیء و فرمانی که آن را نشان می دهد نام ببرید، شرطی را که می خواهید منتظرش بمانید تعریف نکرده اید.

همچنین مشخص کنید این نمونه OpenVPN چگونه راه اندازی می شود. تونلی که با GUI مدیریت می شود و تونلی که با سرویس مدیریت می شود چرخه های حیات بوت متفاوتی دارند، و نام سرویس باید از ماشینی که پیش روی شماست بیاید، نه از نمونه ای که برای نصب کننده دیگری نوشته شده. نامزدها را فهرست کنید به جای اعتماد به نامی که به یاد دارید.

Get-Service | Where-Object Name -match 'vpn|openvpn' | Select-Object Name, Status, StartType

زنجیره وابستگی را پیش از افزودن به آن بخوانید

مدیر کنترل سرویس حالت هایی مانند START_PENDING و RUNNING را گزارش می کند، و SERVICE_STATUS reference دقیقاً تعریف می کند هر فیلد چه معنایی دارد. هیچ یک از این حالت ها وعده نمی دهد که همتا، نام DNS یا برنامه پایین دستی قابل دسترسی است. این شکاف تمام دلیل بقای این خرابی در برابر وابستگی درست تنظیم شده است.

Get-Service -Name RemoteAccess | Select-Object Status, StartType
sc.exe qc RemoteAccess
Get-Service -Name RemoteAccess | Select-Object -ExpandProperty DependentServices

خط DEPENDENCIES از sc.exe qc فهرستی است که باید حفظ کنید، چون sc.exe config RemoteAccess depend= کل فهرست را جایگزین می کند و به آن اضافه نمی کند. حذف یک پیش نیاز نامرتبط هنگام افزودن یک سرویس VPN خرابی دومی ایجاد می کند که در بوت دیگری ظاهر می شود و تشخیص آن بسیار سخت تر از خرابی اصلی است. فهرست موجود را پیش از دست زدن به آن در سابقه تغییرات خود کپی کنید.

وابستگی ها رفتار خاموش شدن را هم تغییر می دهند، چون توقف یک پیش نیاز سرویس های وابسته به آن را متوقف می کند. پیش از اتصال RRAS به چیزی که اغلب دوباره راه اندازی می شود، بررسی کنید در زمان نگهداری چه اتفاقی می افتد.

راه اندازی مجدد را به یک شرط مشروط کنید، نه به یک تایمر

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

Get-NetAdapter | Where-Object Status -eq 'Up'
Get-NetRoute -DestinationPrefix 0.0.0.0/0
Get-WinEvent -LogName System -MaxEvents 40 |
  Where-Object ProviderName -eq 'Service Control Manager'

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

به بررسی حداکثر انتظاری بدهید که با زمانی که تونل به طور معقول روی سخت افزار شما می گیرد مطابقت داشته باشد، و کاری کنید وظیفه وقتی تسلیم می شود با وضعیت غیرصفر خارج شود. وظیفه ساکتی که فقط تلاش را متوقف می کند از وظیفه ای که موفق شده قابل تشخیص نیست.

گذار را ثبت کنید تا بوت بعدی خودش را توضیح دهد

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

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