WireGuard chỉ hoạt động sau khi máy chủ gửi: hiểu biết về điểm cuối

Đường hầm dường như chỉ hoạt động sau khi máy chủ gửi thứ gì đó trước. Bắt đầu từ máy khách và không có gì xảy ra, đợi vài giây, thử lại và nó thành công. Chẩn đoán thông thường là NAT bị hỏng, và chẩn đoán thông thường là sai. Điều đã thay đổi là một bên đã biết bên kia sống ở đâu.

Hiểu biết về điểm cuối, không phải khả năng tiếp cận

Một bên WireGuard sẽ không bắt đầu bắt tay cho đến khi biết nơi gửi nó. Cấu hình cung cấp điều đó như một điểm cuối gồm địa chỉ và cổng, và trạng thái đang chạy theo dõi điểm cuối mà nó tin tưởng hiện tại.

wg show in ra cả hai phía của bức tranh đó, và một bên không có điểm cuối trong đầu ra không thể bắt đầu bất cứ điều gì, dù khóa công khai và các tiền tố được phép của nó có chính xác đến đâu. Hãy so sánh góc nhìn của máy khách với góc nhìn của máy chủ trước khi thay đổi bất kỳ quy tắc nào, vì hai bên thường không đồng ý về việc ai biết gì.

Một bên học điểm cuối như thế nào

WireGuard cố ý im lặng. Khi một gói đã được xác thực đúng đến từ một địa chỉ mà bên đó không ngờ tới, phần triển khai cập nhật điểm cuối của bên đó sang nguồn mới, và đó là cách chuyển vùng hoạt động trên một máy tính xách tay thay đổi mạng. Hành vi đó giải thích sự phụ thuộc vào hướng: nếu máy chủ gửi trước và gói của nó đến được máy khách, máy khách học địa chỉ hiện tại của máy chủ và có thể trả lời. Cho đến lúc đó nó không có nơi nào để gửi. Cơ chế là chuyển vùng có xác thực chứ không phải một lối tắt tin cậy ở lần dùng đầu, vì gói phải hợp lệ trước khi điểm cuối di chuyển.

Tài liệu công cụ cho wg mô tả bản cập nhật đó, và đáng đọc một lần nếu bạn định thiết kế xoay quanh nó.

Dịch có trạng thái thêm hướng của riêng nó

Nơi UDP đi qua một cổng dịch, cổng tạo trạng thái cho gói đầu tiên nó thấy. RFC 4787 mô tả hành vi đó và các thời gian chờ cuối cùng loại bỏ ánh xạ. Một ánh xạ không hoạt động sẽ hết hạn, và một gói đến từ phía xa sau đó bị cổng loại bỏ trước khi tới máy chủ. Một đường hầm hoạt động cả buổi sáng ngừng trả lời vào buổi chiều chính vì lý do này.

Đây là cơ chế thứ hai và độc lập tạo ra cùng triệu chứng theo hướng. Cả hiểu biết về điểm cuối và trạng thái dịch đều phải đúng, và sửa cái này không sửa cái kia.

Cấu hình hướng mà bạn thực sự muốn

Đối với một máy khách phải bắt đầu kết nối, hãy đặt điểm cuối của máy chủ trong phần các bên của máy khách và để nó ở đó. Trông chờ máy chủ gửi trước là trông chờ vào một sự tình cờ trong thứ tự lưu lượng sẽ thay đổi trên một mạng yên tĩnh. Cấu hình nên nêu rõ hướng dự định, không phải khám phá nó.

Đối với một bên sau quá trình dịch phải luôn tiếp cận được, hãy bật keepalive liên tục ở phía đó. Keepalive mỗi 25 giây là giá trị khởi đầu thông thường, và mục đích của nó là giữ ánh xạ mở chứ không phải kiểm tra đường hầm. Hãy chọn một phía chịu trách nhiệm, vì bật ở cả hai phía làm tăng gấp đôi lưu lượng và nhiễu nhật ký mà không cải thiện kết quả.

So sánh trạng thái trước và sau tác nhân kích hoạt

Ghi lại hai góc nhìn vào lúc nó thất bại, rồi lại sau khi máy chủ gửi. Lệnh đầu tiên hiển thị các điểm cuối và tuổi của bắt tay. Lệnh thứ hai hiển thị liệu có một mục dịch cho cổng hay không. Bản ghi cho thấy hướng nào thực sự đi qua dây, và kiểm tra tuyến xác nhận rằng máy khách không gửi lưu lượng đó đi nơi hoàn toàn khác.

wg show
conntrack -L -p udp 2>/dev/null | grep 51820
tcpdump -ni any -c 20 'udp port 51820'
ip route get 198.51.100.7

Ghi lại cột điểm cuối và mục dịch cùng nhau. Một bên không có điểm cuối và một cổng không có ánh xạ là hai lỗi khác nhau. Chỉ một trong hai được keepalive khắc phục.