Bước nhảy NAT nào làm rơi ánh xạ VPN nhàn rỗi và cách nhận biết
Một luồng VPN nhàn rỗi có thể chết ở bất kỳ bước nhảy giữ trạng thái nào. Lặp lại một bài kiểm tra, so sánh những gì mỗi ranh giới thấy, và báo cáo kết quả giới hạn thay vì một thủ phạm đoán mò.
Sau một thời gian yên ắng đường hầm kết nối lại, không nhật ký nào nêu tên thủ phạm, và động thái hiển nhiên là chọn thiết bị có tài liệu về thời gian chờ ấn tượng nhất. Đó là một phỏng đoán khoác áo chẩn đoán. Trạng thái có thể tồn tại một lúc trong bộ định tuyến gia đình, trong bộ chuyển dịch của nhà mạng và ở rìa đám mây, và bất kỳ chỗ nào trong đó đều có thể làm rơi một luồng đã im lặng. Thay vào đó, bạn có thể lập bản đồ đường đi, đánh dấu thiết bị nào bạn thực sự quan sát được, và chạy một bài kiểm tra nhàn rỗi có thể lặp lại.
Một bài kiểm tra lặp lại được biến giai thoại thành phép đo. Mọi thứ dưới đây giả định một máy khách, một máy chủ và một giao thức, và giả định bạn chống lại việc đổi hai biến cùng lúc. Mục tiêu là làm cho lần sau rẻ hơn lần này.
Chạy cùng một bài kiểm tra nhàn rỗi mỗi lần
Ghi lại lần cuối luồng còn tốt, sau đó nó nhàn rỗi bao lâu, và liệu một gói mới có đưa nó trở lại không. Ba sự thật đó là phép đo; không có chúng thì chỉ là câu chuyện về một chiếc máy tính xách tay bị rơi. Dùng cùng máy khách, cùng máy chủ và cùng giao thức ở mỗi lần lặp, và ghi lại thời điểm gói đầu tiên sau im lặng được gửi đi.
Sau đó so sánh những gì mỗi ranh giới bạn sở hữu thực sự thấy. Sự phân biệt quyết định cuộc điều tra là máy chủ không thấy gì cả sau khoảng dừng, hay thấy yêu cầu và trả lời vào một đường không còn mang phản hồi nữa.
| What you observe | What it suggests | What it does not prove |
|---|---|---|
| server records no packet after the pause | state was lost upstream of the server | which hop dropped it |
| server answers, client never receives | return-path state or filtering | that the timer belongs to the client |
| client sends nothing at all | client-side timer or application behaviour | that the network path is healthy |
So sánh các đường đi mà không đổi năm thứ
Một mạng truy cập thứ hai được phê duyệt là so sánh hợp lý, vì chuỗi NAT khác nhau. Nó cũng khác về nhà cung cấp, điều kiện vô tuyến và có thể cả họ địa chỉ, nên kết quả là một ranh giới chứ không phải quy kết. Ghi lại các hạn chế cùng với kết quả thay vì âm thầm bỏ chúng khi báo cáo. Viết luôn đường đi: thiết bị, vai trò và liệu trạng thái của nó có đọc được không.
Điều so sánh đường đi mang lại là một câu hỏi giới hạn: luồng sống trên một đường và chết trên đường kia sau một khoảng im lặng tương tự, nên biến nằm ở đâu đó trong những phần khác nhau. Đây là kết quả thật ngay cả khi không nêu tên thiết bị nào, và nó chỉ cho kỹ sư tiếp theo nên dành một buổi chiều ở đâu và không nên ở đâu.
Đáng đọc trạng thái cục bộ trước khi suy đoán về nhà mạng. Trên một cổng Linux, conntrack -L liệt kê các luồng được theo dõi cùng thời gian sống còn lại, biến phỏng đoán về bộ hẹn giờ thành con số bạn có thể nhìn nó hết hạn. Đọc nó trước và sau giai đoạn nhàn rỗi, không chỉ sau.
Tín hiệu giữ kết nối giữ được gì và không giữ được gì
Một tín hiệu giữ kết nối được hỗ trợ giữ ánh xạ mở, và giữ ánh xạ mở không chứng minh gì về dịch vụ phía sau. Đường hầm có thể vẫn được ánh xạ trong khi ứng dụng nó chuyên chở đã ngừng trả lời, và từ đèn trạng thái hai tình huống đó trông giống nhau. Hãy coi tín hiệu giữ kết nối là bảo hiểm chống hết hạn do nhàn rỗi, không phải kiểm tra sức khỏe.
Đặt khoảng thời gian theo thời gian chờ ngắn nhất bạn thực sự đo được, không theo con số sao chép từ diễn đàn. Một tín hiệu giữ kết nối chỉnh dưới mọi bộ hẹn giờ khả dĩ là lưu lượng không ai cần, và nó cũng xóa mất triệu chứng lẽ ra cho bạn biết ranh giới nào hết hạn trước. Chọn khoảng thời gian từ con số đã đo và để mọi thứ khác yên.
Một thay đổi, rồi đo lại
Chống lại mong muốn nâng mọi thời gian chờ và xả mọi cổng trong một bài kiểm tra trực tiếp. Điều đó xóa bằng chứng bạn đến để tìm và làm gián đoạn luồng của người khác, một sự đánh đổi tồi cho giả thuyết chưa được kiểm chứng. Đổi một cài đặt được hỗ trợ trên một thiết bị, rồi lặp lại giai đoạn nhàn rỗi và việc phục hồi của ứng dụng.
Ghi lại quan sát ranh giới nào đã dịch chuyển, và ghi lại cả khi không có gì tốt hơn. Một cài đặt không sửa được gì là thông tin, và nhận ra một lần thì rẻ hơn là lăn nó khắp cơ ngơi.
Viết một phát hiện có thể bảo vệ
Khi không thể kiểm tra bộ chuyển dịch ở thượng nguồn, chỉ nói điều bằng chứng ủng hộ: cuộc trao đổi chết ở đâu đó dọc đoạn này của đường đi sau ngần ấy im lặng, và bước nhảy chịu trách nhiệm vẫn không được quy cho. Một phát biểu giới hạn sống sót qua xem xét và chỉ người tiếp theo đến đúng phân đoạn. Nêu tên một bộ định tuyến ẩn là nguyên nhân không làm được cả hai việc đó. Trao phát hiện giới hạn cho người sở hữu phân đoạn không quan sát được, kèm theo khoảng thời gian.
RFC 4787 mô tả vì sao các bộ hẹn giờ ánh xạ UDP khó suy ra từ một đầu, và chính khó khăn đó khiến phát hiện giới hạn là trung thực. Bộ hẹn giờ là thật, và sự không chắc chắn quanh chúng cũng vậy.