NET_ADMIN trong container VPN: nó có thể thay đổi gì và ở đâu
Khả năng này cho phép thay đổi giao diện, tuyến đường và tường lửa bên trong một không gian tên mạng. Với mạng của máy chủ, không gian tên đó chính là ngăn xếp của máy chủ.
NET_ADMIN là khả năng của Linux cho phép một tiến trình thực hiện quản trị mạng, và trong container nó làm đúng điều đó bên trong không gian tên mạng nơi tiến trình chạy. Đây không phải là giấy phép mở socket và không phải là thứ thay thế cho thiết bị hay tuyến đường. Câu hỏi thú vị không bao giờ là khả năng có được cấp hay không, mà là không gian tên nào nhận thay đổi.
Khả năng bao gồm những gì
Bên trong không gian tên của mình, một tiến trình giữ NET_ADMIN có thể bật và tắt giao diện, gán địa chỉ, thêm và xóa tuyến đường và viết quy tắc tường lửa, đó là nhóm thao tác mà capabilities(7) tập hợp dưới khả năng này. Nó cũng có thể điều chỉnh các thiết lập ở mức giao diện kiểm soát cách nhân xếp hàng và lọc lưu lượng. Một máy khách VPN thường cần một vài trong số đó khi khởi động và không cần gì khác sau đó. Vì vậy hầu hết các image yêu cầu phạm vi rộng hơn mức chúng sử dụng.
Các thao tác bên ngoài không gian tên đó không được bao gồm, và các đặc quyền lân cận là riêng biệt. Việc đọc và ghi gói thô thuộc về NET_RAW, và việc tạo thiết bị tun cần cả khả năng và quyền truy cập nút thiết bị. Một tiến trình không có thiết bị sẽ nhận lỗi quyền trông giống sự cố mạng nhưng không phải.
Không gian tên quyết định bán kính thiệt hại
Một container trên mạng cầu nối riêng của nó tiếp cận loopback riêng, các giao diện riêng và bảng định tuyến riêng. Việc cấp NET_ADMIN ở đó cho phép máy khách VPN xây dựng đường hầm mà không chạm vào các quyết định định tuyến của máy chủ, đây là cách bố trí mà hầu hết các image container giả định.
Chuyển container đó sang mạng của máy chủ và cấp phép tương tự giờ đây chỉnh sửa các tuyến đường và tường lửa của máy chủ, vì không còn không gian tên riêng nào. Máy khách lẽ ra chỉ quản lý một đường hầm giờ có thể chuyển hướng lưu lượng của toàn bộ máy, và một lỗi trong script tháo gỡ của nó để lại trên máy chủ những quy tắc mà không ai viết. Không có gì trong bản thân khả năng thay đổi; bối cảnh đã thay đổi. Đó là lý do cùng một tệp compose hành xử khác nhau trên hai máy chủ.
Ba điều kiện tiên quyết hợp nhất thành một
Các lỗi khởi động trong container VPN thường liên quan đến một trong ba thứ riêng biệt: khả năng, thiết bị đường hầm và sự hỗ trợ của nhân cho giao thức. Cấp cả ba cùng lúc thì hiệu quả, và cũng khiến lỗi tiếp theo không thể quy cho đâu được. Một đoạn compose tối thiểu cấp khả năng và truyền nút thiết bị một cách rõ ràng:
services:
vpn:
image: example/vpn-client:latest
cap_add:
- NET_ADMIN
devices:
- /dev/net/tun
sysctls:
- net.ipv4.conf.all.src_valid_mark=1Đọc tài liệu của chính image để biết nó cần những sysctl nào, vì một sysctl trong container có thể yêu cầu thêm đặc quyền hoặc một thiết lập ở cấp máy chủ. Ở nơi image chỉ hỗ trợ chế độ không gian người dùng, không cần thiết bị nào cả và danh sách khả năng thu hẹp tương ứng.
Cấp thao tác hẹp, không cấp chế độ
Chế độ đặc quyền trao mọi khả năng và đồng thời mở rộng quyền truy cập thiết bị, nên nó che giấu điều kiện nào trong ba điều kiện đã thiếu. Nó cũng khiến các kiểu lỗi của container không thể phân biệt với thay đổi trên máy chủ. Hãy ưu tiên danh sách rõ ràng dù viết dài hơn.
Các triển khai không root và trong không gian tên người dùng thay đổi ý nghĩa thực tế của khả năng, vì tiến trình chỉ có thể giữ nó bên trong không gian tên đã ánh xạ. Sao chép một danh sách khả năng từ ví dụ có root sang môi trường chạy không root và mong đợi cùng phạm vi là cách phổ biến để mất một buổi chiều.
Bí mật thuộc về một quyết định riêng. Việc giữ NET_ADMIN không nói gì về danh tính ngang hàng mà máy khách trình bày, thông tin xác thực nó tải hay cách chúng được luân chuyển. Quản trị mạng không cung cấp sự tin cậy.
Xác minh thay đổi và ghi lại lý do tồn tại của việc cấp quyền
Xác nhận những gì container thực sự nhận được trước khi gỡ lỗi đường hầm. Việc kiểm tra dưới đây báo cáo các khả năng được thêm và chế độ mạng, sau đó cho thấy danh sách giao diện trông như thế nào từ bên trong:
docker inspect --format '{{.HostConfig.CapAdd}} {{.HostConfig.NetworkMode}} {{.HostConfig.Privileged}}' vpn
docker exec vpn sh -c 'grep CapEff /proc/self/status'
docker exec vpn ip -br addr
docker exec vpn ip routeNếu khả năng có mặt mà danh sách giao diện vẫn trống, máy khách đã thất bại trước khi có thể tạo ra bất cứ thứ gì, và nơi tiếp theo cần xem là nhật ký container. Nếu đường hầm tồn tại nhưng lưu lượng không chảy, bảng định tuyến bên trong container trả lời câu hỏi tiếp theo.
Cũng hãy kiểm tra đường tháo gỡ, vì một máy khách ghi quy tắc tường lửa có thể để chúng lại phía sau. Dừng container và kiểm tra lại bộ quy tắc của máy chủ nếu dùng mạng của máy chủ. Một quyền chỉ cần hai giây lúc khởi động không nên được mô tả trong tệp compose như một yêu cầu thường trực mà không có ghi chú giải thích điều đó.
Viết lý do bên cạnh mỗi khả năng: thao tác nào cần đến nó và điều gì thất bại nếu không có nó. Ghi chú đó tồn tại qua các lần cập nhật image, và nó là khác biệt giữa một danh sách đặc quyền đã được xem xét và một danh sách lớn lên nhờ sao chép và dán.