OpenVPN trên VPS: không có thiết bị /dev/net/tun để mở

Lần khởi động đầu tiên thất bại với thông báo về /dev/net/tun hoặc một thiết bị TUN/TAP không mở được. Chứng chỉ chưa được đọc, nên không có gì trong hồ sơ bị quy lỗi. Tiến trình nền đang xin nhân một đối tượng mà khách này không có.

Đối tượng đó là thiết bị ký tự do mô-đun tun cung cấp. Việc bạn có tạo được nó hay không phụ thuộc vào ai sở hữu nhân.

Tiến trình nền xin nhân điều gì

OpenVPN mở /dev/net/tun và xin trình điều khiển một giao diện. Trình điều khiển là mô-đun tun, còn nút thiết bị là tay nắm mà không gian người dùng dùng để chạm tới nó. Nếu mô-đun chưa được nạp, nút có thể thiếu hoặc việc mở có thể thất bại. Không trạng thái nào được sửa bằng cách chỉnh server.conf.

Trước hết hãy đọc lỗi này như một câu hỏi về nền tảng. Lỗi cấu hình xuất hiện sau khi thiết bị mở, không phải trước đó.

VM hay khách dùng chung nhân

Trên KVM, Xen hoặc một máy ảo đầy đủ khác, bạn kiểm soát nhân. Bạn có thể nạp mô-đun và tạo nút. Trên OpenVZ, Virtuozzo hoặc container kiểu LXC, khách dùng chung nhân của máy chủ, nên root bên trong không thể nạp mô-đun mà máy chủ chưa nạp.

Vì thế cùng một lỗi có hai chủ sở hữu rất khác nhau. Trong trường hợp đầu, bạn sửa được từ bên trong phiên máy. Trong trường hợp sau, bạn đang xin máy chủ hoặc nhà cung cấp mở ra thứ gì đó.

Hãy chạy ls -l /dev/net/tun, lsmod | grep tun và ip -brief link show trước khi quyết định bạn đang ở trường hợp nào.

Trên VM, nạp mô-đun lúc khởi động

Trên máy ảo, modprobe tun thường tạo nút thiết bị. Kiểm tra rằng nó đã xuất hiện, rồi làm cho việc nạp trở nên vĩnh viễn qua cấu hình mô-đun của bản phân phối thay vì dựa vào một lệnh gõ một lần. Một nút biến mất sau khi khởi động lại sẽ thành đúng phiếu đó vào tháng sau.

Cũng nên kiểm tra xem nhân bạn đã khởi động có mô-đun đó hay không. Nhân của nhà cung cấp đã bị lược bớt có thể không có.

Nếu nút tồn tại mà việc mở vẫn thất bại, nghi phạm tiếp theo là quyền và số major/minor của thiết bị. Đó là các sửa chữa cục bộ, không phải yêu cầu gửi nhà cung cấp.

Trong container, thiết bị thuộc về máy chủ

Trong container, thiết bị và khả năng là hai yêu cầu riêng. Môi trường chạy phải cho /dev/net/tun đi qua, và container cần khả năng mạng để tạo giao diện. Một môi trường chạy không root mà không cấp cả hai sẽ tiếp tục sinh ra đúng lỗi mở đó, bất kể hồ sơ viết thế nào. Nhiều máy chủ OpenVZ có công tắc TUN/TAP trong bảng điều khiển khách hàng, và bật nó cùng một lần khởi động lại thường là toàn bộ cách khắc phục.

Hỏi nhà cung cấp hai câu chính xác: mô-đun tun đã được nạp trên máy chủ chưa, và thiết bị có sẵn bên trong phiên máy này không? Một phiếu mơ hồ nhận một câu trả lời mơ hồ.

Vì sao dựng lại mô-đun hiếm khi giúp

Dựng mô-đun bên trong khách hiếm khi giúp. Việc biên dịch cần cấu hình của đúng nhân đang chạy, còn /proc/config.gz là tùy chọn và thường thiếu trên các ảnh tối giản. Ngay cả mô-đun chạy được cũng không thể chèn vào một nhân mà container không sở hữu.

Sau khi thiết bị xuất hiện, hãy khởi động lại dịch vụ và xác nhận giao diện trước khi thử lưu lượng. Thấy tun0 cho thấy tiến trình nền đã mở thiết bị. Nó chưa nói gì về chuyển tiếp, quy tắc tường lửa hay các tuyến mà máy khách nhận được.

Đây là những câu hỏi riêng với bằng chứng riêng. Thiếu thiết bị là lỗi điều kiện tiên quyết; một đường hầm tồn tại mà không chở gì là lỗi chính sách.