Định tuyến đệ quy: khi đường hầm bắt lấy chính các gói của nó

Đường hầm dựng lên, nhật ký cho thấy một lần bắt tay đã hoàn tất, và một giây sau chính phiên đó chết đi rồi kết nối lại thành vòng lặp. Mẫu này có nguyên nhân cụ thể: tuyến đường tới máy chủ giờ trỏ vào bên trong đường hầm, nên những gói mang đường hầm bị gửi xuyên qua đường hầm. Không có gì thay đổi trong phần xác thực, đó là lý do nhập lại thông tin đăng nhập không tạo ra khác biệt nào. Hãy so sánh đường đi bên ngoài trước và sau khi đổi tuyến, và hiện tượng đệ quy sẽ lộ ra.

Trước hết hãy kiểm tra đường đi bên ngoài

Trong cuộc chơi có hai gói chứ không phải một. Gói bên trong thuộc về ứng dụng và nên được mã hóa, còn gói bên ngoài được gửi tới máy chủ và phải tới đó bằng một con đường không phụ thuộc vào đường hầm.

ip route get 198.51.100.7
ip rule show
ip route show table all | grep -F 198.51.100.7
wg show wg0 endpoints

Sau khi đường hầm dựng lên, hỏi nhân hệ điều hành về tuyến đường tới địa chỉ máy chủ, và hỏi lại sau khi tuyến mặc định thay đổi. Bước nhảy tiếp theo rơi vào thiết bị đường hầm chính là hiện tượng đệ quy, và có thể thấy mà không cần bắt gói nào. Việc gắn với giao diện, các nhãn hoặc không gian tên mạng có thể khiến một lần tra cứu thông thường thiếu đầy đủ, nên hãy dùng đúng ngữ cảnh mà máy khách sử dụng. Khi câu trả lời có vẻ đúng nhưng phiên vẫn lặp, hãy đọc các quy tắc của chính sách định tuyến chứ không chỉ bảng chính.

Vì sao phiên chỉ sống thêm một khoảnh khắc

Quá trình bắt tay hoàn tất trước khi tuyến mới được cài, nên vài giây đầu trông vẫn khỏe. Ngay khi máy khách thêm tuyến mặc định, gói bên ngoài tiếp theo đi theo nó vào giao diện mà gói đó phải đi qua. Máy chủ không thấy gì, máy khách gửi lại, và lần thử hoặc hết hạn hoặc giết phiên rồi bắt đầu lại.

Thứ tự đó giải thích vì sao một đường hầm có thể chạy được trên laptop mà hỏng trên router, và vì sao lỗi thường bắt đầu khi lưu lượng khởi chạy chứ không phải lúc kết nối. Nó cũng giải thích vòng lặp: mỗi lần khởi động lại đều dựng lại phiên trước khi tuyến đường khiến điều đó thành bất khả thi.

Tìm xem ai sở hữu ngoại lệ của điểm cuối

Các máy khách được hỗ trợ tự sắp xếp ngoại lệ của mình: một tuyến đường máy chủ qua cổng gốc, hoặc một nhãn giữ socket bên ngoài ở ngoài đường hầm. Câu hỏi là liệu có thứ gì khác đã xóa hoặc ghi đè nó.

Với IPsec dựa trên tuyến, hãy xem xét các bộ chọn chính sách quyết định gói nào đi vào đường hầm và xác nhận rằng địa chỉ của đối tác được loại trừ khỏi đó. Với WireGuard, nhãn tường lửa của giao diện và các quy tắc chính sách của nó giữ các gói vận chuyển ở ngoài đường hầm, nên một tuyến mặc định được thêm thủ công có thể phá vỡ cách sắp xếp đó. Một hồ sơ VPN thứ hai hoặc một script quản trị ghi lại tuyến mặc định là thủ phạm thường gặp. Những quy tắc bỏ qua rộng được thêm từng cái một là kết quả thường thấy, và chúng biến một lỗi định tuyến thành một bảng không ai có thể bảo trì.

Kiểm tra lại sau khi mạng thay đổi

Một tuyến đường máy chủ qua cổng Wi-Fi vẫn đúng cho tới khi máy chuyển sang mạng khác. Khi đó triệu chứng cũ quay lại mà không có thay đổi cấu hình nào.

Ghi lại địa chỉ điểm cuối, tuyến đường trước và sau khi kết nối, và giao diện mà mỗi bên đã dùng. Ba dữ kiện đó thường tách một lỗi của máy khách khỏi việc bị ghi đè, và chúng còn lại sau khi người thu thập chúng rời đi.

Kết nối lại trên mạng mới và lặp lại việc đọc. Nếu ngoại lệ lại thiếu, bản sửa thuộc về hồ sơ sở hữu nó, chứ không phải một lệnh dùng một lần gõ trong lúc sự cố.