SSM qua OpenVPN: theo dõi một nguồn và một nhóm từ đầu đến cuối

Chọn một luồng và một bộ nhận, rồi theo dõi cặp đó qua từng chặng thay vì kiểm tra multicast như một phạm trù. Thiết kế dành riêng cho nguồn thất bại đúng ở một trong bốn chỗ: bộ nhận chưa bao giờ tham gia, bộ định tuyến từ chối gói trên đường trở về, nhân không có trạng thái, hoặc đường hầm chưa bao giờ giao được bản sao. Làm việc theo trình tự đó tốn vài phút mỗi chặng và cho bạn biết bạn thực sự đang ở trường hợp nào trong bốn trường hợp.

Trước hết cố định nguồn, nhóm và bộ nhận

Ghi lại ba giá trị trước khi chạm vào bất kỳ thiết bị nào: địa chỉ nguồn sẽ gửi, địa chỉ nhóm mà bộ nhận sẽ tham gia, và mạng con nơi bộ nhận đang ở. Với một luồng IPv4 minh họa, nguồn 10.50.0.10 và nhóm 232.20.30.40 là kiểu cặp phù hợp với thiết kế dành riêng cho nguồn. Bất cứ điều gì mơ hồ hơn ba giá trị đó đều không thể kiểm tra.

Dải 232/8 được dành riêng cho multicast dành riêng cho nguồn, và mô hình được mô tả trong RFC 4607. Nếu nhóm của bạn nằm ngoài dải đó trong khi bạn cho rằng mình đang chạy SSM, hãy dừng lại và xác nhận ý định thực sự của việc triển khai, vì việc tham gia của bộ nhận và quyết định chuyển tiếp của bộ định tuyến đều phụ thuộc vào mô hình nhất quán.

Kiểm tra xem bộ nhận đã tham gia nguồn chưa

Báo cáo thành viên chỉ cho nhóm không phải là tham gia dành riêng cho nguồn. Hỏi bộ nhận xem nó đã yêu cầu nguồn nào, và trên bộ định tuyến chặng đầu hãy xem trạng thái nhóm để biết danh sách nguồn có xuất hiện không. Nếu báo cáo không mang nguồn nào, bộ định tuyến sẽ coi đó là tham gia từ bất kỳ nguồn nào và toàn bộ thiết kế lặng lẽ thoái hóa thành thứ bạn không hề lên kế hoạch.

Trên một bộ nhận Linux, kiểm tra socket thực sự đã đăng ký điều gì và nhân đã ghi lại điều gì. Tệp cấu hình của ứng dụng không phải bằng chứng; bảng thành viên mới là bằng chứng. Hãy đọc nó khi bộ nhận thực sự đang chạy, vì một mục có thể tồn tại chốc lát sau khi tiến trình tạo ra nó kết thúc. Một mục cũ từ lần thử trước là nguồn đáng tin cậy của sự tự tin giả tạo.

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

Nếu có tham gia với nguồn mong đợi, hãy chuyển sang các bộ định tuyến. Nếu không có, không cấu hình đường hầm nào giúp được, vì không có gì để chuyển tiếp.

Xác minh đường trở về trước khi nhìn vào đường hầm

Định tuyến multicast thực hiện kiểm tra đường trở về, và gói đến trên một giao diện khác với giao diện mà tuyến unicast chỉ tới sẽ bị loại bỏ. Đây là lý do phổ biến nhất khiến một luồng rõ ràng đang được gửi không bao giờ tới được chặng tiếp theo, và nó hoàn toàn không tạo ra lỗi hữu ích nào ở tầng ứng dụng.

Trên bộ định tuyến hướng về nguồn, so sánh tuyến tới nguồn với giao diện mà các gói thực sự đến. Trên bộ định tuyến hướng về bộ nhận, làm điều tương tự cho mạng con của chính bộ nhận và xác nhận danh sách giao diện ra có bao gồm liên kết về phía đó. Sự không khớp theo bất kỳ hướng nào là lỗi RPF, không phải lỗi thành viên.

Sau đó xác nhận TTL của nguồn đủ lớn để sống qua các chặng đã định tuyến mà bạn thiết kế. Một luồng chạy được trên bộ định tuyến thứ nhất và chết ở bộ thứ hai thường là câu hỏi TTL chứ không phải câu hỏi chính sách.

Đọc trạng thái multicast của nhân thay vì cấu hình

Cấu hình cho bạn biết bạn đã yêu cầu gì; nhân cho bạn biết điều gì đang diễn ra. Trên mỗi chặng Linux, đọc các mục định tuyến multicast và xác nhận có danh sách giao diện vào và ra cho đúng cặp nguồn và nhóm. Một mục cho nhóm với nguồn đại diện là đối tượng khác, và nó sẽ không giải thích luồng dành riêng cho nguồn.

ip mroute show from 10.50.0.10 iif eth1
ip route get 10.50.0.10

Các daemon định tuyến giữ quan điểm riêng của chúng bên trên trạng thái đó, và lệnh in ra nó phụ thuộc vào việc đã cài đặt triển khai nào. Nguyên tắc là bất biến: hỏi daemon mục thượng nguồn của nó cho cặp, rồi hỏi nhân xem có mục chuyển tiếp hay không. Một daemon nghĩ rằng nó đang chuyển tiếp trong khi nhân không có mục nào là vấn đề phạm vi cấu hình trên máy đó.

Khi hai bên không đồng ý, hãy sửa máy chứ không phải VPN. Không gì ở hạ nguồn bù đắp được một chặng không chuyển tiếp luồng bạn đã hỏi. Ghi lại cặp, giao diện vào và danh sách ra cho từng chặng khi luồng đang chạy. Bản ghi đó biến lần hỏng tiếp theo thành một phép so sánh thay vì một cuộc điều tra mới.

Quyết định cách đường hầm thực sự nhân bản

Đây là chỗ multicast qua VPN không còn là công việc thường nhật. Đường hầm điểm-điểm giao gói cho đúng một đầu cuối ở phía bên kia, nên một bản sao chỉ tới đúng một máy khách. Một phân đoạn được bắc cầu hành xử giống một liên kết chia sẻ hơn, vì đường hầm mang khung còn cầu quyết định thứ gì sẽ được tràn. Đây là những mô hình phân phối khác nhau, và một thiết kế giả định mô hình thứ hai trong khi chạy mô hình thứ nhất sẽ có vẻ hoạt động với một bộ nhận và hỏng với bộ nhận kế tiếp.

Với nhiều hơn một bộ nhận qua một máy chủ đa điểm, việc nhân bản phải được thiết kế một cách tường minh. Cài một tuyến multicast trên cổng không dạy máy chủ VPN biết những đầu cuối nào nên nhận bản sao, và không tuyến phía máy khách nào đưa ra quyết định đó thay nó. Khi yêu cầu là nhiều bộ nhận, hãy dùng nhân bản được hỗ trợ hoặc một phương án được chọn có chủ đích, và ghi lại bạn đã chọn phương án nào.

Cuối cùng, xác minh tại bộ nhận với một quan sát hẹp: đúng nguồn, nhóm và cổng, trên giao diện bạn mong đợi, trong khi một bộ nhận được ủy quyền đã tham gia. SSM chọn một nguồn gửi, và việc chọn lựa không phải là xác thực nguồn gửi đó, cũng không phải sự cho phép để lưu lượng multicast khác đi qua cùng chính sách.