ولې د ټول ICMP بندول یو فعال VPN لار ماتوي
د اندازې په اړه د غبرګون پیغامونه د ping ځوابونه نه دي. کله چې هغه هیڅکله ونه رسیږي، کوچني پاکټونه تیریږي، لویونه ورک شی، او تونل لړزېدونکی ښکاري.
هغه تونل چې تصدیق تیریږي، ping لیږدوي او بیا په لومړي لوی لیږد کې ودریږي، د مات VPN نه بلکه د ورک ICMP پیغام کلاسیکه نښه ده. لیږوونکی هیڅکله نه پوهیږي چې پاکټ ډیر لوی و، هماغه اندازه بیا هڅه کوي، او اپلیکیشن انتظار کوي. د دې سمول د فایر وال د تګلارې پریکړه ده، نه د کلاینټ بیا نصبول. ترتیب مهم دی: اندازه کړئ چې د اندازې پوله چیرته ده، بیا هغه قاعده تنګه کړئ چې راپور یې وبلعیده.
په دې لار کې ICMP واقعیا څه لیږدوي
د IPv4 لارې MTU کشف په دې ولاړ دی چې روټر راپور ورکړ چې د don't-fragment بټ سره پاکټ نشي لیږل کیدای. هغه راپور ICMP Fragmentation Needed پیغام دی، او پرته له هغه لیږوونکی د خپل برخې اندازه کموولو لپاره هیڅ دلیل نلري. IPv6 سخت تر دی: روټرونه په ترانزیټ کې نه ویشي، نو ICMPv6 Packet Too Big پیغام یوازینی سیګنال دی چې لیږوونکی کوچنی کوي.
دواړه پیغامونه د کنټرول طبقې غبرګون دي، او هیڅ یو یې تشخیصي انګړ نه دی. هغه تګلاره چې ping بندوي او هغه چې ټول ICMP بندوي په قاعدو لیست کې ورته ښکاري خو په شبکه کې ډیر توپیر لري. دوهمه کولای شي یو سم اندازه تونل د زنځیر تر ټولو کوچني حلقې څخه لوی هر څه لپاره یو اړخیزه لار بدله کړي.
ځینې لیږدونه خپل کشف د ازموینې پاکټونو سره پلي کوي، لکه څنګه چې RFC 4821 تشریح کوي، او هغه په دې غبرګون لږ تکیه کوي. دا د دې لپاره دلیل دی چې وګورئ کوم لیږد چلوئ، نه دا چې فکر وکړئ هر تونل مصون دی.
| پیغام | په لار کې هدف | که بند شي |
|---|---|---|
| ICMPv4 ډول 3 کوډ 4 | پاکټ د راتلونکې حلقې لپاره ډیر لوی و | لیږوونکی بیا هڅه کوي او ودریږي |
| ICMPv6 ډول 2 | Packet Too Big، د IPv6 معادل | هماغه تمځای، د ویشلو پرته بېل بدیل |
| ICMP ډول 11 | وخت تیر شو، traceroute یې کاروي | تشخیص هپونه له لاسه ورکوي، ترافیک بیا هم بهیږي |
| ICMP انګړ غوښتنه او ځواب | د رسیدو ازموینه | ping ناکام شی، لار ممکن سمه وي |
ناکامي د اندازې پورې تړلې ده
وپوښتئ چې ایا ناکامي د پاکټ اندازې سره تړاو لري. د ننوتلو پاڼه، DNS پوښتنه او لنډ API زنګ بریالي کیږي، پداسې حال کې چې د فایل پورته کول، لوی ځواب یا د عکس ډاونلوډ ودریږي. دا بڼه د دوو سرونو ترمنځ چیرې د اندازې حد ته اشاره کوي، نه تصدیق یا روټینګ ته. بریالی کوچنی ping د هغې پولې د ځای په اړه نږدې هیڅ نه وایي.
د تونل دننه دوه طبقې باید په پام کې ونیول شي: د بار پاکټ او بیرونی انکپسول شوی پاکټ. داخلي لیږوونکی سم رفتار کولای شي پداسې حال کې چې بیرونې لار د تونل د انګیرنې څخه کوچنۍ وي، له همدې امله د تونل خپله MTU ترتیبه او لاندې فزیکي حلقه دواړه مهم دي.
د قاعدو د سمون مخکې اندازه کړئ
د don't-fragment بټ او خپل ټاکلي بار اندازې سره ازموینه وکړئ, له ناکام کلاینټ څخه محافظت شوي پتې ته:
ping -M do -s 1472 10.20.5.7
ping -M do -s 1300 10.20.5.71472 بایټ بار جمع 28 بایټ سرلیکونه 1500 بایټ پاکټ جوړوي. که لویه ازموینه د ویشلو تېروتنې سره ناکامه شي او کوچنۍ تیره شي، پوله مو پیدا کړه؛ د تونل اضافي لګښت لپاره تنظیم کړئ او تر هغه تکرار کړئ چې کاري اندازه ثابته شي.
بیا تایید کړئ چې تشه پخپله راپور دی. که ازموینه په غلیمانه توګه ناکامه شي، پرته له تېروتنې او ځواب، پیغام شاید غورځول کیږي نه رسول کیږي، او شکمن قاعده ده.
قاعده تنګه کړئ، بیا دنده بیا ازموینه کړئ
سمون باید ځانګړي کنټرول پیغامونه اجازه کړي، نه ټول پروتوکول. په iptables کوربه کې بڼه ډول-ځانګړې اجازه ده؛ نحو د هغه سره سم کړئ چې ستاسو په پلیټ فارم کې فایر وال اداره کوي:
iptables -I INPUT -p icmp --icmp-type fragmentation-needed -j ACCEPT
ip6tables -I INPUT -p icmpv6 --icmpv6-type packet-too-big -j ACCEPTکه دا سیمه ایزه تګلاره وي انګړ ځوابونه بند وساتئ، ځکه لار ورته اړتیا نلري. بیا هغه لیږد چې اصلا ناکام شو د نوي اتصال څخه بیا ازموینه کړئ، او تایید کړئ چې د قاعدې کاونټرونه پیغامونه راتلل ښیي.
که د پیغامونو اجازې وروسته هم لوی لیږد ودریږي، پاتې حد بل ځای کې دی: ډیر لوړ ټاکل شوی تونل MTU، پاکټونه بیا لیکونکی پروکسي، یا د راپور ورکولو پرځای غورځوونکی منځنی بکس. ICMP قاعده اړینه وه، بس نه وه.