Chromecast và DLNA không bao giờ đi qua VPN định tuyến

Nút truyền phát không liệt kê gì, VLC DLNA vẫn trống, và máy ở đầu bên kia trả lời ping mà không phàn nàn. Sự kết hợp đó không phải vấn đề băng thông và cũng không phải bí ẩn tường lửa. Khám phá trong các giao thức này là trao đổi nhóm trên phân đoạn cục bộ, và đường hầm định tuyến không chở lưu lượng có địa chỉ nhóm. Phiên bạn đang cố bắt đầu không bao giờ được chào mời.

Khả năng tiếp cận ổn. Khám phá thì thiếu.

Lầm tưởng: đường hầm cần một thiết lập hoặc thêm băng thông

Các đề xuất thường gặp là bật lưu lượng ngang hàng, nâng MTU, hoặc đổi loại thiết bị của đường hầm. Không cái nào thêm một miền quảng bá. Multicast do switch và ngăn xếp mạng cục bộ chuyển giao, và giao diện TUN điểm-điểm không có địa chỉ nhóm nào để làm ngập.

Đổi thiết lập có thể làm lỗi ồn hơn. Nó không thể làm một thông báo xuất hiện ở nơi giao thức chưa bao giờ gửi.

Trao đổi khám phá thực sự là gì

Ba mẫu bao phủ gần như mọi thứ bạn gặp. mDNS gửi tới 224.0.0.251 trên UDP 5353, SSDP gửi tới 239.255.255.250 trên UDP 1900, và danh sách duyệt SMB cũ đi tới địa chỉ quảng bá của mạng con. Mỗi loại được gửi tới một nhóm chứ không phải một máy, và mỗi loại chờ một trình lắng nghe trên cùng phân đoạn. Bộ nhận ở bên kia đường hầm định tuyến không ở phân đoạn đó, nên không có gì đến.

Ngay cả một thông báo được chuyển tiếp cũng mang tải trọng: thường là địa chỉ LAN và cổng của bên gửi, mà người xem từ xa sau đó phải chạm tới được.

Đọc một bản chụp trước khi đổi đường hầm

Chụp trên giao diện đường hầm khi ứng dụng quét. Bản chụp trống nghĩa là thông báo chưa bao giờ vượt ranh giới, và không mức chỉnh nào của đường hầm thay đổi điều đó. Các gói vẫn xuất hiện trong khi ứng dụng chưa hiển thị gì thường nghĩa là địa chỉ được thông báo không tiếp cận được từ người xem, đây là vấn đề định tuyến khoác áo khám phá.

Hai phút chụp thay cho một giờ đoán về cổng: tcpdump -ni tun0 udp port 5353 or udp port 1900.

Ba cách khắc phục, rẻ nhất trước

Trỏ máy khách thẳng tới địa chỉ dịch vụ. Với DLNA, SMB và máy chủ media đơn giản, cách này bỏ qua hoàn toàn khám phá và chứng minh đường tải trọng hoạt động, khiến nó vừa là bài kiểm tra đầu tiên tốt nhất vừa là cách vòng hợp dùng được. Chromecast là ngoại lệ, vì bộ nhận mong được tìm thấy chứ không phải bị trỏ tới.

Chuyển tiếp giao thức ở cổng ra. Một bộ phản xạ mDNS lặp lại thông báo giữa đường hầm và LAN, và Avahi có phần bộ phản xạ nhận danh sách giao diện rõ ràng. Giữ việc chuyển tiếp hẹp, và xác nhận địa chỉ được thông báo tiếp cận được từ cả hai phía, nếu không câu trả lời vẫn trỏ tới một mạng con mà người xem không định tuyến tới được.

Bắc cầu thay vì định tuyến. Một phân đoạn TAP với máy chủ bắc cầu thiết bị tap vào LAN đặt cả hai đầu trong một miền quảng bá, nên thông báo đi qua nguyên vẹn. Đây cũng là lựa chọn đắt nhất, vì một mạng con nghĩa là một miền lỗi và mọi dịch vụ multicast trên LAN giờ chạm tới mọi ngang hàng.

Điều gì không giúp, dù được đề xuất bao nhiêu lần

Chuyển từ dev tun sang dev tap mà không có cầu vẫn để lại thiết bị TAP còn bị định tuyến, nên hành vi không đổi. client-to-client cho phép unicast giữa các ngang hàng và không làm ngập quảng bá. Chuyển tiếp cổng khám phá tới một máy không giao được lưu lượng có địa chỉ nhóm. Máy chủ media gắn với một địa chỉ vẫn trả lời trên địa chỉ đó cho tới khi cấu hình của chính nó liệt kê giao diện VPN.

Thử một yêu cầu unicast trực tiếp, rồi một yêu cầu được thông báo. Nếu cái đầu chạy và cái sau không, đường hầm khỏe và khám phá là toàn bộ vấn đề.