Cách dựng một bài kiểm tra WireGuard hai peer chứng minh một đường đi duy nhất

Một bài kiểm tra WireGuard mang theo tuyến mặc định, tiền tố LAN, DNS và một ngoại lệ tường lửa không thể nói cho bạn biết phần nào đã hỏng. Thu gọn nó về hai peer, một cặp địa chỉ và một dịch vụ được phép, và lỗi không còn chỗ trốn. Nền tảng nhàm chán chính là chẩn đoán. Hãy dựng nó trước; mất mười lăm phút và tiết kiệm buổi chiều mà nếu không bạn sẽ dùng để đoán mò.

Điều nền tảng chứng minh hẹp hơn phần lớn người ta tưởng. Nó chứng minh hai danh tính đồng ý với nhau, UDP tới được cổng lắng nghe và một đích được phép mang một yêu cầu. Chuyển tiếp, NAT, tuyến LAN và DNS là những tính năng riêng được thêm sau, từng cái một.

Khóa, địa chỉ và endpoint duy nhất

Tạo một cặp khóa trên mỗi hệ thống và chỉ chuyển giữa chúng nửa công khai. wg genkey | tee privatekey | wg pubkey > publickey là lệnh một dòng đã được ghi tài liệu, và nó để khóa riêng trong một tệp mà sau đó bạn có thể bảo vệ. Chọn địa chỉ đường hầm từ một dải không xuất hiện trong bất kỳ cấu hình nào khác bạn sở hữu, chẳng hạn 10.99.0.1/24 và 10.99.0.2/24. Ghi lại địa chỉ nào thuộc máy nào, vì mọi kiểm tra về sau đều phụ thuộc vào ánh xạ đó.

Khóa riêng không bao giờ di chuyển. Nếu một bài kiểm tra cần sao chép một khóa sang phía bên kia, bài kiểm tra đã sai ngay từ đầu. Khi hai hệ thống nằm sau NAT, ít nhất một bên cần một cổng UDP tiếp cận được trong khi bên kia mang một Endpoint trỏ tới nó, còn địa chỉ và cổng công khai thuộc về ghi chú của bạn, không phải giả định của bạn về 51820.

Chuyển tiếp cổng ánh xạ một cổng ngoài khác vẫn chạy tốt miễn là Endpoint khớp với nó. Sự lệch ở đây tạo ra im lặng thay vì lỗi, vì vậy đáng kiểm tra trên giấy trước khi gỡ lỗi trên dây.

Những trường thuộc về wg và những trường không

Bộ trường cốt lõi nhỏ: PrivateKey và ListenPort dưới Interface, PublicKey, AllowedIPs và Endpoint dưới Peer. Address và DNS thuộc về wg-quick chứ không phải bản thân wg, và sự khác biệt đó cắn ngay khi cùng một cấu hình chuyển sang công cụ khác.

[Interface]
PrivateKey = <peer-a-private>
Address = 10.99.0.1/24
ListenPort = 51820

[Peer]
PublicKey = <peer-b-public>
AllowedIPs = 10.99.0.2/32
Endpoint = 203.0.113.10:51820

AllowedIPs đảm nhận hai việc cùng lúc. Nó chọn đích nào đi vào đường hầm, và nó cho phép peer dùng những địa chỉ nguồn đó khi đến. Vì thế mục gương ở phía bên kia phải nêu chính xác địa chỉ đường hầm của bạn; một /32 cho peer sai được đọc như vấn đề định tuyến và hành xử như vấn đề phân quyền. Khởi động nhanh WireGuard cho thấy cùng hình dạng hai peer với cách diễn đạt chuẩn nếu bạn muốn so sánh tên trường.

Đọc handshake thay vì biểu tượng

Nâng giao diện lên qua thứ sở hữu nó, rồi đọc trạng thái thay vì đèn trạng thái. wg show in ra handshake gần nhất theo từng peer cùng các bộ đếm byte, và một handshake trong vài phút gần đây nghĩa là khóa, endpoint và đường UDP đều chạy. Một bộ đếm chỉ tăng theo một chiều tự nó là câu trả lời, và nó không phải cùng lỗi với một handshake không bao giờ xảy ra.

Hai lỗi ngụ ý hai cuộc điều tra khác nhau. Không có handshake nào cả chỉ vào khóa không khớp, Endpoint sai, UDP bị chặn hoặc tường lửa đánh rơi chính handshake. Một handshake thành công nhưng dữ liệu không đi đâu chỉ vào AllowedIPs, một dịch vụ không lắng nghe trên địa chỉ đường hầm, hoặc tường lửa của máy nhận cổng cho LAN nhưng không cho giao diện đường hầm. Đó là hai nửa khác nhau của hệ thống, và nền tảng tách chúng trước khi bạn bắt đầu đổi quy tắc.

Chứng minh một dịch vụ được phép, rồi chiều ngược lại

Gửi một yêu cầu tới địa chỉ đường hầm của peer kia trên một dịch vụ đáng lẽ phải trả lời, và chọn thứ tốt hơn ping. Một phản hồi ICMP thiếu có thể là lọc của máy chứ không phải lỗi đường hầm, nên một ping im lặng không chứng minh chiều nào. Một kết nối TCP tới cổng bạn biết là mở, hoặc một yêu cầu trả về dữ liệu, cho bạn câu trả lời có thể diễn giải.

Chạy chiều ngược lại như một bài kiểm tra riêng với kết quả riêng, vì hai chiều có mục tường lửa và AllowedIPs riêng và có thể hỏng độc lập. Nếu handshake chạy mà yêu cầu không chạy, vấn đề nằm ở đường dữ liệu chứ không phải đường hầm: AllowedIPs, dịch vụ đang lắng nghe hoặc tường lửa của máy. Sửa điều đó trước khi thêm chuyển tiếp, NAT hay DNS, nếu không bạn sẽ dành cả buổi chiều gỡ lỗi một tính năng chưa từng là thủ phạm.

Giữ nền tảng làm tham chiếu

Lưu lại topo đang chạy và nguồn của hồ sơ ở nơi bạn có thể khôi phục, và giữ chúng ngoài mọi thư mục đồng bộ với dịch vụ công khai. Rồi thêm từng tính năng một, lặp lại yêu cầu ban đầu sau mỗi lần: chuyển tiếp, NAT, một tuyến LAN và chỉ sau đó mới DNS. Mỗi bổ sung làm hỏng bài kiểm tra giờ đã nhận diện được, vì không có gì khác di chuyển.

Một nền tảng chỉ làm biểu tượng xanh lên không nói gì cho bạn về việc bổ sung nào gây ra lỗi tiếp theo. Giữ con đường duy nhất được phép chạy như tham chiếu, và mọi thay đổi về sau đều được đo so với nó.