End-to-End Trong Mạng Thực Sự Có Nghĩa Gì?

Khi mọi người nói một kết nối là "end to end," họ có nghĩa là dữ liệu di chuyển từ ứng dụng nguồn gốc cho đến ứng dụng đích mà không có một middlebox nào âm thầm viết lại hoặc chấm dứt nó dọc đường. Nghe có vẻ đơn giản cho đến khi bạn bắt đầu theo dõi đường dẫn thực tế của một gói qua NAT, tường lửa, bộ cân bằng tải, và proxy.

Nguyên tắc end-to-end

Ý tưởng này đến từ một bài báo năm 1984 của Saltzer, Reed, và Clark, cho rằng các chức năng nhất định như độ tin cậy và mã hóa nên nằm ở các điểm cuối của mạng, chứ không ở giữa. Mạng cốt lõi chỉ nên chuyển tiếp các gói. Các điểm cuối xử lý kiểm tra lỗi, truyền lại, và sắp xếp.

TCP là ví dụ rõ ràng nhất. Các bộ định tuyến ở giữa không theo dõi số thứ tự hoặc ghi nhận các phân đoạn. Đó là công việc của hai máy chủ chạy TCP stack. Lớp mạng (IP) chỉ cố gắng giao hàng tốt nhất, và TCP trên mỗi đầu sửa những gì bị mất hoặc sắp xếp lại.

Nơi end-to-end bị gián đoạn ngày nay

Các mạng hiện đại vi phạm nguyên tắc này liên tục, thường vì những lý do hoạt động chính đáng:

• NAT viết lại IP nguồn và port, do đó gói mà máy chủ nhìn thấy không phải là gói mà máy khách đã gửi.
• TLS-terminating proxies và load balancers (như AWS ALB hoặc nginx reverse proxy) kết thúc một phiên TCP/TLS và bắt đầu một phiên mới. Điểm cuối thực tế của máy khách là proxy, không phải máy chủ ứng dụng.
• Stateful firewall theo dõi trạng thái kết nối và có thể loại bỏ các gói không phù hợp với các chuỗi mong đợi, hiệu quả chèn chính nó vào cuộc trò chuyện.
• CGNAT trên các mạng ISP có nghĩa là nhiều khách hàng chia sẻ một IP công cộng, phá vỡ giả định rằng một IP ánh xạ tới một máy chủ duy nhất.

Điều này quan trọng trong thực tế khi bạn đang gỡ lỗi. Nếu người dùng báo cáo "kết nối bị gián đoạn," bạn cần biết liệu nó có gián đoạn ở máy tính xách tay của họ, bộ định tuyến nhà của họ, ISP, nút CDN edge, bộ cân bằng tải, hay máy chủ gốc. Suy nghĩ end-to-end buộc bạn phải theo dõi toàn bộ chuỗi thay vì chỉ kiểm tra nhật ký máy chủ của riêng bạn.

Kiểm tra kết nối end-to-end

Một số công cụ thực sự cho bạn thấy đường dẫn, không chỉ thành công/thất bại:

# Theo dõi tuyến đường hop theo hop
traceroute 8.8.8.8

# Trên Linux, MTR cung cấp thống kê liên tục trên mỗi hop
mtr google.com

# Kiểm tra các vấn đề MTU gây phân mảnh hoặc loại bỏ gói âm thầm
ping -M do -s 1472 8.8.8.8

Lệnh cuối cùng đó đáng để hiểu rõ. Các sự cố path MTU discovery là vấn đề "trông giống như kết nối end-to-end nhưng thực tế không phải" cổ điển. Các gói nhỏ như TCP SYN vượt qua tốt, nhưng khi bạn gửi một payload kích thước đầy đủ, một số hop ở giữa âm thầm loại bỏ nó vì nó quá lớn và ICMP "fragmentation needed" đang bị chặn bởi tường lửa. Kết nối treo và mọi người đổ lỗi cho ứng dụng.

Đối với TCP cụ thể, tcpdump hoặc ss -ti trên cả hai đầu cho bạn biết nếu hai máy chủ thậm chí có đồng ý rằng họ có một kết nối mở:

ss -ti dst 203.0.113.5

Nếu một bên nghĩ rằng kết nối là ESTABLISHED và bên kia không hiển thị gì, thứ gì đó ở giữa (thường là tường lửa hết thời gian chờ kết nối nhàn rỗi) đã âm thầm giết nó.

Tại sao điều này quan trọng đối với bảo mật

Mã hóa end-to-end là phiên bản liên quan đến bảo mật của cùng một khái niệm này. TLS giữa trình duyệt và nút CDN edge không giống như TLS giữa trình duyệt và máy chủ gốc của bạn. Nếu CDN chấm dứt TLS và chuyển tiếp plaintext (hoặc một kết nối TLS mới) tới backend của bạn, bạn có hai hop được mã hóa riêng biệt, không phải một kênh được mã hóa liên tục. Điều đó tốt cho hầu hết các trường hợp sử dụng, nhưng nếu bạn đang xử lý thứ gì đó nhạy cảm, bạn cần biết chính xác nơi giải mã xảy ra và ai có thể thấy plaintext ở mỗi hop.

Logic tương tự áp dụng cho VPN. Một VPN "full tunnel" cung cấp cho bạn mã hóa end-to-end từ thiết bị của bạn tới nút thoát VPN, nhưng kết nối từ nút thoát tới máy chủ đích thực tế là một hop riêng biệt với các thuộc tính bảo mật của riêng nó.

Bài học thực tế

Khi ai đó nói rằng một đường dẫn mạng là end to end, hãy hỏi: end to end giữa hai điểm nào chính xác? Máy khách và bộ cân bằng tải? Bộ cân bằng tải và máy chủ ứng dụng? Đặt tên cho các điểm cuối thực tế biến một yêu cầu mạng mơ hồ thành thứ gì đó bạn có thể kiểm tra bằng một bản ghi packet.

Nếu bạn muốn đi sâu hơn về theo dõi lưu lượng thực và đọc bản ghi packet, hãy xem các phân đoạn Wireshark và TCP/IP fundamentals trên nền tảng DEFENSE_GRID của Korra Studio.