د VPN پینګ کار کوي خو ویبپاڼه ځنډېږي: اندازه یې وګورئ

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

له تر ټولو کوچني پوښتنې تر تر ټولو لویې پوښتنې ولاړ شئ، او ولیکئ چې هر ګام واقعاً څه ثابت کړل۔

د ایکو ځواب ډېره کوچنې پوښتنې ته ځواب وایي

د ایکو ځواب وایي چې د منزل IP سټک ستاسو له سرچینې څخه راغلې ICMP غوښتنې ته ځواب ویلی۔ دا هغه ته څه نه وایي چې ایا په هغه پورټ کې چې تاسو ته اړین دی TCP اورېدونکی شته، ایا تګلاره هغه پورټ ته اجازه ورکوي، یا ایا منزل هوسټ له ګېټوې خپلواک ترافیک فلټر کوي۔ هغه ګېټوې چې یو خدمت ته اجازه ورکوي بل له لاسه ورکولی شي، په داسې حال کې چې دواړه هدفونه پینګ ته ځواب وایي۔ ځواب د یو پاکټ او یو لوري په اړه یوازې یوه واقعیت ولولئ۔

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

وګورئ چې اړیکه پیل شوه که نه

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

curl -v --max-time 10 https://internal.example/ -o /dev/null
ss -tn state established '( dport = :443 )'

له MTU تنظیماتو سره د لاس وهلو دمخه ولیکئ چې له هغو درېیو کوم حالت مو ولید۔ د رد شوې اړیکې د سمولو لپاره د تونل اندازه بدلول هغه بدلون ضایع کوي او ریښتینی لامل یو څه وخت پټوي۔

اندازه په ذکر شوې شمېرې سره واندازه کوئ

کله چې د بار لاندې ځنډ راڅرګند شي، د ټوټه کولو منع بټ په لګولو سره یوه پاکټ اندازه ازموئ او حساب ذکر کړئ ترڅو پایله معنا ولري۔ په Linux کې د iputils سره، 1392 بایټي بار او د 8 بایټو ICMP سرلیک او د 20 بایټو IPv4 سرلیک یوځای کېدل په داخل کې سم 1420 بایټ پاکټ جوړوي۔ هغه حساب په ټیکټ کې ولیکئ، ځکه چې ګېټوې ته رسېدونکی خالي ping د اپلیکیشن په اړه هیڅ نه ثابتوي۔

ping -4 -M do -s 1392 10.44.0.10
ping -4 -M do -s 1372 10.44.0.10

دواړه ازموینې د اندازې نقطې دي، د تونل اندازې سپارښتنې نه۔ که ICMP په لار کې چېرې هم فلټر شي، د وخت پای د اندازې په اړه هیڅ نه وایي، ځکه چې د کلینټ له اړخه فلټرول او ډېر لوی پاکټ یو شان ښکاري۔ بریا هم د مخالف لوري یا بل منزل په اړه هیڅ نه وایي۔

بهرنی لار په حساب کې ونیسئ

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

په IPv4 کې د لارې MTU موندنه د هغو پاکټونو په اړه د غبرګون پورې تړلې ده چې پرته له ټوټه کولو نشي لېږل کېدای، او IPv6 د Packet Too Big پیغامونه کاروي۔ د IPv4 مشخصات هغه میکانیزم بیانوي۔ د غبرګون فلټرول د لېږونکي د زده کړې وړتیا ماتوي، او هغه بیا بیا هغه پاکټونه لېږي چې هېڅکله به ځای پر ځای نه شي۔ نو ځکه کار کوونکې کوچنې غوښتنه او ناکامه لویه غوښتنه دومره په ارامۍ سره یوځای ژوند کوي۔

یوه شمېره بدله کړئ او اپلیکیشن بیا ازموئ

د تونل MTU کم کړئ، یا د TCP لپاره تر ټولو لویه برخه اندازه محدوده کړئ، بیا د ازموینې پر ځای د اپلیکیشن اصلي ازموینه تکرار کړئ۔ هغه ازموینه چې له بدلون وروسته بریالۍ شي او هغه اپلیکیشن چې لا هم ځنډېږي د ورته بڼې بېله ستونزه ده، او یوازې د اپلیکیشن ازموینه یې توپیر کوي۔

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

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