มีคนรันการตรวจพอร์ต เห็นคำว่าเปิด และถือว่าเซิร์ฟเวอร์ได้รับการแก้ไขแล้ว สิ่งที่ผลลัพธ์นั้นหมายถึงจริง ๆ นั้นแคบ: จากตำแหน่งของผู้ตรวจ ในขณะนั้น การเชื่อมต่อ TCP ไปยังที่อยู่และพอร์ตนั้นถูกยอมรับ มันไม่ได้บอกอะไรเกี่ยวกับแฮนด์เชกของโปรโตคอล Minecraft การยืนยันตัวตนบัญชี หรือว่าเซิร์ฟเวอร์อนุญาตให้ผู้เล่นเข้าสู่โลกหรือไม่

นี่คือสี่ชั้นที่แตกต่างกัน และความล้มเหลวในชั้นใดชั้นหนึ่งก็ทำให้ผู้เล่นพูดประโยคเดียวกัน: มันไม่ทำงาน

โพรบทดสอบเพียงสิ่งที่มองเห็นได้

การเชื่อมต่อ TCP จะสมบูรณ์เมื่อทั้งสองฝ่ายจบแฮนด์เชกแบบสามทาง ซึ่งอยู่ต่ำกว่าทุกสิ่งที่เกมรู้ โพรบรายงานว่ามีผู้รับฟังอยู่และตอบกลับจากตำแหน่งเครือข่ายของมัน มันไม่สามารถบอกคุณได้ว่าผู้รับฟังคือตัวเกม เพราะโปรเซสใดก็สามารถผูกพอร์ตและรับการเชื่อมต่อได้

ตำแหน่งสำคัญพอ ๆ กับผลลัพธ์ ผู้ตรวจบนอินเทอร์เน็ตสาธารณะทดสอบเส้นทางหนึ่งจากเครือข่ายหนึ่ง ผู้ตรวจที่ผู้ดูแลรันจากภายในเครือข่ายเดียวกันทดสอบเส้นทางที่ต่างออกไปโดยสิ้นเชิง และผลลัพธ์เชิงบวกที่นั่นแทบไม่บอกอะไรเกี่ยวกับสิ่งที่ผู้เล่นระยะไกลประสบ ผู้ตรวจสองตัวที่ต่างกันในผู้ให้บริการสองรายอาจไม่ตรงกันด้วยเหตุผลที่ไม่เกี่ยวข้องกับเซิร์ฟเวอร์ของคุณเลย

เวลาก็สำคัญ ผลของโพรบอธิบายช่วงเวลาที่มันทำงาน และการเชื่อมต่อที่บ้านซึ่งมีที่อยู่แบบไดนามิกหรือกฎการส่งต่อที่เปลี่ยนไปอาจเลื่อนคำตอบจริงออกไปไม่กี่นาที บันทึกที่อยู่สาธารณะ พอร์ต ตระกูลที่อยู่ และเวลาพร้อมกับคำตัดสิน มิฉะนั้นการสังเกตจะทำซ้ำไม่ได้ ทำการตรวจซ้ำจากเครือข่ายที่ต่างกันจริง ๆ ไม่ใช่จากโทรศัพท์บนการเชื่อมต่อเดียวกัน

สี่ชั้นระหว่างซ็อกเก็ตกับผู้เล่น

ลองนึกถึงลำดับที่ไคลเอนต์ที่เข้าร่วมทำจริง ขั้นแรกมันแปลงที่อยู่ จากนั้นเปิดการเชื่อมต่อ TCP ไปยังพอร์ตที่ประกาศ จากนั้นพูดโปรโตคอลของเกมเองเพื่อเจรจาและยืนยันตัวตน และสุดท้ายเซิร์ฟเวอร์ตัดสินใจว่าตัวตนนั้นได้รับอนุญาตให้เข้าสู่โลกหรือไม่ แต่ละชั้นมีลายเซ็นความล้มเหลวของตัวเอง และมีเพียงชั้นแรกเท่านั้นที่ผู้ตรวจพอร์ตมองเห็น

พอร์ตเริ่มต้นของ Java Edition คือ 25565 แต่ผู้ดูแลอาจประกาศพอร์ตภายนอกที่แตกต่างและส่งต่อไปยังภายใน ดังนั้นตัวเลขที่ผู้เล่นพิมพ์อาจไม่ใช่ตัวเลขที่เซิร์ฟเวอร์เห็น ผู้ตรวจที่เล็งไปยังพอร์ตภายนอกผิดจะรายงานว่าปิดในขณะที่เซิร์ฟเวอร์สมบูรณ์ดี และนี่คือสัญญาณเตือนผิดที่พบบ่อยที่สุดในสาขาทั้งหมดนี้

ชื่อเพิ่มอีกขั้นเหนือพอร์ต หากผู้เล่นพิมพ์ชื่อโฮสต์ การแปลงชื่อต้องคืนที่อยู่ที่ประกาศ และบนเครื่องภายในเครือข่ายอาจคืนที่อยู่ส่วนตัวแทน นั่นไม่ใช่ความล้มเหลวของไฟร์วอลล์ และการส่งต่อพอร์ตไม่ว่าจะมากเพียงใดก็ไม่เปลี่ยนสิ่งนั้น

ทำไมผู้เล่นภายในจึงใช้เส้นทางที่แตกต่าง

ผู้เล่นบน LAN เดียวกัน หรือบน VPN ที่เข้าถึง LAN นั้น พยายามเข้าถึงที่อยู่สาธารณะจากภายใน คำขอไปยังที่อยู่ภายนอกของเราเตอร์ และเราเตอร์ต้องแปลกลับเข้าสู่ภายใน ซึ่งเป็นรูปแบบที่มักเรียกว่า hairpinning หรือการสะท้อน NAT ทั้งการแปลไปข้างหน้าและเส้นทางกลับต้องสอดคล้องกันเพื่อให้ทำงานได้ และเราเตอร์สำหรับบ้านจำนวนมากไม่ได้นำมาใช้เลย

นี่คือเหตุผลที่แขกจากภายนอกเข้าร่วมได้ แต่คนที่นั่งข้างเซิร์ฟเวอร์ทำไม่ได้ เส้นทางภายนอกดีจริง ๆ สิ่งที่ล้มเหลวคือทางอ้อมภายใน และมันล้มเหลวในลักษณะที่จากหน้าจอของผู้เล่นดูเหมือนปัญหาเซิร์ฟเวอร์ บันทึกของเซิร์ฟเวอร์เองเป็นตัวตัดสินว่าเกิดอะไรขึ้น เพราะการเชื่อมต่อที่ไม่เคยถูกแปลจะไม่ไปถึงมันเลย

มีวิธีแก้ที่ซื่อสัตย์สองวิธีและนิสัยแย่หนึ่งอย่าง ตัวเลือกที่ดีคือปล่อยให้ผู้เล่นภายใน ใช้ที่อยู่ส่วนตัวหรือชื่อ split-DNS ที่แปลงภายในไปยังที่อยู่ส่วนตัว หรือเปิดการสะท้อนบนเราเตอร์หากคุณสมบัตินั้นมีอยู่และทำงานถูกต้อง นิสัยแย่คือการเปิดพอร์ตเพิ่มหรือปิดไฟร์วอลล์ของโฮสต์ ซึ่งไม่สามารถส่งผลต่อการแปลที่เราเตอร์ไม่เคยทำ

เอกสารของ Netgate เกี่ยวกับการสะท้อน NAT อธิบายความแตกต่างระหว่างภายนอกและภายในและทางเลือก split-DNS อย่างละเอียดกว่า อ่านมันในฐานะคำอธิบายกลไก ไม่ใช่คำสัญญาว่าผู้ให้บริการ VPN หรือเราเตอร์ใด ๆ จะรองรับทุกรูปแบบของ loopback

รวบรวมหลักฐานจากทุกมุมมอง

สำหรับการทดสอบแต่ละครั้ง ให้บันทึกว่าใครเป็นคนรัน จากที่ไหน เวลาใด ต่อที่อยู่และพอร์ตใด และเซิร์ฟเวอร์บันทึกอะไร การปฏิเสธของเกมพร้อมเหตุผลชัดเจนในคอนโซลเซิร์ฟเวอร์เป็นการค้นพบที่ต่างจากการเชื่อมต่อที่ไม่เคยมาถึง และทั้งสองนำไปสู่ทิศทางตรงกันข้าม

หากผู้เล่นระยะไกลที่ได้รับอนุญาตเข้าร่วมได้ แต่ผู้เล่นในเครื่องหนึ่งคนทำไม่ได้ เส้นทางภายในคือคำถามที่เหลือและควรค่าแก่การสอบสวนของตัวเอง: ไคลเอนต์ใช้ที่อยู่ใด เราเตอร์ทำอะไรกับการแปล และเซิร์ฟเวอร์บันทึกความพยายามเชื่อมต่อใด ๆ หรือไม่ ส่งข้อเท็จจริงสามข้อนั้นให้เจ้าของเครือข่ายแทนการเปิดพอร์ตซ้ำแบบสุ่ม

บทความที่เกี่ยวข้อง