WireGuard: không có tuyến tới peer sau khi đổi subnet — hai lối ra

Bắt tay vẫn mới trong wg show, điểm cuối đúng, khóa chưa từng đổi — vậy mà ping vẫn báo không có tuyến tới peer. Bạn đã đổi subnet của tunnel một giờ trước. Triệu chứng đó là dấu hiệu của sự lệch tiền tố chứ không phải lỗi khóa: WireGuard hoàn tất bắt tay rồi bỏ dữ liệu vì địa chỉ nguồn không còn khớp với thứ mà peer nhận sẽ chấp nhận. Có hai cách hợp lý để thực hiện một thay đổi subnet, và chúng hỏng ở những chỗ khác nhau.

Hai cách thực hiện thay đổi, và chi phí của mỗi cách

Phương án A là đánh số lại tại chỗ: sửa địa chỉ giao diện, dải của các peer, tuyến đường và mọi bản sao của cấu hình, rồi tải lại. Phương án B là dựng giao diện thứ hai trên tiền tố mới bên cạnh cái cũ, chuyển các peer sang, và gỡ giao diện cũ sau khi lưu lượng đã thực sự chuyển.

Chính trạng thái áp dụng dở dang khiến phương án A nguy hiểm, vì nó không trông như hỏng. Giao diện lên, bắt tay thành công và chỉ đường dữ liệu hỏng. Phương án B tốn nhiều công hơn nhưng giữ một đường đang chạy sống trong khi bạn tìm mọi tham chiếu.

Những gì phải di chuyển cùng nhau ở phía bạn

Bốn thứ trên máy cục bộ mô tả cùng một subnet, và đổi một là đổi tất cả: địa chỉ giao diện, AllowedIPs của từng peer, tuyến mà hệ thống dùng cho các đích đó, và mọi thứ trình quản lý cài đặt thay bạn. Với wg-quick, hai thứ cuối được sinh từ cấu hình mỗi lần giao diện lên, nên một bản sao cũ sẽ âm thầm cài lại tiền tố cũ.

So sánh thứ đã cấu hình với thứ đang chạy thay vì tin vào một trong hai:

wg show
wg showconf wg0
ip addr show wg0
ip route get 10.90.0.5

Tra cứu tuyến là bước mọi người bỏ qua. Nó trả lời nhân hệ điều hành thực sự sẽ làm gì với một đích, kể cả một tuyến cụ thể hơn do trình quản lý hoặc môi trường chạy container để lại. Nếu nó báo một giao diện khác với tunnel, thì cấu hình không phải là vấn đề.

Với giao diện đang chạy, hãy áp dụng tệp đã sửa mà không phá tunnel:

wg syncconf wg0 <(wg-quick strip wg0)

Việc đó cập nhật peer và dải tại chỗ. Nó không cập nhật địa chỉ giao diện hay tuyến đường, vì đó không phải thiết lập của WireGuard — nên đánh số lại vẫn cần dựng lại giao diện hoặc đổi địa chỉ bằng ip, rồi kiểm tra lại định tuyến.

Những gì phải di chuyển cùng nhau ở đầu xa

Đây là nơi một thay đổi subnet thường chết. AllowedIPs không chỉ là gợi ý định tuyến; nó còn là danh sách địa chỉ nguồn mà một peer được phép trình ra. Khi bạn đánh số lại các máy khách và để AllowedIPs của máy chủ trên tiền tố cũ, máy chủ chấp nhận bắt tay, nhận các gói đã mã hóa rồi vứt chúng đi vì nguồn bên trong không khớp với bất kỳ dải nào mà nó gắn với peer đó. Không có lỗi nào được ghi, và máy khách thấy hết thời gian chờ.

Vì thế hãy cập nhật phía nhận một cách có chủ đích: mục peer trên máy chủ phải liệt kê tiền tố mới của máy khách, tuyến về của chính máy chủ phải trỏ tới tunnel cho tiền tố đó, và mọi mạng hạ nguồn phía sau máy chủ phải học đường mới. Chính sách tường lửa từng nêu dải cũ cũng cần cách xử lý như vậy, và mọi thứ chọn lọc dựa trên nguồn cũng thế.

Chẩn đoán phân biệt hai kiểu hỏng rất rẻ. Bắt tay mới mà không có dữ liệu nghĩa là tunnel đang lên và cách đánh địa chỉ bên trong không khớp. Hoàn toàn không có bắt tay nghĩa là bạn đang nhìn khả năng tiếp cận hoặc khóa. Đừng xoay khóa vì một vấn đề tiền tố; nó đặt lại thứ duy nhất đang hoạt động.

Những bản sao cũ sống lâu hơn chỉnh sửa của bạn

Sửa một tệp không giống như thay đổi hệ thống đang chạy, và số bản sao nhiều hơn người ta tưởng: unit hoặc trình quản lý sở hữu giao diện, một hồ sơ thứ hai cùng tên trong thư mục khác, một container với cấu hình nướng sẵn trong ảnh, giao diện router giữ bản đã sửa của riêng nó, và một ứng dụng máy khách nhập lại tunnel đã lưu khi khởi chạy. Mỗi thứ trong số đó đều có thể khôi phục tiền tố cũ sau khi thay đổi của bạn trông đã xong.

Tên cũng di chuyển. Nếu tuyến số hoạt động mà tên máy chủ hỏng, một bản ghi DNS nội bộ hoặc cấu hình dịch vụ vẫn trỏ tới địa chỉ tunnel cũ. Hãy sửa tham chiếu thay vì mở rộng mọi dải peer, vì làm thế sẽ che lấp vấn đề thật và đồng thời làm ACL nguồn lớn hơn.

Hãy để mở một đường khôi phục trong khi làm việc: một cách thứ hai để vào máy, một console nối tiếp, hoặc một lần hoàn tác tệp cấu hình theo lịch. Một thay đổi tunnel khóa bạn ra khỏi chính chiếc máy bạn đang sửa là cách phổ biến nhất khiến việc này thành cả một buổi tối.

Chọn giữa hai cách, và xác minh cú chuyển

Chọn A khi bạn sở hữu mọi peer, số lượng ít và một gián đoạn ngắn là chấp nhận được. Chọn B khi peer là những bàn tay ở xa mà bạn không kiểm soát, khi một liên kết giữa các site phải duy trì, hoặc khi bạn không thể bảo đảm mọi bản sao được cập nhật trong một lượt. Trong trường hợp đó hãy thêm tiền tố mới vào cả hai giao diện, chuyển từng peer một, theo dõi lưu lượng trên cái mới, và chỉ sau đó mới gỡ giao diện cũ cùng các tuyến của nó.

Dù chọn cách nào, thay đổi hoàn tất khi bốn kiểm tra đều qua: bắt tay còn mới, tra cứu tuyến cho một đích thuộc tiền tố mới nêu tên tunnel, một tải vài trăm byte đi được cả hai chiều, và điều đó vẫn đúng sau khi khởi động lại máy hoặc trình quản lý. Để tham khảo, hướng dẫn wg(8) là tài liệu về ý nghĩa của AllowedIPs ở mỗi chiều, và đáng đọc lại trước khi mở rộng một dải để một triệu chứng biến mất.

• Bắt tay mới mà không có dữ liệu: xem AllowedIPs ở phía nhận trước khi chạm vào khóa.
• Tra cứu tuyến chỉ sai giao diện: tuyến thuộc về trình quản lý hoặc container, không phải tệp của bạn.
• Địa chỉ số ổn mà tên máy chủ hỏng: một tham chiếu cũ, không phải vòng lặp định tuyến.
• Thay đổi chỉ hoàn tất khi sau khi khởi động lại vẫn dùng tiền tố mới.