รายการเกม LAN ว่างผ่าน OpenVPN? ตรวจสอบเส้นทางการค้นพบ

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

แยกการเข้าร่วมเซสชันออกจากการค้นหาเซสชัน

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

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

ทดสอบการเข้าร่วมโดยตรงก่อนแตะทันเนล

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

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

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

ทำความเข้าใจว่าการแพร่กระจายสิ้นสุดตรงไหน

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

นี่คือคุณสมบัติของการออกแบบ ไม่ใช่ข้อบกพร่องที่ปะด้วยตัวเลือก OpenVPN และ client-to-client การตั้งค่าของมันควบคุมทราฟฟิกระหว่างเพียร์ภายในทันเนลและไม่ใช่รีเลย์ค้นพบ แม้จะถูกเสนอเพื่อจุดประสงค์นี้ในหลายกระทู้ รีเลย์เป็นองค์ประกอบแยกต่างหากที่มีการกำหนดค่าและโหมดความล้มเหลวของตัวเอง การถือว่าตัวเลือกที่มีอยู่ครอบคลุมสิ่งนี้แล้วคือสาเหตุที่พบบ่อยที่สุดที่การสอบสวนนี้ติดขัด

การค้นพบแบบมัลติแคสต์มีปัญหาเดียวกันกับคลาสที่อยู่ต่างกัน และต้องใช้การกำหนดเส้นทางมัลติแคสต์หรือรีเลย์ ไม่ใช่ข้อยกเว้นการแพร่กระจาย

เมื่อรีเลย์สมเหตุสมผล ให้จำกัดให้แคบ

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

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

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

ทำบริดจ์เฉพาะเมื่อการออกแบบต้องการ Ethernet

เฟรม Ethernet เดินทางภายใน TAP ดังนั้นทันเนล TAP จึงอาจอยู่ในโดเมนการแพร่กระจายที่ทำบริดจ์ไว้โดยเจตนา การเพียงแค่ dev tun เป็น dev tap ไม่ได้สร้างบริดจ์นั้น ไม่ได้ทำให้การกำหนดค่าเซิร์ฟเวอร์เข้ากันได้ และไม่ได้ทำให้แอปพลิเคชันเลือกอินเทอร์เฟซใหม่ คู่มือบริดจ์ของ OpenVPN อธิบายการจัดวางที่กว้างกว่า ไม่ใช่ยาสำหรับล็อบบี้ว่างหนึ่งแห่ง

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

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