IPIP bên trong WireGuard: 20 byte thừa mà không ai tính vào ngân sách

Những ping nhỏ đi qua đường hầm suốt cả ngày, biểu ngữ SSH đến, rồi phiên bị đóng băng đúng lúc quá trình truyền tệp bắt đầu. Kiểu mẫu đó chỉ ra một ngân sách byte được đếm ở lớp sai, nơi đường hầm ngoài được định cỡ theo chi phí của chính nó và không ai trừ đi đường hầm trong. Một gói IPIP lồng nhau chỉ là một gói IP khác đối với WireGuard, và chính vì thế nó tiêu thụ những byte mà bạn chưa bao giờ dành riêng. Cách sửa là số học, và nó vừa trong ba lệnh và một bảng.

Triệu chứng tố cáo điều đó

Sự cố phân mảnh tự thông báo qua kích thước, không bao giờ qua địa chỉ. Peer của bạn trả lời một ping 56 byte trong một giờ rồi im lặng ở 1400 byte trong khi đường hầm vẫn hoạt động và không có tuyến nào thay đổi. Bắt tay vừa, cửa sổ TCP đầy đủ đầu tiên không vừa, và quá trình truyền dừng vài giây sau khi trông vẫn khỏe mạnh.

Đo trần trước khi chỉnh sửa bất cứ thứ gì, vì một trần chưa đo là thứ bạn sẽ đuổi theo hai lần. Gửi một đầu dò dưới kích thước nghi ngờ với bit do-not-fragment được bật, ping -M do -s 1000 10.9.0.2, rồi lặp lại ở một kích thước mà bạn đã biết là quá lớn. Khi sự đảo chiều đi theo kích thước tải trọng trong khi đích không đổi, định tuyến đang làm việc của nó và có một tiêu đề bị thiếu trong ngân sách.

Đếm mỗi tiêu đề một lần, ở đúng lớp

Bắt đầu từ MTU nhỏ nhất trên đường đi chứ không phải từ giao diện đường hầm, vì bức tường nằm trên cả hai đầu. WireGuard tiêu 60 byte cho một vận chuyển IPv4 bên ngoài: 20 cho IP, 8 cho UDP và 32 cho tiêu đề của chính nó, và 80 byte khi vận chuyển đó là IPv6. Một wg0 1420 byte giữ 20 byte dư dưới mức 1440 mà một đường 1500 byte thực sự có thể giao được, và đó là lý do con số sao chép từ wiki vẫn phù hợp ở đây. Vẽ toàn bộ ngăn xếp lên sơ đồ, vì người tiếp theo đổi MTU sẽ chọn một con số tròn mới và thừa hưởng lỗi của bạn.

Hàng thứ năm là nơi ngân sách hỏng, vì 1400 byte mà một giao diện lồng nhau mang theo đã bao gồm 40 byte tiêu đề của chính gói gốc. Chỉ 1360 trong số byte đó đến được tiến trình đọc tệp. Coi 1400 là tải trọng ứng dụng, như bất kỳ sơ đồ nào thiếu cột đó mời bạn làm, và thiết bị bên trong kết thúc với 40 byte quá hào phóng trước một bức tường không hề nhúc nhích.

Đặt hai MTU riêng biệt

Bên mang và thiết bị lồng nhau là các đối tượng riêng, nên mỗi bên cần giá trị của riêng nó. Áp dụng chúng theo thứ tự này, vì thiết bị lồng nhau không thừa hưởng gì từ bên mang:

ip link set wg0 mtu 1420
ip tunnel add ipip0 mode ipip remote 203.0.113.9 local 198.51.100.4
ip link set ipip0 mtu 1400

Quy tắc đáng nhớ: MTU trong = MTU ngoài - 20 khi gói mà đường hầm IPIP mang là IPv4, và - 40 ngay khi một bên của gói trong là IPv6, vì tiêu đề lồng nhau lớn lên từ 20 byte thành 40. Không có gì khác thuộc về phép trừ đó. Chi phí của WireGuard đã được tiêu khi bạn chọn 1420, và tính nó hai lần tạo ra một đường hầm chạy hoàn hảo và vẫn chậm chừng nào không ai đo nó. Một triển khai nơi cả hai thiết bị mang 1400 tròn là dấu vân tay của đúng sai lầm đó.

IPv6 ở bất kỳ bên nào của gói lồng nhau vô hiệu hóa mọi con số ở trên, vậy hãy tính lại thay vì sao chép một con số từ một trang tương tự. Các tiêu đề bị trừ mỗi cái 40 byte ngay khi IPv6 xuất hiện trên đường ngoài hoặc trong datagram gốc, và con số tải trọng giảm đúng chừng đó.

Quy tắc tường lửa mà bạn có lẽ không cần

Giữa hai peer WireGuard thứ duy nhất trên dây là UDP, nên một quy tắc vào cho giao thức 4, con số mà RFC 2003 gán cho việc đóng gói IPv4-trong-IPv4, không tạo ra đường lồng nhau cũng không giữ nó sống. Tiêu đề IPIP sống bên trong tải trọng đã mã hóa, nơi không tường lửa biên nào nhìn thấy nó. Mở giao thức 4 dù sao cũng không mua được gì ngoài thêm một con đường được phép vào máy chủ.

Chính sách nhắc đến nguồn và đích của gói gốc thuộc về sau khi giải đóng gói, trên các giao diện đường hầm và trong bảng định tuyến. Đặt nó ở đó và quy tắc biên có thể vẫn đóng.

Điều WireGuard thực sự xác thực

AllowedIPs phán xét nguồn của gói mà WireGuard mang, và thứ nó mang là gói được đóng gói bằng IPIP. Một nguồn IPIP được phép vẫn được chấp nhận ngay cả khi tiêu đề bên trong nêu tên một máy chủ mà bạn thà không định tuyến tới. Vì vậy nguồn gốc không phải là thứ peer đã kiểm tra thay bạn, và cặp địa chỉ bên trong đó cần sự thực thi riêng sau khi giải đóng gói.

Lớp bọc cung cấp cấu trúc định tuyến, không phải lớp mật mã thứ hai. Gọi IPIP là bảo vệ thêm bên trong WireGuard mô tả một thiết kế khác.

Xác minh bằng một chiếc thang, không phải một ping

Thử các kích thước bao quanh ranh giới bạn đã tính, rồi xác nhận nhân hiểu gì về cả hai thiết bị. Khi 1360 byte tải trọng cộng 40 byte tiêu đề thành 1400, tiếng vọng đầu tiên bên dưới vừa và cái thứ hai ngồi quá trần một byte:

ping -M do -s 1372 10.9.0.2
ping -M do -s 1373 10.9.0.2
wg show wg0
ip -d link show ipip0

Đi qua sạch dưới trần và thất bại ở kích thước đầu tiên trên trần nghĩa là số học đứng vững từ đầu đến cuối. Sau đó chạy lại lần truyền đã kẹt ban đầu, vì một đầu dò tổng hợp chứng minh ngân sách và không nói gì về kích thước ghi của chính người gửi. Nếu đường lồng nhau vẫn vỡ ở kích thước bạn đã chứng minh là vừa, hãy kiểm tra việc giải đóng gói và các tuyến của đầu xa trước khi cắt thêm mười byte khỏi MTU.