המנהרה המפוצלת שלך מדירה את המשגר, לא את המשחק
משגר מפעיל קובץ הפעלה אחר עבור המשחק, ולתהליך הזה יש שקעים משלו. מצא את התהליך האמיתי, התאם את המזהה הנכון, ואז בדוק.
אתה מוסיף את המשגר לרשימת ההחרגות, ההורדה קופצת מאיטית למהירה, והמשחק עדיין נוחת בשרת מרוחק. שום דבר לא שבור. המשגר והמשחק הם שני תהליכים עם שתי קבוצות שקעים, והחרגה של אחד לא אומרת דבר על השני. ההורדה נעשתה מהירה יותר כי ההורדה הייתה התעבורה של המשגר; המשחק הוא החיבור של מישהו אחר, שנפתח על ידי קובץ הפעלה שהכלל שלך מעולם לא ראה.
מתקין אחד, תהליכים רבים
תוכנת משחקים מודרנית היא קבוצת כוכבים קטנה. יש לקוח שמכניס אותך, מעדכן שמושך תוכן, משגר שמתחיל את המשחק, וקובץ הפעלה של המשחק שאולי יוצר בעצמו תהליך שני נגד רמאות או עבור שכבת התאמת המשחקים. כל אחד מהם יכול להחזיק חיבורים משלו ליעדים משלו.
כלל החרגה בדרך כלל נוקב באחד מהם. איזה מהם הוא נוקב תלוי כולו במזהה שהלקוח VPN תומך בו, וזה החלק שמשתמשים ממעטים לבדוק. חלק מהלקוחות מתאימים נתיב קובץ הפעלה, חלקם מזהה חבילה או bundle, וחלקם שם תהליך ששני קבצים בינאריים לא קשורים יכולים לחלוק. קרא את הכלל לפני רשימת התהליכים, כי הכלל מגביל אפילו את מה שאתה יכול לבטא.
התסמין לפיכך אינו "המנהרה המפוצלת שבורה". הוא "הכלל מכסה תהליך שאינו זה שנושא את התעבורה שאכפת לי ממנה", וזו אמירה צרה הרבה יותר וניתנת לתיקון הרבה יותר. ברגע שאתה אומר את זה כך, הצעד הבא מפסיק להיות ניחוש.
מצא את התהליך שבעל החיבור של המשחק
הפעל את המשחק, היכנס למשחק, והסתכל מי הבעלים של השקעים ולא מה שמופיע על המסך. ב-Windows רשימת התהליכים יחד עם שאילתת שקעים לכל תהליך עונות על כך בשתי פקודות:
Get-Process | Where-Object { $_.ProcessName -match 'launcher|game|client' } | Select-Object Id,ProcessName,Path
Get-NetTCPConnection -State Established | Select-Object OwningProcess,RemoteAddress,RemotePort | Sort-Object OwningProcessהפקודה השנייה מדפיסה מזהה תהליך, לא שם, לכן חבר את שני הפלטים לפי מזהה. השורה שאתה מחפש היא זו שכתובתה המרוחקת שייכת לשירות המשחק, והתהליך שבעליה הוא קובץ ההפעלה שהכלל שלך צריך לנקוב בו.
ב-Linux אותה שאלה דורשת פקודה אחת לכל סוג שקע, וכדאי לבדוק את שניהם, כי חיבור משחק עשוי להיות UDP בעוד כל השאר TCP:
ss -tunp state established | grep -i game
ss -tunp | awk 'NR==1 || /udp/'אם המשחק פועל במכולה או בשכבת תאימות, התהליך שתמצא עשוי להיות shim ולא הקובץ הבינארי שהתקנת. במקרה כזה המזהה החשוב הוא זה שהלקוח רואה, שעשוי להיות הנתיב של ה-shim, ושום כמות של עריכת הקובץ המקורי לא תשפיע עליו.
התאם את המזהה שהלקוח שלך תומך בו
קרא את התיעוד של הלקוח לגבי כלל ההחרגה לפני שתוסיף משהו. שלושת המודלים הנפוצים מתנהגים אחרת, ואחד מהם הוא מלכודת.
| Identifier | How it behaves | Failure mode |
|---|---|---|
| Executable path | Matches exactly the file at that path | Breaks when an update moves the binary |
| Process name | Matches any binary with that name | Too broad; catches unrelated software |
| Package or bundle id | Matches a signed application group | May include services you did not intend |
כללי נתיב הם המדויקים ביותר והשבירים ביותר. עדכון משגר שמעביר את קובץ ההפעלה משאיר את הכלל מצביע על קובץ שכבר לא רץ, והתסמין חוזר בלי שמשהו משתנה בבירור. כללי חבילה שורדים זאת, והם גם יכולים לכסות בשקט תהליכי עזר שלא חשבת עליהם, וזה נוח או מדאיג בהתאם לעוזר.
יהיה אשר יהיה מה שהלקוח תומך בו, אל תוסיף רשומות לכל קובץ הפעלה שתמצא. רשימה שנבנתה בניסוי וטעייה עד שסשן אחד עבד אינה ניתנת לבדיקה, והיא תצבור בשקט חריגות לתוכנה לא קשורה. נקוב בשם התהליך שמצאת, ורשום למה הוא נועד.
בדוק במשחק, לא בהורדה
מהירות ההורדה של המשגר היא הבדיקה הגרועה ביותר האפשרית, כי היא מפעילה בדיוק את התהליך שכבר הוחרג. השתמש במה שנכשל, ובדוק את הנתיב ולא את תצוגת הביצועים של המשחק עצמו:
ip route get 203.0.113.55
Get-NetTCPConnection -State Established | Where-Object RemotePort -eq 27015הפקודה הראשונה זקוקה לכתובת שאליה פתר שרת המשחק, שאותה יכול לתת יומן החיבורים של המשחק או הלקוח שלך. אם הנתיב נוקב בממשק הפיזי, הכלל עובד. השנייה מראה אם קיים סשן בכלל, מה שמפריד בין "הוחרג אבל השרת למטה" לבין "לא הוחרג".
שמור על האזור ועל רשת הגישה קבועים בזמן הבדיקה. משחק שנוחת במרכז נתונים אחר בכל ניסיון מייצר כתובות שונות, ואתה תסיים לרדוף אחרי מטרה נעה במקום לאמת כלל. שתי הרצות עם אותה כתובת שוות יותר מעשר עם כתובות שונות.
בדוק שוב אחרי העדכון הבא
לכל כלל מבוסס נתיב יש חיי מדף הנמדדים במחזורי תיקון. כשהמשחק מפסיק לכבד את ההחרגה חודש לאחר מכן, הדבר הראשון לבדוק הוא אם קובץ ההפעלה עבר, והשני הוא אם הופיע לצידו תהליך עזר חדש.
מודל החרגת היישומים שמתעד לקוח אחד הוא התייחסות סבירה לאופן שבו כללים אלה מתוארים, אם כי הפרטים שונים בין מוצרים. קרא את שלך, רשום את המזהה שבו השתמשת, וציין את התאריך. הרשומה הזו היא מה שהופך תעלומה לתיקון של חמש דקות בפעם הבאה שהמשגר ישלח עדכון.
אם הלקוח פשוט לא יכול לבטא את הגבול שאתה צריך, מדיניות רחבה יותר מאושרת עדיפה על ערימת חריגות לא מתועדות. רחב ומובן עדיף על צר ושגוי, במיוחד כשהגרסה הצרה היא מה שכולם מאמינים שנמצא בתוקף.