WireGuard зависає: межа MTU чи відсутнє правило пересилання?
Усе за сервером — це проблема пересилання або зворотного маршруту. Малі запити проходять, а великі зависають — це ознака розміру пакета.
Звичка знижувати MTU, щойно WireGuard починає поводитися неправильно, приховує іншу несправність. Шлюз, який не пересилає, і шлях, який не несе великі пакети, дають розрізнювані картини: один відмовляє в обидва боки і за будь-якого розміру, інший переживає малі запити й гине на великих. Визначте, яка форма у вас, перш ніж змінювати будь-яке число. Тест дешевий, і він прибирає половину можливих причин.
Дві несправності, дві різні форми
Проблема пересилання проявляється одразу за сервером. Рукостискання проходить, адреса тунелю відповідає, і ніщо за шлюзом недоступне навіть малим запитом. Пакет дійшов до сервера і не був переданий, або відповідь не мала зворотного маршруту.
Проблема розміру проявляється лише вище порогу. DNS, рукостискання TCP і невеликий виклик API працюють, а завантаження файлу або велика відповідь зависають. Пакети, що вміщалися, пройшли від краю до краю, а ті, що не вміщалися, були відкинуті десь без корисного звіту.
Ці описи вказують на різних людей і різні файли конфігурації, тому вимірювання форми цінніше за здогад. Один ping до шлюзу не може їх розділити.
Виключіть пересилання, перш ніж щось зменшувати
Перевіряйте призначення за шлюзом, а не сам шлюз. Ping до адреси тунелю сервера доводить лише те, що інтерфейс піднятий і ви досягаєте машини, яка завершує тунель. Трафік для ширшої мережі залежить від увімкненого пересилання IP на цій машині та від брандмауера, який дозволяє пересиланий потік. Істинним має бути і те, й те, і якщо одне хибне, виникає та сама тиша.
Зворотна маршрутизація не менш важлива. Якщо мережа призначення не знає, як дістатися до адреси тунелю клієнта, запит надходить, а відповідь зникає, і клієнт повідомляє про тайм-аут, який виглядає так само, як відкинуте пересилання.
Там, де проєкт використовує трансляцію адрес, правило трансляції є частиною цього зворотного шляху. Видалення його під час пошуку проблеми з MTU перетворює робочий проєкт на зламаний, тому прочитайте наявні правила, перш ніж їх редагувати.
Виміряйте, де починається розрив
Спочатку прочитайте стан пересилання та правила фільтрації. Це перевірки лише для читання, і вони відповідають на дешеве питання:
sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
ip route get 10.30.0.9Потім перевірте розміри з бітом «не фрагментувати», від клієнта, у бік вузла за шлюзом:
ping -M do -s 1200 10.30.0.9
ping -M do -s 1400 10.30.0.9Якщо перша перевірка працює, а друга завершується помилкою фрагментації, шлях повідомляє вам свій придатний розмір. Якщо не працює жодна, ви дивитеся на пересилання або маршрутизацію, і MTU не є змінною, яку треба змінювати.
| 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 |
Виправте той рівень, який ви довели
Коли винне пересилання, виправлення — це правило пересилання або маршрут, виражені якомога вужче, наскільки дозволяє проєкт. Коли винний розмір, виправлення — це MTU, що враховує інкапсуляцію саме на цьому шляху, застосований до інтерфейсу, якому він потрібен, а не до кожного адаптера в парку.
Так чи інакше, після цього повторіть те саме завдання до того ж призначення. Якщо початкове велике передавання тепер завершується, зміна торкнулася того рівня, який відмовляв. Якщо покращилася лише мала перевірка, ви лікували симптом, і реальна межа все ще на місці.
Запишіть, яку форму ви спостерігали до зміни. Цей один рядок, записаний поруч із виправленням, — те, що не дає наступній людині знизити MTU, який ніколи не був проблемою.