WireGuard haltiĝas: ĉu limo de MTU aŭ mankanta plusenda regulo?

La kutimo estas malaltigi la MTU tuj kiam WireGuard miskondutas, kaj tiu kutimo kaŝas alian difekton. Pordego, kiu ne plusendas, kaj vojo, kiu ne portas grandajn pakojn, produktas distingeblajn ŝablonojn: unu fiaskas en ambaŭ direktoj kaj ĉe ĉiu grandeco, la alia travivas malgrandajn petojn kaj mortas ĉe la grandaj. Identigu, kiun formon vi havas, antaŭ ol ŝanĝi iun ajn nombron. La testo estas malmultekosta kaj forigas duonon de la eblaj kaŭzoj.

Du fiaskoj, du malsamaj formoj

Plusenda problemo aperas tuj preter la servilo. La manpremo sukcesas, la tunela adreso respondas, kaj nenio malantaŭ la pordego estas atingebla eĉ per malgranda peto. La pako atingis la servilon kaj ne estis plusendita, aŭ la respondo ne havis revenan vojon.

Grandeca problemo aperas nur super sojlo. DNS, TCP-manpremo kaj malgranda API-voko ĉiuj funkcias, dum elŝuto de dosiero aŭ granda respondo pendas. La pakoj, kiuj konvenis, vojaĝis de fino al fino, kaj tiuj, kiuj ne konvenis, estis forĵetitaj ie sen uzebla raporto.

Tiuj priskriboj montras al malsamaj homoj kaj malsamaj agordaj dosieroj, tial mezuri la formon valoras pli ol konjekto. Unu sola ping al la pordego ne povas apartigi ilin.

Ekskludu plusendadon antaŭ ol malgrandigi ion ajn

Testu celon preter la pordego, ne la pordegon mem. Ping al la tunela adreso de la servilo pruvas nur, ke la interfaco estas aktiva kaj ke vi povas atingi la maŝinon, kiu finas la tunelon. Trafiko por la pli vasta reto dependas de tio, ĉu IP-plusendado estas ŝaltita sur tiu maŝino, kaj de fajroŝirmilo, kiu permesas la plusenditan fluon. Ambaŭ devas esti veraj, kaj se unu estas malvera, rezultas la sama silento.

Revena vojigo same gravas. Se la cela reto ne scias, kiel atingi la tunelan adreson de la kliento, la peto alvenas kaj la respondo malaperas, kaj la kliento raportas tempolimon, kiu aspektas identa al forĵetita plusendado.

Tie, kie la dezajno uzas adresan tradukon, la traduka regulo estas parto de tiu revena vojo. Forigi ĝin dum persekutado de MTU-problemo ŝanĝas unu funkciantan dezajnon en rompitan, do legu la ekzistantajn regulojn antaŭ ol redakti ilin.

Mezuru, kie la rompo komenciĝas

Unue legu la plusendan staton kaj la filtrajn regulojn. Ĉi tiuj estas nur-legaj kontroloj kaj ili respondas la malmultekostan demandon:

sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
ip route get 10.30.0.9

Poste testu grandecojn per la don’t-fragment-bito, de la kliento, al gastiganto preter la pordego:

ping -M do -s 1200 10.30.0.9
ping -M do -s 1400 10.30.0.9

Se la unua provo funkcias kaj la dua fiaskas per fragmentiga eraro, la vojo diras al vi sian uzeblan grandecon. Se neniu funkcias, vi rigardas plusendadon aŭ vojigon, kaj MTU ne estas la variablo ŝanĝenda.

Riparu la tavolon, kiun vi pruvis

Kiam plusendado estas la difekto, la korekto estas plusenda regulo aŭ vojo, esprimita tiel mallarĝe, kiel la dezajno permesas. Kiam grandeco estas la difekto, la korekto estas MTU, kiu konsideras la enkapsuligon sur ĉi tiu specifa vojo, aplikata al la interfaco, kiu bezonas ĝin, kaj ne al ĉiu adaptilo en la floto.

Ĉiel ajn, poste ripetu la saman taskon al la sama celo. Se la origina granda transigo nun finiĝas, la ŝanĝo traktis la tavolon, kiu fiaskis. Se nur la malgranda provo pliboniĝis, vi traktis simptomon kaj la reala limo ankoraŭ staras.

Notu, kiun formon vi observis antaŭ la ŝanĝo. Tiu unu linio, registrita apud la ripeto, estas tio, kio malhelpas la sekvan personon malaltigi MTU, kiu neniam estis la problemo.