MTU-nigra truo: kial malgrandaj petoj funkcias sed alŝutoj haltas

Paĝo ŝarĝiĝas, malgranda API-voko revenas, kaj poste dosiera alŝuto pendas ĝis la kliento rezignas. Nenio en la servila protokolo klarigas tion, ĉar la pakaĵoj estis forĵetitaj meze de la vojo sen ke utila respondo estis sendita reen. Tiu ŝablono estas MTU-nigra truo: ligilo pli mallarĝa ol la sendanto supozas, plus silenta rifuzo tion diri. La grandeco kiu malsukcesas estas ripetebla, kaj tio estas kio igas ĝin diagnozebla.

Kio igas la truon nigra

Ĉiu ligilo havas maksimuman transsendan unuon, kaj pakaĵo pli granda ol la limo de la sekva salto devas aŭ esti fragmentita aŭ malakceptita per ICMP-mesaĝo kiu tion diras. La malkovro de la voja MTU dependas de tio, ke tiu mesaĝo alvenu kaj estu respektata. Filtrigi aŭ ignori ĝin lasas la sendanton ripeti pakaĵon kiu neniam povas eniri.

Enkapsuligo faras tion komuna ĉirkaŭ VPN-oj, ĉar tunelo aldonas eksteran kaplinion al pakaĵo kiu jam estis grandigita por la fizika ligilo. La interna pakaĵo estas laŭleĝa ĉe 1500 bajtoj kaj la enkapsuligita ne, do ĝi mortas ĉe la limo dum malgrandaj pakaĵoj glitas tra. Kompletigita manpremo kaj funkcianta ensaluta paĝo pruvas nur ke malgrandaj pakaĵoj funkcias. La plej granda pakaĵo kiun la aplikaĵo provas sendi estas tiu kiu gravas.

Trovu la grandecon kie ĝi rompiĝas

Duume serĉu la grandecon de la utila ŝarĝo per testo sen fragmentado, de gastiganto unuflanke de la tunelo al gastiganto aliflanke. La plej granda utila ŝarĝo kiu sukcesas estas via uzebla voja MTU minus la kaplinia superŝarĝo.

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

Utilŝarĝo de 1472 bajtoj sukcesas sur pura 1500-bajta Ethernet-vojo post kiam la 28 bajtoj de IPv4 kaj ICMP-kaplinioj estas aldonitaj. Kiam la sama testo sukcesas nur kun pli malgranda utilŝarĝo post kiam la tunelo staras, la diferenco estas la enkapsuliga superŝarĝo, kaj la tunela limo estas kie la malakcepta mesaĝo devus esti generita. Notu ambaŭ nombrojn, antaŭ kaj post konektiĝo, ĉar tiu paro estas la pruvo. Ripetu la teston por IPv6 kiam la aplikaĵo uzas ĝin, ĉar la kaplinio estas pli granda kaj la malsukcesa sojlo moviĝas.

Legu la pruvojn antaŭ ol kulpigi la tunelon

Eraroj de malproksimaj aplikaĵoj, kongesto kaj ordinara perdo ankaŭ haltigas alŝutojn, do unu malsukcesa transdono ne identigas nigran truon. Kio apartigas ilin estas la grandeca rilato: ripetebla sukceso ĉe 1200 bajtoj kaj ripetebla halto ĉe 1400 bajtoj, en la sama direkto, tra la sama finpunkto.

Kapto ĉe ambaŭ finoj montras la grandajn pakaĵojn foriri kaj neniam alveni, sen malakcepto inter ili. Tio estas la momento rigardi la liman aparaton anstataŭ la servilon, kiu respondas al ĉiu peto kiun ĝi efektive ricevas. Kongesto ankaŭ haltigas, sed ĝi haltigas malsamajn grandecojn en malsamaj tempoj, kio estas malsama subskribo.

Kontrolu la riparon sur ambaŭ transportoj

La subtenata riparo estas lasi la limon raporti la realan limon, aŭ fiksi tie la maksimuman segmentan grandecon de TCP por ke neniu trogranda segmento estu provata. Malaltigi ĉiun MTU en la reto, aŭ malŝalti la fajroŝirmilon, kaŝas la simptomon kaj lasas agordon pri kiu neniu povos rezoni poste.

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

Kontrolu per la sama grandeca testo, poste per la aplikaĵo kiu malsukcesis, kaj kontrolu duan protokolon, ĉar UDP-aplikaĵoj neniam ricevas la segmentgrandecan korekton de TCP. Konservu la originalajn valorojn en la bileto, ĉar riparo kiu ne povas esti malfarita estas dua problemo atendanta okazi. Se la grandeca testo pasas kaj la alŝuto ankoraŭ haltas, la nigra truo ne estis la kaŭzo, kaj la enketo devus daŭrigi anstataŭ vastigi la ŝanĝon.