Một trang trình duyệt duy nhất hiển thị địa chỉ IP hầu như không chứng minh được gì về đường hầm chia tách. Địa chỉ nhìn thấy được có thể là đúng vì lý do sai, và một luồng bị loại trừ thì không bao giờ được nó kiểm tra. Hãy ghi lại kết quả mong đợi trước khi kiểm tra: ứng dụng hoặc đích nào nên dùng đường hầm, cái nào nên đi trực tiếp, và điều gì phải dừng lại khi đường hầm thất bại. Không có kế hoạch đó, mọi con số hợp lý đều trông như thành công.

Lầm tưởng: một lần tra cứu địa chỉ chứng minh độ phủ

Việc kiểm tra IP trả lời một câu hỏi: thế giới bên ngoài nhìn thấy gì từ một ứng dụng tại một thời điểm. Nó không nói gì về một tiền tố nội bộ, một hồ sơ trình duyệt thứ hai hay một tên cần được phân giải riêng tư. Nó cũng không nói gì về thất bại, và đó là một nửa của thiết kế đường hầm chia tách bị hỏng trong môi trường sản xuất.

Trang địa chỉ cũng không thể hiển thị tuyến đường, bộ phân giải hoặc chính sách thất bại. Hãy coi nó là một quan sát, không phải một phán quyết.

Thử một luồng được bao gồm và một luồng bị loại trừ

Gửi một yêu cầu vô hại từ ứng dụng nên được bao gồm, hoặc tới tiền tố mà bạn kỳ vọng sẽ được định tuyến qua đường hầm, và ghi lại nguồn, đích, họ địa chỉ và đường đi quan sát được. Làm điều tương tự cho một luồng nên đi trực tiếp. Phía bị loại trừ là phía mà mọi người bỏ qua, và đó là bằng chứng duy nhất cho thấy việc chia tách là có chủ ý chứ không phải ngẫu nhiên. Một tiến trình phụ có thể mang một danh tính chính sách riêng, nên hãy kiểm tra trong tiến trình sở hữu socket.

flow: Firefox to intranet.example:443, IPv4, source 10.8.0.6, tunneled
flow: Firefox to 1.1.1.1, IPv4, source 192.0.2.20, direct

Vì vậy, một bài kiểm tra chạy trong ứng dụng sai có thể cho thấy điều ngược lại với ý định của thiết kế. Ghi lại bốn trường cho cả hai phía trước khi đưa ra bất kỳ kết luận nào.

Thêm DNS và trường hợp thất bại

Hỏi bộ phân giải của hệ thống và bộ phân giải mà ứng dụng sử dụng, sau đó so sánh các câu trả lời đó với địa chỉ đầu ra mà trang web báo cáo. Hai lớp có thể không đồng ý một cách có chủ ý, và một lần tra cứu trên trình duyệt không kiểm tra chính sách của hệ điều hành. Một shell làm cho việc so sánh trở nên lặp lại được: Cố ý cắt đường hầm, rồi gửi một yêu cầu mà trình duyệt chưa lưu trong bộ nhớ đệm; một trang được phục vụ từ bộ nhớ đệm không cho bạn biết dự phòng đã đi theo hướng nào. Ghi lại điều thực sự đã xảy ra thay vì điều thiết kế dự đoán.

curl -s https://ifconfig.me
nslookup intranet.example

Đường hầm chia tách thất bại theo kiểu đóng và loại thất bại theo kiểu mở trông giống hệt nhau cho đến khi bạn cố ý cắt đường hầm. Ghi lại hành vi bạn quan sát được, không phải hành vi bạn mong đợi.

Lặp lại sau khi trạng thái thay đổi

Lặp lại các quan sát tương tự sau khi kết nối lại, chuyển mạng và cập nhật ứng dụng liên quan. Một ngoại lệ đã lưu có thể tiếp tục trỏ tới một đường đi hoặc danh tính ứng dụng không còn tồn tại, và thiết kế lặng lẽ không còn khớp với tài liệu của nó. Ba sự kiện đó là nơi các đường hầm chia tách trôi dạt, và mỗi sự kiện đều rẻ để kiểm tra lại. Một bài kiểm tra chỉ chạy một lần khi triển khai mô tả một cấu hình không còn tồn tại.

Nếu một kết quả khác đi, hãy tìm chủ sở hữu quy tắc và giai đoạn xử lý trước khi thay đổi nhiều cài đặt cùng lúc. Thay đổi năm thứ và quan sát một kết quả không phải là chẩn đoán, đó là một cấu hình mới.

Kết quả cần xác lập điều gì

Gắn các quan sát với chính sách và phiên bản máy khách mà bạn thực sự đã kiểm tra. Mục tiêu là cho thấy việc triển khai này khớp với độ phủ mà nó tuyên bố, không phải rằng mọi ứng dụng trong tương lai sẽ riêng tư. Đó là một tuyên bố hẹp hơn, và đó là điều bạn thực sự có thể chứng minh bằng bằng chứng. Ghi tuyên bố, phiên bản và kết quả bốn trường vào nhật ký thay đổi.

Sau đó người đánh giá tiếp theo có thể biết thiết kế đã thay đổi hay bài kiểm tra đã thay đổi. Đường hầm chia tách được xác minh khi cả hai phía, việc tách bộ phân giải và hành vi khi thất bại khớp với những gì bạn đã ghi lại lúc đầu. Một kết quả IP không xác minh điều nào trong số đó.

Bài viết liên quan