ولې د یوې اندازې لګښت لرونکې لارې د VPN خرابۍ لیدل ستونزمنوي
کله چې څو تونلونه یو شان لګښت شریک کړي، هره جریان کولای شي بل وټاکي. بریالی ping د هغې لارې په اړه چې ستاسو اپلیکیشن واقعاً کاروي هیڅ نه وایي.
یو کاروونکی راپور ورکوي چې داخلي اپلیکیشن له یوې ماشین څخه کار کوي او له بلې څخه ناکامېږي، په داسې حال کې چې له ګېټ وې څخه چلول شوی ping په دواړو حالتونو کې بریالی کیږي. د یوې اندازې لګښت لرونکو څو تونلونو سره دا تناقض نه دی. هره جریان په خپل بل ګام کې ځای پرځای کیږي، نو ستاسو پلټنه او د کاروونکي ناسته کېدای شي یوازې جلا لارې وکاروي. لاندې توضیح د هر څه بدلولو دمخه هغه ټاکنه بیا جوړوي.
یو ping، څو ممکنه لارې
کله چې یوه لاره په یو شان لګښت کې له یو څخه زیات بل ګام ولري، روټر باید د هرې کڅوړې لپاره یو وټاکي. ډېری پلي کول د کڅوړې ساحې هش کوي، معمولاً د سرچینې او منزل پتې د پروتوکول او پورټونو سره یوځای، تر څو ځوابونه په همدې لاره پاتې شي. بېلابېل اپلیکیشنونه، یا حتی د یو اپلیکیشن بېلابېلې اړیکې، بېلابېل هشونه تولیدوي.
له همدې امله له ګېټ وې څخه تشخیص دومره لږ ثابتوي. د ګېټ وې خپله پلټنه خپلې پتې او پورټونه لري، او له هغې خپل هش. کېدای شي په روغ تونل کې ښکته شي، په داسې حال کې چې کاروونکی په خراب تونل کې ښکته کیږي.
پلیټفارم بل ګام څنګه ټاکي
د اټکل کولو پرځای ټاکنه بیا جوړه کړئ. له کرنل څخه وپوښتئ چې د ناکامې ناستې په څېر ورته سرچینه او منزل لپاره کومه لاره کاروي. هغه پلټنه هغه ساحې هم لري چې ساده منزل-پلټنه یې نه ګوري. له یو فعال کلاینټ څخه یې هم چل کړئ او دواړه ځوابونه پرتله کړئ:
ip route get 10.20.5.7 from 10.20.0.14د iproute2 نوي نسخې پروتوکول او منزل پورټ هم مني، کوم چې هغه وخت مهم دی چې هش یې لري. هغه پایله د فعال کلاینټ له همدې پلټنې سره پرتله کړئ، او توپیر هغه شواهد دي چې تاسو ته نه وو.
| Observation | Likely cause | First check |
|---|---|---|
| Ping works, application fails | A different flow hash selects another tunnel | Per-flow lookup from the client's address |
| Some users fail, others do not | One tunnel lacks a prefix or selector | Compare both tunnels' installed routes |
| Fails only at larger sizes | Tunnels have different effective MTU | Probe the same size over each path |
| Fails after a reconnect | Stateful asymmetry between paths | Session state on both gateways |
د ناکامې جریان تعقیب کړئ، د لارو جدول نه
د لارو جدول دواړه تونلونه لیستوي او د تعریف له مخې سم ښکاري. پوښتنه دا ده چې هر تونل له ټاکل کېدو وروسته د کڅوړې سره څه کوي. تصدیق کړئ چې دواړه ورته ساتل شوې مختصې، ورته د لیږلو اجازه او یو د بیرته راستنیدو لاره لري چې هماغه کلاینټ ته رسیږي.
په منځ کې د حالت لرونکو وسیلو ته پام وکړئ. که غوښتنه له یو تونل څخه ووځي او ځواب له بل څخه راستون شي، نو هغه فایر وال یا NAT چې اصلي جریان یې کله هم نه دی لیدلی، هغه به وغورځوي. دواړه تونلونه ټرافیک سم لیږدوي، او اړیکه بیا هم ناکامېږي.
د هرې لارې MTU هم وګورئ. اضافي انکپسولیشن لرونکې لاره د کارولو وړ اندازه کموي، او هغه لېږد چې په یو تونل بریالی کیږي په بل کې په هماغه اندازه ودریږي چې کوچنی ماتېږي.
په یو وخت کې یوه لاره پرتله کړئ
چېرې چې ډیزاین ساتنه اجازه ورکوي، یو تونل له خدمت څخه وباسئ او د کاروونکي دنده تکرار کړئ. که خرابي ورکه شي، ستونزه د هغې لارې ده چې تاسو ویستلې، او بله مرحله دا ده چې د هغې ترتیب له ګاونډي سره پرتله کړئ، نه دا چې د لارښوونې جدول بیا وګورئ.
تکراریدونکي ping نه، اصلي اپلیکیشن پرتله کړئ. ولیکئ چې خرابي یو ځانګړی بل ګام، د کڅوړې اندازه یا له بیا نښلیدو وروسته بدلون تعقیبوي که نه، ځکه چې دا درې نمونې جلا جلا ترمیماتو ته اشاره کوي.
په پای کې ولیکئ چې ولې لارې سره معادل بلل کیږي او خرابي باید څنګه یوه له دوی څخه له خدمت وباسي. څو لاري یوازې هغه وخت خوندي ده چې لارې واقعاً د بدلیدو وړ وي، او دا د اټکل کولو پرځای د کتلو وړ ډیزاین بیان دی.