څنګه د VPN له لارې یوازې یوه شخصي فرعي شبکه وساتو

د تونل له لارې یوه شخصي فرعي شبکه او نور هر څه د خپل عادي مسیر له لارې تېرول یوه کوچنۍ غوښتنه ده، خو د غلطولو ډېرې لارې لري۔ پایله د split tunneling په نوم غونډه نه ټاکي، بلکې دا چې پرېکړه چېرې پلي کېږي: د کاروونکي په خپل مسیر جدول کې، په هغه لاره کې چې سرور یې تېل وهي، یا په هغه تګلاره کې چې دواړه خواوې پرې خبرې کوي۔ غلط پوړ وټاکئ، نو یا به هغه بشپړ تونل ترلاسه کړئ چې هېڅکله یې نه غوښت، یا به هغه تونل ته لاره ومومئ چې بله خوا یې منلو ته زړه نه ښه کوي۔ زه د هر تنظیم له پرانیستلو مخکې درې شرطیزه ازموینه کاروم، بیا لاندې میتودونو څخه یو ټاکم۔

درې شرطونه چې ډیزاین ټاکي

لومړی، تاسو ته د شبکې له مالک څخه دقیق مخکښ او ماسک ته اړتیا ده۔ 10.x شبکه مخکښ نه ده؛ 10.20.0.0/16 مخکښ دی۔ ډاډ ترلاسه کړئ چې دا ستاسو د کور LAN، Docker پول یا بل VPN سره چې تاسو یې چلوئ نه ورته کېږي، ځکه چې ورته کېدل لاره مبهمه کوي او کرنل هغه ننوتنه ټاکي چې ستاسو په نظر کې نه وه۔

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

دریم، د پلي کېدو ځای۔ ځینې کاروونکي لاره نصبوي او پاتې کار د عملیاتي سیستم وي۔ نورې تګلارې خبرې کوي، او هغه تګلاره چې دروازه یې نه مني هېڅ تونل نه جوړوي: بستې پرته له ښکاره تېروتنې غورځول کېږي۔ تر دې چې څه ولیکئ، معلومه کړئ چې له دې دوو کوم یو ستاسو دی۔

WireGuard: AllowedIPs هماغه د مسیر جدول دی

په کاروونکي کې، AllowedIPs هغه منزلونه لیستوي چې تونل ته د ننوتلو اجازه لري، او wg-quick هر ننوتنه عادي لاره جوړوي۔ نو د دې کار نیم کاروونکی یوازې یوه کرښه ده۔

[Peer]
PublicKey = ...
Endpoint = vpn.example.net:51820
AllowedIPs = 10.20.0.0/16

اوس د هماغه کاروونکي لپاره د سرور ننوتنه پرتله کړئ۔ هغه بیانوي چې سرور کاروونکي ته څه لېږي، او دا معمولاً د کاروونکي د تونل پته ده، نه شخصي فرعي شبکه۔

[Peer]
PublicKey = ...
AllowedIPs = 10.99.0.2/32

د دې دواړو بدلول هغه تېروتنه ده چې زه یې ډېره وینم۔ 10.20.0.0/16 د سرور د peer برخې لاندې ایښودل ښيي چې ټوله فرعي شبکه د هغه کاروونکي شاته ده، او دا د سایټ تر سایټ ادعا ده، نه اجازه۔ هغه بستې چې د هېڅ peer له AllowedIPs سره سمون نه لري په چوپتیا غورځول کېږي، نو غلطه ننوتنه په بشپړه توګه د اورمهال ستونزه ښکاري۔

که لارې پخپله اداره کوئ، Table = off د [Interface] لاندې وټاکئ او هغه لاره چې غواړئ زیاته کړئ۔ بیا هېڅ شی په اتوماتيک ډول نه زیاتېږي، نو لاره باید په هغه څه کې وي چې انټرفیس پورته راوړي۔

OpenVPN: لاره تېل وهي، بیا ډاډ ترلاسه کړئ چې رسېدلې ده

په عادي سرور کې بدلون په سرور ترتیباتو کې د کاروونکو د حوض ترڅنګ یو لارښود دی۔

push "route 10.20.0.0 255.255.0.0"

کاروونکی یې د نښلېدو پر مهال زیاتوي۔ د ناکامۍ طریقه هغه وخت ښکاري چې هماغه پروفایل redirect-gateway هم تېل وهي، یا کله چې یو چا دمخه route-nopull زیات کړی وي: لومړی ناسته بشپړ تونل کوي، او دویم هره تېل وهل شوې لاره غورځوي، ستاسو هم۔

کاروونکی چې د بشپړې تونل سرور په وړاندې تنګ چلند ته اړتیا لري باید یوازې هغه برخې له پامه وغورځوي چې نه یې غواړي۔ په OpenVPN 2.4 او وروسته کې، pull-filter سم د همدې لپاره دی۔

pull-filter ignore "redirect-gateway"
route 10.20.0.0 255.255.0.0

د پتې کورنۍ جلا وساتئ: تېل وهل شوې IPv4 لاره هغه داخلي خدمت لپاره چې IPv6 ته حل کېږي هېڅ نه کوي، او هغه خدمت د تونل له لارې ناکامېږي، پداسې حال کې چې نور هر څه سم ښکاري۔

کله چې شخصي فرعي شبکه په VPN سرور نه وي بلکې د بل کاروونکي شاته وي، سرور ته باید وویل شي۔ د client-config-dir له لارې د هر کاروونکي لپاره فایل زیات کړئ چې iroute 10.20.0.0 255.255.0.0 ولري، له هغه سره سمون لرونکی route هم، تر څو نور کاروونکي لاره زده کړي۔ پرته له iroute سرور هېڅ دلیل نه لري چې هغه مخکښ سم هماغه ځانګړي تونل له لارې ولېږي۔

IPsec: د ترافیک ټاکونکي باید سره سمون ولري

په IPsec کې د تېل وهلو لپاره لاره نشته۔ دواړه خواوې پرې خبرې کوي چې کومې پتې د تونل دننه دي، او د هوکړه شوو ټاکونکو څخه بهر ترافیک نه کوډ کېږي او نه د هغې له لارې لېږل کېږي۔ په strongSwan کاروونکي کې ټاکونکي ښکاره دي۔

leftsubnet=192.168.1.0/24
rightsubnet=10.20.0.0/16

که دروازه د دواړو خواوو په 0.0.0.0/0 سره تنظیم شوې وي، د IKEv2 تنګېدنه معمولاً ماشوم SA د دواړو وړاندیزونو پرېوتنې ته راکموي، چې هماغه غوښتل شوې پایله ده۔ ځینې دروازې پرځای یې هغه وړاندیز ردوي چې د دوی له تنظیم شوو ټاکونکو سره سمون نه لري، او لاګ بیا د لارې شکایت پرځای ناکام ماشوم SA ښيي۔ کله چې دا پېښ شي بدلون د دروازې دی، ځکه چې د کاروونکي لاره نشي کولای د هغه ټاکونکي لپاره تونل جوړ کړي چې بله خوا به یې نه مني۔

په Windows کې دننه شوی کاروونکی هماغه پرېکړه د دوو تنظیماتو شاته پټوي۔ د تونل وېش باید فعال وي، او مخکښ باید په پروفایل کې ثبت شي۔

Set-VpnConnection -Name Office -SplitTunneling $true
Add-VpnConnectionRoute -ConnectionName Office -DestinationPrefix 10.20.0.0/16

د مخکښ ثبتول هماغه څه دي چې د بیا نښلېدو وروسته یې ژوندي ساتي، کوم چې په لاس زیات شوې لاره نه کوي۔

پای ټکی او DNS د پرېکړې څخه بهر وساتئ

د VPN پای ټکی باید پرته له تونل هم د لاسرسي وړ پاتې شي، که نه تونل په خپل ځان کې پړکېږي۔ کله چې یوازې 10.20.0.0/16 لاره ورکول کېږي دا اتوماتيک دی، ځکه چې پای ټکی عامه پته ده۔ په بشپړ تونل پروفایل کې داسې نه ده، او کاروونکي ته د تونل له پورته کېدو مخکې پای ټکي ته ښکاره هوسټ لاره ته اړتیا ده۔

DNS دویمه پرېکړه ده چې د لارې تېل وهل ستاسو پرځای نه کوي۔ داخلي نومونه معمولاً د هغه حل کوونکي له لارې حل کېږي چې یوازې شخصي شبکه ورته رسېدلای شي۔ که سرور DNS سرور تېل وهي، هر نوم د هغې له لارې ځي؛ که ونه کړي، داخلي نومونه یا ناکامېږي یا په عامه توګه هغه څه ته حل کېږي چې ستاسو په نظر کې نه و۔ ووېشل شوی DNS په داخلي حل کوونکي کې یوه پلټنه ډومېن ساتي، خو دا د کاروونکي ملاتړ ته اړه لري، نو دا د لارې اړخیز اغېز نه بلکې جلا کار وګڼئ۔

وګورئ، بیا بیا پیل کړئ او بیا وګورئ

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

ip route get 10.20.5.7
curl -sS http://10.20.5.7/health
curl -sS https://ifconfig.me

لومړۍ کرښه یو انټرفیس نوموي۔ که ستاسو فزیکي انټرفیس ونوموي، لاره هېڅکله ونه رسېده۔ په Windows کې Find-NetRoute -RemoteIPAddress 10.20.5.7 هماغه پوښتنې ته ځواب وایي، او وروستې ازموینه باید لا هم ستاسو عادي پته وښيي، نه د VPN سرور۔

بیا بیا پیل کړئ۔ په لاس زیات شوې لارې ورکېږي، پداسې حال کې چې د پروفایل، تېل وهل شوې تنظیم یا AllowedIPs څخه راغلې لارې بېرته راځي۔ که تنګ لاسرسی د بیا پیل مخکې کار وکړ او وروسته ناکام شي، ګناه په لاره کې نه، بلکې په دې کې ده چې تونل څنګه پیلېږي۔

تر دې چې بشپړ یې وبولئ، څلور شیان تایید کړئ: مخکښ د شبکې له مالک څخه راغلی او له هېڅ ځایي شي سره نه ورته کېږي، د بېرته تګ لاره شته یا ماسک کولو قاعده یې ځای نیسي، هغه میتود چې تاسو تنظیم کړی هماغه دی چې ستاسو په پلیټفارم کې لاره پلي کوي، او له پاک بیا پیل وروسته هم هماغه ازموینې بریالۍ کېږي۔ د strongSwan د لېږد یادښتونه د لوستلو وړ دي که د بېرته تګ لاره هماغه برخه وي چې تل ناکامېږي۔