Trình duyệt mở tên máy chủ VPN qua HTTPS mà không phàn nàn, và ứng dụng SSTP vẫn từ chối kết nối. Không có gì mâu thuẫn trong cặp này. SSTP dùng TLS làm lớp truyền ngoài rồi thực thi yêu cầu riêng và tải trọng PPP bên trong kết nối đó, nên việc tải trang thành công chỉ chứng minh một điều hẹp: máy chủ trả lời một GET trên cổng 443. Ứng dụng đang hỏi một câu khác, và máy chủ có thể trả lời câu đó một cách tồi.

Trang tải được còn đường hầm thì không

Người ta chuyển sang kiểm tra bằng trình duyệt vì nó nhanh, rồi coi kết quả là bằng chứng máy chủ có thể truy cập và đã được cấu hình. Đó là bằng chứng về một GET tới đường dẫn mà thanh địa chỉ đã mở, không hơn. Cuộc trò chuyện VPN bắt đầu sau cùng một lần bắt tay TLS, nhưng gửi một phương thức và đường dẫn mà trang web không bao giờ dùng. Vì thế phản hồi 200 cho trình duyệt không nói gì về việc điểm cuối SSTP có tồn tại hay không.

Tách hai quan sát ra và việc tìm kiếm ngắn lại. Lớp truyền và chuỗi chứng chỉ hoạt động, còn điều gì đó trong trao đổi giao thức bên trên thì không. Đây là một cuộc điều tra khác với cổng hỏng hay chứng chỉ hết hạn, và nó cần bằng chứng khác.

Ứng dụng SSTP thực sự gửi gì

Ứng dụng gửi yêu cầu HTTP với phương thức SSTP_DUPLEX_POST tới đường dẫn /sra_{GUID}/, rồi giữ phần thân kết nối mở như một luồng hai chiều mang các khung PPP. Máy chủ tuân thủ trả lời HTTP/1.1 200 và thôi hành xử như máy chủ web. Mọi thứ khác là một chữ ký: 405 hoặc 404 nghĩa là điểm cuối không có, 301 hoặc 302 nghĩa là có gì đó chuyển hướng yêu cầu, và FIN ngay lập tức nghĩa là proxy hoặc máy chủ đã đóng luồng.

Vì thế mục tiêu phải là máy chủ SSTP chứ không phải máy chủ web gắn thêm chứng chỉ TLS. Phương thức, đường dẫn và phần thân tồn tại lâu là yêu cầu của giao thức, nên proxy ngược không thể thêm chúng chỉ bằng cấu hình. Một proxy chuyển tiếp HTTPS thông thường hoàn hảo vẫn có thể từ chối một phương thức mà nó không nhận ra.

Nơi proxy hoặc máy chủ web phá vỡ luồng

Một trung gian kiểm tra dòng yêu cầu HTTP trước khi chuyển bất cứ thứ gì, và một phương thức tùy chỉnh với đường dẫn bất thường có thể không qua được quy tắc của nó. Một số thiết bị phục vụ trang bình thường trong khi từ chối hoặc ngắt đường hầm, nên ứng dụng báo một kết nối bắt đầu rồi chết thay vì một lời từ chối sạch. Những thiết bị khác chấp nhận yêu cầu rồi áp một thời gian chờ phần thân hoặc nhàn rỗi mà keepalive PPP không chịu nổi. Cả hai trông giống nhau từ phía ứng dụng, vì thế giai đoạn đã thất bại quan trọng hơn văn bản lỗi.

Chia sẻ cổng 443 giữa một trang web và SSTP là một lựa chọn định tuyến, không phải lời hứa rằng mỗi chặng xử lý hai cuộc trò chuyện như nhau. Nếu có bộ cân bằng tải, tường lửa hoặc thiết bị kết thúc TLS trên đường đi, hãy thêm nó vào danh sách nghi ngờ trước khi chạm vào cấu hình VPN.

Kiểm tra từng giai đoạn riêng

Chạy các kiểm tra theo thứ tự và dừng ở thất bại đầu tiên, vì mỗi giai đoạn loại trừ một lớp khác. Đầu dò TLS bên dưới tách danh tính chứng chỉ khỏi mọi thứ SSTP làm. Thay tên máy chủ bằng điểm cuối của bạn và đọc subject cùng chuỗi mà nó in ra.

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com

Sau đó ánh xạ bằng chứng còn lại vào các giai đoạn thay vì đoán từ lỗi của ứng dụng. Bảng bên dưới là danh sách kiểm tra để trích dẫn trong phiếu, cùng chữ ký phân biệt một thất bại với thất bại tiếp theo.

StageWhat it provesFailure signature
TCP to 443A listener exists and the path is openTimeout or connection refused
TLS with SNIThe certificate matches the name you useName mismatch or untrusted chain
SSTP_DUPLEX_POST exchangeThe endpoint is an SSTP server405, 404, 301 or an early FIN
PPP authenticationThe user credential was acceptedAuth failure after a 200 response
Inner routingA permitted destination is reachableTunnel up, no reply from the target

Ghi vào phiếu giai đoạn thành công cuối cùng thay vì viết "không thể kết nối". Đặc tả MS-SSTP ghi lại yêu cầu và trao đổi PPP theo sau bắt tay TLS, và là tài liệu tham chiếu cho việc vì sao một bài kiểm tra trên trình duyệt không thể thay thế cả hai.

Danh tính trước, rồi PPP

Danh tính TLS và xác thực PPP là tuần tự, không phải thay thế, và nhầm lẫn chúng đưa người ta đến cấu hình máy chủ sai. Ứng dụng xác thực trước chứng chỉ máy chủ và mục đích dự kiến của nó, sau đó PPP thương lượng trạng thái riêng và xác thực người dùng bằng phương thức thách thức-phản hồi hoặc EAP. Sự cố chứng chỉ tạo ra lỗi khác với mật khẩu bị từ chối, và không lỗi nào mô tả giai đoạn mà lỗi kia bao phủ.

Thay tên máy chủ bằng địa chỉ, hoặc bấm qua cảnh báo chứng chỉ, sẽ loại bỏ kiểm tra lẽ ra xác định giai đoạn thất bại thay vì sửa nó. Giữ cảnh báo và đọc nó. Cũng đừng đặt lại mật khẩu PPP khi trao đổi HTTP chưa bao giờ chạm tới hành vi SSTP, vì thông tin đăng nhập chưa bao giờ được hỏi.

Bài viết liên quan