SSTP sau một proxy kiểm tra TLS: chỗ phiên bị đứt

Trình duyệt của bạn tải mạng nội bộ của công ty, chứng chỉ proxy được tin cậy, và máy khách SSTP vẫn rơi gần cuối kết nối. Mẫu này chỉ vào sự khác biệt giữa một yêu cầu web và một phiên trong đường hầm, không phải mật khẩu sai. Hãy đi qua kết nối từ TCP trở lên và ghi lại giai đoạn đầu tiên thất bại. Chính giai đoạn, không phải mã lỗi, cho bạn biết proxy có phải nguyên nhân không.

Bắt đầu từ nơi máy khách dừng lại

Máy khách đi qua một trình tự cố định: kết nối TCP tới cổng 443, bắt tay TLS, xác thực chứng chỉ, trao đổi HTTP của SSTP, thương lượng và xác thực PPP, rồi cấu hình IP. Mỗi giai đoạn thất bại để lại một dấu vết khác, và việc lẫn lộn chúng đưa bạn tới trang cấu hình sai.

Lỗi TCP là hết thời gian chờ hoặc đặt lại trước khi bất kỳ byte TLS nào xuất hiện. Lỗi TLS là cảnh báo hoặc hết thời gian bắt tay. Lỗi chứng chỉ tạo cảnh báo về chuỗi hoặc tên. Lỗi HTTP đến sau một lần bắt tay thành công, thường là mã trạng thái hoặc đóng ngay lập tức. Lỗi PPP đến sau khi đường hầm đã được thiết lập về mặt kỹ thuật, vì thế nó trông giống vấn đề xác thực.

Đọc nhật ký máy khách để tìm giai đoạn thành công cuối cùng thay vì dòng lỗi đầu tiên. Dòng lỗi thường báo cáo hậu quả, trong khi ranh giới giai đoạn nêu tên thành phần đã từ chối.

SSTP yêu cầu mạng mang gì

SSTP chạy trên TLS ở TCP 443 và sau đó gửi một yêu cầu HTTP tên SSTP_DUPLEX_POST, được định nghĩa trong đặc tả SSTP, tới một đường dẫn có dạng /sra_{GUID}/. Yêu cầu tuyên bố độ dài nội dung thực tế không giới hạn và giữ luồng mở theo cả hai hướng trong suốt vòng đời phiên. Các khung PPP di chuyển bên trong luồng đó.

Đó là lý do một proxy xử lý duyệt web thông thường vẫn có thể thất bại. Một GET hoặc POST với thân hữu hạn có thể được đệm, kiểm tra và chuyển tiếp; một luồng song công với thân không bao giờ kết thúc thì không. Proxy chờ thân hoàn tất sẽ chờ mãi mãi, và máy khách cuối cùng hết thời gian chờ.

Lọc phương thức và xác thực thêm các kiểu thất bại riêng. Nếu proxy yêu cầu thông tin đăng nhập cho yêu cầu, máy khách VPN có thể không trả lời dù trình duyệt sẽ trả lời. Nếu nó xóa hoặc viết lại phương thức, cổng vào từ chối yêu cầu trước khi PPP bắt đầu.

Vì sao kiểm tra thay đổi danh tính

Proxy kiểm tra TLS kết thúc kết nối TLS của máy khách và mở một kết nối riêng tới cổng vào. Vì thế máy khách xác thực chứng chỉ của proxy, không phải của cổng vào, và cổng vào nhìn proxy như đối tác của mình. Khi tổ chức phân phối gốc của riêng mình, cả trình duyệt và máy khách VPN đều có thể chấp nhận chuỗi đó, nên bắt tay thành công và vấn đề chuyển sang giai đoạn tiếp theo.

Xác thực thành công không có nghĩa proxy có thể mang phiên. Nó vẫn phải chuyển tiếp một POST hai chiều không giới hạn mà không đệm, và giữ cả hai kết nối sống trong nhiều giờ. Nhiều sản phẩm kiểm tra được xây cho lưu lượng yêu cầu-phản hồi và xử lý trường hợp này kém hoặc không xử lý.

Vì thế thêm một gốc lạ hoặc tắt xác thực là cách sửa sai. Nó thay đổi chứng chỉ mà máy khách chấp nhận; nó không làm gì với việc xử lý luồng thứ thực sự làm đứt phiên.

Xác định nhà phát hành trước khi đổi cài đặt

Hỏi điểm cuối xem nó trình bày chứng chỉ nào và ai đã ký. Các lệnh dưới đây cho thấy chuỗi và nhà phát hành mà không cần bắt đầu phiên VPN:

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts
curl -vI https://vpn.example.com/

Nếu nhà phát hành là CA công cộng, kết nối cho máy chủ này có lẽ không bị chặn và lỗi nằm ở nơi khác. Nếu nhà phát hành là CA của chính tổ chức, việc kiểm tra đang hoạt động và cổng vào được tới qua proxy. So sánh dấu vân tay với điều nhóm mạng mong đợi trước khi kết luận chỉ dựa vào tên.

Một thử nghiệm trình duyệt tới cùng máy chủ chỉ chứng minh proxy chấp nhận GET. Nó không nói gì về phương thức SSTP, URI của yêu cầu hay tuổi thọ của thân, nên đừng coi một trang nội bộ đang hoạt động là bằng chứng rằng đường hầm được hỗ trợ.

Chọn con đường được hỗ trợ

Hỏi chủ mạng một câu cụ thể: proxy có cho phép một POST song công không đệm tới cổng vào này trên cổng 443 không? Có dẫn tới một ngoại lệ trong proxy hoặc một đường vòng được ghi lại cho máy chủ VPN. Không có nghĩa là con đường đã kiểm tra không thể mang SSTP, và cách sửa được hỗ trợ là một con đường hoặc giao thức khác, không phải chỉnh máy khách.

Các lựa chọn thường gồm một lối ra không bị kiểm tra cho cổng VPN, một thiết kế đường hầm chia tách chỉ gửi lưu lượng công ty qua proxy, hoặc một giao thức thay thế mà tổ chức hỗ trợ trên cổng khác. Mỗi cái thuộc về thiết kế mạng, và mỗi cái nên được thử với cùng thiết bị và hồ sơ để so sánh cô lập con đường.

Ghi lại kết quả: nhà phát hành, giai đoạn thất bại, quy tắc proxy và con đường đã chọn. Người tiếp theo thấy cùng sự đình trệ 98 phần trăm có thể kiểm tra một sự thật thay vì lặp lại toàn bộ hành trình.