הפעלת משימה כשה-VPN מתחבר: אירוע, בדיקה תקופתית או פרטי גישה?
סקריפט כניסה פועל לפני שהמנהרה קיימת. השוו טריגר של אירוע רשת, בדיקה תקופתית של משאב ופרטי גישה שמורים לפי מה שכל אחד מבטיח.
סקריפט כניסה שממפה כונן או מתחיל עבודת סנכרון פועל לפני שלמנהרה יש כתובת, ולכן הוא נכשל בשקט והמשתמש מתקן אותו ביד כל בוקר. Windows אינו מציע לרוב הלקוחות קריאת חזרה בכל חיבור VPN, אבל הוא רושם את שינוי הרשת, ורישום זה יכול להתחיל את העבודה ברגע הנכון. הבחירה היא בין תגובה לרישום הזה, בדיקה תקופתית של המשאב והסרת ההודעה שהפכה את הכשל לגלוי.
השוואת שלושת המנגנונים לפי מה שהם מבטיחים עדיפה על דירוגם לפי אלגנטיות. כל אחד נכשל אחרת, ואופן הכשל הוא מה שחיים איתו אחר כך.
מדוע הכניסה מופעלת מוקדם מדי
כניסה ואתחול פועלים לפני שמתאם ה-VPN מקבל את כתובתו, ולכן מיפוי כונן, כתובת URL פנימית או חיבור למסד נתונים שננסים באותו רגע אינם זוכים לא למסלול ולא לפותר. הבקשה נכשלת, וההפעלה נשארת במצב שעל המשתמש לתקן ידנית. העברת אותו סקריפט לתיקיית האתחול לא משנה דבר, כי בעיית הסדר נוסעת איתו. הטריגר חייב להיות שינוי רשת ולא אירוע הפעלה.
משימה מתוזמנת בעת כניסה עם השהיה שרירותית נראית כמו תיקון ולמעשה היא ניחוש. היא עובדת בקישור מהיר ונכשלת בקישור איטי, שזה הסוג הפחות שימושי של אמינות.
שלושה ווי חיבור בהשוואה
המנגנונים שונים במה שהם צופים בו, כמה מהר הם מגיבים ומה הם עושים עם התחברות מחדש בהמשך היום. הטבלה משווה אותם בשלוש הנקודות האלה ולא בכמה חכם כל אחד נשמע.
| Mechanism | Reacts to | Covers a mid-session reconnect | Typical failure |
|---|---|---|---|
| Network profile event | A network connect record | Yes, when the event repeats | Runs on the wrong network |
| Resource poll with backoff | The resource becoming reachable | Yes | Log noise and a wasted window |
| Stored credentials alone | Nothing; it removes a prompt | No | Still fires before the tunnel |
קראו את הטבלה שורה אחר שורה. וו האירוע הוא המהיר והרועש ביותר, משום ש-Windows רושם כל רשת כולל ה-Wi-Fi של בית הקפה, ולכן הפעולה חייבת לאמת את המשאב לפני שהיא עושה משהו. הבדיקה התקופתית איטית ומדויקת יותר, משום שהיא מצליחה בדיוק כשהשיתוף או שם המארח עונים, והיא אינה זקוקה לידיעה איזה לקוח מותקן. פרטי גישה שמורים אינם אפשרות מתחרה כלל: הם מסירים את בקשת הסיסמה, וזו סיבה שנייה ובלתי תלויה לכך שמיפוי בעת כניסה נכשל.
הבחירה בין השתיים הראשונות תלויה בכך אם קיים אירוע שמיש בלקוח. במקום שקיים, אירוע יחד עם בדיקת משאב הוא ברירת המחדל הטובה יותר.
בנו את טריגר האירוע כראוי
הרישום נמצא ביומן Microsoft-Windows-NetworkProfile/Operational, ומזהה 10001 מסמן רשת שהתחברה זה עתה. צרו את המשימה עם טריגר בעת אירוע המכוון ליומן הזה, לשם הספק הזה ולמזהה הזה. כל רשת שהמכונה מצטרפת אליה תפעיל אותו, ולכן הפעולה זקוקה לסעיף הגנה ולא להנחה, והיא צריכה לרוץ רק כשהמשתמש מחובר אם העבודה נוגעת בכוננים ממופים.
סעיף ההגנה צריך לבדוק את מה שהמשימה באמת צריכה, כגון נתיב שיתוף או פורט שירות, ולצאת בשקט כשהוא אינו נגיש. בדיקת שם המתאם אינה מספיקה, משום שלקוח יכול לעשות שימוש חוזר במתאם אחד בכמה פרופילים. יציאה שקטה שומרת על היומן קריא ומונעת סערת ניסיונות חוזרים נגד רשת שלעולם לא תשרת את המשאב.
בדקו שהמשימה רצה ברגע הנכון
הוכיחו את התזמון ולא את התצורה. הפקודות שלהלן מציגות את הגדרת המשימה, את אירועי פרופיל הרשת האחרונים ואת השאלה אם המשאב נגיש מהחשבון שהמשימה רצה תחתיו. הריצו אותן לאחר התחברות מחדש אמיתית ולא לאחר הפעלה ידנית.
schtasks /query /tn "VpnPostConnect" /v /fo LIST
Get-WinEvent -LogName Microsoft-Windows-NetworkProfile/Operational -MaxEvents 10
Test-Path \\fileserver\share
whoamiרשומת היסטוריה של משימה שקיימת בזמן שאף אירוע רשת אינו תואם פירושה שהטריגר שגוי ולא הפעולה. אם האירועים מופיעים והמשימה אינה רצה, ייתכן שהמשימה רצה תחת חשבון שאינו רואה את המשאב, ופלט החשבון הוא הרמז. בדיקת משאב שעוברת בזמן שהמיפוי עדיין חסר מצביעה על הקשר ההפעלה ולא על קישוריות. כל אחד משלושת התצפיות האלה מוביל אתכם לתיקון אחר.
כתבו שורת יומן אחת לכל הרצה עם הכתובת, תוצאת המשאב והתוצאה. הכשל הבא יראה אז אם המשימה רצה מוקדם, רצה ברשת הלא נכונה או לא רצה כלל.