MSS-inklemming op 'n VPN-poort: wat dit regstel en wat nie

Klein versoeke werk, groot aflaaie hang, en iemand stel MSS-inklemming voor. Dié voorstel is dikwels genoeg reg om dit in die korrekte volgorde te probeer, en dikwels genoeg verkeerd om 'n middag te mors as jy dit blind toepas. Die drie kontroles hieronder skei 'n egte TCP-grootteprobleem van 'n UDP-probleem, 'n stukkende path-MTU-ontdekking, en 'n inklemming wat nooit die handdruk sien wat dit veronderstel is om te herskryf nie.

Begin met die vorm van die fout

'n Groottefout het 'n kenmerk: die verbinding kom tot stand, verifikasie en klein antwoorde slaag, en dan hang 'n oordrag onbepaald sodra dit 'n volgrootte-segment nodig het. Bladsye wat teks laai maar nooit 'n beeld voltooi nie, is dieselfde fout op 'n kleiner skaal. As niks hoegenaamd konnekteer nie, lê die probleem vroeër in die pad en sal inklemming nie help nie. 'n Inklemming kan nie 'n handdruk herstel wat nooit aangekom het nie.

Die kenmerk bestaan omdat die handdruk die plek is waar die segmentgrootte ooreengekom word. Elke kant adverteer 'n maksimum segmentgrootte as 'n TCP-opsie, en stuurders respekteer die eweknie se advertensie. As die pad nie so 'n groot segment kan dra nie, verskyn die fout later, wanneer die stuurder dit uiteindelik probeer.

Hou die transport in sig terwyl jy daardie simptoom lees. Inklemming is 'n herskrywing van 'n TCP-opsie, so 'n stem- of video-oproep wat onder dieselfde tonnel hang, is nie 'n MSS-probleem nie en sal nie daardeur verbeter word nie. Skryf die transport neer voordat jy aan 'n TCP-opsie raak.

Prys die pad, vergelyk dit dan met die tonnel

Twee getalle maak saak en hulle word dikwels verwar. Die pad-MTU is die grootste pakkie wat die pad sonder fragmentering sal dra, en die aangekondigde MSS vir IPv4 is daardie waarde minus die 40 grepe van IP- en TCP-opskrifte, of minus 60 vir IPv6. Tonnel-inkapseling verbruik 'n deel van die begroting voordat die binneste pakkie eers begin.

ping -M do -s 1400 198.51.100.20
tracepath 198.51.100.20

Die ping met die do-not-fragment-bis vertel jou of 'n pakkie van daardie vraggrootte oorleef; pas die grootte aan totdat dit misluk, en jy het die padperk empiries gevind. Die tracepath-uitvoer rapporteer die MTU wat langs die roete ontdek is, wat vinniger is wanneer dit werk en minder betroubaar wanneer 'n tussenliggende hop die ondersoeke filter.

Trek nou die tonnel se oorhoofse koste af. 'n Buitenste IP-opskrif, 'n UDP-opskrif en 'n tonnelspesifieke opskrif kom almal uit dieselfde 1500 grepe, so die bruikbare binneste MTU op 'n tipiese Ethernet-onderlaag is laer as wat die fisiese skakel voorstel. As die berekende binneste MTU laer is as wat jou eweknieë adverteer, het jy 'n werklike inklem-kandidaat gevind eerder as 'n raaiskoot. As die berekende waarde reeds hoër is as wat eweknieë adverteer, stop hier en kyk elders.

Plaas die inklemming waar die handdruk verbykom

'n Inklemming werk deur die MSS-opsie in die SYN- en SYN-ACK-pakkies te herskryf terwyl hulle die poort oorsteek. As die reël op 'n koppelvlak sit wat nie een van die twee rigtings ooit deurkruis nie, voltooi die onderhandeling onveranderd en bly die simptoom voortduur, en daarom bepaal plasing die uitkoms meer as die waarde.

Rigting is die ander helfte. Om een rigting in te klem maak die helfte van die strome reg en laat die res misluk op 'n manier wat wisselvallig lyk, so pas dit op albei rigtings van die deurgestuurde verkeer toe. Die klassieke Linux-vorm vir 'n tonnelkoppelvlak is 'n mangle-reël wat SYN-pakkies pas:

iptables -t mangle -A FORWARD -o tun0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Let op wat --clamp-mss-to-pmtu werklik doen: dit lei die waarde van die roete se MTU af, wat nie altyd die tonnel se werklike nuttige vragbegroting is nie. Op 'n roetegebaseerde tonnel waar die binneste roete en die buitenste pad verskil, is 'n eksplisiete waarde wat in die vorige kontrole bereken is, meer voorspelbaar as 'n outomatiese een.

Verifieer met 'n nuwe verbinding, en hou die terugvoer lewendig

'n Bestaande verbinding behou die MSS wat dit beding het, so om op dieselfde sessie te toets bewys niks. Maak 'n nuwe verbinding na die verandering oop en lees die bedinge waarde direk, eerder as om dit af te lei uit 'n oordrag wat toevallig klaarmaak.

ss -tin dst 198.51.100.20
iptables -t mangle -S | grep TCPMSS

Die eerste opdrag rapporteer die sok se MSS saam met sy oorladingstoestand, wat die vinnigste bevestiging is dat die inklemming effek gehad het. Die tweede bevestig dat die reël wat jy dink jy bygevoeg het, die reël is wat bestaan, in die tabel waar dit geplaas is.

Beskerm dan die meganisme wat jy nie reggemaak het nie. Path-MTU-ontdekking hang daarvan af dat ICMP-fragmentation-needed-boodskappe die stuurder bereik, so 'n vuurmuur wat hulle laat val, sal groot oordragte aanhou breek selfs met 'n korrekte inklemming in plek. Laat daardie boodskappe vir die tonnelpad deur, of aanvaar dat inklemming kompenseer vir 'n beleid wat jy gekies het.

Weerstaan laastens die versoeking om die inklemming as 'n instelknop te behandel. Dit beperk die segmentgrootte, wat deurset kos op paaie wat dit nooit nodig gehad het nie. Toegepas ná die drie kontroles is dit 'n gerigte herstelling; toegepas eerste is dit 'n verandering wat die oorspronklike fout wegsteek en 'n tweede veranderlike by elke latere toets voeg. Daardie ruil is die moeite werd om doelbewus te maak, nie by verstek nie.

Skryf die pad-MTU neer wat jy gemeet het, die tonnel-oorhoofse koste wat jy afgetrek het, die reël wat jy bygevoeg het en die MSS wat jy daarna gesien het. Vier syfers maak die volgende voorval 'n naslaan eerder as 'n ondersoek.