การค้นหา Chromecast และ DLNA ไม่เคยข้าม VPN ที่ถูกกำหนดเส้นทาง

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

การเข้าถึงปกติดี การค้นหาหายไป

ความเชื่อผิด: อุโมงค์ต้องมีการตั้งค่าหรือความจุมากกว่านี้

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

การเปลี่ยนการตั้งค่าอาจทำให้ความล้มเหลวดังขึ้น แต่ไม่สามารถทำให้ประกาศปรากฏในที่ที่โปรโตคอลไม่เคยส่งมา

การแลกเปลี่ยนการค้นหาคืออะไรกันแน่

สามรูปแบบครอบคลุมเกือบทุกอย่างที่คุณจะพบ mDNS ส่งไปยัง 224.0.0.251 บน UDP 5353, SSDP ส่งไปยัง 239.255.255.250 บน UDP 1900 และรายการท่อง SMB แบบเก่าส่งไปยังที่อยู่แพร่ภาพของซับเน็ต แต่ละอย่างส่งถึงกลุ่มไม่ใช่โฮสต์ และแต่ละอย่างคาดหวังผู้ฟังบนเซกเมนต์เดียวกัน ผู้รับอีกฝั่งของอุโมงค์ที่กำหนดเส้นทางไม่ได้อยู่ในเซกเมนต์นั้น จึงไม่มีอะไรมาถึง

แม้ประกาศที่ส่งต่อไปก็มีเพย์โหลด คือที่อยู่ LAN และพอร์ตของผู้ส่ง ซึ่งผู้ชมระยะไกลต้องเข้าถึงได้

อ่านแคปเจอร์ก่อนเปลี่ยนอุโมงค์

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

แคปเจอร์สองนาทีแทนการเดาเรื่องพอร์ตเป็นชั่วโมง: tcpdump -ni tun0 udp port 5353 or udp port 1900.

สามวิธีแก้ เรียงจากถูกที่สุดก่อน

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

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

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

อะไรที่ไม่ช่วย ไม่ว่าจะแนะนำบ่อยแค่ไหน

การเปลี่ยนจาก dev tun เป็น dev tap โดยไม่มีบริดจ์ยังคงเหลืออุปกรณ์ TAP ที่ถูกกำหนดเส้นทางอยู่ พฤติกรรมจึงไม่เปลี่ยน client-to-client อนุญาตยูนิแคสต์ระหว่างเพียร์และไม่ท่วมการแพร่ภาพ การส่งต่อพอร์ตค้นหาไปยังโฮสต์เดียวไม่ได้ส่งทราฟฟิกที่มีที่อยู่แบบกลุ่ม เซิร์ฟเวอร์มีเดียที่ผูกกับที่อยู่เดียวจะตอบบนที่อยู่นั้นต่อไปจนกว่าการกำหนดค่าของมันเองจะระบุอินเทอร์เฟซ VPN

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