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 ข้ามเส้นทางไปแล้ว การเชื่อมต่อเกมต้องให้พอร์ตเฉพาะเปิดทั้งสองทิศทาง และเส้นทางขากลับสำคัญพอ ๆ กับขาออก
เมื่อเซิร์ฟเวอร์อยู่หลังเกตเวย์
ในตัวอย่างข้างต้นเซิร์ฟเวอร์เกมเป็นเพื่อน ซึ่งทำให้แผนที่อยู่เรียบง่าย หากเซิร์ฟเวอร์อยู่ใน LAN หลังเกตเวย์ VPN ผู้เล่นต้องใช้ที่อยู่ส่วนตัวที่กำหนดเส้นทางได้ของเซิร์ฟเวอร์ เกตเวย์ต้องตั้งค่าการส่งต่อสำหรับ LAN นั้น และ โฮสต์ใน LAN ต้องมีเส้นทางกลับไปยังไคลเอนต์ในอุโมงค์ หากพลาดเส้นทางขากลับ แฮนด์เชกจะตายกลางทาง ซึ่งเป็นความล้มเหลวที่สับสนที่สุดในสามข้อ
อย่าคัดลอกที่อยู่เพื่อนจากตัวอย่างไปยังเครื่องอื่นเพื่อเลียนแบบโครงสร้างนี้ ที่อยู่ในตัวอย่างอธิบายบทบาท และการใช้ที่อยู่เดียวในสองบทบาททำให้เกิดการทับซ้อนที่การกำหนดเส้นทางแก้ไม่ได้
การค้นหา บัญชี และสิ่งที่ไม่ควรเปลี่ยน
การค้นหา LAN อัตโนมัติเป็นความสะดวกที่สร้างบนประกาศ VPN ที่กำหนดเส้นทางไม่จำเป็นต้องบรรทุกการออกอากาศเหล่านั้น ดังนั้นรายการที่หายไปในรายการ LAN จึงไม่บอกอะไรว่าที่อยู่ส่วนตัวที่ระบุชัดเจนทำงานหรือไม่ พิมพ์ที่อยู่แล้วจึงตัดสิน หากเชื่อมต่อได้ ช่องว่างการค้นหาเป็นความไม่สะดวกในการใช้งาน ไม่ใช่ข้อบกพร่อง และสามารถบันทึกไว้เช่นนั้นแทนการสอบสวน
รักษาการยืนยันตัวตนบัญชีปกติและนโยบายการรับเข้าของเกมไว้เช่นกัน เส้นทางส่วนตัวที่ทำงานได้ให้เส้นทาง ไม่ใช่สมาชิกภาพ และการสลับลำดับความสำคัญของอะแดปเตอร์ไม่สามารถแทนการระบุปลายทางที่ไคลเอนต์ควรใช้