Định tuyến một tài khoản Linux qua OpenVPN bằng quy tắc UID

Định tuyến theo tài khoản phù hợp khi mọi socket IPv4 thuộc một người dùng Linux phải đi ra qua một tunnel sẵn có, và không phù hợp khi bạn cần cách ly ở cấp chương trình. Nó chọn theo UID, nên mọi thứ chạy dưới tài khoản đó đều nằm trong phạm vi, kể cả công việc hàng loạt mà bạn quên. Hãy giải quyết câu hỏi đó trước khi chạm vào một ip rule.

Ví dụ dưới đây giả định một tài khoản trình duyệt riêng tại UID 1500, thiết bị tunnel tun-office giữ địa chỉ cục bộ 10.80.0.11, và một VPN cho phép các đích được đề cập. Bản thân daemon chạy ngoài UID đó.

Ba điều kiện chọn cơ chế

Chọn quy tắc UID khi danh tính thực hiện công việc là tài khoản, khi việc chuyển toàn bộ lưu lượng của nó là chấp nhận được, và khi namespace sẽ nặng hơn mức nhiệm vụ xứng đáng. Chọn namespace mạng khi khối lượng công việc cần giao diện, bộ phân giải và bảng định tuyến riêng. Chọn proxy hoặc ràng buộc theo tiến trình khi đúng một ứng dụng cần di chuyển trong khi phần còn lại của phiên vẫn ở đường cục bộ. Viết ba điều này ra giúp tránh một quy tắc âm thầm bao phủ nhiều hơn dự định.

Sai lầm cần tránh là cho rằng trình khởi chạy quyết định chủ sở hữu. Một trình duyệt được phiên của người dùng khác trao URL không tạo socket dưới UID 1500, và không quy tắc nào chuyển lưu lượng nó sinh ra.

Bảng, quy tắc và người gác

Sau khi kiểm tra các quy tắc hiện có và chọn số bảng cùng độ ưu tiên chưa dùng, cách sắp xếp ngắn gọn: tuyến mặc định trong bảng riêng mang địa chỉ nguồn của tunnel, một quy tắc gửi các tra cứu của tài khoản vào bảng đó, và một quy tắc kết thúc chặn đường dự phòng. Viết ra thì đó là việc thay tuyến idempotent, ip -4 route replace default dev tun-office src 10.80.0.11 table 51820, tiếp theo là ip -4 rule add priority 12100 uidrange 1500-1500 lookup 51820.

Người gác là ip -4 rule add priority 12101 uidrange 1500-1500 unreachable, và nó quan trọng hơn độ dài gợi ý. Không có nó, một tuyến thiếu trong bảng 51820 rơi xuống đường lên thông thường và tài khoản âm thầm rò lưu lượng mà chính sách phải bắt. Có nó, cùng lỗi đó trở thành hết thời gian, tức là chặn thay vì dự phòng.

Giữ quy tắc địa chỉ cục bộ thông thường trước những quy tắc này, và quyết định có ý thức xem các ngoại lệ LAN hay quản trị có đứng trước bảng đã chọn không. Tuyến mặc định tìm thấy ở đó về sau không hỏi main để tìm tuyến LAN cụ thể hơn, điều khiến những người mong đợi khớp tiền tố dài nhất áp dụng giữa các bảng ngạc nhiên. Viết danh sách ngoại lệ dự kiến vào ghi chú thay đổi khi lý do vẫn còn mới.

Điều định tuyến UID bỏ sót: DNS

Daemon phân giải mở các socket thượng nguồn dưới UID của chính nó, nên chọn 1500 không chuyển những truy vấn đó vào bảng 51820. Tích hợp DNS là quyết định riêng: trỏ tài khoản đến một bộ phân giải tiếp cận được qua tunnel, hoặc chấp nhận rằng phân giải tên đi theo đường của máy chủ còn lưu lượng thì không.

Một truy vấn loopback tới stub cục bộ không phải bằng chứng rằng truy vấn thượng nguồn đã dùng tuyến của trình duyệt, và việc tải trang thành công từ bộ đệm cũng không.

IPv6 cần câu riêng trong thiết kế

Các quy tắc trên chỉ bao phủ IPv4. Nếu yêu cầu là một tunnel IPv4 không có IPv6 trực tiếp từ tài khoản này, hãy thêm một quy tắc kết thúc đã được xem xét như ip -6 rule add priority 12101 uidrange 1500-1500 unreachable, rồi kiểm tra các quy tắc IPv6 trước đó cùng các ngoại lệ loopback bạn muốn giữ.

Chặn IPv6 trực tiếp không phải là đóng tunnel hai lớp; đó là một ranh giới. Gọi đó là đóng tunnel sẽ khiến người tiếp theo đọc chính sách bối rối, và sự bối rối sẽ hiện ra thành một phiếu hỗ trợ về trang IPv6 bị hỏng.

Xác minh bằng tài khoản thật, rồi nhận trách nhiệm vòng đời

So sánh các tra cứu: ip -4 route get 198.51.100.25 uid 1500 với cùng đích dùng UID thông thường. Sau đó thực hiện một yêu cầu được phép dưới tài khoản riêng và kiểm tra địa chỉ nguồn mà đầu xa nhìn thấy. Địa chỉ nguồn ưu tiên không phải source NAT, và nó sẽ không lấn át một ứng dụng ràng buộc thứ khác. Nếu cả hai tra cứu trả về cùng một đường, quy tắc không làm điều bạn nghĩ.

Giữ bảng, các quy tắc và vòng đời tuyến tunnel dưới một chủ sở hữu, thử kết nối lại và mất tunnel, và khi gỡ chính sách chỉ xóa đúng các mục của nó. Namespace vẫn dùng được nếu giao diện riêng và trạng thái riêng là thứ bạn thực sự cần.