Eng Säit lued, en klengen API-Uriff kënnt zréck, an duerno hänkt en Datei-Upload, bis de Client opgëtt. Näischt am Serverlog erklärt dat, well d’Pakete mëtt op dem Wee fale gelooss goufen, ouni datt eng nëtzlech Äntwert zréckgeschéckt gouf. Dëst Muster ass en MTU-Schwaarzaach: eng Verbindung, déi méi schmuel ass wéi de Sender unhëlt, plus eng stëll Verweigerung, dat ze soen. D’Gréisst, déi feelt, ass widderhuelbar, an dat mécht se diagnostizéierbar.

Wat d’Lach schwaarz mécht

All Verbindung huet eng maximal Transmissiounseenheet, an e Paket, dee méi grouss ass wéi d’Limite vum nächsten Hop, muss entweder fragmentéiert oder mat enger ICMP-Noriicht, déi dat seet, verworf ginn. D’Entdeckung vum Wee-MTU hänkt dovun of, datt déi Noriicht ukommt an honoréiert gëtt. Se filteren oder ignoréieren léisst de Sender e Paket widderhuelen, dee ni ka passen.

Encapsulation mécht dat ronderëm VPNs heefeg, well en Tunnel en äusseren Header un e Paket bäifüügt, dat schonn op de physikale Link gemooss war. De banneschten Paket ass legal bei 1500 Byte an den encapsuléierten net, dofir stierft en op der Grenz, wärend kleng Pakete duerchglidden. En ofgeschlossenen Handshake an eng funktionéierend Login-Säit beweise just, datt kleng Pakete funktionéieren. De gréisste Paket, deen d’Applikatioun versicht ze schécken, ass deen, op deen et ukënnt.

Fannt d’Gréisst, wou et briecht

Sich d’Gréisst vun der Notzlaascht duerch Binärsich mat engem Test ouni Fragmentatioun, vun engem Host op enger Säit vum Tunnel op en Host op der anerer. Déi gréisst Notzlaascht, déi duerchgeet, ass Ären notzbaren Wee-MTU minus den Header-Overhead.

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

Eng Notzlaascht vun 1472 Byte geet op engem proppere 1500-Byte-Ethernet-Wee duerch, wann d’28 Byte vun den IPv4- an ICMP-Headere bäikommen. Wa mat deemselwechten Test nëmmen eng kleng Notzlaascht duerchgeet, nodeem den Tunnel steet, ass den Ënnerscheed den Encapsulation-Overhead, an d’Tunnelgrenz ass déi Plaz, wou d’Verworfungsnoriicht hätt misse generéiert ginn. Notéier béid Zuelen, virun a no dem Verbannen, well d’Paar ass de Beweis. Widderhuel den Test fir IPv6, wa d’Applikatioun en notzt, well den Header méi grouss ass an de Fehlerschwell sech verréckelt.

Liest d’Beweiser, éier Dir den Tunnel beschëllegt

Feeler vun entfernten Applikatiounen, Stau an normale Verloscht halen Uploads och op, dofir identifizéiert een feelgeschloenen Transfer kee Schwaarzaach. Wat se trennt, ass d’Gréisstverhältnis: en widderhuelbare Succès bei 1200 Byte an en widderhuelbare Stopp bei 1400 Byte, an déi selwecht Richtung, iwwer dee selwechten Endpunkt.

Eng Opnam op béide Säiten weist déi grouss Paketen erausgoen an ni ukommen, ouni Verwerfung dertëscht. Dat ass de Moment, op d’Grenzapparat ze kucken, amplaz op de Server, deen all Ufro beäntwert, déi en tatsächlech kritt. Stau hält och op, awer en hält verschidde Gréissten zu verschiddenen Zäiten op, an dat ass eng aner Ënnerschrëft.

Kontrolléiert d’Reparatur op béide Transporten

Déi ënnerstëtzt Reparatur ass, d’Grenz de richtege Limit mellen ze loossen, oder do d’maximal Segmentgréisst vun TCP ze klammen, sou datt kee ze grousse Segment versicht gëtt. All MTU am Netzwierk erofzesetzen oder d’Firewall auszeschalten, verstoppt de Symptom an hannerléisst eng Konfiguratioun, iwwer déi spéider keen nokucke kann.

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

Verifizéier mat deemselwechten Gréisstentest, dann mat der Applikatioun, déi feelgeschloen ass, a kontrolléier en zweet Protokoll, well UDP-Applikatioune kréien ni d’Segmentgréisstkorrektur vun TCP. Behal d’Originalwäerter am Ticket, well eng Reparatur, déi een net ka réckgängeg maachen, en zweet Probleem ass, dee waart, bis et geschitt. Wa den Gréisstentest duerchgeet an den Upload nach ëmmer hänkt, war d’Schwaarzaach net d’Ursaach, an d’Enquête soll virugoen, amplaz d’Ännerung auszebreeden.

Ähnlech Artikelen