ولې یو فعال VPN بیا هم په ځواب کې مهال وخت تېرېږي
د غوښتنې رسېدل خصوصي سرور ته د تبادلې یوازې نیمه برخه ده. د هغې ځواب باید د ټاکل شوي ګېټوې، لارې یا ژباړې له لارې ټنل ک्लاینټ ومومي.
غوښتنه رارسېږي، سرور هغه ثبتوي، او کاینټ بیا هم د وخت تېرېدو خبر ورکوي۔ دا ترکیب یعنې ځواب خپله بېرته تګ لاره ونه موندله، او دا یو له هغو لږو خرابیو څخه دی چې تاسو یې له دواړو خواوو په یو وخت کې تصدیق کولی شئ۔ پلټنې په ترتیب سره ترسره کړئ او کله چې یوه یې ناکامه شوه ودرېږئ۔
له هغه ځایه پیل کړئ چې غوښتنه ورته رسېدلې
له بل هر څه پلټنې مخکې تصدیق کړئ چې بسته خدمت ته رسېدلې ده۔ د سرور خوا ته د لاګ ثبت، د اړیکو شمېرنه یا په لرې پای کې اجازه شوې نیونه ټول ورته پوښتنې ځواب ورکوي، او د دوی نه شتون تاسو بېرته ټنل ته استوي نه مخکې ځواب ته۔ دا هغه پلټنه ده چې د لېږد ستونزه د بېرته تګ لارې له ستونزې جلا کوي۔
که غوښتنه هېڅکله ونه رسېده، دلته ودرېږئ۔ ټنل، خصوصي مختګ ته لارښوونه یا د لاسرسي قاعده موضوع ده، او د ځواب لاره لا اړونده نه ده۔ هغه سرچینه پته هم ولیکئ چې سرور لیدلې ده۔ هغه یا د حوض هغه پته ده چې کاینټ ته ورکړل شوې یا ژباړل شوې پته، او همدا توپیر ټاکي چې بیا کومه پلټنه پلي کېږي۔
ځواب ته حوض ته لاره ورته اړتیا ده
د لرې لاسرسي کاینټ معمولاً له حوض څخه پته ترلاسه کوي، او خصوصي شبکه د هغه حوض ته بېرته تګ لارې ته اړتیا لري۔ هغه سرور چې ډیفالټ لاره یې خپل ګېټوې ته اشاره کوي بسته همغه ګېټوې ته سپاري، چې حوض چېرې دی پوهه نه لري، نو ځواب هلته مړ کېږي۔ کاینټ د وخت تېرېدو ګوري ځکه چې هېڅ بېرته رانغی، او دا له هغې غوښتنې څخه چې هېڅکله نه ده وتلې توپیر نه شي کېدای۔
هغه لاره وګورئ چې سرور د کاینټ پتې لپاره غوره کوي، نه هغه چې د خپل فرعي شبکې لپاره کاروي۔ دا دوه پلټنې کېدای شي بېل ځوابونه ورکړي، او دلته دوهمه مهمه ده۔ ژباړه بدیله طرحه ده او هغه څه بدلوي چې سرور یې ویني۔ دا کولی شي د بېرته تګ لاره ساده کړي، او همدارنګه د کاینټ اصلي پته د سرور له لاګونو څخه لرې کوي، چې په هغه ساحه جوړ شوي هر قاعده یا راپور باندې اغېزه کوي۔
د سرور نیونه د ګېټوې له نیونې سره پرتله کړئ
هغه څه چې له سرور څخه وځي د هغو څه سره پرتله کړئ چې ګېټوې ته رسېږي۔ د سرور د وتلو انټرفېس نیونه او د ټنل ګېټوې نیونه د پوښتنې بېلو نیمو برخو ته ځواب وایي، او د دوی ترمنځ تشه د زیان ځای ښیي۔
ip route get 10.90.0.14
tcpdump -ni any host 10.90.0.14 and port 443
ip route show table all | grep 10.90.0.0| Where the reply stops | What it proves |
|---|---|
| Request in the server log, nothing on its outbound capture | The server picked a gateway that cannot reach the pool |
| Reply leaves the server but never shows up at the gateway | Loss on the LAN path, not on the tunnel |
| Reply reaches the gateway but not the client | Return translation or tunnel policy, not the server route |
هغه غوښتنه چې ګېټوې پخپله جوړوي د کاینټ ازموینې کمزوری بدیل دی، ځکه چې له بلې پتې راځي او نورو قواعدو سره مخ کېږي۔ له همدې امله له ګېټوې بریالی ping او له کاینټ ناکامه غوښتنه کېدای شي یو وخت ریښتیني دواړه وي۔
کله چې په لاره کې څو روټرونه وي، هر هغه یې وګورئ چې حوض ته لاره ورته اړتیا ده۔ د سایټ تر سایټ طرحه اکثراً غواړي چې لرې مختګ په یو څخه ډېرو وسایلو کې معلوم وي، او ګېټوې پخپله باید د ټنل او LAN ترمنځ لېږد وکړي؛ د strongSwan د لېږد یادښتونه د دې sysctl او فایر وال اړخ پوښي۔
حوض، مختګ او مسؤل ولیکئ
په یادښت کې څلور حقایق راځي: هغه حوض چې کاینټ ترلاسه کړ، هغه خصوصي مختګ چې ورته اړتیا وه، هغه روټر چې د ځواب مسؤل دی، او که شته وي د ژباړې قاعده۔ له دې سره وروسته د ګېټوې بدلون پرتله ده نه څېړنه۔
بیا د عادي کاینټ او د اپلیکیشن ریښتیني حساب سره بیا ازموینه وکړئ۔ د اپلیکیشن واکونه پراخول د بستې بېرته تګ لاره نه جوړوي، او په دې تشخیص کې د حساب بدلون به بل پرتله ګډه وړي۔ که طرحه پر ژباړې ولاړه وي، هغه هلته مستند کړئ چېرې چې د سرور لاګونه لوستل کېږي۔ هغه څوک چې په پلټنې نښه کې نااشنا سرچینه پته ویني باید نقشه بیا له ټکټ څخه کشف نه کړي۔