ทำไมมัลติคาสต์จึงไม่ข้าม VPN หากไม่มีแผน

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

เริ่มจากกลุ่มและแอปพลิเคชัน

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

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

การค้นหาในลิงก์ท้องถิ่นควรหยุด

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

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

สามสิ่งที่มัลติคาสต์แบบกำหนดเส้นทางต้องการ

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

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

ip maddr show dev tun0
ip mroute show
ss -gnu | grep 239.255.0.10
ip route get 10.20.5.20

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

พิสูจน์ด้วยต้นทางหนึ่งและผู้รับหนึ่ง

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

tcpdump -ni tun0 -c 10 'ip multicast'
tcpdump -ni eth0 -c 10 'ip multicast and host 239.255.0.10'

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

เลือกที่อยู่บริการเมื่อต้องการเพียงบริการ

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

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