Ping ثبوت نه دی: د دوو سایټونو ترمنځ لاره وازمویئ

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

له هغه کسټمر پیل کړئ چې خدمت ته اړتیا لري

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

مستند هوسټ نوم وآزمویئ او، چېرته چې خدمت اجازه ورکوي، د همدې پورټ مستقیمه پته کتنه۔ ناکامه نوم لټون او نه رسېدونکې حل شوې پته تاسو بېلې لارې ته وړي۔ که تاسو د هوسټ نوم پر ځای IP کیږدئ، د HTTPS هویت کتنه مه بندوئ چې کار وکړي؛ د سند خبرداری معلومات دی، نه خنډ۔

په هر څنډه کې لاره ووهئ

هغه لار ولولئ چې کسټمر غوره کوي، بیا هغه لار چې ګیټ وے د هغه منزل لپاره غوره کوي، بیا په هر څنډه کې کاونټرونه یا محدود نیول۔ تاسو دوه حقایق لټوئ: آیا غوښتنه لرې LAN ته ورسېده، او آیا ځواب بیرته راغی۔ د انټرفیس کاونټرونه هر بل جریان هم رانغاړي، نو د ګراف د بڼې پر ځای د دقیق وخت ټاک او د پتې جوړې له مخې اړیکه جوړه کړئ۔ په غلط څنډه کې نیول د نه نیولو څخه بدتر دي، ځکه چې د ثبوت په څیر ښکاري۔

ip route get 10.10.0.5
sudo tcpdump -ni any host 10.10.0.5 and port 445
sudo tcpdump -ni any net 10.10.0.0/24 and net 10.20.0.0/24

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

هغه پروتوکول وکاروئ چې اپلیکیشن یې کاروي

ICMP کمزورې کتنه ده۔ کېدای شي فلټر شي، په سرعت محدوده شي یا له خدمت څخه بېل پالیسي ورسره چلند وکړي، چې د دواړو بریالیتوب او ناکامي په ابهام کې اچوي۔ ریښتینی پورټ او، چېرته چې شونې ده، د پروتوکول ریښتینی لاس ورکول وآزمویئ۔

nc -vz 10.10.0.5 445
curl -sv --max-time 5 https://files.corp.internal/ -o /dev/null
openssl s_client -connect 10.10.0.5:443 -servername files.corp.internal

بشپړ شوی TCP لاس ورکول د هغه پورټ لپاره رسیدنه او پالیسي ثابتوي۔ دا نه ثابتوي چې اپلیکیشن کار کوي: تصدیق، اپلوډ یا ځانګړې API غوښتنه لا هم ناکامېدای شي۔ هغه عمل چې کاروونکي واقعاً کوي وآزمویئ، له ریښتیني معاملې بیا بیا سپارلو پر ځای د بې زیانه برابرې لارې سره۔

هغه حالت بیا تولید کړئ چې پکې ناکامېږي

ناکامي چې یوازې په لویو لېږدونو کې ښکاره کېږي د اندازې ستونزه ده، نه د اړیکې۔ د don't-fragment بټ سره لوی پیکټ ولېږئ او وګورئ چې چېرته دریږي۔ که کوچنې غوښتنه بریالۍ شي او لویه ودرېږي، د ټونل MTU او په ګیټ وے کې د MSS اداره کول بل شکمن دي۔

ping -M do -s 1400 10.10.0.5
ping -M do -s 1472 10.10.0.5
curl -sS --max-time 30 -F file=@./sample.bin https://files.corp.internal/upload

که یوازې یوه فرعي شبکه ناکامه شي، د ترافیک غورونکي، د لارې اعلانونه او د هغې شبکې د بیرته ستنیدو ګیټ وے وګورئ۔ که یوازې د هوسټ نوم ناکام شي، DNS تعقیب کړئ، په دې کې چې کسټمر کوم حل کوونکی کارولی او آیا لرې لید له هغې سایټ څخه ښکاري۔ درې بېلې ناکامۍ، درې بېلې سمونې، او پینګ ازموینه له هغو یو هم نه توپیروي۔

له سمونې وروسته، هغه ازموینه بیا کړئ

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

څلور بنسټیز ارزښتونه او پایله ولیکئ۔ د همدې نښې راتلونکی راپور بیا کولای شي له ping پر ځای له ثبوتونو پیل شي۔