SSM บน OpenVPN: ติดตามหนึ่งแหล่งและหนึ่งกลุ่มตั้งแต่ต้นจนจบ

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

กำหนดแหล่ง กลุ่ม และผู้รับก่อน

จดค่าสามค่าก่อนแตะอุปกรณ์ใด ๆ ที่อยู่ต้นทางที่จะส่ง ที่อยู่กลุ่มที่ผู้รับจะเข้าร่วม และซับเน็ตที่ผู้รับอยู่ สำหรับสตรีม IPv4 ตัวอย่าง แหล่ง 10.50.0.10 และกลุ่ม 232.20.30.40 คือคู่ที่เหมาะกับการออกแบบเฉพาะเจาะจงแหล่ง อะไรที่คลุมเครือกว่าสามค่านี้ทดสอบไม่ได้

ช่วง 232/8 สงวนไว้สำหรับ multicast ที่เฉพาะเจาะจงแหล่ง และแบบจำลองอธิบายไว้ใน RFC 4607 หากกลุ่มของคุณอยู่นอกช่วงนั้นในขณะที่คุณคิดว่ากำลังรัน SSM ให้หยุดและยืนยันว่าการติดตั้งตั้งใจไว้จริง ๆ อย่างไร เพราะการเข้าร่วมของผู้รับและการตัดสินใจส่งต่อของเราเตอร์ต่างก็ขึ้นกับความสอดคล้องของแบบจำลอง

ตรวจสอบว่าผู้รับเข้าร่วมกับแหล่งแล้ว

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

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

ip maddr show dev eth0
cat /proc/net/igmp | sed -n '1,40p'

หากการเข้าร่วมมีอยู่พร้อมแหล่งที่คาดไว้ ให้ไปที่เราเตอร์ หากไม่มี การกำหนดค่าอุโมงค์ใด ๆ ก็ไม่ช่วย เพราะไม่มีอะไรให้ส่งต่อ

ตรวจสอบเส้นทางย้อนกลับก่อนดูอุโมงค์

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

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

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

อ่านสถานะ multicast ของเคอร์เนลแทนการกำหนดค่า

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

ip mroute show from 10.50.0.10 iif eth1
ip route get 10.50.0.10

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

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

ตัดสินใจว่าอุโมงค์ทำสำเนาจริงอย่างไร

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

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

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