Các tầng của SSTP được giải thích: gói bên trong vẫn tiết lộ điều gì

Trong hầu hết các giải thích, hai sự thật về SSTP bị gộp làm một, và chính sự gộp đó khiến các bản bắt gói trở nên khó hiểu. Gói của ứng dụng vẫn tồn tại bên trong kênh được bảo vệ, và kết nối TCP mang kênh đó giữ nguyên địa chỉ của chính nó suốt chặng đường. Thứ chạy trên dây là một vật mang cùng hàng hóa của nó, không bao giờ là thứ thay thế cho một trong hai. Hãy đi qua chồng giao thức từ ngoài vào trong và dán nhãn mỗi ranh giới bạn vượt qua.

Bắt đầu từ vật mang bên ngoài

Thứ đầu tiên trên dây là một kết nối TCP thông thường tới cổng 443, với địa chỉ thật mà các bộ định tuyến chuyển tiếp. Chính kết nối đó là thứ sống sót qua việc dịch địa chỉ mạng và là thứ một nhà cung cấp dịch vụ truy cập có thể đếm. Bảo vệ phần tải không loại bỏ vật mang, và nó không che giấu khối lượng hay thời gian.

Mọi thứ sau điểm này được mang đi thay vì được định tuyến. Vật mang vẫn tiếp tục hoạt động ngay cả khi trao đổi bên trong thất bại.

Đi theo phần đóng gói vào bên trong

Bên trong kênh được bảo vệ có một trao đổi điều khiển SSTP, rồi một phiên PPP, rồi gói mạng mà máy khách muốn được chuyển đến. Mỗi tầng có thương lượng riêng, thông điệp lỗi riêng và máy trạng thái riêng. Vì vậy một sự cố có thể trông như sự cố TLS từ một góc nhìn và như sự cố PPP từ góc nhìn khác. Đọc các tầng theo thứ tự sẽ cho biết máy trạng thái nào đã dừng.

Một bản bắt gói hiếm khi hiển thị toàn bộ chồng giao thức. Tiêu đề bên ngoài chỉ nhìn thấy được bên ngoài điểm cuối, còn tiêu đề bên trong chỉ sau khi giải đóng gói. Sự bất đối xứng đó đến từ nơi bạn đứng, không phải từ giao thức.

Sơ đồ dưới đây nhóm các tầng lại để ít nhất có thể nói về chúng. Nó không phải là cách bố trí byte, nó không hứa một bản ghi cho mỗi gói, và nó không nói gì về số phép mã hóa mà một cách hiện thực thực hiện.

outer IP header
  TCP to port 443
    TLS record layer
      SSTP control and data packets
        PPP frames
          inner IP packet
            application transport and payload

Dán nhãn người quan sát trước khi đọc bản bắt gói

Hai bản bắt gói của cùng một phiên trả lời những câu hỏi khác nhau, và giao diện nơi chúng được lấy quyết định trả lời câu nào. Trên đường truy cập, bạn thấy vật mang và các bản ghi TLS, và có thể đo kích thước cùng khoảng cách mà không nhìn thấy địa chỉ bên trong. Tại điểm cuối, sau khi giải đóng gói, gói bên trong là lưu lượng thông thường theo chính sách chuyển tiếp riêng.

Viết giao diện và hướng lên mỗi bản bắt gói trước khi diễn giải nó. Dấu vết lấy từ một bộ điều hợp vật lý sẽ không bao giờ hiển thị địa chỉ của ứng dụng bên trong như những trường bên ngoài thông thường, và đọc sự vắng mặt đó như một lỗi mã hóa là sai lầm phổ biến. Dấu vết lấy từ bên trong đường hầm hoàn toàn không hiển thị vật mang nào, nên nó không thể trả lời câu hỏi về góc nhìn của nhà cung cấp. Kỷ luật tương tự áp dụng cho nhật ký của điểm cuối, vốn ghi lại thứ tự thương lượng chứ không phải nội dung.

Giữ lại những kiểm tra mà sơ đồ không thể chứng minh

Thứ tự các tầng không chứng minh rằng một triển khai xác thực chứng chỉ máy chủ, thương lượng một phiên bản TLS được hỗ trợ hay cấp quyền cho tài khoản. Mỗi điều đó là một quyết định cấu hình có thể thất bại độc lập với phần đóng gói.

Hãy xác minh chúng bằng một máy khách báo cáo những gì nó đã thương lượng thay vì suy luận từ một bản vẽ. Bắt đầu với bắt tay TLS, rồi trao đổi SSTP, rồi PPP, và dừng ở giai đoạn đầu tiên báo lỗi. Lệnh thứ nhất in chuỗi và phiên bản đã thương lượng, lệnh thứ hai liệt kê các lần bắt tay có trong bản bắt gói.

openssl s_client -connect vpn.corp.internal:443 -servername vpn.corp.internal
tshark -r sstp.pcap -Y "tls.handshake.type == 1"