Bộ nhớ đệm tuyến VPN có đang che giấu thay đổi của bạn? Kiểm tra ba điều

Xóa bộ nhớ đệm tuyến là phản xạ đầu tiên khi một thay đổi không có hiệu lực, và trên Linux hiện đại đó là công sức lãng phí: bộ nhớ đệm tuyến IPv4 toàn cục đã bị loại bỏ từ nhiều năm trước, nên ip route show cache không in ra gì và không có gì để xóa. Trạng thái đánh lừa bạn sống ở một tầng cao hơn: trong một socket, một ánh xạ NAT, một trình phân giải hoặc một trình quản lý mạng đã áp dụng lại hồ sơ cũ. Ba câu hỏi phân tách những trường hợp đó: đường sai đến từ một luồng mới hay một kết nối cũ, nền tảng của bạn có lưu tuyến vào bộ nhớ đệm hay không, và trạng thái nằm trong định tuyến hay ở trên nó. Hãy trả lời chúng trước khi đặt lại một giao diện.

Kiểm tra một: đường cũ có đến từ một luồng mới?

Một kết nối đã thiết lập giữ tuyến mà nó được tạo ra cùng. Đó là lý do một phiên SSH qua đường hầm sống sót qua thay đổi bảng định tuyến trong khi một phiên mới ngay lập tức đi theo đường mới, và cũng là lý do «thay đổi không làm gì cả» thường có nghĩa là «socket cũ vẫn đang giữ nó». Hãy thử với một tiến trình mới, không phải với cửa sổ bạn đã mở sẵn.

ss -tnp | head
ip route get 1.1.1.1
curl -m 5 -sS -o /dev/null -w '%{remote_ip}
' https://example.com

Lệnh cuối in ra địa chỉ mà kết nối mới thực sự đến được, và đó là cách rẻ nhất để thấy đường thật mà không tin vào một cửa sổ trạng thái. So sánh nó với địa chỉ nguồn mà không gian tên hoặc giao diện lẽ ra phải dùng.

Nếu một luồng mới đi đúng đường còn luồng cũ không hồi phục, hãy ngừng nhìn vào định tuyến. Tuyến đúng; phiên đã cũ.

Kiểm tra hai: nền tảng của bạn có lưu bộ nhớ đệm tuyến không?

Trên Linux câu trả lời là không, theo nghĩa mà hầu hết hướng dẫn muốn nói. Không có bộ nhớ đệm đích toàn cục để bỏ, và mục nhập theo socket giữ một tuyến đã chọn sẽ được giải phóng cùng với socket. Phần bộ nhớ đệm trong hướng dẫn ip-route mô tả hành vi lịch sử, không phải thứ bạn có thể xóa trên một nhân hiện hành.

Các nền tảng khác khác nhau, và đây là nơi việc sao chép lời khuyên đi sai. Windows giữ một bộ nhớ đệm đích mà bạn có thể xóa bằng netsh interface ip delete destinationcache. BSD và macOS hiển thị tra cứu theo từng đích qua route -n get, và bộ nhớ đệm của chúng hết hạn theo lịch riêng. Một lệnh hoạt động trên một trong số đó không làm gì trên Linux, vì vậy cùng một cách sửa dường như thất bại với một nửa số người thử nó.

Bảng NAT hoặc conntrack không phải bộ nhớ đệm tuyến, dù nó tạo ra cùng triệu chứng. Một luồng đã được dịch trước thay đổi của bạn vẫn giữ bản dịch của nó, và conntrack -L sẽ hiển thị nó rất lâu sau khi chính sách định tuyến đã tiến xa. Đó là trạng thái cũ, nhưng việc xóa tuyến sẽ không chạm vào nó.

Kiểm tra ba: trạng thái nằm trong định tuyến hay ở trên nó?

Hãy đọc tra cứu hiện tại trước bất cứ điều gì khác: ip route get cho đích, sau đó cùng lệnh với from và địa chỉ nguồn, sau đó ip rule show. Nếu ba điều đó khớp với ý định của bạn, định tuyến không phải tầng cần sửa, và quan sát cũ đến từ nơi khác.

Ba nghi phạm thường gặp ngồi trên định tuyến. Trình quản lý mạng có thể cài lại một tuyến từ hồ sơ đã lưu vài giây sau khi bạn xóa nó, nên thay đổi của bạn trông như đang quay lại; hãy kiểm tra nmcli connection show --active và trạng thái của unit trước khi sửa bảng lần nữa. Bộ nhớ đệm của trình phân giải trả về một địa chỉ cũ, trông như lỗi định tuyến cho đến khi bạn hỏi cùng tên đó bằng một công cụ bỏ qua bộ nhớ đệm. Nhóm kết nối của một ứng dụng giữ một socket đang hoạt động tới đích cũ và không bao giờ hỏi nhân một quyết định mới.

Ba câu trả lời cho phép kết luận điều gì

Ghép các câu trả lời lại và cách sửa thường tự nói ra. Một luồng mới đi sai đường trên nền tảng không có bộ nhớ đệm tuyến nghĩa là chính sách thực sự sai, nên hãy đọc các quy tắc và bảng mà đường hầm đã cài. Một luồng mới đi đúng đường trong khi phiên cũ bị kẹt nghĩa là vấn đề nằm ở ứng dụng hoặc socket. Tuyến đúng nhưng quan sát hỏng trong cả hai trường hợp nghĩa là trạng thái nằm trên định tuyến.

Hãy chống lại việc làm mới chung chung. Khởi động lại ngăn xếp mạng hoặc xóa mọi tuyến trên một máy có tuyến mặc định là đường hầm có thể cắt đúng kết nối bạn đang dùng để sửa nó, và nó phá hủy bằng chứng lẽ ra cho biết tầng nào đã hỏng.

Nếu thực sự phải xóa gì đó, hãy xóa thứ nhỏ nhất khớp với chẩn đoán: socket của một tiến trình, một mục conntrack, bộ nhớ đệm của trình phân giải. Sau đó lặp lại cùng bài kiểm tra luồng mới và ghi lại điều gì đã thay đổi.

Hãy giữ ba trạng thái tách biệt trong ghi chú của bạn

Cấu hình đã lưu, tra cứu hiện tại và luồng quan sát được là ba sự thật khác nhau, và việc gộp chúng vào «bộ nhớ đệm» là điều khiến lỗi khó tái tạo. Ghi lại hồ sơ hoặc unit sở hữu tuyến, đầu ra của ip route get, và nguồn và đích của kết nối thực.

Ghi bên cạnh nền tảng và phiên bản máy khách, vì một cách sửa xóa bộ nhớ đệm đích của Windows không phải là cách sửa áp dụng cho máy chủ Linux, và một quy trình sao chép giữa hai bên dạy bài học sai. Khi bạn chuyển vấn đề cho người khác, ba dòng đó cho phép họ tái tạo trạng thái hỏng thay vì đoán.