Cách kiểm tra máy chủ của một hồ sơ OpenVPN trước khi nhập nó

Ai đó gửi cho bạn một hồ sơ, bạn nhập nó, và ba mươi giây sau một ứng dụng khách đang gọi đến một đích mà chưa ai kiểm tra. Trước tiên hãy đọc tệp trong trình soạn thảo văn bản, vì mọi thứ quan trọng nằm trong một nhúm chỉ thị: remote, proto, port, ca, cert, tls-crypt và verify-x509-name. Mọi thứ còn lại là giá trị mặc định, và đó chính là nơi những bất ngờ trú ngụ.

Liệt kê mọi điểm cuối mà tệp có thể dùng

Hãy bắt đầu từ các điểm cuối, vì một hồ sơ có thể chứa vài điểm. grep -nE '^[[:space:]]*(remote|proto|port|remote-random|connection)' profile.ovpn in mọi ứng viên theo thứ tự trong tệp, kể cả những cái lồng bên trong các khối <connection> nội tuyến.

Khi một chỉ thị bỏ qua cổng, ứng dụng khách quay về giá trị mặc định của trình lắng nghe, vì vậy chỉ remote vpn.example.com nghĩa là cổng 1194 với bất kỳ proto nào xuất hiện sau đó trong tệp. Nhiều dòng remote đơn giản là các lựa chọn thay thế: ứng dụng khách thử chúng theo thứ tự trừ khi remote-random xáo trộn chúng, và nó không bao giờ âm thầm thay thế máy chủ của nhà cung cấp khác. Hai dòng remote trên các miền không liên quan là điểm mà bạn dừng lại và hỏi cái nào mới là ý định.

Cũng để ý cách viết proto. tcp được chấp nhận như từ đồng nghĩa của tcp-client phía khách, nhưng tcp-server trong hồ sơ khách là lỗi cấu hình thường bị treo thay vì thất bại sạch sẽ.

Xác nhận tên trước, rồi đến cổng

dig +short vpn.example.com cho bạn biết tên có tồn tại không và nó trả về những địa chỉ nào, và một điểm cuối nhiều địa chỉ hoặc nằm sau proxy có thể trả về vài địa chỉ một cách hợp lệ. Phân giải tên là điều kiện tiên quyết, không phải bằng chứng sở hữu; bất kỳ ai cũng có thể trỏ một tên vào một địa chỉ, và một địa chỉ có thể trả lời cho nhiều tên.

Sau đó kiểm tra trình lắng nghe trên cổng bạn tìm được, phù hợp với lớp truyền tải. Trên TCP, openssl s_client -connect vpn.example.com:1194 -servername vpn.example.com in chuỗi mà máy chủ trình bày. Trên UDP bạn cần DTLS: openssl s_client -dtls1_2 -connect vpn.example.com:1194 thực hiện cùng một lần bắt tay qua các datagram. Một lần bắt tay hoàn tất chứng minh rằng có gì đó đang lắng nghe và giữ một chứng chỉ, điều này nhiều hơn những gì ping cho thấy và ít hơn những gì chính các thiết lập tin cậy của hồ sơ đòi hỏi.

Khi bắt tay thất bại và máy chủ vẫn trả lời ping, cổng có lẽ sai hoặc bị lọc. Hãy coi đó là lý do để yêu cầu đúng cổng, không phải lời mời quét các cổng lân cận. nc -vzu cũng báo thành công trên một số ngăn xếp khi chẳng có gì lắng nghe, vì vậy một phép thử UDP trần trụi không có nghĩa gì nếu không có bắt tay phía sau.

Đọc các ghim tin cậy tách khỏi địa chỉ

Địa chỉ quyết định khách đi đâu; khối tin cậy quyết định khách tin ai khi đến nơi. verify-x509-name "vpn.example.com" name ghim tên chung của chủ thể, và remote-cert-tls server yêu cầu việc dùng khóa mở rộng để xác thực máy chủ. Một hồ sơ do nhà cung cấp đưa cho bạn nên mang cả hai.

Hãy tìm ca, một khối <ca> nội tuyến, và hoặc tls-crypt hoặc tls-auth. Hồ sơ dùng tls-auth cần key-direction 1 trên khách khi phía máy chủ dùng hướng 0, và sự không khớp làm hỏng bắt tay bằng lỗi TLS đọc như lỗi chứng chỉ. Một CA nội tuyến không thuộc về nhà cung cấp mà bạn vừa phân giải tên nghĩa là tệp được ghép từ hai nguồn, và đó là trường hợp đáng từ chối dứt khoát.

verify-x509-name nhận các chế độ name, name-prefix hoặc subject, và chế độ cuối cùng mong đợi một tên phân biệt đầy đủ theo đúng thứ tự mà máy chủ in ra. Hãy chọn chế độ khớp với hình dạng của giá trị, vì ứng dụng khách từ chối mọi kết nối thay vì cảnh báo về một lần suýt khớp. Với tệp mà bạn không viết, name với một tên máy chủ đơn giản là lựa chọn ít gây bất ngờ nhất.

Kiểm tra các tùy chọn thất bại trong im lặng

OpenVPN 2.6 thương lượng mật mã qua data-ciphers, và một hồ sơ chỉ mang dòng cipher AES-256-CBC cũ có thể hoàn tất kênh điều khiển rồi kẹt ở phần dữ liệu. Đọc giá trị đó cho bạn biết tệp có cũ hơn máy chủ bạn đang tham gia hay không; trang hướng dẫn của 2.6 liệt kê thứ tự thương lượng nếu bạn cần trích dẫn nó cho nhà cung cấp.

auth-user-pass không có tên tệp nghĩa là khách sẽ hỏi, vì vậy một hồ sơ trông tự đủ vẫn cần thông tin đăng nhập. auth-user-pass credentials.txt nghĩa là nó mong đợi một tệp mà có lẽ bạn không được gửi. nobind và resolv-retry infinite là bình thường và vô hại, trong khi explicit-exit-notify chỉ dành cho UDP và vô nghĩa trên TCP.

Không điều nào trong số này thay đổi nơi hồ sơ kết nối, nhưng mỗi điều thay đổi việc nó có kết nối được hay không, và không điều nào hiển thị trong hộp thoại nhập của ứng dụng khách.

Quyết định, rồi ghi lại điều bạn đã quyết

Sau lần đọc này có ba kết cục, và chỉ một là nhập. Khi điểm cuối và các ghim khớp với hướng dẫn bạn nhận được qua một kênh riêng, hãy nhập nó. Khi điểm cuối có vẻ đúng nhưng ghim hoặc CA không khớp, hãy yêu cầu một tệp đã sửa. Khi tệp trộn các điểm cuối hoặc vật liệu CA từ các nguồn khác nhau, hãy xóa nó và yêu cầu một bản sao mới.

Ghi lại mã băm bạn đã xem xét, để người tiếp theo biết tệp có thay đổi hay không: sha256sum profile.ovpn, dán bên cạnh điểm cuối trong ghi chú của bạn. Một hồ sơ là cả một cách sắp đặt, không phải danh sách địa chỉ, vì vậy đừng bao giờ ghép một remote đang hoạt động vào khối tin cậy của người khác trong khi giữ thông tin đăng nhập của họ.

Giữ khóa riêng và mật khẩu ngoài ảnh chụp màn hình và luồng trò chuyện khi bạn so sánh ghi chú. Điểm cuối và các tùy chọn không bí mật là đủ để hỏi một câu chính xác, và phần còn lại thuộc về tệp.

Nếu bạn vẫn nhập nó và lần thử đầu tiên thất bại, hãy chạy ứng dụng khách với --verb 3 và đọc mười dòng đầu: địa chỉ remote đã phân giải, proto đã thương lượng và lỗi TLS xuất hiện theo thứ tự đó, điều này cho bạn biết bạn đã bỏ qua bước kiểm tra nào ở trên.