Hai bước nhảy VPN liên tiếp: ai thực sự thấy lưu lượng của bạn?

Mỗi hồ sơ khách hàng nêu một máy chủ, nên từ chỗ người dùng chỉ có một đường hầm và một chỗ mà sự bảo vệ kết thúc. Điều xảy ra sau cổng đầu tiên đó là một quyết định thiết kế mà khách hàng không bao giờ thấy, và hai thiết kế phổ biến hành xử rất khác nhau khi bị kiểm tra. Trong chuỗi nối tiếp, cổng đầu tiên giải mã rồi mã hóa lại. Trong chuỗi lồng nhau, nó bóc một lớp ngoài và chuyển tiếp một đường hầm bên trong mà nó không thể mở. Số bước nhảy giống nhau ở cả hai, vì thế khác biệt phải được vẽ ra chứ không phải đếm.

Bắt đầu từ khách hàng và gọi tên cả hai đầu

Bắt đầu từ nơi người dùng bắt đầu, trong hồ sơ kết nối. Nó chứa một địa chỉ từ xa, một phương thức xác thực và, khi thiết kế hỗ trợ, một danh sách tuyến. Gắn nhãn đường hầm ngoài đó từ khách hàng đến cổng A và cho nó địa chỉ ví dụ: địa chỉ đường hầm của khách hàng 10.77.0.2, của A 10.77.0.1 và điểm cuối công khai của A 198.51.100.10, lấy từ dải tài liệu TEST-NET-2 để không gì trong ví dụ có thể trùng với một máy chủ thật.

Không gì trong hồ sơ đó nhắc đến cổng B, và đó không phải lỗi. Bước nhảy thứ hai thuộc về A, và nghĩa vụ duy nhất của khách hàng là đưa lưu lượng đến A và nhận lại những gì quay về. Việc A kết thúc đường hầm, chuyển tiếp nó hay mở một cái mới là câu hỏi mà phần còn lại của chuyến đi này trả lời, và nó quyết định A đọc được gì.

Nối tiếp: A giải mã rồi mã hóa lại

Trong thiết kế nối tiếp, A kết thúc lưu lượng hai lần. Nó bóc lớp bảo vệ khỏi khách hàng, lấy gói IP của ứng dụng và sau đó gửi gói đó qua đường hầm thứ hai do A tạo về phía B. Giữa hai thao tác đó, gói nằm trên đường chuyển tiếp của A như một gói IP bình thường được đánh địa chỉ tới một đích riêng tư.

Điều đó tạo ra hai hệ quả đáng nói thẳng. A có thể áp chính sách lên gói bên trong, dưới dạng tuyến, quy tắc lọc và ghi nhật ký nguồn và đích, và A phải giữ hai bộ thông tin xác thực: một làm máy chủ cho khách hàng và một làm khách hàng của B. Sự bảo vệ tồn tại ở mọi khoảnh khắc, nhưng đối tượng được bảo vệ đổi danh tính tại A.

Từ đó không suy ra rằng A đọc văn bản rõ của ứng dụng. Khi khách hàng và dịch vụ chạy TLS và xác minh chứng chỉ của nhau, A thấy một luồng bản ghi TLS chứ không phải một yêu cầu đọc được. Việc xác nhận nơi sự bảo vệ đó kết thúc đòi hỏi phải nhìn vào chuỗi chứng chỉ của dịch vụ, không phải sơ đồ đường hầm.

Lồng nhau: A chỉ bóc lớp ngoài

Trong thiết kế lồng nhau, khách hàng xây một đường hầm trong tới B trước, rồi mang đường hầm đó bên trong đường hầm ngoài tới A. A bóc tiêu đề ngoài, tìm thấy một đường hầm trong và chuyển tiếp nó mà không giữ khóa của nó, nên sự bảo vệ bên trong vẫn kết thúc tại B.

Khi đó đường lên của khách hàng mang hai lớp, còn đường giữa A và B mang một lớp. A thấy địa chỉ bên ngoài của đường hầm trong, đủ để biết có lưu lượng và đại khái nó đi đâu, và không đủ để đọc tải trọng. Đó là toàn bộ khác biệt so với trường hợp nối tiếp, và không bộ đếm bước nhảy nào cho thấy nó. Điều A vẫn có thể làm là từ chối chuyển tiếp thứ nó không đọc được, và điều đó luôn sẵn có cho nhà vận hành cổng đó.

Việc lồng nhau phải trả giá cho tính chất đó. Mỗi lớp thêm chi phí tiêu đề, nên việc lập kế hoạch MTU và MSS trở thành bắt buộc chứ không chỉ gọn gàng, và một đường đi hoạt động với một lớp có thể âm thầm bỏ các gói lớn khi có hai lớp. Mỗi lớp cũng cần hành vi kết nối lại và giữ kết nối riêng, và một sự cố ở một lớp trông như gián đoạn một phần qua lớp kia.

Vẽ những người quan sát, không chỉ các đường hầm

Các đường hầm là phần dễ của bản vẽ. Những người quan sát mới là chủ đề của thiết kế, nên hãy viết một dòng cho mỗi điểm nhìn và điền xem mỗi bên thực sự đọc được gì.

Hai dòng luôn bị lẫn với nhau: nhà vận hành của A và nhà cung cấp đường hầm của khách hàng. Họ có thể là một thực thể, và tên cổng riêng không làm họ độc lập. Quyền sở hữu độc lập cần kiểm soát hành chính riêng, thông tin xác thực riêng và ghi nhật ký riêng.

Siêu dữ liệu sống sót qua cả hai thiết kế. Thời gian, kích thước gói và số kết nối vẫn quan sát được ở mỗi bước nhảy, nên hai bước nhảy làm tăng chi phí tương quan chứ không xóa tín hiệu. Một thiết kế hứa hẹn vô hình nên được đối chiếu với danh sách đó trước khi ai đó dựa vào nó.

Đi qua các đường hỏng trước khi chọn

Cố ý phá hỏng mọi thứ từ phía khách hàng, theo thứ tự người dùng sẽ gặp. Bắt đầu từ giao diện và MTU của nó, vì việc lồng nhau hỏng ở kích thước gói sớm hơn nhiều so với hỏng ở xác thực.

ip -4 addr show dev tun0
ip link show dev tun0 | grep mtu
ping -M do -s 1380 -c 2 10.77.1.1

Sau đó xác nhận các điểm cuối bảo vệ thay vì giả định chúng. Yêu cầu dịch vụ cung cấp chứng chỉ của nó từ bên trong đường hầm đang mở, và so sánh chuỗi mà khách hàng thấy với chuỗi mà dịch vụ thực sự trình bày. Một cổng ký lại hoặc chặn giữa sẽ thay đổi chứng chỉ đó, và việc kiểm tra trở nên hiển nhiên chỉ với một lệnh.

openssl s_client -connect intranet.example.com:443 -brief < /dev/null

Kết thúc bằng ma trận kết nối lại: đường hầm của khách hàng rơi, đường hầm của B rơi, đường giữa A và B thay đổi. Ghi lại cái gì trở lại và cái gì không, và liệu một kết nối bên trong có bao giờ rơi xuống một tuyến ngoài vật mang dự định của nó. Ghi lại các địa chỉ mỗi bài kiểm tra đã dùng, vì lặp lại nó trên một mạng truy cập khác trả lời một câu hỏi khác. Cũng lặp lại bài kiểm tra MTU sau mỗi lần kết nối lại, vì một đường đi đã thay đổi có thể hạ kích thước dùng được mà không một dòng cấu hình nào dịch chuyển.

Chọn nối tiếp khi A phải áp chính sách lên gói bên trong, hoặc khi khách hàng không chạy được hai đường hầm chồng lên nhau. Chọn lồng nhau khi tải trọng bên trong phải ở lại không đọc được tại A. Viết lựa chọn đó cùng những người quan sát và các con số MTU của nó, và người tiếp theo sẽ không phải vẽ lại toàn bộ bức tranh để trả lời một câu hỏi.