Hai uplink, một gateway và một peer WireGuard mà lưu lượng cứ liên tục xuất hiện trên đường dự phòng. Quá trình bắt tay vẫn khỏe mạnh suốt thời gian. Vì thế rất dễ đọc nhầm triệu chứng thành lỗi WireGuard thay vì lỗi định tuyến.

Thực hiện các bước kiểm tra dưới đây theo thứ tự. Mỗi bước có một điều kiện dừng, và nhảy vượt lên trước thường tạo ra một câu trả lời sai đầy tự tin.

Tách bắt tay khỏi luồng được chuyển tiếp

Trao đổi peer được mã hóa có một tuyến điểm cuối tới địa chỉ công khai của máy chủ. Lưu lượng client được chuyển tiếp có đích khác và có thể được chọn bởi dấu hoặc quy tắc chính sách. Đó là hai quyết định định tuyến dùng chung một giao diện. Coi cái này là bằng chứng về cái kia là sai lầm đầu tiên.

Dừng lại ngay khi bạn bắt gặp mình đang suy luận từ bắt tay. Nó chỉ là bằng chứng về đường tới điểm cuối.

Đọc quy tắc chính sách, không phải bảng mặc định

Bảng mặc định cho thấy điều gì xảy ra khi không có quy tắc chính sách nào khớp. Trên một gateway định tuyến theo nguồn, dấu hoặc đích, quy tắc quyết định nằm ở nơi khác. Bảng thông thường có thể trông hoàn toàn hợp lý trong khi lựa chọn thật sự được thực hiện phía trên nó.

ip rule show
ip route show table main
ip -4 route get 203.0.113.9 from 10.30.8.2

Đọc các quy tắc chính sách và các bảng mà chúng trỏ tới. Sau đó xác nhận quy tắc nào khớp với luồng thử nghiệm của bạn. Một quy tắc tham chiếu tới giao diện không còn mang uplink dự định là một phát hiện, không phải chi tiết. Việc tra tuyến ở cuối cho câu trả lời nhanh hơn nhiều so với đọc bảng rồi đoán.

Kiểm tra dấu và dịch cùng nhau

Định tuyến theo chính sách dựa trên một dấu gói được đặt trước đó trong chuỗi. Nếu quy tắc đánh dấu bỏ sót lưu lượng của bạn, luồng sẽ rơi xuống bảng chính và đi ra qua giá trị mặc định ở đó. Các gói được chuyển tiếp thường bỏ qua những chuỗi được viết cho lưu lượng tạo ra tại chỗ.

nft list chain inet filter prerouting
conntrack -L -s 10.30.8.2 2>/dev/null | head
ip -s link show dev eth1

Dịch phải đồng ý với uplink mang luồng. Một quy tắc dịch sang địa chỉ chính trong khi gói đi ra bằng đường dự phòng tạo ra các phản hồi hướng tới một giao diện mà luồng chưa từng dùng. Kiểm tra điều kiện giao diện của chính quy tắc dịch. Quy tắc vô điều kiện hoạt động cho tới khi uplink thứ hai được dùng, rồi thất bại theo cách trông như gián đoạn.

Để ý giao diện nào mang phản hồi

Bắt gói trên cả hai uplink trong khi một yêu cầu đang chạy. Ghi lại giao diện nào mang yêu cầu và giao diện nào mang phản hồi. Các đường không đối xứng dễ thấy hơn nhiều so với dự đoán.

Nếu phản hồi đến qua uplink sai, vấn đề đã chuyển từ WireGuard sang theo dõi kết nối hoặc dịch. Không thay đổi nào trong cấu hình peer sửa được điều đó.

Chỉ thay đổi một thứ với một đường lùi

Giữ quyền truy cập qua console hoặc ngoài băng trước khi sửa quy tắc chính sách trên gateway. Thực hiện một thay đổi, thử đúng đích đã được cấp phép, rồi kết nối lại và xác nhận bắt tay vẫn dùng đường tới điểm cuối dự định. Thêm một bài thử số trên họ địa chỉ thứ hai, vì chính sách chỉ cho v4 vẫn để lỗi đó mở.

Ghi lại mỗi luồng đã dùng uplink nào. Bản ghi đó biến báo cáo tiếp theo thành một bước kiểm tra hai phút thay vì cả buổi chiều. các ghi chú của WireGuard về không gian tên và định tuyến mô tả cách chủ động tách đường tới điểm cuối khỏi lưu lượng được đưa vào đường hầm, điều thường sạch hơn việc sao chép một cách lách bằng tuyến mặc định.

Bài viết liên quan