OpenVPN hay IKEv2: bốn bước kiểm tra trước khi chọn giao thức

Việc chọn giữa OpenVPN và IKEv2 thường được tranh luận như một câu hỏi về giao thức, và cách đặt vấn đề đó làm lãng phí quyết định. Điều quyết định là liệu máy chủ và thiết bị của bạn có hỗ trợ cùng một cấu hình hoàn chỉnh hay không, và liệu cấu hình đó có chịu được cách bạn di chuyển giữa các mạng hay không. Hai ngăn xếp không chuyển hóa thành nhau: tệp OVPN không phải là cấu hình IKEv2 với cú pháp khác. Bốn bước kiểm tra, thực hiện theo thứ tự, trả lời câu hỏi nhanh hơn bất kỳ bảng tính năng nào.

Thiếu ứng dụng khách là hết tranh luận

Windows và macOS có sẵn ứng dụng khách IKEv2, nên cấu hình IKEv2 không tốn thêm chi phí triển khai ở đó và thừa hưởng các tùy chọn cung cấp mà hệ điều hành đã mở ra. OpenVPN trên cùng những máy đó nghĩa là một ứng dụng khách bên thứ ba phải cài đặt, cập nhật và hỗ trợ, và ứng dụng khách đó phải chấp nhận mọi tùy chọn mà cấu hình sử dụng. Hãy đếm các nền tảng bạn phải bao phủ trước khi so sánh bất cứ điều gì khác, vì một nền tảng không có ứng dụng khách hoạt động được thì không phải là điểm so sánh.

Trên Windows, một lệnh liệt kê các cấu hình đã tồn tại và cho biết mỗi cấu hình thuộc loại nào. Tên mà nó in ra là tên mà các bước kiểm tra sau đó sử dụng.

Get-VpnConnection -AllUserConnection
Get-VpnConnection -Name <profile-name> | Select-Object Name, ServerAddress, TunnelType

Lời nhắc cài đặt ứng dụng khách là câu trả lời thực sự cho cột OpenVPN trên những nền tảng đó, và đó là công việc triển khai chứ không phải giới hạn của giao thức. Không cách bố trí nào loại bỏ việc kiểm tra tin cậy, xác minh danh tính hay bảo trì. Hãy hỏi cấu hình được phân phối thế nào, thông tin đăng nhập được gia hạn ra sao và thiết bị bị mất được gỡ bỏ thế nào trước khi bạn cam kết. Một bản cài đặt đơn giản vẫn có thể che giấu quy trình khôi phục mà không ai muốn chạy vào cuối tuần.

Tính di động là thiết lập chung, không phải lời hứa của giao thức

IKEv2 có thể dùng MOBIKE khi cả hai đầu hỗ trợ và bật nó, cho phép ứng dụng khách giữ đường hầm trong khi địa chỉ của nó thay đổi. RFC 4555 định nghĩa phần mở rộng này, và cách diễn đạt có điều kiện rất quan trọng: máy chủ bỏ qua khả năng đó sẽ thương lượng lại thay vào đó. Kết quả có thể trông giống hệt khi truyền tệp và rất khác khi gọi trực tiếp.

Hãy thử chuyển đổi mà bạn thực sự quan tâm, với một thứ đang chạy mà bạn có thể quan sát. Để ping -t <internal-host> chạy trên Windows, hoặc ping đơn giản ở nơi khác, rồi chuyển từ Wi-Fi sang mạng di động và quan sát các khoảng trống. Lỗi MOBIKE xuất hiện dưới dạng xác thực lại toàn bộ trong nhật ký ứng dụng khách, chứ không phải cập nhật địa chỉ âm thầm. Điều bạn đang đo là đường hầm có chịu được thay đổi hay không, chứ không phải giao thức có quảng cáo hỗ trợ hay không.

Các ứng dụng khách OpenVPN kết nối lại theo hành vi nền tảng của chúng và bộ đếm thời gian của cấu hình, nên cùng một bài kiểm tra có thể tạo ra hình thức gián đoạn khác. Hãy so sánh sự kiện quan trọng với người dùng của bạn, chứ không phải nhãn trên giao thức.

Thông tin đăng nhập thuộc về dịch vụ, không phải ngăn xếp

Chứng chỉ và các cách đăng nhập khác thuộc về dịch vụ kết thúc kết nối. Yêu cầu mật khẩu ở một ứng dụng khách không nói gì về khả năng tương thích với ứng dụng khác, và một cấu hình hoạt động với cổng khác không nói gì về cổng này. Hãy giữ nguyên các quy tắc danh tính máy chủ khi so sánh hai ngăn xếp. Đổi giao thức trước khi xác định lỗi thường tạo ra cấu hình thứ hai không tương thích.

Hãy kiểm tra thông tin đăng nhập mà ứng dụng khách sẽ trình bày trước khi đổ lỗi cho bất kỳ giao thức nào, vì chứng chỉ hết hạn hoặc cấp sai đều thất bại như nhau ở cả hai. Kết quả bên dưới hiển thị chủ thể, nhà phát hành và ngày hiệu lực mà không đọc khóa riêng tư.

openssl x509 -in client.crt -noout -subject -issuer -dates

Với kết nối công ty, hãy dùng phương thức mà công ty công bố và ngừng coi việc so sánh là một thí nghiệm. Nếu bạn tự so sánh hai lựa chọn, trước tiên hãy kiểm tra xem cả hai có kết thúc ở cùng một cổng hay không, vì chi tiết duy nhất đó quyết định bao nhiêu phần kết quả của bạn là về giao thức. Một lời từ chối nêu tên thông tin đăng nhập là vấn đề thông tin đăng nhập, và đổi giao thức bao nhiêu cũng không sửa được.

Kiểm tra xem đường hầm thực sự định tuyến gì

Sau khi kết nối, hãy xác nhận rằng tuyến bạn cần tồn tại và tên được phân giải. Một cấu hình dành cho tài nguyên nội bộ có thể cố ý để việc duyệt web thông thường trên đường cục bộ, và đó là quyết định chính sách chứ không phải lỗi. Điều quan trọng là các đích mà nhóm bạn dùng có thể truy cập qua đường hầm hay không.

Trên Windows, hai lệnh bao quát tuyến và tra cứu tên. Tương đương trên Linux là ip route show default và resolvectl query <internal-host>.

Get-NetRoute -DestinationPrefix 0.0.0.0/0
Resolve-DnsName <internal-host>

Một đường hầm dựng lên mà không định tuyến gì hữu ích là kết quả phổ biến khi cấu hình bị sao chép giữa các dịch vụ, và bài kiểm tra kết nối chung sẽ không cho thấy điều đó vì giao diện đang hoạt động. Hãy thử tài nguyên mà người dùng của bạn mở đầu tiên, không phải một địa chỉ công cộng mà bất kỳ đường nào cũng tới được. Nếu tên phân giải thành địa chỉ công cộng trong khi tuyến trỏ vào trong đường hầm, câu trả lời DNS và tuyến thuộc các quyết định khác nhau và cả hai đều cần sửa.

Sau các bước kiểm tra, hãy cân nhắc bảo trì

Không giao thức nào dễ bảo trì hơn một cách trừu tượng. Bảo trì phụ thuộc vào việc ai vận hành cổng, cấu hình đến thiết bị thế nào và thiết bị bị mất mất quyền truy cập nhanh ra sao. Một ứng dụng khách đầu cuối đơn giản có thể đứng trước một máy chủ khó vận hành hơn, và điều ngược lại cũng xảy ra. Hãy hỏi nhóm bạn có thể tiếp tục vận hành cái nào trong hai sau khi người xây dựng nó rời đi.

Chọn kết nối được hỗ trợ bao phủ công việc, rồi kiểm tra nó với quyền truy cập bạn thực sự cần, không phải với danh sách tính năng. Ghi lại mỗi lựa chọn kết thúc ở cổng nào, vì hai cổng khác nhau làm việc so sánh trở thành câu hỏi về tuyến cũng nhiều như về giao thức. Lặp lại bốn bước kiểm tra trên thiết bị bạn thực sự sẽ mang theo, và giữ lại cấu hình vượt qua trên đó.