Truyền màn hình qua VPN: khám phá, điều khiển hay luồng phát?
Một bộ thu vắng mặt, một phiên bị từ chối và một luồng khựng lại hỏng ở những chỗ khác nhau. Gọi tên giai đoạn trước khi đổi chính sách VPN của điện thoại hay đổi mạng.
Truyền màn hình hỏng ở ba chỗ trông giống hệt nhau từ ghế sofa. Điện thoại có thể không bao giờ thấy bộ thu, bộ thu có thể hiện ra rồi từ chối phiên, hoặc phiên có thể bắt đầu rồi khựng lại một phút sau. Đường hầm trên điện thoại thay đổi mỗi đường đi đó theo cách khác nhau, và với một trong số đó nó không thay đổi gì cả. Hãy gọi tên giai đoạn thất bại trước, rồi mới quyết định xem đổi chính sách có phải là đòn bẩy đúng không.
Gọi tên giai đoạn thất bại trước khi đổi chính sách
Quan sát điện thoại làm gì ngay sau khi bạn chạm vào biểu tượng truyền. Danh sách trống là kết quả của khám phá, một cú chạm báo lỗi là kết quả của điều khiển, và một phiên bắt đầu trước khi khựng lại là kết quả của phát lại. Ba thứ đó có chủ khác nhau, và thường chỉ hai thứ đầu liên quan đến cài đặt đường hầm của điện thoại.
| Stage | What the phone shows | Evidence that separates it |
|---|---|---|
| Discovery | No receiver in the list | Another device on the same segment sees the receiver |
| Control | Receiver listed, session refused | Port answer versus permission prompt |
| Playback | Session starts, then stalls | The receiver's own link, not the phone's |
Ghi lại giai đoạn trước khi thay đổi bất cứ điều gì. Một bản sửa áp cho sai giai đoạn làm lần kiểm tra sau không đọc được, và phần lớn giai thoại về truyền màn hình đến đúng từ sự nhầm lẫn đó.
Khám phá là lưu lượng cục bộ, và đường hầm che nó đi
Bộ thu tự quảng bá qua các thông báo cục bộ và điện thoại tìm chúng bằng truy vấn trên cùng liên kết, nên bất cứ gì đưa điện thoại ra khỏi liên kết đó cũng đưa bộ thu ra khỏi danh sách. Một đường hầm định tuyến toàn bộ lưu lượng ra khỏi LAN có thể che những trao đổi đó, và quyền truy cập mạng cục bộ ở cấp ứng dụng có thể chặn chúng ngay cả khi tuyến tồn tại. Wi-Fi khách có cô lập máy khách tạo ra đúng danh sách trống đó mà không cần VPN. Hãy chứng minh hai thiết bị dùng chung một phân đoạn trước khi đổ lỗi cho đường hầm.
avahi-browse -at | grep -i -E 'chromecast|googlecast'
dig +short @224.0.0.251 -p 5353 _googlecast._tcp.local PTRLệnh đầu liệt kê những gì tự quảng bá trên phân đoạn của máy trợ giúp, lệnh thứ hai hỏi thẳng nhóm DNS multicast. Một bộ thu không có trong cả hai cũng sẽ không xuất hiện trong ứng dụng trên điện thoại, dù trạng thái đường hầm của điện thoại thế nào. Nếu bộ thu nhìn thấy từ thiết bị tắt đường hầm mà không thấy từ thiết bị bật đường hầm, bạn đã tìm ra cả giai đoạn lẫn nguyên nhân cùng lúc.
Ngoại lệ LAN giữ đường hầm hoạt động
Nhiều ứng dụng khách cung cấp ngoại lệ mạng cục bộ giữ đường hầm hoạt động trong khi cho phép địa chỉ cục bộ. Hãy dùng cài đặt đã được ghi chép đó thay vì tắt kill switch hay toàn bộ tường lửa, vì chúng thay đổi nhiều hơn hẳn nhu cầu của truyền màn hình. Nếu mạng cố ý tách thiết bị thông minh, hãy hỏi chủ mạng về lưu lượng khám phá, điều khiển và hồi đáp cụ thể thay vì xin quyền truy cập phẳng.
nc -vz 192.168.1.50 8009Một phép thử điều khiển tới bộ thu tách quyền khỏi khả năng tới được: cổng trả lời nghĩa là tuyến tồn tại, còn từ chối nghĩa là điện thoại được phép khám phá thiết bị mà vẫn không nói chuyện được với nó. Cổng 8008 và 8009 là các cổng truyền thông thường, và ứng dụng có thể dùng cổng khác, nên hãy coi một cổng bị từ chối là gợi ý chứ không phải phán quyết. Ngoại lệ và quyền của ứng dụng vẫn độc lập, vì cấp quyền cục bộ không tạo tuyến và thêm tuyến không cấp quyền. Kill switch cũng có thể bỏ lưu lượng cục bộ sau khi kết nối lại, nên khám phá phải được kiểm tra lại khi đường hầm trở lại.
Phát lại có thể không dùng kết nối của điện thoại
Trong một phiên do ứng dụng điều khiển, điện thoại trao cho bộ thu một địa chỉ media và bộ thu tự tải nó qua kết nối của mình, nên đổi địa chỉ công cộng của điện thoại không làm gì cho luồng phát. Một tựa bị giới hạn theo tài khoản vẫn có thể thất bại vì lý do riêng, và yêu cầu truyền màn hình của Google bao quát khả năng tương thích của ứng dụng và thiết bị chứ không phải tuyến mạng. Định tuyến chính chiếc TV qua một đường hầm là cấu hình riêng với những câu hỏi chính sách riêng.
Hai dấu hiệu phân biệt các chế độ. Một phiên truyền vẫn tiếp tục sau khi khóa màn hình điện thoại là do ứng dụng điều khiển, vì bộ thu tự tải; một bản phản chiếu dừng khi màn hình nguồn gửi khóa là luồng liên tục từ điện thoại. Khi khám phá và điều khiển thành công mà phát lại khựng, hãy nhìn vào liên kết Wi-Fi của bộ thu và đường internet của nó, vì bài kiểm tra tốc độ trên điện thoại mô tả chiếc điện thoại chứ không phải chiếc TV.
Hoàn tác ngoại lệ và kiểm tra lại
Mọi thay đổi tạm thời đều cần đường quay lại, và thứ tự rất quan trọng. Gỡ ngoại lệ LAN, kết nối lại đường hầm để ứng dụng khách áp lại chính sách, rồi lặp lại bước khám phá và ghi lại xem bộ thu có biến mất lần nữa không. Trình tự đó cho bạn biết ngoại lệ đang làm việc hay có thứ khác đã thay đổi ở giữa.
# after removing the LAN exception, reconnect and confirm the tunnel is up
resolvectl status | grep -E 'DNS Servers|Default Route|Protocols'
avahi-browse -at | grep -i -E 'chromecast|googlecast'Sau đó kiểm tra ba giai đoạn riêng rẽ, vì đạt ở một giai đoạn không nói gì về các giai đoạn khác. Kế đó kiểm tra xem các ứng dụng không liên quan trên điện thoại còn đi theo tuyến dự định không, vì một ngoại lệ cục bộ lặng lẽ thành đường vòng hoàn toàn là kết cục tệ hơn một phiên truyền cần thêm một cú chạm.