Một ứng dụng Linux thông thường dùng VPN mà không chạm vào TUN

Một trình duyệt dùng VPN Linux đã thiết lập không mở /dev/net/tun. Nó mở một socket, và nhân quyết định gói tin của socket đó đi ra qua giao diện nào. Tiến trình tạo ra đường hầm làm công việc khác với tiến trình mà nó vận chuyển lưu lượng. Giữ hai vai trò này tách biệt trả lời phần lớn câu hỏi về quyền trước khi chúng được đặt ra.

Theo một gói tin từ socket đến đường hầm

Một ứng dụng thông thường gọi connect hoặc send, và nhân tìm tuyến đường đến đích. Nếu tuyến đã chọn trỏ tới giao diện đường hầm, gói tin được xếp vào hàng đợi của thiết bị mà daemon VPN đọc. Daemon mã hóa nó và gửi ra qua giao diện vật lý. Mỗi mũi tên trong mô tả đó là một chỗ có thể trả lời câu hỏi về quyền.

Không có gì trên đường đó đòi hỏi ứng dụng phải biết về thiết bị. Daemon giữ bộ mô tả tệp và thực hiện các thao tác giao diện, trong khi ứng dụng chỉ thấy một API mạng bình thường.

Hãy vẽ hai nửa một lần, và các câu hỏi về quyền sẽ dễ đặt hơn. Nửa trên là thế giới ứng dụng, nửa dưới thuộc về daemon.

Quyết định ai cần thiết bị và ai không

Tạo hoặc gắn vào giao diện TUN cần quyền truy cập thiết bị và thêm khả năng cấu hình nó, vì vậy một dịch vụ VPN được hỗ trợ bắt đầu với thẩm quyền quản trị mạng hoặc dùng một trình trợ giúp đặc quyền. Yêu cầu đó thuộc về daemon. Nó không nói gì về trình duyệt, ứng dụng khách cơ sở dữ liệu hay công cụ truyền tệp. Một dịch vụ cần khả năng đó cần nó cho bước thiết lập của chính mình, không phải cho các ứng dụng khách.

Khi tuyến và chính sách đã vào chỗ, một tiến trình thông thường dùng đường đi kết quả qua các lệnh gọi socket quen thuộc. Nó không cần nút thiết bị và không cần root.

Thay đổi quyền của thiết bị không phải cách cấp cho ứng dụng quyền truy cập đích. Nó chỉ chuyển ranh giới thiết bị đi nơi khác.

Kiểm tra không gian tên mà ứng dụng thực sự chạy

Một container, hoặc không gian tên mạng thứ hai, cấp cho các tiến trình của nó một bộ giao diện và bảng tuyến riêng. Một đường hầm trên máy chủ không tự xuất hiện ở đó, và không thay đổi quyền thiết bị nào làm được điều đó. Ứng dụng sẽ chỉ định tuyến qua những gì không gian tên đó cung cấp. Đó là lý do một ảnh container không thể thừa hưởng đường hầm của máy chủ một cách tình cờ.

Kiểm tra bằng ip netns list và ip -n NAME route, hoặc bằng cách xem liên kết không gian tên của tiến trình. Câu trả lời thường thấy trong một lệnh.

Hai người dùng trên cùng một máy chủ cũng có thể được cấp các đường khác nhau bằng chính sách. Đó là quyết định mạng, không phải bằng chứng về quyền sở hữu thiết bị.

Tách khả năng khỏi chính sách mạng

Một số công cụ cần nhiều hơn một socket. Bắt gói cần socket thô, và thay đổi tuyến cần thẩm quyền quản trị. Đó là các thao tác riêng với quyền riêng, và cấp một cái không nên được đọc như yêu cầu chung để dùng VPN.

Một chương trình tự cài đặt đường hầm của mình là trường hợp thứ ba. Nó thực sự mở TUN vì đảm nhận vai trò của daemon, đó là lý do nó cần đặc quyền của daemon.

Hãy gọi tên thao tác trước khi gọi tên đặc quyền. Hai thứ đó thường dễ tách hơn vẻ ngoài.

Xác minh sự tách biệt bằng hai tài khoản

Kết nối đường hầm với vai trò dịch vụ, rồi chạy ứng dụng như người dùng thông thường và xác nhận nó tới được tài nguyên riêng. Kiểm tra ip route get cho đích từ shell của người dùng đó để xem giao diện nào được chọn. Nếu tuyến đúng mà kết nối vẫn thất bại, vấn đề là chính sách chứ không phải đặc quyền.

Thiết kế thu được là đặc quyền tối thiểu với ranh giới rõ ràng: một thành phần sở hữu việc thiết lập và tài nguyên đường hầm, các khối công việc giữ tài khoản bình thường, và chính sách mạng quyết định cái gì được đi qua. Chạy mọi thứ bằng root làm sụp đổ các vai trò đó mà không giải thích gì.