WireGuard bị treo: giới hạn MTU hay thiếu quy tắc chuyển tiếp?
Mọi thứ ngoài máy chủ là vấn đề chuyển tiếp hoặc tuyến quay về. Yêu cầu nhỏ chạy được trong khi yêu cầu lớn bị treo là dấu hiệu của kích thước gói.
Thói quen là hạ MTU ngay khi WireGuard bắt đầu hoạt động sai, và thói quen đó che giấu một lỗi khác. Một cổng không chuyển tiếp và một đường không mang được gói lớn tạo ra những mẫu dễ phân biệt: một cái hỏng ở cả hai chiều và ở mọi kích thước, cái kia sống sót với yêu cầu nhỏ và chết với yêu cầu lớn. Hãy xác định bạn đang gặp hình thái nào trước khi thay đổi bất kỳ con số nào. Phép thử rẻ và nó loại bỏ một nửa số nguyên nhân có thể.
Hai lỗi, hai hình thái khác nhau
Vấn đề chuyển tiếp xuất hiện ngay sau máy chủ. Bắt tay thành công, địa chỉ đường hầm trả lời, và không có gì phía sau cổng thể truy cập được dù chỉ với một yêu cầu nhỏ. Gói tin đã đến máy chủ mà không được chuyển tiếp, hoặc phản hồi không có tuyến quay về.
Vấn đề kích thước chỉ xuất hiện trên một ngưỡng. DNS, bắt tay TCP và một lệnh gọi API nhỏ đều hoạt động, trong khi tải tệp hoặc phản hồi lớn bị treo. Những gói vừa đi được từ đầu đến cuối, còn những gói không vừa bị bỏ ở đâu đó mà không có báo cáo hữu ích.
Những mô tả đó chỉ đến những người khác nhau và những tệp cấu hình khác nhau, vì vậy đo hình thái đáng giá hơn phỏng đoán. Một ping đến cổng không thể tách chúng ra.
Loại trừ chuyển tiếp trước khi thu nhỏ bất cứ thứ gì
Hãy thử một đích ngoài cổng, không phải chính cổng. Ping đến địa chỉ đường hầm của máy chủ chỉ chứng minh rằng giao diện đang hoạt động và bạn đến được máy kết thúc đường hầm. Lưu lượng cho mạng rộng hơn phụ thuộc vào việc chuyển tiếp IP được bật trên máy đó và vào tường lửa cho phép luồng được chuyển tiếp. Cả hai đều phải đúng, và nếu một trong hai sai thì sẽ có cùng sự im lặng.
Định tuyến quay về cũng quan trọng như vậy. Nếu mạng đích không biết cách đến địa chỉ đường hầm của máy khách, yêu cầu đến và phản hồi biến mất, và máy khách báo hết thời gian chờ trông giống hệt một lần chuyển tiếp bị bỏ.
Ở nơi thiết kế dùng dịch địa chỉ, quy tắc dịch là một phần của tuyến quay về đó. Xóa nó trong khi đuổi theo sự cố MTU biến một thiết kế đang chạy thành hỏng, vì vậy hãy đọc các quy tắc hiện có trước khi sửa chúng.
Đo nơi sự đứt bắt đầu
Trước tiên hãy đọc trạng thái chuyển tiếp và các quy tắc lọc. Đây là những kiểm tra chỉ đọc và chúng trả lời câu hỏi rẻ:
sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
ip route get 10.30.0.9Sau đó thử kích thước với bit don’t-fragment, từ máy khách, hướng tới một máy ngoài cổng:
ping -M do -s 1200 10.30.0.9
ping -M do -s 1400 10.30.0.9Nếu phép thử đầu chạy và phép thử thứ hai thất bại với lỗi phân mảnh, đường đang cho bạn biết kích thước dùng được của nó. Nếu cả hai đều không chạy, bạn đang nhìn vào chuyển tiếp hoặc định tuyến, và MTU không phải là biến cần thay đổi.
| Observation | Points toward | Where to look |
|---|---|---|
| Nothing beyond the gateway works | Forwarding or return route | Forwarding flag, filter rules, routing table |
| Small works, large stalls | Packet size on the path | Tunnel MTU and the link underneath |
| Only names fail | DNS resolution | The resolver configured for the tunnel |
| Works sometimes | Multiple paths or state expiry | Flow selection and NAT state |
Sửa lớp mà bạn đã chứng minh
Khi chuyển tiếp là lỗi, cách sửa là một quy tắc chuyển tiếp hoặc một tuyến, được diễn đạt hẹp nhất trong mức thiết kế cho phép. Khi kích thước là lỗi, cách sửa là một MTU tính đến việc đóng gói trên đúng đường này, áp dụng cho giao diện cần nó chứ không phải cho mọi bộ điều hợp trong đội.
Dù thế nào, sau đó hãy lặp lại cùng công việc với cùng đích. Nếu lần truyền lớn ban đầu giờ hoàn tất, thay đổi đã xử lý đúng lớp đang hỏng. Nếu chỉ phép thử nhỏ được cải thiện, bạn đã chữa triệu chứng và giới hạn thật vẫn còn đó.
Hãy ghi lại bạn đã quan sát hình thái nào trước khi thay đổi. Dòng duy nhất đó, được ghi bên cạnh cách sửa, là thứ ngăn người tiếp theo hạ một MTU chưa bao giờ là vấn đề.