Vì sao multicast không đi qua VPN nếu không có kế hoạch

Hai site có thể đến được nhau hoàn hảo qua unicast mà vẫn hành xử như thể một bên không thấy thông báo khám phá của máy in, luồng IPTV hay nhịp tim của cụm. Đây không phải đường hầm hỏng; đây là khác biệt giữa một đích đến và một nhóm. Việc phân phối multicast cần một mô hình thành viên, trạng thái chuyển tiếp dọc đường đi và một giao diện sẵn sàng mang lưu lượng, và không thứ nào trong đó đến từ một tuyến unicast. Đi từ nhóm của ứng dụng đến một bên nhận hoạt động được là con đường ngắn nhất tới câu trả lời.

Bắt đầu từ nhóm và ứng dụng

Hỏi ứng dụng dùng địa chỉ nhóm nào và lưu lượng để làm gì. Một giao thức khám phá thông báo dịch vụ, một luồng phát trực tuyến và các gói hello của giao thức định tuyến là ba vấn đề khác nhau với ba câu trả lời chấp nhận được khác nhau. Bản thân địa chỉ nhóm cho biết phạm vi: các địa chỉ trong khối điều khiển mạng cục bộ không nhằm được định tuyến chuyển ra ngoài liên kết, và các ứng dụng dùng chúng thường giả định một miền quảng bá duy nhất. Một luồng phát trực tuyến trên nhóm có phạm vi toàn cầu là thiết kế khác với giao thức khám phá vốn chờ mọi thiết bị nghe mọi truy vấn, và chỉ cái thứ hai mới quan tâm đến kích thước của miền quảng bá.

Quyết định xem yêu cầu là dịch vụ hay cơ chế khám phá, vì hai câu trả lời đó khác nhau về chi phí một bậc. Một bên yêu cầu một địa chỉ không đổi; bên kia yêu cầu một miền quảng bá mở rộng qua một liên kết diện rộng cùng mọi thứ theo sau.

Khám phá cục bộ lẽ ra phải dừng lại

Multicast DNS như mô tả trong RFC 6762 được thiết kế quanh một liên kết: truy vấn đi tới một nhóm cố định, câu trả lời được gửi tới cùng nhóm đó, và giao thức dựa vào việc mọi thành viên nghe được tất cả. Bộ định tuyến không chuyển tiếp lưu lượng đó theo mặc định, và đó là quyết định thiết kế chứ không phải sơ suất. Ranh giới tồn tại để một thiết bị trong tòa nhà này không thể tùy tiện tự thông báo sang tòa nhà khác. Một đường hầm có vẻ sửa được khám phá bằng cách mang nhóm đi khắp nơi đã gỡ bỏ ranh giới đó cho mọi ứng dụng, không chỉ cho ứng dụng đang cần giúp.

Bộ lặp và bộ phản xạ có tồn tại, và chúng là dịch vụ thật với hậu quả thật: mọi tên được thông báo ở một site trở nên hiển thị ở site kia, kể cả tên thiết bị nhận diện người hay thiết bị. Nếu yêu cầu thực sự là một dịch vụ cụ thể phải tìm được, thì một bản ghi dịch vụ công bố trong DNS thường là thay đổi nhỏ hơn, và nó chỉ tiết lộ một tên thay vì cả dòng tên.

Ba thứ mà multicast được định tuyến cần

Multicast được định tuyến cần ba thứ làm việc cùng nhau: các bên nhận tham gia nhóm, bộ định tuyến duy trì trạng thái chuyển tiếp cho nhóm, và một đường hầm coi địa chỉ nhóm là lưu lượng cần mang. Một đường hầm có chính sách chỉ liệt kê các mạng con unicast sẽ bỏ lưu lượng của nhóm tại ranh giới mã hóa, và đó là lý do triệu chứng đầu tiên thường là im lặng chứ không phải lỗi. Một giao diện dựa trên tuyến như đường hầm GRE hay VTI mang những gì bảng định tuyến gửi vào, điều này làm nhóm đến được khi trạng thái multicast đã tồn tại.

Khả năng tiếp cận nguồn là nửa còn lại. Các giao thức định tuyến multicast như PIM xây cây phân phối bằng cách kiểm tra rằng đường về nguồn đúng là đường mong đợi, nên một tuyến unicast trỏ đi nơi khác sẽ phá cây ngay cả khi tư cách thành viên nhóm đúng. Cài một tuyến cho bên nhận không giúp gì cho phép kiểm tra đó, và đây chính là lỗi tạo ra ping chạy được và luồng thất bại. Hãy xác minh đường về của nguồn trước, sau đó thêm tư cách thành viên, và chỉ sau đó mới nhìn vào ứng dụng.

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

Hai dòng đầu cho thấy máy chủ đã tham gia vào đâu và nhân hệ điều hành chuyển tiếp gì, dòng thứ ba cho thấy tư cách thành viên của chính ứng dụng, và dòng cuối cho thấy tuyến unicast mà phép kiểm tra đường ngược sẽ dùng. Đọc chúng cùng nhau giúp phân biệt một ứng dụng chưa từng tham gia với một mạng chưa từng chuyển tiếp.

Chứng minh bằng một nguồn và một bên nhận

Trước khi chạm vào cấu hình, hãy xác nhận ứng dụng chạy trên một phân đoạn duy nhất. Nếu nó thất bại cục bộ thì định tuyến multicast không phải vấn đề và không thay đổi đường hầm nào giúp được. Sau đó lặp lại với một bên nhận qua đường hầm và quan sát gói tin ở cả hai phía của ranh giới mã hóa.

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

Các gói thấy bên trong đường hầm nhưng vắng bên ngoài chỉ ra đóng gói hoặc chính sách; các gói thấy ở cả hai phía mà ứng dụng không tiến triển chỉ ra tư cách thành viên của bên nhận hoặc ràng buộc của ứng dụng. Giữ bản ghi ngắn và đã lọc, vì một bản ghi multicast rộng trên phân đoạn bận rộn phần lớn là nhiễu.

Chọn địa chỉ dịch vụ khi chỉ cần dịch vụ

Khám phá tồn tại để tìm một thứ biết di chuyển. Một máy chủ có tên ổn định không cần khám phá, và một địa chỉ được ghi lại trong DNS riêng trả lời câu hỏi thật của người dùng mà không mở rộng miền quảng bá qua một liên kết diện rộng. Cùng lý lẽ đó áp dụng cho máy in, thiết bị gia dụng và dịch vụ web nội bộ. Một tên trong DNS đến được từ mọi site cần nó mà không thông báo gì cho các site không cần, và nó tiếp tục hoạt động khi thiết bị được thay bằng thiết bị có địa chỉ khác.

Khi một giao thức thực sự cần multicast, hãy giới hạn nó ở nhóm và những site cần, ghi lại lý do, và xem lại quyết định khi ứng dụng thay đổi. Mở rộng khám phá ra khắp nơi thì dễ một lần, và khó rút lại sau một năm với những thiết bị âm thầm phụ thuộc vào nó.