TCP MSS-ի սահմանափակումը Linux IPsec դարպասում։ ինչ է այն ուղղում

Ping-ը աշխատում է, SSH-ը աշխատում է, փոքր էջ է բեռնվում, և հետո յուրաքանչյուր մեծ պատասխան կանգ է առնում մինչև ժամկետի լրանալը։ Դասական օրինաչափությունը մատնանշում է փաթեթի չափը, ոչ թե հասանելիությունը. ուղին կրում է ձեռքսեղմումը և առաջին մի քանի կիլոբայթը, ապա լրիվ չափի սեգմենտը անհետանում է։ Linux IPsec դարպասում TCP MSS կանոնը հաճախ լուծումն է, բայց միայն այն դեպքում, երբ հասկանում եք, թե ինչ է այն փոխում և որտեղ է իրականում այն փաթեթը, որին այն դիպչում է։ Ստորև հերթականությունը հետևում է փաթեթին ախտանիշից մինչև կանոնի տեղադրումը, որպեսզի կարողանաք կանգ առնել հենց որ բացատրությունը դադարի համապատասխանել։

Ախտանիշը, որը հուշում է MSS-ի մասին

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

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

Ինչ է անում TCPMSS կանոնը և ինչ չի անում

Կանոնը վերագրում է MSS պարամետրը TCP ձեռքսեղմման փաթեթներում, երբ դրանք անցնում են։ Այն չի սահմանում թունելի ինտերֆեյսի MTU-ն, չի փոխում IPsec քաղաքականությունը, և ներկայիս միջուկներում միայն իջեցնում է հայտարարված արժեքը՝ փոխարենը չբարձրացնելով արդեն ավելի փոքրը։ Այն նաև դիպչում է միայն TCP-ին. UDP բեռնվածքները, DNS-ի վարքը և պայմանավորված երթևեկության ընտրիչները նրա հասանելիությունից դուրս են։

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

Տեղադրեք կանոնը ներքին TCP ուղու վրա

Քաղաքականության վրա հիմնված Linux դարպասում փոխանցված փաթեթը դեռ սովորական TCP է թվում, երբ հրապարակույտը տեսնում է այն։ IPsec քաղաքականությունը որոշում է, որ փաթեթը կպաշտպանվի. հրապարակույտը ներքին հոսքի համար ESP վերնագիր չի տեսնում, ուստի այստեղ ESP-ի հետ համապատասխանեցումը նկարագրում է բոլորովին այլ փաթեթ։ Այդ անհամապատասխանությունն է պատճառը, որ որոշ կանոններ ճիշտ են թվում և երբեք չեն համապատասխանում։

iptables-ի տերմիններով կանոնը պատկանում է փոխանցման ուղու mangle աղյուսակին՝ սահմանափակված ձեռքսեղմման փաթեթներով՝ iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1270։ Թիվը օրինակ է, ոչ թե համընդհանուր հաստատուն. ստացեք այն ինկապսուլյացիայի ծախսից և ուղու իրական MTU-ից։ nftables-ի համարժեքը սահմանում է սեգմենտի առավելագույն չափը forward կամ postrouting շղթայում։

IKE-ի և ESP-ի արտաքին լսող կանոնները առանձնացրեք ներքին փոխանցման կանոններից։ Մեկ կանոնը, որը փորձում է թույլատրել և՛ հավելվածի հոսքը, և՛ արտաքին արձանագրությունը, ի վերջո հուսալիորեն չի համապատասխանում ոչ մեկին։

Հարգեք հրապարակույտի տիրոջը և NAT-ի հերթականությունը

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

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

Ստուգեք նեղ շրջանակում, ապա կանգ առեք

Բացեք նոր կապ ձախողվող ծառայությանը և հետևեք և՛ հավելվածին, և՛ կանոնի հաշվիչներին։ Եթե կանգը վերանում է, դուք ապացույց ունեք այդ TCP ուղու մասին այդ ինկապսուլյացիայով։ Դուք ապացույց չունեք, որ յուրաքանչյուր VPN արձանագրություն տեղավորվում է, որ յուրաքանչյուր UDP հավելված ուղղվել է, կամ որ որոշակի վերին ծառայությունն էր սկզբնական պատճառը։

Թույլ տվեք ICMP չափի հետադարձ կապին աշխատել այնտեղ, որտեղ քաղաքականությունը թույլ է տալիս, և զգուշորեն վերաբերվեք ուղու MTU-ի վրա հիմնված ավտոմատ սահմանափակմանը, երբ արտաքին IPsec ուղին ներկայացված չէ ներքին երթուղով։ Որքան նեղ է եզրակացությունը, այնքան ավելի հեշտ է ախտորոշել հաջորդ միջադեպը։