Vì sao nhiều kết nối ứng dụng dùng chung một phiên OpenVPN

Hãy hình dung một trình duyệt đang tải trang HTTPS trong khi một máy khách SSH vươn tới máy chủ khác và một bộ phân giải trả lời một truy vấn, tất cả qua một phiên OpenVPN. Trên giao diện vật lý bạn thấy một cuộc trò chuyện; bên trong đường hầm bạn thấy ba. Cả hai góc nhìn đều đúng, và biết vì sao chính là khác biệt giữa một bản bắt gói hữu ích và một bản gây rối. Theo một luồng bên trong từ ổ cắm đến sợi dây và việc phân tầng không còn trừu tượng nữa.

Một cuộc trò chuyện bên ngoài, nhiều luồng bên trong

Mỗi ứng dụng mở ổ cắm riêng, và nhân hệ điều hành cấp cho nó một bộ năm gồm địa chỉ nguồn, cổng nguồn, địa chỉ đích, cổng đích và giao thức. Những bộ năm đó tồn tại trước khi bất kỳ đường hầm nào tham gia. Sau đó việc định tuyến quyết định rằng tất cả đều đi ra qua thiết bị đường hầm, nên gói được trao cho OpenVPN vẫn mang các tiêu đề gốc ở bên trong. OpenVPN mã hóa gói bên trong đó và bọc kết quả vào một cuộc trò chuyện UDP hoặc TCP bên ngoài duy nhất với đối tác. Vậy cuộc trò chuyện bên ngoài là một, còn các luồng bên trong nhiều bằng số ứng dụng đã mở.

Không có gì sụp đổ. Các bộ năm bên trong tồn tại từ đầu đến cuối, và đó là lý do phía xa vẫn phân biệt được ba luồng.

Cổng giữ nguyên cố định

Thứ không đổi là bộ năm bên ngoài: địa chỉ của bạn, cổng cục bộ mà máy khách đã gắn, địa chỉ đối tác và cổng dịch vụ đã cấu hình. Chính bộ năm này là thứ tường lửa hay NAT trên đường đi phải cho phép, và là thứ một bản bắt gói trên tuyến lên sẽ hiển thị. Nó cũng là thứ thay đổi sau khi kết nối lại hoặc chuyển mạng, vì máy khách có thể gắn một cổng cục bộ khác. Một đường hầm không có nghĩa là một cổng nguồn cố định mãi mãi.

Cổng bên trong mới là thứ các đầu mút quan tâm. Một luồng HTTPS giữ cổng đích 443 bên trong đường hầm dù phương tiện vận chuyển bên ngoài nằm trên cổng mà nhà vận hành đã cấu hình. Các đầu mút của ứng dụng không bao giờ biết về cổng bên ngoài.

Việc bóc gói thay đổi điều gì ở đầu xa

Tại đối tác, lớp bên ngoài được bóc ra, và gói bên trong là thứ còn lại. Từ đó, việc chuyển tiếp và chính sách truy cập áp dụng cho đích và giao thức bên trong. Máy chủ web vẫn nhận một kết nối HTTPS, trình nền SSH vẫn nhận SSH, và bộ phân giải vẫn nhận một truy vấn.

Đó là lý do một quy tắc cho phép phương tiện vận chuyển bên ngoài không phải là quy tắc cho phép một dịch vụ bên trong. Quy tắc đầu mô tả một đường đi; quy tắc sau mô tả một sự cho phép.

TCP bên ngoài nghĩa là một luồng, không phải một kết nối

Khi phương tiện vận chuyển bên ngoài là UDP, số phận của mỗi luồng bên trong là độc lập: một datagram bị mất ảnh hưởng tới một lần truyền cho đến lần gửi lại của chính nó. Khi phương tiện vận chuyển bên ngoài là TCP, mọi luồng bên trong chia sẻ một luồng byte đáng tin cậy.

Chính luồng chia sẻ đó là phần người ta bỏ sót. Việc phục hồi diễn ra một lần, cho tất cả, nên một phân đoạn bị mất làm chậm lưu lượng của mọi ứng dụng được ghép kênh bên trong. Vẫn là nhiều kết nối ở các đầu mút và một kết nối trên sợi dây, và hiệu ứng chặn đầu hàng sống ngay trên sợi dây. Số cổng đang lắng nghe không cho bạn biết gì về điều này, và đó là lý do đếm cổng là cách tệ để suy luận về hiệu năng đường hầm.

Mô tả chính xác thiết lập của bạn

Hãy gọi tên lưu lượng bên trong đã chọn và phương tiện vận chuyển bên ngoài cụ thể chuyên chở nó, thay vì nói rằng máy gửi mọi thứ qua một cổng. Các dịch vụ cục bộ, một đường hầm thứ hai và họ địa chỉ còn lại đều tạo ra những luồng không bao giờ vào cuộc trò chuyện này. Một bản bắt gói trên tuyến lên hiển thị bộ năm bên ngoài; một bản bắt gói trong đường hầm hiển thị các bộ bên trong.

Lấy cả hai và đặt các dấu thời gian cạnh nhau. Nếu cần chứng minh ứng dụng nào tạo ra luồng bên trong nào, bảng ổ cắm trên máy chủ là công cụ tốt hơn, vì nó ánh xạ cổng trực tiếp tới tiến trình. Sau đó ghi lại bộ năm bên ngoài bạn đã quan sát và thời điểm bạn quan sát nó, vì bản bắt gói tiếp theo sau một lần kết nối lại có thể hợp lệ mà hiển thị những con số khác.