Ping-ները հաջողվում են, մեծ փոխանցումները կախվում են, և թունելը հայտարարում է, որ ինքը առողջ է։ Ինչ-որ մեկը նվազեցնում է ինտերֆեյսի MTU-ն, մեկ ուրիշը սահմանափակում է MSS-ը, և երբեմն խնդիրը անհետանում է պատճառներով, որոնք ոչ ոք չի գրանցում։ Այս երկու թվերը նկարագրում են տարբեր օբյեկտներ, ուստի սխալը փոխելը տալիս է ուղղում, որը նման է բախտի։ Ահա կարգը՝ որոշե՛ք շերտը, կիրառե՛ք համապատասխան կարգավորումը, ապա փորձարկե՛ք նոր միացման վրա։

Երկու թիվ, երկու օբյեկտ

MTU-ն պատկանում է կապուղուն կամ ինտերֆեյսին. դա ամենամեծ փաթեթն է, որը կարելի է հանձնել առանց բաժանելու։ MSS-ը պատկանում է TCP-ին. դա TCP բեռի ամենամեծ քանակն է, որը սեգմենտը կարող է տանել, և այն բացառում է ինչպես TCP, այնպես էլ IP վերնագրերը։ Սովորական Ethernet կապուղու վրա IPv4-ով 1500 բայթանոց MTU-ն տալիս է հայտնի 1460 բայթանոց MSS-ը։ Այս թվերը նկարագրում են տարբեր շերտեր և փոխանակվում են տարբեր մեխանիզմներով։ Դրանք շփոթելը հեշտ է, որովհետև երկուսն էլ չափվում են բայթերով և երկուսն էլ մոտ են 1500-ին։

Մեկը գալիս է որպես ինտերֆեյսի կարգավորում։ Մյուսը գալիս է որպես տարբերակ SYN սեգմենտի ներսում՝ բանակցված ծայրերի միջև, որոնք երբեք չեն տեսնում ձեր ինտերֆեյսը։

Որտեղ է նստում արտաքին հավելյալ ծանրաբեռնվածությունը

VPN-ը ներքին փաթեթը դնում է մյուսի մեջ, և արտաքին փաթեթը պետք է տեղավորվի ֆիզիկական ուղու մեջ։ Ինկապսուլյացիայի վերնագրերը, արտաքին IP վերնագիրը, տրանսպորտի վերնագիրը և ցանկացած նույնականացման պիտակ սպառում են բայթեր, որոնք ներքին փաթեթը չի կարող օգտագործել։ Թողե՛ք թունելի ինտերֆեյսը 1500-ի վրա, և արտաքին փաթեթը պարբերաբար գերազանցում է այն, ինչ ուղին կարող է տանել։ Երբ դրված է 'չմասնատել' բիթը, երթուղիչը գցում է այն և պետք է հետ ուղարկի ICMP սխալ; եթե այդ սխալը զտվում է, ուղարկողը երբեք չի իմանում։

Ահա թե ինչու ձախողումը ընտրովի է թվում։ Փոքր հարցումները ավարտվում են, և ամեն ինչ, ինչ լցնում է սեգմենտը, կանգ է առնում, որովհետև միայն մեծ փաթեթներն են դեն նետվում։ Թունելը, որն անցնում է ping-ը, այն թունելը չէ, որը տանում է տվյալներ։

MSS-ի սահմանափակումը և որտեղ է այն գործում

MSS-ի սահմանափակումը վերագրում է SYN սեգմենտի արժեքը, երբ այն անցնում է ընտրված կետով, ինչի պատճառով երկու ծայրերն էլ ընտրում են ավելի փոքր բեռ՝ առանց իմանալու, թե ինչու։ Linux-ում դա mangle աղյուսակի թիրախ է, որը կիրառվում է բացահայտ կանոնով, և այն պետք է խփի SYN փաթեթներին ձեր ուզած ուղղությամբ։ Սահմանափակե՛ք այն թունելի ինտերֆեյսով և հասցեների տիրույթով, որովհետև լայն կանոնը փոխում է այն երթևեկության վարքը, որը երբեք չի մտնում թունել։

Ազդեցությունը միայն TCP-ի վրա է։ UDP հավելվածը, QUIC նստաշրջանը և ցանկացած արձանագրություն, որը կառուցում է իր սեփական դատագրամները, մնում են անձեռնմխելի։

Ախտորոշե՛ք ֆիքսված ուղով

Միաժամանակ պահե՛ք մեկ փոփոխական։ Փորձարկե՛ք փաթեթով, որի չափը դուք եք ընտրում, և դրե՛ք 'չմասնատել' դրոշը, որպեսզի միջուկը հաղորդի արդյունքը՝ այն թաքցնելու փոխարեն։

Գրանցե՛ք, թե որտեղից է սկսվում ձախողումը՝ թունելի ներսում, թունելի ինտերֆեյսում, թե ինկապսուլյացիայից հետո ֆիզիկական ուղու վրա։ Ապա փոխե՛ք մեկ թիվ և կրկնե՛ք նույն փորձարկումը, ոչ թե մեկ այլ։ Գոյություն ունեցող միացումները պահում են բանակցված MSS-ը, ուստի քաղաքականության փոփոխությունը տեսանելի է միայն նոր միացման վրա, և դրա համար էլ քեշավորված էջը ոչինչ չի ապացուցում ոչ մի ուղղությամբ։ Եթե մեկ մեծ վերբեռնում սկսում է աշխատել, դուք սովորել եք այդ ուղու մասին, և ոչ դրա վրա գտնվող յուրաքանչյուր արձանագրության մասին։

Ինչ չի ուղղում յուրաքանչյուր փոփոխություն

Ինտերֆեյսի MTU-ի իջեցումը չի փոխում արդեն հաստատված նստաշրջանի MSS-ը։ MSS-ի սահմանափակումը չի օգնում UDP հոսքին և չի վերականգնում այն ուղին, որտեղ ICMP սխալները զտվում են միայն մեկ ուղղությամբ։ Յուրաքանչյուր փոփոխություն ուղղում է խնդիրների մեկ դաս և մնացածը թողնում է ճիշտ այնպես, ինչպես կար։

Գրե՛ք, թե որ կարգավորումը կիրառեցիք, որտեղ, և որ փորձարկումը ցույց տվեց տարբերությունը, այլապես հաջորդ ինժեները կկիրառի երկուսն էլ և կկորցնի ասելու ունակությունը, թե որն էր կարևոր։ Եթե սահմանափակումն իրական է և մշտական, նախընտրե՛ք թունելի MTU, որն արտացոլում է այն, փոխարենը այն թաքցնող սահմանափակման։ Եթե ստիպված եք սահմանափակել, թողե՛ք կանոնը սահմանափակ և մեկնաբանված, որովհետև չբացատրված mangle կանոնը լռելյայն դառնում է մշտական։

Առնչվող հոդվածներ