แคสต์ผ่าน VPN: การค้นหา การควบคุม หรือสตรีม?
ตัวรับที่หายไป เซสชันที่ถูกปฏิเสธ และสตรีมที่หยุดชะงัก ล้มเหลวคนละจุด ระบุระยะก่อนเปลี่ยนนโยบาย VPN ของโทรศัพท์หรือเครือข่าย
การแคสต์พังในสามจุดที่มองจากโซฟาแล้วเหมือนกันหมด โทรศัพท์อาจไม่เห็นตัวรับเลย ตัวรับอาจปรากฏขึ้นแล้วปฏิเสธเซสชัน หรือเซสชันอาจเริ่มแล้วหยุดชะงักในอีกหนึ่งนาที อุโมงค์บนโทรศัพท์เปลี่ยนแต่ละเส้นทางนั้นต่างกัน และสำหรับเส้นทางหนึ่งมันไม่เปลี่ยนอะไรเลย ระบุระยะที่ล้มเหลวก่อน แล้วค่อยตัดสินว่าการเปลี่ยนนโยบายเป็นคันโยกที่ถูกต้องหรือไม่
ระบุระยะที่ล้มเหลวก่อนเปลี่ยนนโยบาย
ดูว่าโทรศัพท์ทำอะไรทันทีหลังจากคุณแตะไอคอนแคสต์ รายการว่างคือผลของการค้นหา การแตะที่รายงานข้อผิดพลาดคือผลของการควบคุม และเซสชันที่เริ่มก่อนจะหยุดคือผลของการเล่น สามอย่างนี้มีเจ้าของต่างกัน และโดยปกติมีเพียงสองอย่างแรกที่เกี่ยวกับการตั้งค่าอุโมงค์ของโทรศัพท์
| Stage | What the phone shows | Evidence that separates it |
|---|---|---|
| Discovery | No receiver in the list | Another device on the same segment sees the receiver |
| Control | Receiver listed, session refused | Port answer versus permission prompt |
| Playback | Session starts, then stalls | The receiver's own link, not the phone's |
จดระยะไว้ก่อนเปลี่ยนอะไร การแก้ไขที่ใช้กับระยะผิดทำให้การทดสอบครั้งถัดไปอ่านไม่ออก และตำนานแคสต์ส่วนใหญ่มาจากความสับสนนั้นเอง
การค้นหาเป็นทราฟฟิกในวง และอุโมงค์ซ่อนมันไว้
ตัวรับประกาศตัวเองผ่านการประกาศในวง และโทรศัพท์หาพวกมันด้วยคำถามบนลิงก์เดียวกัน ดังนั้นอะไรก็ตามที่เอาโทรศัพท์ออกจากลิงก์นั้นก็เอาตัวรับออกจากรายการด้วย อุโมงค์ที่เปลี่ยนเส้นทางทราฟฟิกทั้งหมดออกจาก LAN อาจซ่อนการแลกเปลี่ยนเหล่านั้น และสิทธิ์เข้าถึงเครือข่ายในวงระดับแอปอาจบล็อกได้แม้เส้นทางจะมีอยู่ Wi-Fi สำหรับแขกที่มีการแยกไคลเอนต์ให้รายการว่างแบบเดียวกันโดยไม่มี VPN เลย พิสูจน์ว่าอุปกรณ์ทั้งสองอยู่ในเซกเมนต์เดียวกันก่อนโทษอุโมงค์
avahi-browse -at | grep -i -E 'chromecast|googlecast'
dig +short @224.0.0.251 -p 5353 _googlecast._tcp.local PTRคำสั่งแรกแสดงสิ่งที่ประกาศตัวเองในเซกเมนต์ของเครื่องช่วย และคำสั่งที่สองถามกลุ่ม multicast DNS โดยตรง ตัวรับที่ไม่มีในทั้งสองก็จะไม่ปรากฏในแอปบนโทรศัพท์เช่นกัน ไม่ว่าสถานะอุโมงค์ของโทรศัพท์จะเป็นอย่างไร ถ้าตัวรับมองเห็นได้จากอุปกรณ์ที่ปิดอุโมงค์และมองไม่เห็นจากอุปกรณ์ที่เปิดอุโมงค์ คุณก็พบทั้งระยะและสาเหตุพร้อมกัน
ข้อยกเว้น LAN ทำให้อุโมงค์ยังทำงานอยู่
ไคลเอนต์จำนวนมากมีข้อยกเว้นเครือข่ายในวงที่ทำให้อุโมงค์ยังทำงานอยู่แต่ยอมให้ใช้ที่อยู่ในวง ใช้การตั้งค่าที่มีเอกสารนั้นแทนการปิดคิลสวิตช์หรือไฟร์วอลล์ทั้งหมด เพราะสิ่งเหล่านั้นเปลี่ยนไปไกลกว่าที่การแคสต์ต้องการ ถ้าเครือข่ายแยกอุปกรณ์อัจฉริยะโดยเจตนา ให้ขอเจ้าของสำหรับทราฟฟิกการค้นหา การควบคุม และการตอบกลับที่เฉพาะเจาะจง แทนที่จะขอการเข้าถึงแบบเปิด
nc -vz 192.168.1.50 8009การทดสอบควบคุมไปยังตัวรับแยกสิทธิ์ออกจากการเข้าถึงได้: พอร์ตที่ตอบกลับหมายความว่าเส้นทางมีอยู่ ส่วนการปฏิเสธหมายความว่าโทรศัพท์ได้รับอนุญาตให้ค้นหาอุปกรณ์และยังคุยกับมันไม่ได้ พอร์ต 8008 และ 8009 เป็นพอร์ตแคสต์ปกติ และแอปอาจใช้พอร์ตอื่น ดังนั้นให้ถือพอร์ตที่ถูกปฏิเสธหนึ่งพอร์ตเป็นเบาะแส ไม่ใช่คำตัดสิน ข้อยกเว้นและสิทธิ์ของแอปยังเป็นอิสระจากกัน เพราะการให้สิทธิ์ในวงไม่ได้สร้างเส้นทาง และการเพิ่มเส้นทางไม่ได้ให้สิทธิ์ คิลสวิตช์ยังอาจทิ้งทราฟฟิกในวงหลังเชื่อมต่อใหม่ ซึ่งเป็นเหตุผลที่ต้องทดสอบการค้นหาซ้ำเมื่ออุโมงค์กลับมา
การเล่นอาจไม่ใช้การเชื่อมต่อของโทรศัพท์
ในเซสชันที่แอปเป็นผู้นำ โทรศัพท์ส่งที่อยู่สื่อให้ตัวรับ และตัวรับดึงมันผ่านการเชื่อมต่อของตัวเอง การเปลี่ยนที่อยู่สาธารณะของโทรศัพท์จึงไม่ทำอะไรกับสตรีม ชื่อเรื่องที่จำกัดด้วยบัญชีอาจยังล้มเหลวด้วยเหตุผลของมันเอง และ ข้อกำหนดการแคสต์ของ Google ครอบคลุมความเข้ากันได้ของแอปและอุปกรณ์ ไม่ใช่เส้นทางเครือข่าย การส่งโทรทัศน์เองผ่านอุโมงค์เป็นการกำหนดค่าอีกแบบที่มีคำถามเชิงนโยบายของมันเอง
สองเบาะแสแยกโหมดออกจากกัน การแคสต์ที่ยังเล่นต่อแม้ล็อกหน้าจอโทรศัพท์เป็นการนำโดยแอป เพราะตัวรับดึงเอง การสะท้อนที่หยุดเมื่อหน้าจอผู้ส่งล็อกคือสตรีมต่อเนื่องจากโทรศัพท์ เมื่อการค้นหาและการควบคุมสำเร็จแต่การเล่นหยุดชะงัก ให้ดูที่ลิงก์ Wi-Fi ของตัวรับและเส้นทางอินเทอร์เน็ตของมันแทน เพราะการทดสอบความเร็วบนโทรศัพท์อธิบายโทรศัพท์ ไม่ใช่โทรทัศน์
ย้อนข้อยกเว้นและทดสอบใหม่
การเปลี่ยนแปลงชั่วคราวทุกอย่างต้องมีทางกลับ และลำดับสำคัญ ให้ลบข้อยกเว้น LAN เชื่อมต่ออุโมงค์ใหม่เพื่อให้ไคลเอนต์ใช้นโยบายอีกครั้ง จากนั้นทำขั้นตอนการค้นหาซ้ำและจดว่าตัวรับหายไปอีกหรือไม่ ลำดับนั้นบอกคุณว่าข้อยกเว้นทำงานอยู่หรือมีอย่างอื่นเปลี่ยนไปในระหว่างนั้น
# after removing the LAN exception, reconnect and confirm the tunnel is up
resolvectl status | grep -E 'DNS Servers|Default Route|Protocols'
avahi-browse -at | grep -i -E 'chromecast|googlecast'หลังจากนั้นตรวจสอบทั้งสามระยะแยกกัน เพราะการผ่านของระยะหนึ่งไม่ได้บอกอะไรเกี่ยวกับระยะอื่น จากนั้นตรวจสอบว่าแอปอื่นที่ไม่เกี่ยวข้องบนโทรศัพท์ยังไปตามเส้นทางที่ตั้งใจหรือไม่ เพราะข้อยกเว้นในวงที่กลายเป็นทางอ้อมเต็มรูปแบบอย่างเงียบ ๆ เป็นผลลัพธ์ที่แย่กว่าการแคสต์ที่ต้องแตะเพิ่มหนึ่งครั้ง