RRAS עולה לפני שמנהרת OpenVPN מוכנה בעת האתחול

השרת מופעל מחדש, OpenVPN מתחיל, ו-RRAS עולה בזמן שהמתאם או המסלול שהוא תלוי בהם עדיין חסרים. הפעלה מחדש ידנית של RRAS כעבור דקה מתקנת את זה, מה שגורם לבעיה להיראות פתורה ומסתיר את האמיתית. כאן מתבלבלים בין שני תנאים שונים: שירות התנאי המוקדם פועל, ומשאב הרשת ש-RRAS באמת צריך הפך לשמיש. תלות של שירות Windows יכולה לבטא את התנאי הראשון ולעולם לא את השני, ולכן הוספת תלות בלי להגדיר את המשאב קונה לכם אתחול מסודר יותר ואותה תקלה.

איך נראה התסמין באתחול קר

הסימן הוא ההבדל בין התחלה קרה להפעלה מחדש. בהתחלה קרה 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 קיבל אותו לבסוף. השורה הבודדת הזו עונה על השאלה שהמהנדס הבא ישאל, והפקתה כמעט לא עולה דבר. בלעדיה החקירה הבאה מתחילה מאותם ניחושים כמו זו.

עצרו את האוטומציה אחרי מספר ניסיונות מוגדר ודווחו על כישלון במקום לנסות שוב לנצח. אתחול שמסתיים בהודעה ברורה „המשאב מעולם לא הופיע“ שווה יותר מזה שממשיך להפעיל מחדש שירות בחושך. כשהודעה הזו תופיע, שם המשאב שרשמתם בפרק השני הוא מה שהאדם הבא יחפש.