Vì sao tính năng cast ngừng hoạt động sau khi bật VPN trên router
Việc dò tìm chạy qua multicast link-local, còn TV tự tải nội dung. Một quy tắc mặc định của chính sách có thể chặn yêu cầu LAN và đẩy nó vào đường hầm.
Việc cast hoạt động trước khi bật VPN trên router và hỏng ngay sau đó, trong khi việc duyệt web thông thường trên điện thoại vẫn chạy. Hai sự kiện này không mâu thuẫn, vì cast không phải là một kết nối duy nhất. Điện thoại dò tìm và điều khiển bộ nhận qua mạng cục bộ, sau đó bộ nhận tự tải nội dung bằng kết nối của chính nó.
Hai đường đi hỏng theo hai cách khác nhau
Đường điều khiển là cục bộ. Điện thoại tìm bộ nhận bằng cách hỏi mạng cục bộ, rồi mở một kết nối điều khiển tới địa chỉ vừa học được. Nếu bộ nhận không bao giờ xuất hiện trong danh sách, bước dò tìm đã thất bại trước khi có bất kỳ nội dung nào được yêu cầu.
Đường nội dung không nhất thiết là cục bộ. Nhiều bộ nhận tự tải luồng, bằng kết nối riêng và thông tin đăng nhập riêng, nên tuyến của điện thoại không mô tả tuyến của bộ nhận. Một chiếc điện thoại trông như dùng một lối ra không nói gì về việc lưu lượng của TV đi đâu.
Chính sự tách biệt này khiến lỗi trông lạ. Đường hầm đã đổi bảng định tuyến của điện thoại và không đổi bảng của TV, nên một triệu chứng xuất hiện ở một bên của cặp phải được truy ở chính bên đó. Kiểm tra sai thiết bị là lý do thường gặp khiến một bản sửa trông như không làm gì.
Vì sao bước dò tìm hỏng trước
Việc dò tìm thường chạy qua multicast link-local. mDNS gửi tới 224.0.0.251 trên cổng UDP 5353, còn SSDP gửi tới 239.255.255.250 trên cổng UDP 1900. Cả hai theo thiết kế bị giới hạn trong một liên kết, vì vậy router không chuyển tiếp chúng giữa các đoạn mạng nếu không có bộ lặp hay proxy hỗ trợ. Một VPN có định tuyến không mở rộng nhóm multicast, và tuyến chính sách không thể làm một nhóm chưa từng rời liên kết xuất hiện trên liên kết khác.
Vậy lỗi đầu tiên không liên quan gì đến mã hóa. Multicast của điện thoại rời khỏi giao diện đã gửi nó, bộ nhận nằm ở một đoạn mạng không bao giờ thấy nó, và danh sách thiết bị trả về trống. Danh sách trống không phải bằng chứng rằng TV mất truy cập internet.
Cách ly cũng tạo ra triệu chứng y hệt mà không cần VPN nào. Mạng khách và tính năng cách ly máy khách trên điểm truy cập cố ý ngăn các thiết bị nói chuyện với nhau, và bật VPN trên router phía trên một đoạn mạng đã cách ly không thay đổi gì về điều đó. Hãy kiểm tra thiết lập cách ly trước khi kiểm tra đường hầm. Đó là câu trả lời rẻ hơn và phổ biến hơn.
Cách bố trí các đoạn mạng là nửa còn lại. Một router thứ hai, một nút mesh ở chế độ khác, hay một đoạn mạng có dây sau một NAT khác đều đặt bộ nhận ở nơi lưu lượng dò tìm của điện thoại không tới.
Vì sao quy tắc mặc định có thể nuốt một yêu cầu cục bộ
Một router đưa toàn bộ lưu lượng vào đường hầm sẽ cài tuyến mặc định trên giao diện đường hầm. Nếu tiền tố LAN không được loại trừ khỏi chính sách đó, một gói tin gửi tới thiết bị cách hai mét giờ khớp với tuyến mặc định, và router đẩy yêu cầu điều khiển vào đường hầm thay vì ra switch.
| Stage | What carries it | How a router VPN interferes |
|---|---|---|
| Discovery | Link-local multicast on a single segment | Not extended across segments, and not repaired by a route |
| Control connection | Unicast to the receiver address on the LAN | A policy default can capture the LAN destination and tunnel it |
| Media fetch | The receiver's own connection | Unaffected by the phone's route, but affected by the TV's own policy |
| Account authorization | Tokens held by the application | Can fail for reasons unrelated to any route |
Thứ tự quy tắc quyết định kết quả. Định tuyến theo chính sách đánh giá quy tắc theo thứ tự ưu tiên, nên ngoại lệ cho tiền tố cục bộ phải đứng trước quy tắc chọn bảng đường hầm. Thêm ngoại lệ sau quy tắc đường hầm không có tác dụng, vì vậy một cấu hình trông đúng vẫn có thể đẩy lưu lượng LAN ra lối ra từ xa.
Bản sửa rất hẹp: cho phép những đích cục bộ cụ thể mà luồng cast cần, và để phần cách ly còn lại yên. Bỏ cách ly máy khách ngay từ bước đầu chữa được triệu chứng nhưng ném đi một kiểm soát mà mạng vốn được thiết kế để có.
Một lần xem nhanh trên điện thoại sẽ xác định bạn gặp lỗi nào. Nếu tuyến tới bộ nhận trỏ vào đường hầm, vấn đề là chính sách. Nếu trỏ vào LAN mà việc dò tìm vẫn hỏng, vấn đề là multicast hoặc cách ly, và đổi tuyến sẽ không giúp gì.
ip route get 192.168.1.50
ip rule show
avahi-browse -rt _googlecast._tcpHãy thử đúng khâu đã thay đổi, không phải đổi quốc gia
Ghi chép quan sát tốt hơn thử nghiệm lặp lại. Ghi lại bộ nhận có xuất hiện trong danh sách thiết bị không, yêu cầu điều khiển có tới được nó không, và việc phát có bắt đầu sau khi chọn luồng không. Mỗi câu trả lời loại một bước khỏi diện nghi vấn.
Sau đó hãy kiểm tra từng bước trực tiếp thay vì đổi vị trí lối ra. Đổi quốc gia VPN kiểm tra đường nội dung và không đụng gì tới bước dò tìm và điều khiển, nên nó có thể trông như có ích do tình cờ mà không dạy bạn điều gì.
Về phía bộ nhận, hãy kiểm tra tuyến của chính nó và trạng thái tài khoản của chính nó. Một chiếc TV tải nội dung qua lối ra khác với điện thoại là thiết kế bình thường, và lỗi ở đó là câu hỏi về chính sách mạng của bộ nhận, không phải về đường hầm của điện thoại.
Hãy ghi kết quả thành một câu về việc bước nào hỏng và điều gì đã thay đổi nó. Câu đó đáng giá hơn một tuần đổi quốc gia và còn sống qua lần cập nhật firmware tiếp theo.
Cast là một ca kiểm thử tốt cho quy tắc chung về đường hầm. Khi thêm một đường hầm vào mạng, câu hỏi đầu tiên là những đích nào lẽ ra không bao giờ được đi vào đó, câu thứ hai là những đích nào trong số đó vẫn bị chính sách âm thầm chấp nhận.