Bắt tay WireGuard thành công nhưng không có internet: lần theo gói tin
Bắt tay chỉ chứng minh khóa và khả năng kết nối. Lần theo một gói tin từ AllowedIPs qua chuyển tiếp, NAT và tuyến quay về để xem nó dừng ở đâu.
Đường hầm đã lên, wg show báo cáo một lần bắt tay gần đây, bạn ping được địa chỉ đường hầm của máy chủ, và không có gì phía sau trả lời. Phản xạ đầu tiên là tạo lại khóa hoặc chia sẻ lại cấu hình. Việc đó thay đổi đúng phần đường đi đã được chứng minh là hoạt động.
Một lần bắt tay hoàn tất cho biết hai bên đồng ý về khóa, UDP đến được điểm cuối, và định tuyến mật mã chấp nhận gói tin. Nó không cho biết gói tin có thể rời máy chủ sau đó hay không.
Vì vậy hãy lần theo một gói tin thay vì đoán. Có bốn nơi gói tin có thể chết, và mỗi nơi để lại một dấu vết khác nhau.
Bắt tay thực sự chứng minh điều gì
WireGuard là một giao thức UDP thiết lập phiên bằng bắt tay Noise rồi mã hóa gói tin cho một peer. Khi wg show hiển thị một lần bắt tay vài giây trước và bộ đếm truyền tăng, điểm cuối, khóa và khóa công khai của peer đều đúng.
Điều nó không chứng minh là máy khách của bạn có gửi lưu lượng hướng ra internet vào giao diện hay không, máy chủ có sẵn lòng chuyển tiếp hay không, hoặc một phản hồi có tìm được đường về hay không. Đó là những quyết định định tuyến của nhân và tường lửa, và chúng được đưa ra bên ngoài đường hầm.
Đó là lý do ping tới địa chỉ đường hầm của máy chủ lại là một phép thử gây nhầm lẫn đến vậy. Gói tin đó được gửi tới chính máy chủ, nên nó kết thúc cục bộ. Nó không bao giờ cần chuyển tiếp, không bao giờ cần dịch địa chỉ và không bao giờ cần tuyến quay về từ internet.
AllowedIPs là một quyết định định tuyến
Trên máy khách, AllowedIPs đảm nhận hai việc. Đó là bảng định tuyến khóa mật mã quyết định địa chỉ đích nào đi vào đường hầm của peer này, và đó là danh sách địa chỉ nguồn mà peer sẽ chấp nhận từ bạn. Nếu cấu hình máy khách chỉ liệt kê 10.8.0.0/24, các đích công cộng không bao giờ vào giao diện và tuyến mặc định bình thường của bạn đưa chúng ra ngoài đường hầm. Khi đó đường hầm hoạt động hoàn hảo và không làm gì bạn muốn.
Hãy xem máy khách thực sự đã cài gì thay vì những gì tệp cấu hình nói:
wg show wg0 allowed-ipsip route get 1.1.1.1
Lệnh thứ hai là lệnh quyết định. Nếu câu trả lời nêu giao diện vật lý và cổng mặc định thông thường, gói tin không được đưa vào đường hầm và không thay đổi nào phía máy chủ sửa được điều đó. Thêm 0.0.0.0/0 cho IPv4 và ::/0 cho IPv6 riêng biệt; một quy tắc bắt trọn một họ địa chỉ sẽ để họ kia trên đường đi ban đầu, và đó là nguyên nhân phổ biến của một đường hầm IPv4 hoạt động và một truy vấn IPv6 bị kẹt.
Gói tin chết ở đâu trên cổng
Nếu tuyến đúng mà gói tin vẫn không đi đâu, nó đến máy chủ và dừng ở đó. Bốn bước kiểm tra bao quát hầu hết các cổng.
Chuyển tiếp. sysctl net.ipv4.ip_forward trả về 0 là câu trả lời kinh điển, và nhiều bản phân phối vẫn mặc định là 0. Nó phải là 1, và được đặt vĩnh viễn trong một tệp sysctl thay vì bằng lệnh biến mất khi khởi động lại. Chuyển tiếp IPv6 là một công tắc riêng.
Chính sách lọc. Một chuỗi FORWARD với chính sách drop mặc định sẽ bỏ lưu lượng đường hầm trong khi cho phép lưu lượng tới chính máy chủ, điều này khớp chính xác với triệu chứng. Hãy đọc bộ quy tắc đang sống, không phải tệp đã lưu: nft list ruleset hoặc iptables -S.
Dịch địa chỉ hoặc định tuyến. Máy khách dùng địa chỉ đường hầm riêng cần NAT nguồn trên giao diện ra của máy chủ, hoặc một tiền tố đã định tuyến mà mạng phía trên biết cách trả về. Việc chọn giữa hai cách tuân theo quy hoạch địa chỉ. Thêm MASQUERADE vào một mạng đã định tuyến tiền tố của bạn trở lại là vô hại nhưng vô nghĩa, còn bỏ nó đi ở nơi không có tuyến nào sẽ để các phản hồi được gửi tới một dải riêng không thể định tuyến.
Đường về. Trong các thiết kế định tuyến, router phía trên cần một tuyến trỏ tới máy chủ của bạn. Mạng của nhà cung cấp cũng có thể chặn điều đó: một số đám mây bật kiểm tra nguồn và đích trên instance, và nó âm thầm bỏ các gói tin có nguồn không phải địa chỉ của chính instance cho tới khi kiểm tra đó bị tắt.
DNS thất bại khác với định tuyến
Một gói tin tới địa chỉ đã biết và một lần tra tên là hai kiểu hỏng riêng biệt, và các thông báo lỗi đánh lạc hướng theo hai chiều ngược nhau. Nếu ping 1.1.1.1 hoạt động mà trình duyệt không tải được gì, tuyến vẫn tốt còn việc phân giải tên thì không. Nếu bản thân ping thất bại, DNS không liên quan và bạn quay lại phần trước.
wg-quick có thể đặt resolver từ dòng DNS = trong cấu hình, và systemd-resolved có hành vi riêng theo từng liên kết. Một VPN ghi đè resolver bằng địa chỉ chỉ với tới được bên trong đường hầm sẽ làm mọi truy vấn thất bại ngay khi đường hầm sập, trông như thể đường hầm làm hỏng internet.
| Symptom | Layer to inspect |
|---|---|
| Tunnel address pings, nothing else does | Client route, then gateway forwarding |
| Public IP pings, hostnames fail | Resolver selection and reachability |
| Handshake completes, no reply ever | FORWARD policy or missing NAT on the server |
| Small requests work, large transfers stall | MTU and TCP MSS clamping |
Một trình tự tạo ra bằng chứng
Hãy chạy kiểm tra phía máy khách trước, vì đó là một lệnh và loại đi một nửa khả năng. Sau đó xác nhận máy chủ có thực sự được thiết kế làm lối ra internet hay không; một cổng dựng cho truy cập riêng không hỏng khi các đích công cộng thất bại.
Trên máy chủ, hãy quan sát giao diện trong khi bạn gửi ping từ máy khách: tcpdump -ni wg0 icmp phải hiển thị yêu cầu, và tcpdump -ni eth0 icmp phải hiển thị nó đi ra, dù đã dịch hay chưa. Nếu nó xuất hiện ở cái đầu và không bao giờ ở cái thứ hai, điểm dừng nằm ngay trên máy chủ. Nếu nó đi ra mà không có phản hồi nào quay lại, vấn đề nằm ở phía trên, và đó là câu chuyện khác.
Cuối cùng, hãy làm cho bản sửa sống sót qua lần khởi động lại. Chuyển tiếp thuộc về một tệp sysctl, các quy tắc tường lửa thuộc về dịch vụ nạp chúng, và các tuyến của máy khách thuộc về cấu hình dựng giao diện chứ không phải một shell bạn sẽ quên. Kết nối lại, lặp lại đúng hai phép thử đó và xác nhận các bộ đếm nhúc nhích.