Hồ sơ khóa máy chủ thất bại sau proxy TLS: thế hệ nào?

Một người dùng kết nối được còn người kia thì không, qua cùng một cổng, trong cùng một ngày. Cả hai đều có hồ sơ khóa máy chủ, cả hai đều trên cùng bản dựng Access Server, và khác biệt duy nhất là thời điểm hồ sơ của họ được tạo. Đó là mẫu đáng để nhận ra, vì "khóa máy chủ" gọi tên một chính sách chứ không phải một chuỗi kết nối. Access Server đã phát hành hai thế hệ của hiện vật đó, và một proxy đảo TLS chỉ đứng trước một trong các đường của chúng. Ba điều kiện quyết định bạn đang ở nhánh nào.

Hai thế hệ, hai chuỗi kết nối

Trong thiết kế cũ, còn hiệu lực đến 2.8, tệp được nhập là một hồ sơ giả. OpenVPN Connect dùng nó để xác thực với API web của Access Server qua HTTPS, nhận một hồ sơ tạm khóa người dùng và một token phiên, và chỉ sau đó mới thiết lập VPN. Hai giao vận chạy tuần tự, và cái đầu tiên là một yêu cầu web thông thường.

Định dạng được giới thiệu với 2.9 không thực hiện bước khởi động theo từng kết nối đó. Đây là một hồ sơ gốc mà các OpenVPN ứng dụng tương thích có thể dùng, không chỉ OpenVPN Connect. Tải xuống hoặc nhập qua URL vẫn có thể liên quan đến HTTPS — đó là bước xuất bản, không phải lấy hồ sơ tạm theo từng kết nối.

Bản nâng cấp không nhất thiết viết lại các hồ sơ đã phát hành, nên một phiên bản máy chủ hiện tại vẫn có thể phát hành hiện vật cũ. Bản dựng máy chủ cho biết điều gì là khả thi, không phải điều người dùng này đã nhập.

Ba điều kiện chọn nhánh của bạn

Điều kiện đầu tiên là thế hệ của hiện vật. Yêu cầu tệp, xem nó được tạo ra thế nào, và ghi lại phiên bản ứng dụng đã nhập nó. Nếu bạn không thể xác định thế hệ từ tệp, một hồ sơ mới được phát hành cho tài khoản thử nghiệm sẽ cho bạn biết máy chủ sản xuất gì hôm nay, và đó là thông tin khác với thông tin người dùng đang lỗi có.

Điều kiện thứ hai là giao diện đầu của bạn thực sự kết thúc cái gì. Một proxy đảo HTTP tầng bảy có nhiệm vụ gỡ TLS không phải cùng đối tượng với một bộ chuyển tiếp TCP tầng bốn, và bộ chuyển tiếp UDP cũng không phải. Bố cục thông thường của Access Server trên cổng 443 khiến daemon OpenVPN TCP nhận diện lưu lượng trình duyệt và chuyển nó cho các dịch vụ web, nên việc chèn một bộ kết thúc HTTPS không liên quan ở phía trước không bảo toàn cách xử lý giao thức của daemon đó. Chia sẻ số 443 không làm hai thiết kế tương đương.

Điều kiện thứ ba là lỗi rơi vào đâu. Lỗi trước VPN và lỗi kênh điều khiển trông giống nhau trong một ứng dụng chỉ nói "đang kết nối", nhưng chúng để lại bằng chứng ở những nơi khác nhau. Nếu định dạng cũ đang được dùng, bước khởi động là ứng viên. Nếu định dạng mới đang được dùng, nhật ký truy cập web trống là điều dự kiến và không chứng minh gì theo hướng nào.

Khi hiện vật cũ: bước khởi động thất bại trước

Đọc lỗi thực tế của ứng dụng thay vì trạng thái cuối của nó. Các trường đáng chú ý là lỗi HTTPS, danh tính máy chủ mà ứng dụng mong đợi, đích mà yêu cầu đã đi tới, và liệu việc xác thực chứng chỉ có hoàn tất không. Sau đó đối chiếu chúng với nhật ký của dịch vụ web và proxy phía máy chủ.

Việc một trình duyệt đến được trang đăng nhập không phải bằng chứng rằng xác thực API của ứng dụng này đã thành công. Đó là những yêu cầu khác nhau, với kỳ vọng chứng chỉ khác nhau và thường tên máy chủ khác nhau. Nếu cổng được phục vụ đúng mà ứng dụng vẫn lỗi, thì bất đồng nằm ở đường khởi động, không phải ở mật khẩu người dùng.

Đừng làm cho phép so sánh đạt bằng cách tắt xác thực TLS hoặc nới lỏng chính sách xác thực. Điều đó biến một sự không khớp cấu hình có thể chẩn đoán thành một đường chạy được nhưng chưa được xác minh, và chính thay đổi đó biến một bài thử tạm thời thành một lỗ hổng vĩnh viễn. Tài liệu của Access Server về hồ sơ kết nối mô tả cả hai thế hệ và luồng hồ sơ tạm, và đó là tài liệu tham chiếu cần kiểm tra trước khi cho rằng proxy là thủ phạm.

Khi hiện vật mới: hãy đọc kênh điều khiển

Với hồ sơ kiểu 2.9, ứng dụng đi thẳng đến điểm cuối VPN gốc. Hãy điều tra các điểm cuối trong hồ sơ, giao vận đang dùng, và lỗi kênh điều khiển. Nếu ứng dụng không bao giờ phát ra yêu cầu HTTP, điều đó phù hợp với thiết kế và không phải triệu chứng.

Đây cũng là nơi câu hỏi về proxy đổi hình dạng. Việc gỡ HTTPS không thể phá vỡ một luồng chỉ TCP mà nó không bao giờ thấy, nhưng vẫn có thể phá vỡ bản tải xuống công bố hồ sơ, và một bộ chuyển tiếp chỉ TCP sẽ không mang UDP chút nào. Kiểm tra hồ sơ yêu cầu giao vận nào trước khi kết luận rằng giao diện đầu không liên quan.

Truyền thẳng TLS cho một luồng là một bố cục hẹp. Nó không cung cấp chuyển tiếp UDP và không tái tạo hành vi chuyển tiếp dịch vụ của chính daemon trên 443. Nếu giao diện đầu của bạn làm một trong những điều đó, hãy nói là điều nào, vì cách khắc phục khác nhau.

Các cách khắc phục vẫn hẹp

Kiểm tra ít xâm lấn nhất là tạo một hồ sơ mới được hỗ trợ cho tài khoản thử nghiệm và kết nối qua điểm cuối gốc dự định với cùng các yêu cầu xác thực. Nếu điều đó chạy được còn hồ sơ cũ được giữ lại thì không, bạn đã tách hiện vật khỏi máy chủ và khỏi proxy trong một bước.

Việc phân phối một hồ sơ khóa người dùng loại bỏ hoàn toàn sự phụ thuộc vào bước khởi động cũ, vì không có trao đổi hồ sơ tạm nào có thể thất bại. Nó phải được phát hành cho người dùng dự định, không bao giờ sao chép từ quản trị viên, và nó thay đổi điều ứng dụng được phép làm, nên hãy coi đó là một quyết định chính sách chứ không phải một cách lách.

Sau đó sửa bố cục xuất bản để mọi đường cần thiết đều tồn tại: đường web cho tải xuống và dùng cổng, và đường VPN gốc trên giao vận mà các hồ sơ mong đợi. Giữ công việc của proxy trên một tầng. Một đường hầm khóa người dùng chạy được chứng minh đường đó chạy được; nó không chứng minh mọi bố cục proxy hỗ trợ mọi thế hệ, và một lỗi khởi động cũ không kết tội định dạng mới hơn.

• Xác định thế hệ của hiện vật trước khi chạm vào proxy.
• Xác định lỗi xảy ra trước đường hầm hay bên trong nó.
• Xác nhận giao diện đầu kết thúc cái gì: HTTP, luồng TCP hay UDP.
• Thử một hồ sơ vừa phát hành với điểm cuối gốc khi chính sách không đổi.