Xuất bản luồng từ camera: RTSP và HLS không phải cùng một biên

Bạn mở một cổng của camera, trỏ một trình phát vào đó và cho rằng vấn đề internet đã được giải quyết. Rồi một chiếc điện thoại không phát được, một trình duyệt không phát được, và trang quản trị của camera chỉ cách biên công cộng một đường dẫn gõ sai. Mô hình phân phối bạn chọn, RTSP hay HLS, quyết định phần lớn điều đó trước khi bất kỳ quy tắc tường lửa nào được viết. VPN chỉ cung cấp chặng riêng tư.

VPN sửa đường đi của nguồn, không phải đường đi của người xem

Một VPS nối vào mạng LAN của camera qua đường hầm có thể tiếp cận camera tại địa chỉ riêng của nó, và điều đó thực sự hữu ích. Nghĩa là camera không cần cổng vào riêng và router trong nhà vẫn đóng. Điều đó không cho bạn biết người xem sẽ nói ngôn ngữ gì. Trình phát trên máy tính, trình duyệt, điện thoại và tivi thông minh hỗ trợ các giao thức khác nhau, và mỗi thứ có kỳ vọng riêng về TLS, xác thực và codec.

Đây là giả định đáng gạt bỏ: xuất bản nghĩa là làm cho nguồn có thể tiếp cận được. Xuất bản thực ra nghĩa là trao cho một nhóm khán giả xác định một cách được hỗ trợ để tiêu thụ phương tiện. Một luồng đã xuất bản có định dạng, khán giả và thông tin xác thực; một camera tiếp cận được thì không có gì trong số đó. Khả năng tiếp cận là phần mà đường hầm giải quyết, và điểm vào của người xem là phần bạn vẫn phải thiết kế.

RTSP là một cuộc thương lượng, không phải một cổng

RTSP mang điều khiển phiên: một máy khách yêu cầu mô tả, thiết lập một hoặc nhiều vệt phương tiện rồi phát. Việc vận chuyển chính phương tiện được thương lượng trong lúc thiết lập đó, nên giao thức không được mô tả tốt bằng một cổng TCP được chuyển tiếp. Cuộc thương lượng ấy là phần người ta bỏ qua khi so sánh các quy tắc tường lửa.

Tùy theo điểm cuối, RTP có thể đến trên các cổng UDP riêng hoặc được xen vào kết nối điều khiển. Một relay chỉ chuyển tiếp cổng 554 và cho rằng phần còn lại sẽ chạy thường tạo ra một phiên kết nối được, báo có một vệt rồi không hiển thị gì. Hãy kiểm tra kiểu vận chuyển mà camera của bạn thực sự thương lượng trước khi viết quy tắc cho nó. Một bản bắt gói ở phía riêng tư trả lời điều đó trong một phút, còn đoán mò tốn cả một buổi tối.

Với một nhóm khán giả nhỏ, đã biết và có trình phát tương thích, một relay RTSP được cấu hình có chủ đích có thể là câu trả lời đúng. Hãy giới hạn nguồn mà nó được phép kéo và yêu cầu xác thực tại relay. Ghi lại những trình phát bạn đã thử, vì một luồng RTSP chạy được trong VLC vẫn có thể thất bại trong trình duyệt.

HLS là danh sách phát cộng với tài nguyên

Người xem HLS lấy một danh sách phát, rồi lấy các phân đoạn phương tiện mà danh sách đó nêu tên. Đặc tả HLS định nghĩa mô hình tài nguyên đó, và chi tiết vận hành quan trọng là các danh sách phát tham chiếu tới các URL khác. Các tham chiếu tương đối được giải quyết theo vị trí của danh sách, nên một proxy viết lại đường dẫn phải viết lại chúng một cách nhất quán.

Nếu camera đã phục vụ HLS dùng được, một frontend công cộng có thể chuyển tiếp các yêu cầu danh sách và phân đoạn đó qua đường hầm. Hãy để ý khóa, chuyển hướng và URL do ứng dụng tạo ra. Bất kỳ URL tuyệt đối nào trỏ tới một máy chủ riêng sẽ hỏng ngay khi một người xem ngoài mạng LAN đi theo nó. Đường dẫn tương đối là những đường sống sót qua việc viết lại của proxy, nên hãy ưu tiên chúng ở bất cứ đâu bạn kiểm soát đầu ra được tạo.

Nếu camera chỉ nói RTSP, phải có thứ gì đó chuyển nguồn sang định dạng của người xem. Đóng gói lại và chuyển mã là hai việc khác nhau: đóng gói lại giữ nguyên codec, còn chuyển mã mã hóa lại để tương thích, và chỉ việc thứ hai mới tốn CPU đáng kể. Không việc nào trở nên cần thiết chỉ vì có VPN trên đường đi.

Hãy lập kế hoạch cho đường lên dựa trên nơi diễn ra việc phân phối. Một đầu vào riêng tư cấp cho một dịch vụ phương tiện công cộng hành xử rất khác với việc từng người xem tự kéo luồng của mình qua đường hầm. Kiểu thứ hai thường kết thúc bằng một kết nối tại nhà bị bão hòa và một camera có vẻ hỏng ngẫu nhiên.

Đặt xác thực ở biên mà bạn xuất bản

TLS, xác thực người xem và ghi nhật ký truy cập thuộc về điểm vào công cộng, không thuộc về camera. Điều đó giữ thông tin xác thực của camera tách khỏi thông tin xác thực của luồng. Nó cũng cho bạn một nơi duy nhất để thu hồi quyền truy cập khi một thành viên khán giả rời đi. Đặt những kiểm soát đó trên camera thay vào đó nghĩa là mọi thay đổi khán giả trở thành một thay đổi hành chính trên một thiết bị lẽ ra không bao giờ được tiếp cận công khai.

Giữ VPN và quyền quản trị của camera tách khỏi đường xuất bản. Một VPS có thể chạm tới giao diện web của camera để kéo luồng không nên đồng thời là máy phơi bày giao diện đó. Khán giả không bao giờ nên biết địa chỉ của camera.

Sau đó hãy kiểm chứng hai đầu mà bạn thực sự đã dựng thay vì cho rằng chuỗi hoạt động:

$ ffprobe -v error -rtsp_transport tcp rtsp://10.50.0.9:554/stream1
$ curl -sI https://stream.example.net/live/index.m3u8
HTTP/2 200
content-type: application/vnd.apple.mpegurl

Một lần dò nguồn riêng tư thành công và một lần lấy danh sách phát thành công ở biên công cộng chứng minh hai nửa khác nhau của thiết kế. Hãy kiểm tra chúng riêng rẽ. Phát lại từ cùng loại máy khách mà khán giả của bạn dùng là phép thử duy nhất bao trùm toàn bộ chuỗi.

Điều bạn có cuối cùng là một chuỗi với mục đích ở mỗi mắt: nguồn riêng tư, đầu vào bị giới hạn, đóng gói đã chọn, lối vào người xem được cấp quyền. Không mắt nào trong số đó là tùy chọn, và không mắt nào được tạo ra bằng cách mở một cổng.