د Linux IPsec ګیټوې پر TCP MSS تنظیم: څه سمول کوي

Ping کار کوي، SSH کار کوي، یوه کوچنۍ پاڼه بارېږي، او بیا هره لویه ځواب تر پای وخت پورې بندېږي۔ کلاسیک نمونه د لاسرسي پر ځای د بنډل اندازې ته اشاره کوي: لار لاس ورکول او لومړني څو کیلوبایټ وړي، بیا بشپړ اندازه برخه ورکېږي۔ په Linux IPsec ګیټوې کې د TCP MSS قاعده ډېری وخت حل وي، خو یوازې هغه وخت چې پوه شئ دا څه بدلوي او هغه بنډل چې لمس کوي په رښتیا چېرې دی۔ لاندې ترتیب بنډل له نښې څخه د قاعدې ځای ته تعقیبوي، نو کولی شئ لکه څنګه چې تشریح نور سم نه وي سمدلاسه ودروئ۔

هغه نښه چې MSS ته اشاره کوي

TCP په لاس ورکولو کې د برخې تر ټولو لوی اندازې باندې خبرې اترې کوي۔ که هغه ارزښت تر هغې لوی وي چې لار یې د انکپسولیشن وروسته وړلی شي، لېږونکی هغه برخې جوړوي چې هېڅکله نه رسېږي، او اړیکه له لومړي پړاو وروسته بندېږي۔ کوچني ځوابونه ځای پرځای کېږي؛ لوی نه۔

د ICMP غبرګون کولی شي اړیکه د لارې MTU کشف له لارې وژغوري، او هغه فایر وال چې دا پیغامونه غورځوي بندېدل په یوه غلي بې غږه سوري بدلوي۔ له همدې کبله ورته تونل یوه اپلیکیشن ته کار کوي او بل ته پرته له کوم ښکاره توپیر په ترتیباتو کې ناکامېږي۔

د TCPMSS قاعده څه کوي او څه نه کوي

قاعده په TCP لاس ورکولو بنډلونو کې د MSS غوراوی بیا لیکي کله چې تېرېږي۔ دا د تونل انټرفیس 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 اندازې غبرګون کار وکړي، او کله چې باندنی IPsec مسیر د داخلي لارې له خوا نه وي استازیتوب شوی، د لارې MTU پر بنسټ اتوماتیک محدودیت په احتیاط سره وکاروئ۔ هرڅومره چې پایله تنګه وي، راتلونکې پېښه تشخص کول هماغومره اسانه دي۔