Vòng lặp tuyến mặc định của WireGuard: tìm đường của điểm cuối

Giao diện khởi động, cấu hình peer trông đúng và không có bắt tay nào bao giờ hoàn tất. Thêm một tuyến mặc định qua đường hầm là bước thường gây ra điều này: cùng bảng tuyến giờ quyết định các gói đã mã hóa của chính đường hầm sẽ đi đâu, và câu trả lời nó tạo ra lại quay vào đường hầm. Không gì có thể chở gói bên ngoài mà sẽ chở gói bên trong, nên kết nối dừng trước khi bắt đầu. Việc sửa rất nhỏ, nhưng có thứ tự, và việc xác minh quan trọng hơn việc chỉnh sửa.

Xác nhận vòng lặp trước khi đổi tuyến

Đọc địa chỉ điểm cuối hiện tại của peer rồi hỏi ngăn xếp định tuyến xem một gói đến địa chỉ đó sẽ đi đâu. Nếu câu trả lời nêu tên giao diện đường hầm, vòng lặp đã được xác nhận và không cần chẩn đoán thêm. Lưu cả hai đầu ra vào bản ghi thay đổi trước khi chạm vào bất cứ thứ gì, vì phép so sánh sau khi sửa là hai lệnh đó. Vòng lặp không tinh tế khi đã nhìn thấy; khó khăn là giao diện trông khỏe mạnh trong khi nó xảy ra.

sudo wg show wg1 endpoints
ip route get 198.51.100.20
ip rule show

Bao gồm các quy tắc chính sách trong bản ghi đó. Một tuyến mặc định trông đúng trong bảng chính vẫn có thể thua một quy tắc chọn bảng khác cho lưu lượng được đánh dấu hoặc không đánh dấu, và vòng lặp sẽ xuất hiện lại với bảng tuyến trông ổn.

Đọc đường của điểm cuối, không phải đường của đường hầm

Đường của điểm cuối là tuyến mà các datagram đã mã hóa đi đến địa chỉ công khai của peer, và nó phải nằm ngoài đường hầm chừng nào đường hầm còn tồn tại. Đường của đường hầm là mọi thứ peer được phép chở. Hai đường này dùng chung một bảng tuyến, và chính vì thế một mục bắt tất cả có thể làm chúng sụp vào nhau. Tách lưu lượng của đường hầm khỏi vận chuyển của chính đường hầm là toàn bộ bài toán thiết kế, và mọi công cụ được hỗ trợ đều giải quyết nó ở đâu đó hơi khác nhau.

Kiểm tra riêng cả hai họ địa chỉ nếu giao diện mang cả hai. Việc loại trừ IPv4 đang hoạt động không cho biết gì về việc điểm cuối IPv6 có còn truy cập được hay không, và cấu hình hỗn hợp có thể trông như đang hoạt động cho đến khi địa chỉ IPv6 của peer được chọn.

Khôi phục đường của điểm cuối bằng một thay đổi mạch lạc

Có hai cách tiếp cận được hỗ trợ, và trộn chúng là cách một thiết lập đang hoạt động trở nên khó đoán. Cách thứ nhất là để công cụ sở hữu giao diện quản lý toàn bộ đường hầm: wg-quick có xử lý riêng cho dải peer mặc định, nó cài đặt một bảng riêng, các quy tắc chính sách và một dấu socket, điều này giữ các gói bên ngoài ở ngoài đường hầm. Hãy để cơ chế đó nguyên vẹn thay vì tái tạo một nửa bằng tay. Một thiết lập trộn tuyến mặc định được thêm thủ công với một trình quản lý vốn đã cài dấu và quy tắc thường thất bại sau khi kết nối lại, khi trình quản lý ghi lại trạng thái mà bước thủ công đã giả định.

Cách thứ hai là thiết kế thủ công trong đó điểm cuối nhận một tuyến máy chủ rõ ràng qua cổng vật lý. Thêm tuyến đó trước tuyến mặc định, thay thế thay vì thêm để một mục cũ không thể thắng, và xác nhận tra cứu sau đó.

sudo ip route replace 198.51.100.20/32 via 192.0.2.1 dev eth0
ip route get 198.51.100.20
sudo ip route add default dev wg1

Xác minh, rồi giữ một đường quay lại

Dấu thời gian bắt tay tiến lên là bằng chứng đầu tiên, và nó mạnh hơn một giao diện chỉ tồn tại. Theo dõi bằng một bài kiểm tra ứng dụng qua đường hầm, rồi cố ý hạ giao diện xuống và xác nhận máy chủ trở về trạng thái dùng được thay vì giữ một tuyến mặc định trỏ vào hư không. Bước cuối đó là bước người ta bỏ qua, và nó quyết định việc khởi động lại có để máy mắc kẹt hay không.

sudo wg show wg1 latest-handshakes
sudo wg-quick down wg1
ip route show default
ip route get 198.51.100.20

Trước tất cả những điều này, hãy lưu trạng thái định tuyến hiện tại và chắc chắn có một đường vào không phụ thuộc vào đường hầm: một bảng điều khiển, một địa chỉ quản lý ngoài băng hoặc một đồng nghiệp tại chỗ. Một máy từ xa mất tuyến mặc định không thể khôi phục qua kết nối mà nó vừa mất, và bước an toàn nhất trong runbook là bước được thực hiện trước lệnh đầu tiên.