רשימת משחקי LAN ריקה דרך OpenVPN? בדקו את נתיב הגילוי

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

הפרידו בין הצטרפות להפעלה לבין מציאתה

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

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

נסו הצטרפות ישירה לפני שאתם נוגעים במנהרה

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

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

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

הבינו היכן השידור נעצר

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

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

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

כשממסר מוצדק, החזיקו אותו צר

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

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

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

גשר רק כשהתכנון דורש Ethernet

מסגרות Ethernet נוסעות בתוך TAP, ולכן מנהרת TAP יכולה להשתייך לתחום שידור שגושר בכוונה. החלפה של dev tun ב-dev tap אינה בונה את הגשר הזה, אינה הופכת את תצורת השרת לתואמת ואינה גורמת לאפליקציה לבחור בממשק החדש. מדריך הגישור של OpenVPN מתאר את הסידור הרחב ולא תרופה ללובי ריק אחד.

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

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