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

שלב 1: ודאו שההתחברות היא הדבר היחיד שעבד

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

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

רשמו את החשבון, האזור, המשחק והשעה. בלי ארבעת הערכים האלה, השוואה מאוחרת היא בין שתי בדיקות שונות שבמקרה חולקות שם.

שלב 2: תנו שם לתעבורה של כל פעולה

אספקת תוכן מתנהגת כמו העברת HTTP גדולה, והיא סובלת השהיה טוב בהרבה משהיא סובלת אובדן. חיפוש משחקים וסשנים בתוך המשחק משתמשים לעתים קרובות ב-UDP, שבו נתיב שמפיל חבילות נראה כמו משחק שבור ולא כמו הורדה איטית. שני הפרופילים האלה נכשלים באופן שונה באותו מנהרה, ולכן הורדה מהירה לא מנבאת סשן עובד.

בדקו את היעדים ואת השקעים הפעילים במקום קודם את רשימת הפורטים של הספק. הרשימה אומרת מה הפלטפורמה רשאית להשתמש בו, בעוד השקעים אומרים מה הלקוח הזה עושה עכשיו.

nslookup api.steampowered.com
ss -uanp | head -20
curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' https://store.steampowered.com/

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

שלב 3: בדקו את מדיניות ההכללה לפני רשימת הפורטים

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

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

ip route show default
ip -brief addr
Get-NetAdapter | Select-Object Name, Status, InterfaceDescription

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

שלב 4: שללו נתיב SOCKS שאינו יכול לשאת UDP

Tor מספק פרוקסי SOCKS, והתמיכה ב-SOCKS ברחבי המערכת אינה עקבית לגבי UDP. ההתנהגות המתועדת של Tor אינה מיישמת UDP ASSOCIATE, ולכן משחק שתעבורת הסשן שלו היא UDP לא יכול להשתמש בנתיב הזה, יהיה הלקוח מופנה אליו איך שיהיה. דפדפן שעובד דרך הפרוקסי מוכיח רק שזרמי ה-TCP של הדפדפן עובדים.

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

התייחסו ל-VPN מנותב ולפרוקסי SOCKS כאל כלים שונים בעלי יכולות שונות. החלפת האחד בשני היא שינוי עיצוב, לא העדפת תצורה.

השוו את הרשומה להסכם

נגישות הרשת והרשאת החשבון הן שאלות נפרדות, ורק על הראשונה עונה מנהרה עובדת. ההגבלה עוסקת בכוונה שמאחורי הפרוקסי ולא בפרוטוקול שבחרתם. ההסכם בתוקף מגביל פרוקסי IP שמטרתו להסתיר היכן מתגורר בעל החשבון, ולכן נתיב שעובד עשוי עדיין להיות מחוץ לתנאים שקיבלתם. קראו את ההסכם במקום להתייחס לקישוריות כאישור.

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

tracert -h 12 store.steampowered.com
ss -uanp | grep -i -E 'game|steam'
curl -sS -o /dev/null -w '%{remote_ip} %{time_connect}\n' https://store.steampowered.com/

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

מאמרים קשורים