MSS clamping pe un gateway VPN: ce repară și ce nu repară

Cererile mici funcționează, descărcările mari se blochează și cineva sugerează MSS clamping. Sugestia este destul de des corectă ca să merite încercată în ordinea corectă și destul de des greșită ca să pierzi o după-amiază dacă o aplici orbește. Cele trei verificări de mai jos separă o problemă reală de dimensiune TCP de o problemă UDP, de o descoperire path-MTU stricată și de un clamp care nu vede niciodată handshake-ul pe care ar trebui să-l rescrie.

Începe cu forma defecțiunii

O defecțiune de dimensiune are o semnătură: conexiunea se stabilește, autentificarea și răspunsurile mici reușesc, apoi un transfer se blochează la nesfârșit de îndată ce are nevoie de un segment de dimensiune completă. Paginile care încarcă text dar nu termină niciodată o imagine sunt aceeași defecțiune la scară mai mică. Dacă nu se conectează nimic, problema este mai devreme pe cale și clamping-ul nu va ajuta. Un clamp nu poate repara un handshake care nu a ajuns niciodată.

Semnătura există pentru că handshake-ul este locul unde se agreează dimensiunea segmentului. Fiecare parte anunță o dimensiune maximă de segment ca opțiune TCP, iar expeditorii respectă anunțul celeilalte părți. Dacă calea nu poate duce un segment atât de mare, defecțiunea apare mai târziu, când expeditorul încearcă în sfârșit unul.

Ține transportul în vedere în timp ce citești acel simptom. Clamping-ul este o rescriere a unei opțiuni TCP, așa că un apel vocal sau video care se blochează sub același tunel nu este o problemă de MSS și nu se va îmbunătăți de pe urma ei. Notează transportul înainte de a atinge o opțiune TCP.

Evaluează calea, apoi compar-o cu tunelul

Două numere contează și sunt adesea confundate. path-MTU este cel mai mare pachet pe care calea îl transportă fără fragmentare, iar MSS anunțat pentru IPv4 este acea valoare minus cei 40 de octeți ai antetelor IP și TCP, sau minus 60 pentru IPv6. Encapsularea tunelului consumă o parte din buget înainte ca pachetul interior să înceapă.

ping -M do -s 1400 198.51.100.20
tracepath 198.51.100.20

Ping-ul cu bitul do-not-fragment îți spune dacă supraviețuiește un pachet de acea dimensiune a încărcăturii; ajustează dimensiunea până când eșuează și ai găsit empiric limita căii. Ieșirea tracepath raportează MTU-ul descoperit de-a lungul rutei, ceea ce este mai rapid când funcționează și mai puțin fiabil când un hop intermediar filtrează sondele.

Acum scade costul tunelului. Un antet IP exterior, un antet UDP și un antet specific tunelului provin toate din aceiași 1500 de octeți, așa că MTU-ul interior utilizabil pe o bază Ethernet tipică este mai mic decât sugerează legătura fizică. Dacă MTU-ul interior calculat este sub ce anunță partenerii tăi, ai găsit un candidat real la clamp, nu o presupunere. Dacă valoarea calculată este deja peste anunțul partenerilor, oprește-te aici și caută în altă parte.

Pune clamp-ul acolo unde trece handshake-ul

Un clamp funcționează rescriind opțiunea MSS în pachetele SYN și SYN-ACK în timp ce traversează gateway-ul. Dacă regula stă pe o interfață pe care niciuna dintre direcții nu o traversează vreodată, negocierea se încheie neschimbată și simptomul persistă, de aceea plasarea decide rezultatul mai mult decât valoarea.

Direcția este cealaltă jumătate. Clamping-ul pe o singură direcție repară jumătate din fluxuri și lasă restul să eșueze într-un mod care pare intermitent, așa că aplică-l pe ambele direcții ale traficului redirecționat. Forma clasică în Linux pentru o interfață de tunel este o regulă mangle care potrivește pachetele SYN:

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

Observă ce face de fapt --clamp-mss-to-pmtu: derivă valoarea din MTU-ul rutei, care nu este întotdeauna bugetul real de încărcătură al tunelului. Pe un tunel bazat pe rută, unde ruta interioară și calea exterioară diferă, o valoare explicită calculată în verificarea anterioară este mai previzibilă decât una automată.

Verifică cu o conexiune nouă și ține feedback-ul viu

O conexiune stabilită păstrează MSS-ul negociat, așa că testarea în aceeași sesiune nu dovedește nimic. Deschide o conexiune nouă după modificare și citește valoarea negociată direct, în loc să o deduci dintr-un transfer care se termină din întâmplare.

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

Prima comandă raportează MSS-ul socketului împreună cu starea de congestionare, ceea ce este cea mai rapidă confirmare că clamp-ul a avut efect. A doua confirmă că regula pe care crezi că ai adăugat-o este regula care există, în tabelul în care a fost plasată.

Apoi protejează mecanismul pe care nu l-ai reparat. Descoperirea path-MTU depinde de mesajele ICMP fragmentation-needed care ajung la expeditor, așa că un firewall care le aruncă va continua să strice transferurile mari chiar și cu un clamp corect. Permite acele mesaje pentru calea tunelului sau acceptă că clamping-ul compensează o politică pe care ai ales-o.

În final, resistă tentației de a trata clamp-ul ca pe un buton de reglaj. Restrânge dimensiunea segmentului, ceea ce costă debit pe căi care nu au avut niciodată nevoie de asta. Aplicat după cele trei verificări este o reparație țintită; aplicat primul este o schimbare care ascunde defectul original și adaugă o a doua variabilă la fiecare test ulterior. Acel compromis merită făcut deliberat, nu implicit.

Notează path-MTU măsurat, costul tunelului scăzut, regula adăugată și MSS-ul văzut după aceea. Patru numere fac din următorul incident o căutare în loc de o anchetă.