د IKEv2 ټوټه کولو توپیر له سند زنځیر ستونزې څخه

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

دوه ټوټه کولو میتودونه، یوه نښه

IKEv2 خپل د ټوټه کولو غځېدنه لري، چې په RFC 7383 کې تعریف شوې او خوندي IKE پیغامونه په کوچنیو IKE پیغامونو ووېشي۔ دواړه خواوې پر دې وړتیا خبرې اترې کوي، او پیغام د IP طبقې نه، بلکې د IKE پلي کولو له خوا بیا یوځای کېږي۔

عادي IP ټوټه کول یو بل میتود دی چې د ناکامۍ بېله طریقه لري۔ د دواړو خواوو تر منځ روټر یو لوی ډیټاګرام ټوټې ټوټې کوي، یا یې وغورځوي او هغه ICMP پیغام بېرته راګرځوي چې کېدای شي هېڅکله لیږونکي ته ونه رسېږي۔ ځینې شبکې ټوټې په غلې ډول غورځوي، او ځینې منځني وسایل لومړۍ ټوټه اداره کوي خو نورې نه۔ د اپلیکیشن له نظره درې واړه حالتونه ورته ښکاري۔

د NAT تېرېدل درېیم بدلېدونکی زیاتوي، ځکه چې بیا ESP په UDP کې نغاړل کېږي او بهرنی پاکټ لویېږي په داسې حال کې چې په 4500 پورټ کې د عادي UDP ترافیک په څېر ښکاري۔ هغه لار چې UDP ښه تېروي، لا هم کېدای شي په هغه ډیټاګرام کې ناکامه شي چې نور نه ځایېږي۔

هغه تبادله ولولئ چې ناکامه شوه

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

هغه څه چې تاسو یې ثابتول غواړئ دا دي چې ځواب ورکوونکي غوښتنه اصلاً ولیده که نه۔ که پیل کوونکي څه لیږلي او ځواب ورکوونکي د هغې هېڅ ریکارډ نه لري، ستونزه په رسولو کې ده۔ که ځواب ورکوونکي غوښتنه تحلیل کړه او رد یې کړه، ستونزه په خود سند کې ده، او ټوټه کول پام اړوي۔ دا توپیر له یوې پاڼې د وخت ختمېدو پیغامونو څخه ډېر ارزښت لري۔

لاره بدله کړئ، سند نه

هماغه کلاینټ، هماغه سند او هماغه ترتیبات له بلې شبکې څخه وآزموئ۔ د موبایل هاټسپاټ معمولاً تر ټولو ارزانه دوهمه لاره ده، او دا له دفتر لینک څخه واقعاً بېله ده، نه یوازې په نوم۔

که لاس ورکول په دوهمه لاره بشپړ شي، د سند زنځیر سم دی او لومړۍ لاره بدلېدونکې ده۔ که په دواړو کې ورته ناکام شي، شبکه ازمویل بند کړئ او پیغامونو ته پخپله وګورئ۔ هماغه یوه پرتله د ممکنه توضیحاتو شاوخوا نیمه لرې کوي۔

د هر څه د سمولو مخکې تبادله واندازه کړئ

د زنځیر اندازه او د لارې اندازه ترلاسه کړئ۔ دواړه شمېرې محدودوي چې لاس ورکول څه لیږلای شي، او دواړه اندازه کول ارزانه دي:

openssl crl2pkcs7 -nocrl -certfile chain.pem | openssl pkcs7 -print_certs -noout | grep -c subject
ls -l chain.pem
ping -M do -s 1400 198.51.100.7
ip -s link show eth0 | sed -n '1,6p'

لومړنۍ دوه د سندونو شمېر او د فایل اندازه درکوي، چې د تصدیق پیغام څومره لوی به وي د هغې مناسبه نښه ده۔ د ping ازموینه راپور ورکوي چې د هغې اندازې ډیټاګرام په لاره کې ژوندی پاتې کېږي که نه، او د انټرفېس شمېرونکي ښیي چې ستاسو په خوا کې ټوټې وغورځول شوې که نه۔ په Windows کې ورته ازموینه هغه ping ده چې do-not-fragment بیرغ او روښانه پېلوډ اندازه لري۔

ازموینه ښکته خوا ته تکرار کړئ تر څو بریالۍ شي۔ تر ټولو لویه اندازه چې تېرېږي هغه د دې لارې کاري بودیجه ده، او له هرې خپرې شوې اصلي ارزښت څخه ډېره ګټوره ده۔

هغه طبقه سمه کړئ چې واقعاً ماته شوې ده

که لاره لوی ډیټاګرامونه غورځوي، په دواړو خواوو کې IKE ټوټه کول فعال کړئ او تایید کړئ چې غځېدنه خبرې اترې شوې نه یوازې وړاندیز شوې۔ که لاره په IP کچه ټوټو سره بد چلند کوي، سمون هلته یا د بهرني انټرفېس MTU ته اړه لري، د سندونو ذخیرې ته نه۔

که زنځیر بې اړتیا اوږد وي، هغه تر هغو منځنیو سندونو پورې لنډ کړئ چې یوې خوا ته واقعاً اړین دي۔ د هغه ریښې لرې کول چې کلاینټ لا دمخه باور پرې لري مناسبه ساتنه ده؛ د منځني لرې کول داسې نه دي، او د پیغام د کوچني کولو لپاره د تایید بندول د رسولو ستونزه د امنیت ستونزې سره بدلوي۔

ولیکئ کوم میتود مو بدل کړ او له هغې وروسته لاس ورکول څنګه ښکارېدل۔ بله پېښه معمولاً په بله شبکه کې د هماغې نښې سره پېښېږي، او هماغه یادښت دوه ساعته لس دقیقې کوي۔