Cách phân biệt tuyến do VPN đẩy xuống với tuyến tĩnh trên Linux

Một tiền tố xuất hiện trên laptop khi đường hầm dựng lên, nên có cảm giác VPN đã cài nó. Có thể đúng, nhưng cùng kết quả đó cũng có thể đến từ một script máy khách chạy khi kết nối, một hồ sơ kết nối liệt kê subnet, hoặc một tuyến tĩnh vốn có từ đầu và chỉ bắt đầu hoạt động khi giao diện tồn tại. Chọn sai chủ sở hữu nghĩa là tuyến quay lại sau mỗi lần dọn dẹp, và người tiếp theo lại lặp đúng cách sửa đó. Trình tự dưới đây tách ba khả năng trước khi thay đổi bất cứ điều gì.

Bước 1: gọi tên cơ chế cài đặt tiền tố

Các giao thức khác nhau cung cấp khả năng tiếp cận theo cách khác nhau, và gọi tất cả là quảng bá sẽ che mất sự khác biệt. Máy chủ OpenVPN đẩy một chỉ thị tuyến qua kênh điều khiển và máy khách cài nó trừ khi bộ lọc pull chặn. Cấu hình WireGuard liệt kê các tiền tố được phép ở cục bộ, máy khách dùng chúng cho cả định tuyến khóa mã hóa lẫn các tuyến nó thêm vào. Đường hầm IPsec thỏa thuận bộ chọn lưu lượng với đối tác, và nhân cài các tuyến từ những bộ chọn đó.

Xác định đường hầm của bạn dùng cơ chế nào trong số này trước khi đọc bất kỳ bảng nào. Một tuyến được đẩy lúc kết nối không phải là quảng bá của giao thức định tuyến và không hứa rằng tiền tố tiếp cận được phía sau đầu xa. Ghi cơ chế bên cạnh tiền tố, vì nó quyết định chỗ sửa nằm ở đâu.

Bước 2: so sánh bảng qua một lần kết nối

Lưu bảng chính khi đường hầm xuống, dựng nó lên, lưu lại và so sánh hai bản ghi. Mọi thứ xuất hiện thuộc vòng đời kết nối, và mọi thứ còn lại thuộc cấu hình cục bộ.

Ghi lại bằng ip route show table main > /tmp/route-down.txt, kết nối rồi ghi lại. Làm tương tự với ip -6 route nếu trang dùng IPv6, vì tiền tố thiếu ở đó tạo ra lỗi trông như không liên quan đến định tuyến.

Bước 3: đọc metric, không chỉ sự hiện diện

Hai mục cho cùng một tiền tố có thể cùng tồn tại, và nhân chọn metric thấp hơn. Một tuyến tĩnh có metric 50 sẽ tiếp tục thắng tuyến được đẩy ở 100 dù cả hai đều hiển thị, vì thế «tuyến có ở đó» và «lưu lượng dùng nó» là hai phát biểu khác nhau.

Hỏi nhân trực tiếp bằng ip route get 10.20.5.7 và đọc giao diện mà nó báo cáo. Nếu lưu lượng ra ngoài qua card vật lý trong khi tuyến của đường hầm nằm trong bảng, metric hoặc độ dài tiền tố giải thích điều đó, không phải máy khách VPN. Lặp lại việc tra cứu cho một máy chủ bạn biết nằm sau đường hầm và một máy bạn biết là không, và sự khác biệt cho thấy việc tách có hành xử đúng như dự định không.

Bước 4: tìm các mục sống lâu hơn đường hầm

Tuyến tĩnh sống sót qua ngắt kết nối theo thiết kế, và các mục cũ đến từ đó. Một tuyến thường trú trỏ tới giao diện không còn tồn tại có thể nuốt một subnet trong im lặng, và tuyến trỏ tới tên giao diện được dùng lại có thể gửi lưu lượng riêng ra nhầm cửa sau khi khởi động lại.

Kiểm tra phía thường trú ở nơi bản phân phối của bạn dùng, dù là unit systemd-networkd, hồ sơ NetworkManager hay script trong thư mục up của máy khách. Sửa bảng đang sống bằng ip route del chỉ giữ đến lần kết nối tiếp theo. Hãy coi lần xóa đó là phép thử giả thuyết chứ không phải sửa chữa.

Khi đầu xa cung cấp phạm vi sai, hãy nêu với nhà vận hành thay vì lọc mọi thứ. Bỏ toàn bộ cài đặt được đẩy cũng bỏ DNS và chính sách đường hầm chia đôi mà hồ sơ dựa vào.

Bước 5: xác nhận đường về trước khi đổ lỗi cho máy khách

Với kết nối site-to-site hoặc một subnet sau đường hầm, phía xa cần tuyến về địa chỉ máy khách của bạn và bật chuyển tiếp trên gateway. Một đường một chiều trông đúng như lỗi định tuyến của máy khách, chỉ khác là bắt tay và gói đi ra đều thành công.

Lọc đường về thêm một cái bẫy thứ hai trên gateway Linux. Phản hồi đến trên giao diện khác với giao diện tuyến dự đoán bị chế độ nghiêm ngặt bỏ, và các đường bất đối xứng qua hai nhà cung cấp kích hoạt nó một cách đáng tin cậy. Bộ đếm bỏ gói trên gateway, không phải trên máy khách, cho bạn biết lọc có phải nguyên nhân.

Bước 6: kiểm tra tài nguyên, không phải ping

Khi tuyến đã chọn đúng, mở tài nguyên thật và xác nhận lưu lượng về. Một phản hồi ping chứng minh đường đi theo một hướng và không nói gì về dịch vụ, còn một dịch vụ trả lời trên kết nối đã lưu đệm chứng minh còn ít hơn.

Sau đó lặp lại toàn bộ kiểm tra sau khi kết nối lại. Giá trị của trình tự là nó dự đoán lần kết nối sau sẽ làm gì, vì thế cả so sánh lẫn metric đều thuộc về ticket.