MSS կանոնը աշխատում է երթուղիչում, բայց բաց է թողնում Squid-ը

Ադմինիստրատորը TCPMSS սահմանափակում է ավելացնում FORWARD-ում։ Ուղիղ երթուղավորված երթևեկությունը լավանում է, բայց տեղական Squid օրինակի միջոցով ներբեռնումները դեռ կախվում են։ Վստահորդի կապը կայքի հետ պարզապես հաճախորդի TCP միացումը չէ, որ անցնում է այդ շղթայով։

Սովորական փակող forward-վստահորդում հաճախորդի կողմի միացումը տեղում ավարտվում է։ Վստահորդը ստեղծում է երկրորդ TCP միացում դեպի աղբյուրը կամ ծնողը։ Linux-ում այդ միացման համար ստեղծված փաթեթները հետևում են տեղական ելքի ուղուն։

Այսպիսով, միայն FORWARD-ի համար նախատեսված կանոնը կարող է լիովին աշխատունակ լինել և այնուամենայնիվ բաց թողնել այն ձեռքսեղմումը, որը պետք է ճշգրտեր։ Հուկ ընտրելուց առաջ քարտեզագրեք իրական միացումը և SYN-ի ուղղությունը։ Կոնտեյներները կամ առանձին անվանատարածքները կարող են ավելացնել ևս մեկ երթուղավորված հատված, ուստի ճիշտ տեղը կախված է նրանից, թե որտեղ է աշխատում գործընթացը։

Մի՛ դրեք PMTU թիվը ուղիղ MSS-ի մեջ

Ուղու MTU-ն IP փաթեթի չափն է։ TCP MSS-ը նկարագրում է TCP բեռնվածքը և պետք է հաշվի առնի համապատասխան վերնագրերը։ Նույն կերպ, ping-ի բեռնվածքի երկարությունը IP փաթեթի ամբողջ երկարությունը չէ։ Հայտնի 28 բայթ ավելացումը կապված է հիմնական IPv4 ICMP echo դասավորության հետ, ոչ թե ամեն հասցեների ընտանիքի կամ ինկապսուլյացիայի։

TCPMSS թիրախը փաստագրում է բացահայտ արժեքներ և PMTU սահմանափակում։ Սահմանափակումը դեռ հենվում է երթուղու MTU տեղեկության վրա. դա ապացույց չէ, որ ուղու հայտնաբերումը առողջ է, և չի փոխարինում անհրաժեշտ ICMP հաղորդագրությունների թույլատրմանը։

Համապատասխանեցրեք նաև ախտանիշը տեսությանը։ Ավարտված ձեռքսեղմումը, որին հաջորդում են խոշոր փոխանցումների կանգերը, կարող է արդարացնել փաթեթի չափի ուսումնասիրությունը։ Կրկնվող անպատասխան SYN-երը կամ անմիջական reset-ը պահանջում են ավելի լայն բացատրություն. փոքր փաթեթների ձախողումը չի ապացուցում չափազանց մեծ տվյալների հատված։

Արձանագրության մեջ առանձին պահեք աշխատող ուղիղ միացումը և ձախողվող վստահորդի միացումը։ Նրանք կարող են օգտագործել տարբեր աղբյուրներ, ուղիներ և ինկապսուլյացիա, նույնիսկ նույն մեքենայից։