MTU-swart gat: wêrom lytse oanfragen wurkje, mar uploads fêst komme te stean

In side ladt, in lytse API-oprop komt werom, en dan hinget in triem-upload oant de klant it opjout. Neat yn it tsjinnerloch ferklearret dat, want de pakketten waarden midden op it paad weilitten sûnder dat der in brûkbere antwurd weromstjoerd waard. Dat patroan is in MTU-swart gat: in ferbining dy’t smeller is as de stjoerder oannimt, plus in stil wegere dat te sizzen. De grutte dy’t misbeteart is werhelber, en dat is wat it diagnostisearber makket.

Wat it gat swart makket

Elke ferbining hat in maksimale oerdrachtienheid, en in pakket grutter as de grins fan de folgjende hop moat ofwol fragmintearre wurde of wegere wurde mei in ICMP-berjocht dat dat seit. It ûntdekken fan de MTU fan it paad hinget derfan ôf dat dat berjocht oankomt en respektearre wurdt. It filterjen of negearjen lit de stjoerder in pakket werhelje dat nea passe kin.

Ynkapseling makket dit gewoan by VPN’s, want in tunnel foeget in bûtenste kop oan in pakket ta dat al foar de fysike ferbining diminsjonearre wie. It binnenste pakket is legaal op 1500 bytes en it ynkapselle net, dat it stjert op de grins wylst lytse pakketten trochglide. In foltôge handshake en in wurkjende oanmeldside bewize allinnich dat lytse pakketten wurkje. It grutste pakket dat de applikaasje besiket te stjoeren is it ien dat fan belang is.

Sykje de grutte wêr’t it brekt

Sykje binêr de grutte fan de lading mei in test sûnder fragmintaasje, fan in host oan ien kant fan de tunnel nei in host oan de oare kant. De grutste lading dy’t slagget is dyn brûkbere paad-MTU minus de kop-oerheadding.

ping -M do -s 1400 -c 2 192.0.2.20
ping -M do -s 1200 -c 2 192.0.2.20
ping -f -l 1372 192.0.2.20

In lading fan 1472 bytes slagget op in skjin 1500-byte Ethernet-paad sadree’t de 28 bytes fan de IPv4- en ICMP-koppen tafoege wurde. Wannear’t deselde test pas by in lytsere lading slagget nei’t de tunnel oan stiet, is it ferskil de oerheadding fan de ynkapseling, en de tunnelgrins is wêr’t it wegingsberjocht makke wurde moatten hie. Skriuw beide sifers op, foar en nei it ferbinen, want dat pear is it bewiis. Werhelje de test foar IPv6 as de applikaasje dat brûkt, om’t de kop grutter is en de mislearringsdrompel ferskoot.

Lês it bewiis foardat jo de tunnel de skuld jouwe

Flatings fan op ôfstân lizzende applikaasjes, oerlêst en gewoan ferlies litte uploads ek fêst komme te stean, dat ien mislearre oerdracht identifisearret gjin swart gat. Wat se skiedt is de grutteferhâlding: in werhelbere súkses by 1200 bytes en in werhelber fêststean by 1400 bytes, yn deselde rjochting, troch itselde einpunt.

In opname oan beide kanten lit de grutte pakketten fuortgean en nea oankomme, sûnder wegere dertusken. Dat is it momint om nei it grinsapparaat te sjen ynstee fan de tsjinner, dy’t elk fersyk beantwurdet dat er echt ûntfangt. Oerlêst stiet ek fêst, mar it stiet ferskillende gruttes op ferskillende tiden fêst, en dat is in oare hanttekening.

Kontrolearje de reparaasje op beide transporren

De stipe reparaasje is de grins it echte limyt melde te litten, of dêr de maksimale segmintgrutte fan TCP te klamjen sadat gjin te grut segmint besocht wurdt. Elke MTU op it netwurk ferleegje, of de firewall útskeakelje, ferberget it symptoom en lit in konfiguraasje efter dêr’t nimmen letter oer neitinke kin.

ip link show dev tun0
sudo nft list ruleset | grep -i -E 'mtu|mss'
sysctl net.ipv4.tcp_mtu_probing
ping -M do -s 1400 -c 2 192.0.2.20

Kontrolearje mei deselde gruttetest, dan mei de applikaasje dy’t mislearre, en kontrolearje in twadde protokol, want UDP-applikaasjes krije nea de segmintgrutte-korreksje fan TCP. Hâld de oarspronklike wearden yn ’e kaart, want in reparaasje dy’t net weromdraaid wurde kin is in twadde probleem dat wachtet om te barren. As de gruttetest slagget en de upload stiet noch hieltyd fêst, wie it swarte gat net de oarsaak, en it ûndersyk moat trochgean ynstee fan de feroaring te ferbreedzjen.