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 који никада није био проблем.