ایا ترافیک واقعاً د VPN له لارې تړلی؟ څنګه یې تصدیق کړو
د لارې پلټنه، لومړی ټوپ، د فزیکي اډاپټر باندې نیول او له باندې د پتې کتنه هر یو د پوښتنې بېلابېلو برخو ته ځواب ورکوي.
دوه نیمګړتیاوې د سیستم د ټرې له آیکون څخه یو شان ښکاري: هغه ترافیک چې تونل ته ننوځي او هغه ترافیک چې په خاموشۍ سره تر څنګ تېرېږي. کلاینټ په دواړو حالتونو کې Connected ښیي، ځکه Connected یوازې دا مانا لري چې د تونل انټرفیس شته او کلاینټ هغه لارې نصب کړې چې غوښتل یې. ایا د یو اپلیکیشن یو پاکټ هغه لارې وکارولې، دا جلا پوښتنه ده چې ځواب یې د سټک په بل ځای کې ورکول کیږي. څلور اندازه اخیستنې یې ډېره برخه حل کوي — د لارې پلټنه، لومړی ټوپ، د فزیکي اډاپټر باندې نیول او له باندې کتنه — او د سرور خپل سیشن لید پاتې برخه پوښي.
له هغې لارې پیل وکړئ چې پاکټ به وهي
د لارښوونې جدول پخپله پرېکړه ده، نو د ټول لوستلو او اټکل کولو پرځای د یو مقصد په اړه ترې وپوښتئ. په Linux کې، ip route get هغه انټرفیس او سرچینه پته نوموي چې کرنل غوره کړې:
ip route get 203.0.113.10
ip route get 10.20.5.7په Windows کې، Find-NetRoute -RemoteIPAddress 203.0.113.10 د route print -4 څخه ډېر ګټور دی، همدې دلیل لپاره: هغه لاره راپور ورکوي چې وګټله، نه ټولې موجودې لارې. سره له دې جدول یو ځل د هغه 0.0.0.0 کرښې لپاره ولولئ. هلته د /1 جوړه مانا دا ده چې بشپړ تونل کلاینټ ډیفالټ لاره بیا لیکلې: د OpenVPN redirect-gateway def1 اختیار د تونل له لارې 0.0.0.0/1 او 128.0.0.0/1 نصبوي، چې د فزیکي ډیفالټ له منځه وړلو پرته په تر ټولو اوږده مخکښه سمون کې موجوده 0.0.0.0/0 ته ماتې ورکوي. له همدې امله دوه ډیفالټ لارې کولی شي یو ځای وي، خو هر څه بیا هم تونل ته ځي.
دوه جزئیات جدول درواغجن کوي. لومړی، د ډیفالټ لارو شمېر نه، بلکې هغه مخکښه وګورئ چې سمون کړی، ځکه د انټرفیس میټریک یا د /1 جوړه ګټونکی ټاکي. دویم، هغه اړیکه چې له مخکې شته، هغه لاره ساتي چې پرې جوړه شوې وه؛ د تونل له پورته کېدو وروسته خلاص سیشن کولی شي تر بیا تنظیمېدو پورې زړه لاره وکاروي، او له همدې امله بیا نښلول د لارښوونې ستونزه جوړه کړې ښکاري. چلېدونکی کلاینټ — ps ax | grep openvpn — یوازې دا ثابتوي چې پروسه پیل شوې.
یو داخلي او یو عام نوم تعقیب کړئ
د لارې پلټنه نیت ښیي؛ لاره رسول ښیي. د نښلېدو پر مهال د هغه نوم چې باید داخلي وي او هغه نوم چې باید نه وي تعقیب کړئ او لومړی ټوپ پرتله کړئ:
traceroute intranet.corp.example
traceroute 1.1.1.1د دواړو لپاره یو شان لومړی ټوپ مانا دا ده چې داخلي نوم هېڅکله تونل ته نه دی ننوتلی او نیمګړتیا له هغې پورته ده، معمولاً هغه نوم چې عامې پتې ته حل کیږي یا هغه لاره چې هېڅکله نه ده نصب شوې. که داخلي ترافیک د 10.8.0.1 له لارې ووځي او عام ترافیک د 192.168.1.1 له لارې، نو ویشل شوی تونل هغه څه کوي چې د هغې لپاره تنظیم شوی و. هغه نقش چې VPN دروازې ته رسېږي او بیا یوازې د وخت پای ته رسېدنې بېرته راوړي، معمولاً د بېرته راستنېدو لار یا د سرور د اور وژنې ستونزه ده، نه ورکه شوې لېږدونې لاره.
فلټر شوی ICMP دا کتنه درواغجنوي: په دواړو نقشونو ستوري د مړ تونل په څېر ښکاري او معمولاً هغه اور وژنه ده. چېرې چې کولی شئ TCP پورټ وآزمویئ — په Linux کې traceroute -T -p 443 — او په یاد ولرئ چې نقش نه وایي کوم حل کوونکی ځواب ورکړ: نوم کولی شي په سیمه ییزه توګه حل شي او بیا هم د تونل له لارې ورته رسېدل ممکن وي.
په تونل باندې نه، بلکې د فزیکي اډاپټر باندې ونیسئ
فزیکي تړاو یوازینی ځای دی چې ښیي شبکه واقعاً څه ویني. د تونل پورته والي پر مهال دفتر ته تلونکی سیشن باید د VPN سرور ته استول شوي کوډ شوي بار په څېر ښکاره شي، نه د 10.20.5.7 سره د اړیکې په څېر:
sudo tcpdump -ni eth0 udp port 53
sudo tcpdump -ni eth0 host 10.20.0.5لومړی فلټر په سیمه ییزه توګه وتونکې نوم حلونه نیسي، کوم چې تر ټولو عام او تر ټولو خاموش لیک دی — پاڼه بیا هم لویږي، حل کوونکی یوازې پوښتنه ولیده. دویم د تونل دننه یوازې موجودیدونکې داخلي پتې ته عادي ترافیک نیسي. په Windows کې، pktmon پرته له ډرایور ورته کار کوي: pktmon filter add -p 53، بیا pktmon start --capture --pkt-size 128، بیا pktmon stop او pktmon format pktmon.etl -o capture.txt. دا بیرغونه د Windows جوړښتونو تر منځ لږ توپیر لري، نو د نحو باور کولو دمخه pktmon filter add /? وګورئ.
د لیکونو موندلو لپاره فزیکي انټرفیس ونیسئ؛ په تونل باندې نیول هغه پاکټونه لري چې تاسو مخکې باور لرئ هلته دي، او په سرور کې هغه نالوستونکي بهرني پاکټونه لري چې سرچینه یې دروازه ده. په هر انټرفیس کې بایټ شمېرونکي پاکټونه بیانوي، نه پروګرامونه؛ د ترافیک یوې پروسې ته منسوبول د هغه مانیټور اړتیا لري چې ساکټونه له پروسو سره نښلوي.
د بهرنۍ خدمت څخه وپوښتئ، بیا د هر اپلیکیشن لپاره بیا وپوښتئ
یوازینې کتنه چې وتل ثابتوي له باندې راغلی ځواب دی: هغه خدمت چې خپله لیدل شوې سرچینه پته بېرته راوړي. دا له شیل څخه چل کړئ، چېرې چې انټرفیس غوره کولی شئ، او دوه ځله یې چل کړئ:
sudo curl --interface tun0 https://example.net/ip
sudo curl --interface eth0 https://example.net/ipبېلابېل ځوابونه تاسو ته د دواړو لارو ثبوت او د یو ځانګړي اپلیکیشن د ازموینې لار درکوي: هغه وتړئ، یا یې په یوې لارې لرونکې شبکه نوم فضا کې چل کړئ، او وګورئ چې لرې پای کومه پته ثبتوي. ورته ځوابونه هغه په زړه پورې نیمګړتیا ده: یا تړل اغېز ونه کړ، یا د کوربه او لرې پای تر منځ څه د رسېدو دمخه سرچینه پته بیا لیکي. په Windows کې، curl --interface د اډاپټر نوم نه، پته غواړي.
هغه براوزر چې VPN پته راپور ورکوي هغه براوزر ثابتوي. د بریښنالیک کلاینټ، د پاکټ مدیر، د بیک اپ استازی یا دویم براوزر پروفایل هر یو بېله لاره نیولی شي، په ځانګړي ډول کله چې د پراکسي تنظیم یا د ویشل شوي تونل لاره یو له دوی پوښي. د پتې بدلون پخپله د لیک ثبوت نه دی: د بار متعادل کوونکی کولی شي د لیدل شوي وتلو له مخې بېل ځواب ورکړي، نو ثبت شوې سرچینه پته پرتله کړئ، نه پاڼه.
د پیر د تایید لپاره د سرور لید وکاروئ
سرور بلې پوښتنې ته ځواب وایي: ایا پیر نښلول شوی، څومره یې لېږدولی او ایا سیشن بیا پیل شو. هغه پیر چې په سرور کې فعال دی خو د کلاینټ شمېرونکي په سختۍ خوځېږي، مانا دا ده چې د اپلیکیشن ترافیک تونل ته نه ننوځي، هر څه چې د کلاینټ جدول وویل. او هغه پیر چې د هغه کاروونکي لپاره ډېر معلومات لېږدوي چې وایي هېڅ نه کار کوي، بله څېړنه ده.
دلته دوه تګلې دي. ماسک شوی تونل هر بهیر داسې ښیي لکه له دروازې راغلی، نو لاګونه او د هر کلاینټ حساب په یوه پته کې راټولیږي. او کلاینټ د سیمه ییز کوربه په توګه ګڼل کیږي، نو د دې پوښتنې چې څوک د VPN له لارې فایلونه کاپي کوي، ځواب د سرور په فایل شریکولو ترافیک یا د سرور په کوربه پلټنه ورکول کیږي — د تونل کتل پای ټکي او حجم درکوي، نه د فایل نومونه.
د ډیزاین پرېکړه له لیک څخه بېله کړئ
د تونل څخه بهر هر څه لیک نه دي. د تړاو سیمه ییز او خپرېدونکی ترافیک د ډیزاین له مخې سیمه ییز پاتې کیږي، هغه چاپېر چې د multicast له لارې موندل کیږي په LAN کې اعلان ته دوام ورکوي، او DHCP باید سیمه ییز ووځي. هغه اپلیکیشن چې ځانګړي انټرفیس ته تړل شوی په قصد سره د لارښوونې جدول ته ځان نه رسوي، او یوازې د اور وژنې قاعده، نوم فضا یا د پالیسۍ لاره هغه بدلوي.
IPv6 په چک لیست کې خپله جلا کرښه مستحق دی. هغه تونل چې یوازې IPv4 لېږدوي دوه ګوني سټیک کوربه ته بله کارېدونکې لاره پرېږدي، او دوه ګونی سټیک مقصد به هغه غوره کړي — DNS هم، که حل کوونکی د IPv6 له لارې د لاسرسي وړ وي. IPv4 پایله بشپړه ګڼلو دمخه په اډاپټر کې IPv6 بند کړئ یا تایید کړئ چې تونل هغه لېږدوي.
کله چې کتنې سره سمون نه خوري، ناسمون بیا معمولاً نیمګړتیا نوموي:
| What you see | What it means | Next step |
|---|---|---|
| The route picks tun0 but the capture shows cleartext to 10.20.5.7 | Something bypassed the table: a bound app, a policy route or a session older than the tunnel | Reset the flow, check the app bind, check the ip rule list |
| The route picks eth0 for an internal name | The name resolves to a public address, or the route was never installed | Compare the resolved address with the routes the server pushes |
| The capture shows DNS to the LAN resolver | Resolver leak: data is tunneled, lookups are not | Point the resolver inside, or push it from the server |
| All four checks agree and one app still fails | Path selection is fine; suspect MTU, a per-app proxy or the far end | Test the same destination from a known-good client |
هغه ترتیب چې کار کوي: د نښلېدو دمخه او وروسته د لارښوونې جدول وساتئ، یو داخلي او یو عام نوم تعقیب کړئ، په فزیکي اډاپټر باندې DNS ونیسئ، د ځانګړي اپلیکیشن لپاره له شیل وتلې پته بېرته راوړئ، بیا د حجم لپاره سرور ولولئ. که لومړني څلور سمون وخوري، تونل هغه څه لېږدوي چې تاسو فکر کوئ او پاتې ستونزه له هغې پورته ده. که دوه یې سمون ونه خوري، ناسمه جوړه پخپله نیمګړتیا ده، نه آیکون.