Minecraft דרך VPN: איזו כתובת נכנסת לרשימת השרתים?
נקודת הקצה של ה-VPN בונה את המנהרה; המשחק צריך את הכתובת הפרטית של המארח ואת הפורט. שייכו תפקידים לכתובות, ואז בדקו מאזין, מסלול וכללי מארח.
הקלדת נקודת הקצה של ה-VPN ברשימת השרתים של Minecraft נראית הגיונית ונכשלת בכל פעם, כי הכתובת הזו מסיימת את המנהרה ולא מארחת את המשחק. שחקן שמחובר לאותו VPN כבר יש לו מסלול אל מארח המשחק, ולכן הרשומה חייבת לציין את המארח ואת הפורט שהמשחק מאזין עליו. תקנו את שני אלה ושאר הבעיה היא זמינות שירות רגילה, רשימת בדיקה קצרה בהרבה ממה שנראה בהתחלה.
שתי כתובות, שני תפקידים
כתובת אחת היא תשתית ציבורית: נקודת הקצה של התעבורה שנושאת חבילות מוצפנות בין עמיתים. האחרת היא כתובת פרטית של המכונה שמריצה את השרת הייעודי. הן אינן ניתנות להחלפה, והחלפת האחת בשנייה מייצרת חיבור שנדחה או פסק זמן שנראה כמו בעיית חומת אש.
| Role | Address | Where it belongs |
|---|---|---|
| Public transport endpoint | 203.0.113.40 | VPN client configuration, never the game |
| Game host on the VPN | 10.60.0.20 | Server address field, with the port |
| Player peer | 10.60.0.30 | Assigned by the tunnel, nothing to type |
עם הפורט המוגדר כברירת מחדל, השחקן מקליד 10.60.0.20:25565 ולא שום דבר אחר. עמוד ההורדה של שרת ה-Java של Mojang מציין את 25565 כברירת מחדל, ולמפעיל שרת ששינה את הפורט צריך להאמין ולא לפקפק בו לפי מדריך ישן.
הפכו את הכתובת הזו לשירות אמיתי
כתובת נגישה היא הכרחית ואינה מספקת. השרת הייעודי חייב לפעול, להיות תואם לגרסה שהקליינט של השחקן מריץ, ולהאזין בכתובת שהמנהרה יכולה למסור אליה. תהליך שקשור רק ל-loopback לא הופך לנגיש מפני שמישהו הוסיף כתובת נוספת למכונה.
ודאו את המאזין לפני שנוגעים בחומת אש:
ss -lntp | grep 25565
nc -vz 10.60.0.20 25565השורה הראשונה מראה למה התהליך נקשר בפועל, והשנייה מראה אם עמית יכול להשלים לחיצת יד TCP. כשהקשירה היא 127.0.0.1, שום כמות של תצורת VPN לא משנה את התוצאה, והפרט הבודד הזה מסביר מספר מפתיע של דיווחים «ה-VPN שבור».
מדיניות עמיתים, חומת אש ומסלול החזרה
שתי שאלות הרשאה יושבות מעל המאזין. תצורת העמיתים של ה-VPN חייבת לאפשר תעבורה בין שני העמיתים, וחומת האש של מארח המשחק חייבת לקבל את פורט המשחק מאותו עמית. החזיקו את שתיהן מוגבלות לשירות המשחק ולעמיתים המורשים במקום לכבות את חומת האש של המארח, שמחליפה כלל של שתי שורות בבעיה גדולה בהרבה. כללים צרים הם גם הגרסה היחידה של זה שעוברת סקירת אבטחה בלי פסקת הצדקה.
אחר כך זכרו מה מוכיח ping מוצלח. הגעה לשער ה-VPN, או קבלת תשובה ממארח המשחק, מוכיחה רק ש-ICMP חצה את המסלול. חיבור משחק צריך שהפורט הספציפי יהיה פתוח בשני הכיוונים, ומסלול החזרה חשוב כמו המסלול היוצא.
כשהשרת יושב מאחורי השער
בדוגמה שלמעלה שרת המשחק הוא עמית, מה ששומר על תוכנית כתובות פשוטה. אם השרת נמצא במקום זאת ברשת מקומית מאחורי שער VPN, השחקן צריך את הכתובת הפרטית הניתנת לניתוב של השרת, השער צריך העברה מוגדרת לאותה רשת, ו המארח ברשת המקומית צריך מסלול חזרה אל הקליינט במנהרה. אם מפספסים את מסלול החזרה, לחיצת היד מתה באמצע, וזו התקלה המבלבלת ביותר מבין השלוש.
אל תעתיקו את כתובת העמית מהדוגמה למכונה אחרת כדי לחקות את הטופולוגיה הזו. כתובות בדוגמה מתארות תפקידים, ושימוש חוזר באחת בשני תפקידים יוצר חפיפה שהניתוב לא יכול לפתור.
גילוי, חשבונות ומה לא לשנות
גילוי LAN אוטומטי הוא נוחות הבנויה על הכרזות. VPN מנותב אינו חייב לשאת את השידורים האלה, ולכן רשומה חסרה ברשימת ה-LAN לא אומרת דבר על כך שהכתובת הפרטית המפורשת עובדת. הקלידו את הכתובת ואז שפטו. אם היא מתחברת, פער הגילוי הוא מטרד שמישות ולא תקלה, ואפשר לתעד אותו ככזה במקום לחקור אותו.
שמרו גם על אימות החשבון הרגיל ומדיניות הקבלה של המשחק ללא שינוי. מסלול פרטי שעובד מעניק מסלול, לא חברות, ושום סידור מחדש של עדיפויות מתאם לא מחליף את זיהוי היעד שהקליינט אמור להשתמש בו.