בודק הפורט אומר פתוח? למה שחקני Minecraft עדיין לא יכולים להצטרף

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

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

בדיקה בוחנת רק את מה שהיא יכולה לראות

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

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

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

ארבע שכבות בין שקע לשחקן

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

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

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

למה השחקן מבפנים הולך בנתיב אחר

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

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

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

התיעוד של Netgate על השתקפות NAT מתאר ביתר פירוט את ההבחנה בין חוץ לפנים ואת חלופת split-DNS. קרא אותו כתיאור של המנגנון ולא כהבטחה שספק VPN או נתב מסוים תומך בכל גרסת loopback.

אסוף ראיות מכל נקודת מבט

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

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