MTU-swartgat: waarom klein versoeke werk maar groot oplaai vasloop

’n Bladsy laai, ’n klein API-oproep keer terug, en dan hang ’n lêeroplaai tot die kliënt tou opgooi. Niks in die bedienerlog verklaar dit nie, want die pakkette is in die middel van die pad laat val sonder dat ’n nuttige antwoord teruggestuur is. Daardie patroon is ’n MTU-swartgat: ’n skakel wat smaller is as wat die sender aanneem, plus ’n stil weiering om dit te sê. Die grootte wat misluk, is herhaalbaar, en dit is wat dit diagnoseerbaar maak.

Wat maak die gat swart

Elke skakel het ’n maksimum-oordragseenheid, en ’n pakket groter as die volgende sprong se limiet moet óf gefragmenteer óf met ’n ICMP-boodskap wat dit sê, verwerp word. Pad-MTU-ontdekking hang daarvan af dat daardie boodskap aankom en geëerbiedig word. Om dit te filter of te ignoreer, laat die sender ’n pakket herhaal wat nooit kan pas nie.

Enkapsulering maak dit algemeen rondom VPN's, want ’n tonnel voeg ’n buitenste kop aan ’n pakket by wat reeds vir die fisiese skakel gegrootteer is. Die binneste pakket is wettig teen 1500 grepe en die ingekapselde een nie, so dit sterf by die grens terwyl klein pakkette deurgly. ’n Voltooide handdruk en ’n werkende aanmeldbladsy bewys net dat klein pakkette werk. Die grootste pakket wat die toepassing probeer stuur, is die een wat saak maak.

Vind die grootte waar dit breek

Bisorteer die loonvrag-grootte met ’n toets wat nie fragmenteer nie, vanaf ’n gasheer aan die een kant van die tonnel na ’n gasheer aan die ander kant. Die grootste loonvrag wat slaag, is jou bruikbare pad-MTU minus die kop-oorhoofding.

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

’n Loonvrag van 1472 grepe slaag op ’n skoon 1500-grepe Ethernet-pad sodra die 28 grepe se IPv4- en ICMP-koppe bygetel word. Wanneer dieselfde toets eers by ’n kleiner loonvrag slaag nadat die tonnel op is, is die verskil die enkapsulering-oorhoofding, en die tonnelgrens is waar die verwerpingsboodskap geskep moes gewees het. Teken albei getalle aan, voor en ná die verbinding, want daardie paar is die bewys. Herhaal die toets vir IPv6 wanneer die toepassing dit gebruik, aangesien die kop groter is en die mislukkingsdrempel skuif.

Lees die bewyse voordat jy die tonnel blameer

Foute in afgeleë toepassings, oorbelasting en gewone verlies laat oplaai ook vasloop, so een mislukte oordrag identifiseer nie ’n swartgat nie. Wat hulle skei, is die grootteverhouding: ’n herhaalbare sukses by 1200 grepe en ’n herhaalbare vasloop by 1400 grepe, in dieselfde rigting, deur dieselfde eindpunt.

’n Vangs aan albei kante wys die groot pakkette vertrek en nooit aankom nie, sonder enige verwerping tussenin. Dit is die oomblik om na die grenstoestel te kyk eerder as na die bediener, wat elke versoek wat hy werklik ontvang, beantwoord. Oorbelasting laat ook vasloop, maar dit laat verskillende groottes op verskillende tye vasloop, wat ’n ander handtekening is.

Kontroleer die herstel op albei transporde

Die ondersteunde herstel is om die grens die werklike limiet te laat rapporteer, of om TCP se maksimum segmentgrootte daar vas te klem sodat geen oorgrootte segment probeer word nie. Om elke MTU op die netwerk te verlaag, of die vuurmuur af te skakel, versteek die simptoom en laat ’n konfigurasie wat niemand later kan beredeneer nie.

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

Verifieer met dieselfde grootte-toets, dan met die toepassing wat misluk het, en kyk na ’n tweede protokol, want UDP-toepassings kry nooit TCP se segmentgrootte-regstelling nie. Hou die oorspronklike waardes in die kaartjie, want ’n herstel wat nie omgekeer kan word nie, is ’n tweede probleem wat wag om te gebeur. As die grootte-toets slaag en die oplaai steeds vasloop, was die swartgat nie die oorsaak nie, en die ondersoek moet aanbeweeg eerder as om die verandering te verbreed.