شنه آیکون، هماغه عامه IP: VPN کوم لاره پرېښوده

نښلول شوی، شنه آیکون، او د پتې ښودلو پاڼه لا هم د عرضه کوونکي پته ښیي، خو دا په خپله خرابي نه ده. کلاینټ دوه جلا کارونه کوي: تونل جوړوي، او د لارښوونې جدول سمون کوي. هر یو له بل پرته کېدای شي، او ټاکلې لارښوونه هغه ترتیبات دي چې پکې دویم په قصد پرېښل کېږي.

کلاینټ په رښتیا څه نصب کړل

د دې پرځای چې وپوښتئ تونل پورته دی که نه، وپوښتئ کومه برخه به بسته ریښتیني منزل ته ورسوي. هغه تونل چې دې منزل ته لاره نه لري، هغه خصوصي سړک دی چې هیڅوک پرې نه ځي.

ip route get 9.9.9.9
Find-NetRoute -RemoteIPAddress 9.9.9.9
route print -4

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

د ټاکلې لارښوونې درې بڼې

د بشپړ تونل پروفایل معمولاً د برخې په لور ډیفالټ لاره لیکي، یا د نیمې کرښې هغه مختګونه لیکي چې د مختګ اوږدوالي له مخې ګټي، په داسې حال کې چې اصلي ډیفالټ په جدول کې پاتې کېږي. ټاکلې لارښوونه بله غوره ده، او په څو بڼو راځي. یو پروفایل د RDP سرور په څېر یوازینی کوربه لارښوونې کوي، بل هغه عامه لمن چې له ځانګړي ځای څخه ورته رسېدل وي، او دریم یو اپلیکیشن په قصد بېلوي. درې واړه قانوني دي، او هیڅ یو یې هغه پته نه بدلوي چې یوه عادي وېبپاڼه یې ویني.

grep -nE "redirect-gateway|route-nopull|route " /etc/openvpn/client/*.conf
ip route show table main | head -20

د هغه لارښوونې لپاره چې پریکړه کوي پروفایل ولولئ، بیا د هغه څه لپاره چې تولید کړي جدول ولولئ. ټېل وهل شوې لارښوونه پر کلاینټ هم ځپل کېدای شي، نو د سرور تورنولو دمخه باید پروفایل او جدول سره سمون ولري.

بل اړخ باید د سرچینې پته بیا ولیکي

دویمه خرابي شته چې له براوزره هماغسې ښکاري. لاره تونل ته ځي، سرور بستې ترلاسه کوي او بیا یې د کلاینټ د خصوصي پتې سره نه بدلېدلې لېږي. بل ټوپ د هغې پتې لپاره د بېرته راتلو لاره نه لري، نو ځوابونه ورکېږي او پاڼې ځوړندې پاتې کېږي. سرور باید په هر حال ولېږي، او باید سرچینه په داسې څه وژباړي چې انټرنېټ یې بېرته لارښوونه کولی شي.

sysctl net.ipv4.ip_forward
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -t nat -S | grep MASQUERADE

هغه برخه ونومئ چې په رښتیا انټرنېټ ته مخامخ ده، چې په عصري وېش کې تل eth0 نه وي. ثابت پته لرونکی کوربه سرور کولی شي د masquerade پرځای په مستقیم ډول هغې پتې ته وژباړي. دواړه نیمې مهمې دي، ځکه بې ژباړې لېږل د لارښوونې وړ نه سرچینې تویوي، او بې لېږلو ژباړه بسته هېڅکله نه ویني.

د نومونو حل خپله لاره ځي

ترافیک کولی شي د تونل له لارې ووځي، په داسې حال کې چې هغه کتنه چې نوم یې وموند د ځایي شبکې حل کوونکي ته تللې وه. ښکاره پته هماغه پاتې کېږي، کتنې نه، او هماغه تشه د ووېشل شوي DNS ډیزاین غوره کوي.

resolvectl status | head -20
resolvectl query example.org

وګورئ کوم سرور ځواب ورکړ او ایا له تونل دمخه له اساس کرښې توپیر لري. په ووېشل شوي تونل کې دا معمولاً هغه تنظیم دی چې خلکو د پتې شکایت کولو پر مهال بدلول غوښتل، او هماغه دی چې هېڅکله یې نه دی کتلی.

څلور کتنې چې مسئله هواروي

د وتلو پته د تونل د بندېدو پر مهال ثبت کړئ، بیا د خلاصېدو پر مهال. په دواړو حالتونو کې د منزل کتنه ترسره کړئ او هر ځل برخه یادداشت کړئ.

curl -sS https://ifconfig.me/ip
ip route get 9.9.9.9

کله چې کتنه د تونل دننه ولګېږي او انعکاس لا هم د عرضه کوونکي پته ښیي، په وتلو کې ژباړه نشته. کله چې کتنه پر فزیکي اډاپټر ولګېږي، پروفایل ټاکل شوی دی او عامه پته هېڅکله په لوبه کې نه وه. هغه انعکاسي خدمت چې تاسو باور پرې لرئ پر ځای کړئ او څلور واړه کتنې یو ځای ولیکئ، ځکه جلا جلا هغه کیسې دي. یو ځای هغه ښیي چې کلاینټ د دوو کارونو کوم یو په رښتیا ترسره کړ.