Vì sao hồ sơ OpenVPN không nhập được vào SoftEther
SoftEther có thể cung cấp một trình lắng nghe tương thích OpenVPN, nhưng ứng dụng khách gốc cần hồ sơ kết nối riêng của nó. Hãy xác định dịch vụ trước khi tách khóa.
Hai tệp đều trông giống cấu hình VPN rơi vào cùng một thư mục, và chỉ một trong hai hoạt động. Hồ sơ OpenVPN mô tả một đường hầm TLS với các chỉ thị mà ứng dụng khách đó hiểu, trong khi kết nối SoftEther mô tả một phiên với một trung tâm ảo theo một hợp đồng xác thực khác. Chuyển cái này thành cái kia không phải bài tập định dạng, vì hai ứng dụng khách không triển khai cùng một giao thức. Việc xác định dịch vụ nào nhà vận hành thực sự công bố quyết định mọi thứ tiếp theo.
Hai tệp, hai hợp đồng
Hồ sơ OpenVPN là cấu hình ứng dụng khách: một điểm cuối từ xa, một phương thức truyền, vật liệu TLS và các chỉ thị cho định tuyến và đàm phán lại. Kết nối SoftEther là một phiên ứng dụng khách gốc với một trung tâm ảo, có một bộ điều hợp ảo gắn vào.
Chúng có thể mô tả quyền truy cập vào cùng một mạng mà không thể hoán đổi cho nhau. Trình lắng nghe OpenVPN là một tính năng tương thích mà máy chủ có thể công bố trên một cổng riêng, và nó nói OpenVPN thay vì giao thức gốc. Ứng dụng khách gốc nói giao thức gốc và mong đợi hồ sơ của riêng nó. Một máy chủ, hai cửa, và mỗi cửa có khóa riêng.
Phần mở rộng tệp gần như không cho bạn biết gì, vì vậy câu trả lời của nhà vận hành quan trọng hơn tên tệp.
Đọc máy chủ trước khi chạm vào khối chứng chỉ
Hỏi nhà vận hành ba điều: cổng và phương thức truyền nào, phương thức xác thực nào, và họ mong bạn dùng ứng dụng khách nào. Những câu trả lời đó loại bỏ phần lớn phỏng đoán.
Sau đó xác nhận cái gì thực sự đang lắng nghe, chứ không phải cái mà một hướng dẫn khẳng định. Một trình lắng nghe tương thích bị tắt không hiển thị gì trên cổng của nó, còn một cái được bật hiển thị một socket ngay cả khi chưa ai từng kết nối. Sự khác biệt giữa cổng đóng và đăng nhập bị từ chối là chẩn đoán hữu ích đầu tiên. Mọi thứ sau đó phụ thuộc vào việc đã gõ cửa nào.
ss -lunp | grep -E ':1194|:443'
sudo ss -ltnp | grep -E ':992|:5555'
grep -nE '^(remote|proto|auth-user-pass|ca |cert |key )' profile.ovpn
Một cổng UDP thiếu trong danh sách trình lắng nghe là tính năng bị tắt, không phải sự cố tường lửa.
Điều ứng dụng khách gốc cần mà hồ sơ không thể cung cấp
Ứng dụng khách gốc cài một bộ điều hợp mạng ảo và gắn kết nối vào đó. Không có bộ điều hợp đó thì không có giao diện để định tuyến, vì vậy một kết nối gốc có thể xác thực được mà vẫn không mang lưu lượng nào.
Xác thực gốc chạy với một trung tâm ảo, dùng một đối tượng người dùng do quản trị viên trung tâm tạo. Các khối chứng chỉ sao chép từ hồ sơ OpenVPN không trở thành người dùng trung tâm, và người dùng trung tâm không trở thành chứng chỉ ứng dụng khách. Hai hệ thống lưu những thứ khác nhau, và hồ sơ không có chỗ để đặt bản ghi người dùng của trung tâm. Đó là khác biệt cấu trúc chứ không phải vấn đề cú pháp.
Giữ khóa riêng ngoài mọi dịch vụ chuyển đổi, vì một khóa rời khỏi máy phải được coi là đã lộ.
Điều trình lắng nghe tương thích OpenVPN chấp nhận
Trình lắng nghe tương thích là một máy chủ OpenVPN thực sự theo quan điểm của ứng dụng khách: nó mong đợi một ứng dụng khách OpenVPN và các chỉ thị mà ứng dụng khách đó hỗ trợ. Các khối chứng chỉ nội tuyến là tính năng của OpenVPN, và chúng thuộc về phía đó của hàng rào.
Điều nó sẽ không làm là chấp nhận một hồ sơ SoftEther gốc, vì hồ sơ đó không phải cấu hình OpenVPN. Trình lắng nghe cũng không biến ứng dụng khách gốc thành ứng dụng khách OpenVPN. Nếu nhà vận hành chỉ cung cấp dịch vụ gốc, câu trả lời là ứng dụng khách gốc; nếu họ cung cấp trình lắng nghe tương thích, câu trả lời là OpenVPN và vật liệu riêng của nó.
Hãy yêu cầu bản xuất được nhà vận hành hỗ trợ thay vì tự lắp ráp một bản từ các mảnh, vì bản xuất mang theo những chi tiết mà một tệp làm thủ công thường bỏ sót.
Chứng minh đường đi trước khi sửa chỉ thị
Sau khi chọn ứng dụng khách, hãy kiểm tra đường hầm trước khi chạm vào tuyến. Đăng nhập thành công và một giao diện mang lưu lượng là hai kết quả khác nhau.
sudo openvpn --config profile.ovpn --verb 3
ip -br addr
ip route get 10.70.4.20
resolvectl status | grep -A2 'DNS Servers'
So sánh địa chỉ được cấp với nhóm mà nhà vận hành mô tả, sau đó xem tuyến và trình phân giải riêng. Một kết nối trung tâm gốc có thể xác thực sạch sẽ và không cài tuyến nào, điều mà từ phía ứng dụng khách trông như một đường hầm hỏng. Chỉ khi ba điều đó khớp nhau mới đáng sửa một chỉ thị. Sửa sớm hơn sẽ che mất tầng nào sai.